| seakrait | 11-04-2010 05:32 PM |
Your car's gonna get hacked!
No, seriously. All these electronic nannies and network systems built into our new fancy cars nowadays make our lives totally convenient: Ford's Sync, GM's OnStar, etc. plus internal networks within the vehicle itself. They do not have robust protection from network intrusions however.
The actual paper (from UW and UCSD) might be a bit boring for those of you not technically minded but here's the abstract and conclusions: Quote:
Experimental Security Analysis of a Modern Automobile
Abstract - Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks. While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure. We demonstrate that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems. Over a range of experiments, both in the lab and in road tests, we demonstrate the ability to adversarially control a wide range of automotive functions and completely ignore driver input—including disabling the brakes, selectively braking individual wheels on demand, stopping the engine, and so on. We find that it is possible to bypass rudimentary network security protections within the car, such as maliciously bridging between our car’s two internal subnets. We also present composite attacks that leverage individual weaknesses, including an attack that embeds malicious code in a car’s telematics unit and that will completely erase any evidence of its presence after a crash. Looking forward, we discuss the complex challenges in addressing these vulnerabilities while considering the existing automotive ecosystem.
| Quote:
VII. DISCUSSION AND CONCLUSIONS
Although we are not the first to observe that computerized automotive systems may present new risks, our empirical approach has given us a unique perspective to reflect on the actual vulnerabilities of modern cars as they are built and deployed today. We summarize these findings here and then discuss the complex challenges in addressing them within the existing automotive ecosystem.
• Extent of Damage. Past work, e.g., [19], [24], [26], [27], [28], discuss potential risks to cyber-physical vehicles and thus we knew that adversaries might be able to do damage by attacking the components within cars. We did not, however, anticipate that we would be able to directly manipulate safety critical ECUs (indeed, all ECUs that we tested) or that we would be allowed to create unsafe conditions of such magnitude.
• Ease of Attack. In starting this project we expected to spend significant effort reverse-engineering, with non-trivial effort to identify and exploit each subtle vulnerability. However, we found existing automotive systems—at least those we tested—to be tremendously fragile. Indeed, our simple fuzzing infrastructure was very effective and to our surprise, a large fraction of the random packets we sent resulted in changes to the state of our car. Based on this experience, we believe that a fuzzer itself is likely be a universal attack for disrupting arbitrary automobiles (similar to how the “crashme” program that fuzzed system calls was effective in crashing operating systems before the syscall interface was hardened).
• Unenforced Access Controls. While we believe that standard access controls are weak, we were surprised at the extent to which the controls that did exist were frequently unused. For example, the firmware on an ECU controls all of its critical functionality and thus the standard for our car’s CAN protocol variant describes methods for ECUs to protect against unauthorized firmware updates. We were therefore surprised that we could load firmware onto some key ECUs, like our telematics unit (a critical ECU) and our Remote Control Door Lock Receiver (RCDLR), without any such authentication. Similarly, the protocol standard also makes an earnest attempt to restrict access to DeviceControl diagnostic capabilities. We were therefore also surprised to find that critical ECUs in our car would respond to DeviceControl packets without authentication first.
• Attack Amplification. We found multiple opportunities for attackers to amplify their capabilities—either in reach or in stealth. For example, while the designated gateway node between the car’s low-speed and highspeed networks (the BCM) should not expose any interface that would let a low-speed node compromise the high-speed network, we found that we could maliciously bridge these networks through a compromised telematics unit. Thus, the compromise of any ECU becomes sufficient to manipulate safety-critical components such as the EBCM. As more and more components integrate into vehicles, it may become increasingly difficult to properly secure all bridging points.
Finally, we also found that, in addition to being able to load custom code onto an ECU via the CAN network, it is straightforward to design this code to completely erase any evidence of itself after executing its attack. Thus, absent any such forensic trail, it may be infeasible to determine if a particular crash is caused by an attack or not. While a seemingly minor point, we believe that this is in fact a very dangerous capability as it minimizes the possibility of any law enforcement action that might deter individuals from using such attacks.
In reflecting on our overall experiences, we observe that while automotive components are clearly and explicitly designed to safely tolerate failures—responding appropriately when components are prevented from communicating—it seems clear that tolerating attacks has not been part of the same design criteria.
| the actual paper is here: http://www.autosec.org/pubs/cars-oakland2010.pdf |
