CONNECTED CAR SECURITY THREAT ANALYSIS AND RECOMMENDATIONS

Transcription

1 CONNECTED CAR SECURITY THREAT ANALYSIS AND RECOMMENDATIONS Version: 1.00 Author: Sławomir Jasek SecuRing Date: This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

2 This document was originally created by the SecuRing team. Current version will be available at SecuRing web page. If you have any comments, change requests, want to provide feedback or help with future versions of this document, please don t hesitate to contact me at slawomir.jasek@securing.pl Sławomir Jasek - 2 -

3 CONTENTS 1. Introduction Attack vectors and threat agents Telematics connection SMS API Cloud : web interfaces, mobile APIs, data collection Mobile applications Infotainment Firmware upgrades (OTA, USB, Bluetooth, mobile app...) Wireless interfaces (Wi-Fi, Bluetooth) External sensors Wireless key entry External devices connected via OBD Vehicle-to-vehicle, autonomous etc References

4 1. INTRODUCTION A contemporary car is composed of at least a dozen electronic control units, connected via several dedicated buses, and exchanging thousands of messages processed in real-time. As more and more of crucial car functionality is managed by software rather than hardware, the complexity of software grows exponentially. Unfortunately, this often leads to vulnerabilities, especially as testing all possible attack scenarios before shipment is in fact beyond reach. Additionally, the current trend of development areas in infotainment, smartphone link, telematics, diagnostics and autonomous car implicates dynamic progress of car's components integration with external systems and applications. This exposes cars to serious, until now inapplicable threats. Adding the fact that cars are a very attractive target of malicious attacks, security implications are inevitable. Patching process of car's firmware for security vulnerabilities revealed after releasing millions of units may be very difficult and expensive (not to mention damage to reputation). That is why it is so important to implement security mechanisms correctly from the beginning, starting in the design phase. In this article we will try to categorize and describe most notable threat agents to contemporary car systems, sample attack scenarios, publicly disclosed vulnerabilities, and some recommendations for countermeasures which should be taken into consideration during development

5 2. ATTACK VECTORS AND THREAT AGENTS The most significant attack vectors are pictured below: Threat agents and their main goals: Thief - a thief who wants to steal the car, or just open it and steal its contents. Proximity intruder - an intruder who is in a short, limited range from the car or the owner. Owned mobile device - an intruder who takes over mobile device (malware, temporal access, stealing,...) Malicious media - a malicious media, data, files... Attacker from internet - anonymous attacker from the Internet. Spying attempts - an individual attempting to spy on a user (e.g. his location or driving habits). Hostile intents - an adversary with hostile intents - for example to cause an accident, scare the user etc

6 2.1. Telematics connection Threat agents: Thief Proximity intruder Attacker from internet Spying attempt Attack scenarios: The most obvious attack scenario applies to intercepting telematics traffic. The assumption that GSM or satellite communication medium is difficult to intercept is not up-to-date in face of current availability and possibility to create a GSM intercepting device (IMSI catcher). In the simplest form the attack would consist in passive sniffing of unencrypted traffic, but with above-mentioned hardware it is also possible to actively intercept the connection. Such scenario would allow to mount so called Man-in-the-Middle attack, which may abuse improper authentication and encryption in order to inject malicious commands into traffic. Less obvious attacks include direct connection to exposed services - adversary acting at remote IP connection could directly attack excessive services available on IP address of telematic unit from external network. Examples of publicly known attacks: As it has been disclosed in [5] the GSM transmission of telematics unit was not properly secured, and in effect it was possible to take remote control over the car. The issue affected - 6 -

7 about 2.2 millions of cars. Excessive service available on IP address of telematic unit from external network has been abused to remotely attack cars, as described in [1]. It was possible to connect to vulnerable service on a dedicated TCP port from the same GSM operator's network. The issue affected about 1.4 million cars. Recommendations: Data transmission between car and backend servers should be properly encrypted. Both sides of the transmission should authenticate each other. The IP address of telematics unit should not disclose any external services

