CSE 914

1. CSE 914 Defending Connected Vehicles Against Malware Challenges and a Solution Framework Authors: Tao Zhang, Helder Antunes, and Siddhartha Aggarwal Presenter: Pranshu Bajpai (@amirootyet)

2. 01 #whoami

3. #whoami PhD candidate at Michigan State University Security Researcher at SRG, MSU Previously worked as an independent penetration tester Active speaker at security conferences: DEFCON, GrrCon, ToorCon, BSides, APWG eCrime, CascadiaJS and others https://twitter.com/amirootyet https://www.linkedin.com/in/pranshubajpai http://www.cse.msu.edu/~bajpaipr/

4. 02 Malware

5. Terminology Virus Worm Trojan horse Spyware Ransomware Rootkit Backdoor “Malware needs execution privileges”

6. A Key-Management-Based Taxonomy for Ransomware – Pranshu Bajpai, Aditya K Sood, Richard Enbody [1] https://ieeexplore.ieee.org/document/8376213/

7. Polymorphic versus Metamorphic Polymorphic “...constant malicious code body together with the necessary information to decrypt and encrypt this code body...the code body is decrypted and then encrypted again so the new generation of malware will look different from the previous one.”

8. Polymorphic versus Metamorphic Metamorphic “...uses code evolution techniques to transform into a new look without any constant part each time it replicates.”

9. Attack Vectors Downloaded files Removable media Email attachments “The higher access privileges a malware gets, the more damage it will be able to cause.” [2]

10. 03 Malware and Connected Vehicles

11. Potential infection vectors for vehicles Vulnerabilities in the design and implementation of hardware and software Drive-by downloads Vulnerabilities (injections) in external data such as software package Vulnerabilities in the OS

12. Onboard diagnostics ports Access to vehicle’s internal networks Installing malware on ECUs is straightforward Diagnostics tools can be infection with malware Right-to-repair law indicates anyone can update ECU firmware Difficult to control the source and contents of firmware update package

13. OTA Firmware and software updates Vehicles have over a 100 million lines of software code Updates needed! Opportunity for malware to infect from remote sources

14. Embedded web browsers Users can now download media content and applications Installing software from untrustworthy sources

15. Aftermarket equipment Used to replace factory installed equipment Windows, Linux, or Android-based devices Modified to have backdoors and other malware

16. Removable Media Ports USB ports Allows IVI systems to access music files Also used to update ECU firmware • Use specific name for malware to trick embedded system into executing it • Malware can be added to music files (WMA file attack) Cross-system functionality allows malware to propagate to other components

17. Linux and Malware Repos owned and operated by trusted distributors Different level of access privileges. Example: root, regular, guests Large number of Linux distros currently in use Linux is open source

18. Linux is NOT immune to malware.Neither is Mac OS!

19. Linux-on-vehicles and Malware Open OBD port allows anyone to update firmware on ECUs • Update packages do not come from trusted repos Common Linux distribution among many vehicle models (GENIVI) • Easier for malware to spread on a common platform Regular user privileges are sufficient for malware on vehicles • No root privileges needed Successful malware attack on vehicles will have significantly more severe consequences

20. Motivation for Malware Developers Harm People & Property Breach Driver Privacy Theft Ransom! Sabotage Disrupt Transportation Fun and Publicity

21. 04 Existing Approaches to Vehicle Security And Limitations

22. Physical Network Separation Physically separated networks used to isolate electronic subsystems Issue: need to communicate with each other and external networks for advanced vehicle functions Power Train Vehicle Safety ADAS Body Control IVI Systems

23. Message Obfuscation Proprietary messages for ECUs used by automakers Known only to authorized parties These are known to be easy to decode [3]

24. Predefined Messages Many ECUs accept only predefined messages Gateways will relay only predefined messages Hardcoded in firmware Reduces malware, but limits ability to communicate Cannot be used for user application traffic containing arbitrary data Security Functionality Usability

25. Limited Applications, Application Features, UI Inadequate security leads to limited applications and features Example: web browsers do not allow content downloading or video streaming

26. Control of Applications and Content Application-specific authentication is required before firmware update of ECU Rudimentary challenge-response procedures Easy to crack Only accept cryptographically signed updates Increasing number of malware are signed with legitimate signatures and digital certificates

