PENETRATION TESTING OF AUTOMOTIVE DEVICES Dr. Ákos Csilling Robert Bosch Kft., Budapest HUSTEF 15/11/2017
Imagine your dream car 2
Image: 2017 ESCRYPT. Exemplary attack demonstration only. This is NOT a real attack/vulnerability! 3
Is this realistic? Even reputable IT companies are vulnerable to cyber attacks. Car hacking has also been widely reported in the media. Individual tools are easily available: Ransomware kit Botnet distribution In-vehicle exploit Online/offline infection (infotainment) Spread to reach engine control Engine lock command Diagnostic services Anonymous payment collection Unlock optional Image from Wikimedia, 2017 Christiaan Colen, licensed under cc-by-sa-2.0. 4
The car as a rolling computer centre Originally, cars were designed as closed systems. Cyber-security was not an issue. Many different! electronic control units (ECUs) on an inhomogeneous network. Strong cost incentive smallest possible controller, least possible memory, no complex calculations. Start up in seconds, reaction time is often critical, many real-time constraints. External connectivity (Infotainment, SW updates, emergency calls, v2x smart services, IoT back-end). CANbus designed for a closed environment, no inherent protection. Automotive Ethernet designed as an open environment, no inherent protection. Physically accessible Almost open access while parked. Third-party repair shops need diagnostic and repair access. Uncontrolled spare parts may be installed. Side-channel attacks on legitimate HW. Human factor: the owner may willingly or not compromise security. From an enterprise security point of view, pretty difficult! 5
Vehicle network vulnerability Wireless external connectivity (GSM, WiFi, Bluetooth) Connect to an IoT backend for smart services (parking, traffic info) Connect to smart infrastructure and other vehicles (v2x) Connect to user devices CANbus most common vehicle network Shared bus among many devices No source ID Simple priority arbitration based on message ID Easy to fake any message Accessible via On-Board Diagnostic (OBD) port 6
Proof of concept demo 7 Image: 2017 ESCRYPT.
Life-cycle risks Development (supply chain!) Bugs Unsecure features Information leaks Manufacturing (supply chain!) Key management Configuration control Maintenance (independent garages, spare parts) Access control to diagnostics functions (vs. antitrust regulations) Firmware update over the air (FOTA) Min. 15 years aftermarket parts availability Cloud-based connected services Very useful, but security and privacy must be guaranteed! 8
How to protect our cars? Learn from functional safety in the automotive industry Strict development process, requirement and test traceability, failure modes and effects analysis (FMEA) Coding rules, static analysis, test coverage Learn from classical enterprise and network security Cryptography, secure protocols, threat and risk analysis Coding rules, grey-box analysis, penetration testing Apply best practices at all levels Legal framework Organizational measures State of the art technology Healthy paranoia 9
Protection at all levels! Legal framework Define responsibility Define authority Define standards Technical aspects Use state of the art technology Domain-based vehicle architecture @ Hardware security module Back-end infrastructure and services Defensive design, secure coding Penetration testing and analysis Fast SW release and remote update capability Organizational aspects $ Clarify incentives Train people Security engineering process Risk and threat analysis Manage product lifecycle Security management In-field monitoring 10
Domain-based architecture Each domain has a separate controller Domain controllers isolate critical functions Central gateway connects the various domains controls external connectivity, diagnostics port implements firewall manages virtual networks (VLAN) Automotive Ethernet used between domains Point-to-point connections, managed switches Hardware security module (HSM) enables sophisticated security features 11
Our experience getting started Goal: build up security testing and analysis experience from zero Situation: existing conformance testing capability Action: try port scan on automotive Linux dev kit (GENIVI on Raspberry Pi) Results: Open ports: ssh + Diagnostic Log and Trace (DLT) DLT: Debug info leak + diagnostic commands accepted Conclusion: This is normal during development No real functionality no real attack surface The production configuration must be verified! Long way to go! Next step: Test actual products in development 12
Conclusions Hacking vehicles is a real threat Protection is not easy! Legislation is in progress Secure technology is available Using it correctly is challenging Organizational challenge Expect a constant battle! 13