8 2.2. SMS API Threat agents: Thief Proximity intruder Atacker from internet Spying attempts Attack scenarios: Several systems implement SMS commands - for example during turned off engine, initialization, or network connection problems. It should be taken into consideration, that SMS can be intercepted and spoofed, e.g. using similar techniques as described above ("IMSI catcher"). Therefore SMS whitelisting is not enough to perform remote authentication. The telephone number associated with the SIM card also cannot be regarded confidential, as well as the SMS command format (e.g. possible to sniff, reverse firmware). An attacker may try to send specially crafted text messages directly to the device. Examples of publicly known attacks: In [8] researchers proved, that by sending carefully crafted SMS messages to one of external devices connected to the dashboard of a car, they were able to transmit commands to the car s CAN bus, for example to enable or disable its brakes

9 Recommendations: Remote SMS administration should use an additional form of authentication (and preferably also encryption) on top of SMS. Given the difficulty of properly securing communication in this medium, it should be considered to disable administrative commands available via SMS API

10 2.3. Cloud : web interfaces, mobile APIs, data collection Threat agents: Attacker from internet Spying attempts Hostile intents Thief Attack scenarios: Some telematics systems allow to be monitored via a dedicated web interface. An attacker may try to create account associated with particular car only by knowledge of VIN number (which should not be considered confidential), or somehow abuse the pairing process. External web interfaces or mobile APIs are affected by problems typical to web applications, known for many years but unfortunately still captured in the wild even in risk-critical applications. For example access control, brute-force, malicious injection, server-side misconfiguration, unpatched software etc. The data collected by telematics system is a profitable target, and in order to attack it an intruder may utilize sophisticated, targeted methods against internal staff workstations. Examples of publicly known attacks: At the time of writing this article there are no publicly known attacks on remote car "backend interfaces. But there are publicly known hundreds of examples of successful attacks on similar interfaces in risk-critical applications - e.g. in internet banking. Recommendations: The secure software development practices should be implemented, and enforced especially during development of publicly exposed services (e.g. web application, mobile API). This applies to all phases of development and includes proper threat modeling, secure design and external assessment. The backend system, administrative access and supporting infrastructure should be properly secured. According to least privilege principle (as well as existing and forthcoming regulations), the system should not collect or process excessive data, overwrite or anonymize historical ones

11 2.4. Mobile applications Threat agents: Owned mobile device Proximity intruder Spying attempts Malicious media Attack scenarios: The main two groups of mobile apps, with different risk applied are infotainment and remote control applications. Infotainment applications The majority of infotainment (e.g. social media, music streaming, phone sync) mobile applications are by design connected only to "infotainment unit" - radio/navigation/display, which often hosts additionally its own native applications. The risk involved may be overlooked - an intruder's goal may be simply to scare the driver and cause an accident, or just spy on him. Taking remote control over the car's radio (e.g. via vulnerable mobile application) may be more than enough for such purpose. Besides, the assumption that this unit is separated from car's control bus (and thus it is not possible to take control over the car) is not always true [see also below]

12 Remote control applications Development of applications, which allow to remotely control the car, should enforce strict secure coding requirements. The risk involved may be even higher than e.g. in mobile banking application, yet these applications are not developed with equal care. We have examined most basic security aspects of several applications from different vendors, and the conclusions are not optimistic. For example, most of tested "remote car" applications does not obfuscate the code, and can be easily decompiled. The "Lack of Binary Protections" is included in OWASP Mobile Top 10 list. Of course the security mechanisms should not depend only on the obfuscation, but the lack of it makes it much easier to analyze the application, what may help to conduct further attacks and it is generally considered as bad practice. Another concern is that no single examined application utilizes certificate-pinning, which raises the bar for attacks on SSL transmission, and is de-facto standard in high-risk (e.g. banking) applications. The most risky elements of applications (e.g. access control mechanisms on the server-side API) could not be examined without pairing with existing car. Sample attacks on mobile users include intercepting transmission between mobile application and server (abusing improper transmission protections), malware on the device (e.g. hostile application), temporary access to device or stealing, social engineering. The possibility to take control over the car's infotainment unit may be further abused to escalate the attack and get access to car s internal bus. Examples of publicly known attacks: As it recently turned out [6], the ios application of a tracking device did not verify SSL certificates properly, and it was possible to conduct "Man-in-the-middle" attack on the connection, thus taking over control of the car. Recommendations: Secure coding principles for mobile applications include implementing proper transmission encryption, avoiding of sensitive information storage on a device, and properly designing authentication