27. Network-Specific Security Protocols Ethernet introduced in vehicles MACsec could be used to deliver hop-by-hop security MACsec supports data integrity, data origin authentication, data confidentiality, replay protection using symmetric-key algorithms Only applies to Ethernet • What about non-Ethernet networks? Requires neighbor discovery protocols for authentication devices and for security keying materials • Overly complex and costly for vehicular resources

28. Application-Specific Security Protocols IEEE 1609.2 supports authentication of vehicle safety messages over DSRC radios Could be used for internal network but requires support for public key crypto for digital signatures and certificates PKI that supplies digital certificates to hundreds of millions of vehicles in the US!

29. 05 Unique Challenges in Defending Vehicles Against Malware

30. Unique Challenges Limited processing, memory, communication capabilities Average age of passengers vehicles was 11.4 years in 2013 [4] Vehicle’s onboard resources are difficult to change after initial release Ensure minimal inconvenience to owners with minimal intervention Onboard malware defense system cannot practically rely on itself to keep up-to-date

31. Unique Challenges Balancing malware defense processing load versus vehicle-to-cloud communication Not all threat intel from vehicles can be trusted (false data injection) Determine which malware are relevant to vehicles and trigger updates accordingly Any malware defense system should be highly scalable

32. 06 Existing Malware Defense Mechanisms And Their Limitations When Applied to Connected Vehicles

33. Signature-Based Malware Detection Identify new malware and create signature End points retrieve malware signatures Most widely used Simpler and safer Requires less processing power

34. IOC • Symptoms of RAA infection • Indicators of Compromise • Hashes (unique checksums of malware files) • Dropped files (files created during malware execution) • Network activity (network activity pertaining to the malware)

35. Limitations of Signature-based Detection Prohibitively large malware signature database for resource constrained vehicles Typical malware database contains over a million malware signatures 100s of MBs Impractical to install on each vehicle Over 11.4 years of lifetime means database becomes too large to maintain onboard Additional storage capacity needed Amount of processing power needed to scan against this massive database also increases

36. Limitations of Signature-based Detection Cloud malware analysis functions cannot trust vehicles sending data to detect new malware False information feed can be kept in check with trust levels based on prior reputation Need a methodology for determining which malware is relevant to vehicles

37. Limitations of Signature-based Detection Signature-based detection is ineffective for metamorphic malware Signatures cannot detect zero days Signature databases need frequent updates Scanning incoming traffic and downloaded files against large database has high processing cost

38. Behavior and Heuristic-Based Detection Behavior-based: observe what the malware does during execution Heuristic-based: examine programs for suspicious activity • Rule based • Data mining • Machine learning Allows the vehicle to rely on itself (cloud not needed) Can detect zero days and metamorphic malware High false positive and false negative rates Complex and resource intensive Will likely become obsolete before vehicle’s lifespan ends

39. 07 Cloud-Assisted Vehicle Malware Defense Framework

40. “…impractical to rely solely on each individual vehicle. Cloud services can help defend resource constrained devices against malware.”

41. Architecture Overview and Principles

42. Role of the Security Cloud Examine received files for malware Collect and analyze threat-related intel from vehicles Scan network traffic (V2I) Update onboard malware defense Support OTA malware removal

43. Role of the Security Cloud

44. Role of the Security Cloud Proactively collect malware samples to detect new malware early Passive versus active malware collection

45. Communication Load and Delay Requires balancing of several factors: • Malware detection techniques used on vehicles (not specified in framework) • Amount and content of malware related information • Files to be sent to the cloud • Manner of file identification and representation Adjust dynamically • Most popular and most damaging malware

46. Onboard Malware Defense Functions & Architecture

47. Onboard Malware Defense Functions & Architecture Detects malware on security gateway and prevents execution Detects and blocks malware traffic on security gateway Detects suspicious activities that indicate a security risk Triggers an automatic scan for unauthorized files Scanning for nonexecutable files is lesser priority Executables can be digitally signed and allowed to execute • Further scan file for malware to debilitate signed malware

48. Onboard Malware Defense Procedure

49. 08 Discussions

50. Discussions Which in-vehicle system should implement the onboard threat detection? Does all external traffic pass through this gateway? How do we handle the delays and processing needs? Is the gateway alone able to detect all malware? How to minimize communication overhead and delays incurred by using cloud security?