Hardening Attack Vectors to cars by Fuzzing

Transcription

1 Hardening Attack Vectors to cars by Fuzzing AESIN 2015 Ashley Benn, Regional Sales manager 29 th October, Synopsys, Inc. 1

2 Today, there are more than 100m lines of code in cars 2015 Synopsys, Inc. 2

3 CAR > 100 million lines of software code Cars are Software products, not only hardware anymore! Source : Prime Research 2015 Synopsys, Inc. 3

4 What does software control in these cars? Almost anything we want: Brakes FCW (forward collision warning) assisted braking, ABS to make the car stop better, Traction Control to handle better. Steering LDW (lane departure warning) and Park Assist Lidar yes, cars these days have collision prevention systems that detect other cars or objects and how fast they move Engine controls make the car explode fuel in the cylinders Throttle ACC (adaptive cruise control) make the car go! Network connectivity Mothership activities On-Star, Automatic accident notification - ecall 2015 Synopsys, Inc. 4

5 Software, computers and vehicle infrastructure Not just the vehicles Infrastructure to facilitate cooperating autonomous systems Connected cars in Smart Cities Driverless/autonomous cars will require roadside infrastructure that will communicate with vehicles to inform them of congestion, roadworks, etc 2015 Synopsys, Inc. 5

6 90% of all reported security incidents result from exploits against defects in software

7 Known vs unknown vulnerabilities Known Vulnerabilities: disclosed to the software vendor and/or security community, fixes or patches are available. ~70,000 unique Known Vulnerabilities (CVEs) Known vulnerabilities databases (NVD) Software with known vulnerabilities can be fixed/patched immediately Unknown Vulnerabilities: have not been disclosed to the software vendor and/or security community, do NOT have existing fixes or software patches available. Impossible to know how many unknown vulnerabilities exist You can t fix a problem you re not aware of 2015 Synopsys, Inc. 7

8 2015 Synopsys, Inc. 8 debugging today

9 Software/Security Development Life Cycle (SDLC) Requirements Design Implementation Testing Production Business requirements Quality gates Security and privacy risk assessment Project planning Budget and delivery Design requirements UX design Attack surface analysis Architecture Testing plan Unit testing Static code analysis (SAST) Software Composition Analysis (SCA) Architectural enforcement Open Source compliance Functional testing Protocol fuzzing Security review Interactive Application Security Testing (IAST) Security web dynamic testing (DAST) Application Performance Management Runtime Application Self Protection (RASP) Test management 2015 Synopsys, Inc. 9

10 Software Composition Analysis Manage your software Supply Chain 2015 Synopsys, Inc. 10

11 Today, Up to 90% of an Average Software Package Consists of Third-Party Code Builders and Buyers of Software Falsely Assume Security is an Upstream Responsibility, Bearing the Risk of an Unchecked Cyber Supply Chain Third-Party Code (Commercial Off-The- Shelf) First-Party Custom Code Third-Party Code (Free Open Source Software) 2015 Synopsys, Inc. 11

12 Test for Known Vulnerabilities in Third Party Software With more connectivity and interfaces, automobiles are increasingly exposed to third party software like never before. CAR INFOTAINMENT 35 3 rd -Party SW Components CAR INFOTAINMENT 1,174 CVEs affecting 17 Components 2015 Synopsys, Inc. 12

13 Dynamic Fuzz Testing Manage the infinite space of Unknown Vulnerabilities 2015 Synopsys, Inc. 13

14 What is Fuzz Testing Fuzzing is the process of sending intentionally invalid data to a product in the hopes of triggering an error condition or fault. These error conditions can lead to exploitable vulnerabilities. HD Moore 2015 Synopsys, Inc. 14

15 How is Software Fuzzed? ORGANIC: Invalid inputs sent unintentionally over time. Resulting vulnerabilities are a robustness or quality concern MALICIOUS: Hackers methodically searching for vulnerabilities that can be exploited. Resulting vulnerabilities are a security concern. PROACTIVE: Software builders and buyers who want to detect and remediate vulnerabilities before they are exploited. Mitigate risk by improving the quality and security of the software you build or buy. Fuzzing is the #1 technique used by black hat hackers and security researchers to discover new vulnerabilities Synopsys, Inc. 15

16 More About Fuzz Testing In fuzzing, there are typical invalid input types used to trigger common failure modes. Typical inputs: Boundaries conditions Illegal values Tough strings Good checksums on bad data Session awareness Failure modes: CrashDownload Busy loop Resource Leakage Other anomalous behaviors 2015 Synopsys, Inc. 16

17 Fuzzing No source code required good for buyers and builders Dynamic testing for locating unknown vulnerabilities Fuzzing technique makes a big difference The more legitimate the fuzzer can look, the better Focuses on exposed attack surface The oracle challenge What is failure? How can your fuzzer detect failure? Simple: valid messaging to verify external interface Better: target instrumentation, like valgrind, Asan, etc. Add behavior analysis: how Heartbleed was found DAST: Dynamic Application Software Testing 2015 Synopsys, Inc. 17

18 Fuzz testing is an excellent way to discover unknown vulnerabilities and prevent zero-day attacks Fuzz testing as part of the SDLC 2015 Synopsys, Inc. 18

19 Programmers write software code Developers write source code Multiple teams, perhaps Pull in third party components (More developers) Build finished product 2015 Synopsys, Inc. 19

20 Programmers make mistakes Developers are mortal Third party developers are also mortal 2015 Synopsys, Inc. 20

21 Static Analysis Finds bugs in source code Developers fix bugs Static Analysis 2015 Synopsys, Inc. 21

22 Software Composition Analysis SCA Finds third party components Lists known vulnerabilities Update or patch components Static Analysis 2015 Synopsys, Inc. 22

23 Fuzzing SCA Dynamic fuzz testing Find unknown vulnerabilities Fix more bugs Static Analysis Fuzzing 2015 Synopsys, Inc. 23

24 You Never Get All the Way There SCA There are always more bugs Fewer bugs == lower risk Quantitative & Traceable Static Analysis Fuzzing 2015 Synopsys, Inc. 24

25 What if You Didn t Write the Software? What are you getting? Trust, but verify SCA still works here Fuzzing still works here Fix by negotiating Apply pressure before buying SCA Or exploit! Fuzzing 2015 Synopsys, Inc. 25

26 Attack surfaces and exploit scenario 2015 Synopsys, Inc. 26

27 How do hackers exploit vulnerabilities in these attack surfaces? Well its NOT like in the films the hacker doesn t sit at a keyboard for 5 minutes then declare Yes I m in! 2015 Synopsys, Inc. 27

28 The reality is months/years of laborious effort Identifying individual vulnerabilities Then piecing together the elaborate jigsaw Head-unit RTOS vulnerability Media player audio file processing vulnerability Bluetooth configuration interface vulnerability SPI (serial periphery interface) bus vulnerability Diagnostic (pass through) device vulnerability OBD-II 2015 Synopsys, Inc. 28

29 But the end results can be very dramatic! More Connected, Less Secure. There is no safety without security! 2015 Synopsys, Inc. 29

30 Conclusion To mitigate risk of automotive cyber-security incidents Test your software and your software supply chain with Static Analysis, Software Composition Analysis and Fuzzing 2015 Synopsys, Inc. 30

31 2015 Synopsys, Inc. 31