13 2.5. Infotainment Threat agents: Owned mobile device Hostile intents Proximity intruder Malicious media Attacker from internet Spying attempts Attack scenarios: Nowadays it is difficult to imagine infotainment unit completely disconnected from other car's components. The connection is required even for simple features like automatic radio volume adjustment based on current speed, not to mention more advanced applications like diagnostic information. The assumption that infotainment or diagnostics are physically separated from car's control bus (and thus it is not possible to take control over the car) is often not true. The so-called "galvanic" separation often happens to be partly in software, in a form of a microcontroller filtering allowed commands and communication directions. As it has been demonstrated in [1], the separation may be bypassed by reflashing the controller, and an intruder may gain access to internal bus for example via car's radio unit. The sample attacks on infotainment unit depend on its functionality, and may include hostile internal/mobile application (see also Mobile application 2.4), improper data improper data or access control in various components and inputs (navigation, external services, USB, radio RDS data, audio/video file...). The attack may be also mounted against used software and hardware

14 components e.g. additional services like UPNP, hotspot captive portal, embedded Wi-Fi or Bluetooth (see also Wireless - 2.7). Examples of publicly known attacks: The researchers created malicious audio, which played on the car's stereo could alter the firmware of the device, giving attackers an entry point to change other components on the car [9]. As shown in [1], it was relatively simple to gain administrative access to the infotainment unit, what was further abused to take control over internal bus. Recommendations: All external data should be treated as potentially hostile: properly validated and normalized. In design there should be implemented multi-layer protections, least privilege principle and separation of processes. The used software components should be developed in compliance with secure coding guidelines, and enable quick and secure upgrade in case of disclosure of a known vulnerability

15 2.6. Firmware upgrades (OTA, USB, Bluetooth, mobile app...) Threat agents: Owned mobile device Proximity intruder Malicious media Attack scenarios: The firmware image delivered by various media (OTA, USB, Bluetooth, mobile app ) may be intercepted and decrypted. The attacker may reverse engineer the firmware contents, what allows to understand internal device operation and may reveal stored secrets (e.g. keys, commands). In a more sophisticated scenario, an attacker may tamper the firmware image, and use it to upgrade the car s component microcontroller to change its operation. Examples of publicly known attacks: As it was proved in [1], the integrity of image was not properly validated, and it was possible to upgrade tampered one, in effect compromising security of the microcontroller. Recommendations: The security mechanisms should not rely on secrets stored in firmware (aka "snake oil security"). The firmware file image encryption is recommended security mechanism, but will not prevent skilled attacker from decrypting the image (e.g. by reverse-engineering the key from car's unit), but may slow down an adversary with analyzing the code. During upgrade, special care should be taken into proper verification of image integrity proper cryptographic sign of all the image contents

16 2.7. Wireless interfaces (Wi-Fi, Bluetooth) Threat agents: Connected Car SecurityThreat Analysis and Recommendations Owned mobile device Proximity intruder Attack scenarios: The risk involved with attacks on local wireless connections is smaller than remote attacks - because it does require physical nearness. However, an attacker could install small unit acting as a proxy between local wireless interfaces and remote adversary. We should also take into consideration, that the thief would need to get to the car eventually, so any local vulnerability that helps to unlock the car should be considered critical. Wi-Fi hotspot An excessive service available on the Wi-Fi router may be attacked, in effect giving administrative access to unit. Additional impact on risk is put by the fact that Wi-Fi access password could be broken, and the attack could be conducted by external intruder, which aim will not be just to use the free Wi-Fi connection. Similar attacks may be conducted on used software components, like captive portal, proxy etc. - for example using known vulnerabilities. Various embedded operating systems (including Linux) have history of flaws in Wi-Fi device drivers, what in some cases may allow for remote command execution

17 Bluetooth The Bluetooth stack implementation may have vulnerabilities which can be abused to attack the car. The new Bluetooth Low Energy adoption may increase the security problems, as this technology is more difficult to secure properly. Examples of publicly known attacks: An excessive service available on the Wi-Fi router was attacked as in [1], in effect giving administrative shell access to internal unit's functions. The weakness in Wi-Fi access password allowed to conduct the attack by external intruder. As it has been demonstrated in [3], the Bluetooth stack implementation may have vulnerabilities which can be abused to attack the car. Recommendations: The wireless interfaces should use verified and stable firmware and drivers, and utilize industrystandard security mechanisms (authentication, pairing and encryption). According to least privilege principle, excessive services should not be exposed on the hotspot's internal IP

18 2.8. External sensors Threat agents: Proximity intruder Attack scenarios: More and more of the car's functionalities are based on various external sensors. External sensors may be spoofed and the car systems may take improper decisions based on the data. Also there are possible flaws in parsing of external data, which in some cases may allow to take control over the receiving component. The more of the car's functionality is based on sensors (e.g. autonomous car), the bigger the risk. Examples of publicly known attacks: As it has been demonstrated in [10], external sensors may be spoofed and the car systems may take improper decisions based on the incorrect data. Recommendations: The authenticity of data from external sensors should be carefully verified. The integrity of data

19 2.9. Wireless key entry Threat agents: Proximity intruder Thief Attack scenarios: The wireless key entry has been abused for several years by thieves via a very simple trick - a wireless amplifier. The thief standing by car directs antenna to the key (located for example inside the house), and creates "wireless bridge". The car receives amplified key signal, and opens the door automatically. It is abused especially by thieves stealing contents of the car (not the car itself). But the security mechanisms in wireless keys also have serious implementation problems, as has been demonstrated by several researchers [7]. The fact that the vendor delayed this publication by a court order did not resolve it. Examples of publicly known attacks: The weaknesses of a wireless key entry solution have been demonstrated by several researchers in [7]. The fact that the vendor delayed this publication by a court order did not resolve the actual problem. Recommendations: It takes a team of talented cryptographers and long independent review procedure to design completely new, solid cryptographic algorithm. It is recommended rather to use verified algorithms in a secure configuration: proper initialization, secure random, algorithm combination, key length and parameters. The wireless amplification attack may be circumvented by additional measures like second factor confirmation

20 2.10. External devices connected via OBD Threat agents: Proximity intruder Spying attempts Attacker from internet Owned mobile device Hostile intents Attack scenarios: On-board Diagnostic interface is mandatory for almost 20 years, and is present in all current vehicles. It provides information on engine, fuel consumption, battery level etc. By design it is connected to the diagnostic bus, but in many car models diagnostic bus is not separated from other buses. Vendors often also allow to reconfigure several internal functions of the car by proprietary software connected to interface, which authenticates itself using special keyed commands. The security of the process is usually based on the confidentiality of the keys and commands, which will leak eventually. As has been shown in [4], it is relatively easy to reveal the keys by reversing diagnostic software or brute-force. For example, the unauthorized services of "chip tuning" the engine or meter reversing are available for years. There are several of external devices that can be connected to OBD port. Some of them allow to track the car remotely, some even allow to unlock it. Various telematics vendors offer their devices in such external form. Such devices may have serious vulnerabilities. An attacker may want to abuse device s functionality e.g. for tracking the victim, or try to get direct access to car s bus

21 The risk and attack scenarios depend on the device functionality (e.g. connection to Internet, mobile application, tracking, remote control etc.). Examples of publicly known attacks: An example research regarding security of external telematic control units (TCU) devices was published in [8]. The researchers pointed several vulnerabilities, which in effect allowed them to take remotely full control over a car. Recommendations: Depending on functionality, the recommendations concerning above mentioned issues (e.g. telematics connection, cloud interfaces, mobile applications and wireless) apply

22 2.11. Vehicle-to-vehicle, autonomous etc. Threat agents: Connected Car SecurityThreat Analysis and Recommendations We can expect intensive development of the new car applications for collision avoidance, autonomic car, vehicle-to-vehicle communication or traffic routing [11]. So far the technology is not yet widely deployed, and there are not successful attacks publicly known. But the complexity of the software involved combined with attacker s motivation will most probably lead to disclosure of new vulnerabilities, like in the above mentioned examples. info@securing.pl Jontkowa Górka 14a, Kraków, Poland tel fax We help to achieve appropriate level of applications and systems security. Founded in Since that time we have worked for leading banks, insurance companies, telecom providers, government institutions and software houses, providing services such as: application security testing and assessment, code review, definition of security requirements, project review, education. We are focusing on application security problems. Our expertise covers different kinds of application (e.g. electronic banking, electronic payments, FOREX, e- commerce, voting, building automation, surveillance technologies, automotive, internet of things, etc.) and wide spectrum of technologies (web, mobile, WebServices, embedded, desktop)

23 3. REFERENCES ConnectedDrive html Dismantling Megamos Crypto: Research: News: 8. Paper: News: / html Icons made by Freepik from Flaticon is licensed by Creative Commons BY