Forget Suicide Car Bombs, Next its Suicide Cars.

[rs]

There is a new paper out of the Department of Computer Science and Engineering University of Washington titled "Experimental Security Analysis of a Modern Automobile". The full paper can be found at http://www.autosec.org/pubs/cars-oakland2010.pdf.

Here is the 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.

In this context "ecosystem" means the overall business interconnection of companies which design, develop, manufacture and distribute components to the automobile industry as a whole. For example, both Mercedes Benz and BMW produce high-end luxury vehicles with anti-lock brakes, however both companies use components supplied by Bosch GmbH, a manufacturer of (among other things) various components of automobiles such as anti-lock brake systems, collision avoidance systems, engine control computer modules, etc. The design and support of such components and the overall regulatory environment in which all automobile companies operate world-wide make it essentially impossible for companies to produce their own parts, even for large multi-national companies such as Mercedes Benz and Bavarian Motor Works.

Continuing with the paper, the introduction provides some interesting background. Emphasis in the quote is mine.

I. INTRODUCTION

Through 80 years of mass-production, the passenger automobile has remained superficially static: a single gasoline powered internal combustion engine; four wheels; and the familiar user interface of steering wheel, throttle, gearshift, and brake. However, in the past two decades the underlying control systems have changed dramatically. Today’s automobile is no mere mechanical device, but contains a myriad of computers. These computers coordinate and monitor sensors, components, the driver, and the passengers. Indeed, one recent estimate suggests that the typical luxury sedan now contains over 100 MB of binary code spread across 50–70 independent computers—Electronic Control Units (ECUs) in automotive vernacular—in turn communicating over one or more shared internal network buses [8], [13].

While the automotive industry has always considered safety a critical engineering concern (indeed, much of this new software has been introduced specifically to increase safety, e.g., Anti-lock Brake Systems) it is not clear whether vehicle manufacturers have anticipated in their designs the possibility of an adversary. Indeed, it seems likely that this increasing degree of computerized control also brings with it a corresponding array of potential threats.

Compounding this issue, the attack surface for modern automobiles is growing swiftly as more sophisticated services and communications features are incorporated into vehicles. In the United States, the federally-mandated On-Board Diagnostics (OBD-II) port, under the dash in virtually all modern vehicles, provides direct and standard access to internal automotive networks. User-upgradable subsystems such as audio players are routinely attached to these same internal networks, as are a variety of shortrange wireless devices (Bluetooth, wireless tire pressure sensors, etc.). Telematics systems, exemplified by General Motors’ (GM’s) OnStar, provide value-added features such as automatic crash response, remote diagnostics, and stolen vehicle recovery over a long-range wireless link. To do so, these telematics systems integrate internal automotive subsystems with a remote command center via a widearea cellular connection. Some have taken this concept even further—proposing a “car as a platform” model for third-party development. Hughes Telematics has described plans for developing an “App Store” for automotive applications [22] while Ford recently announced that it will open its Sync telematics system as a platform for third-party applications [14]. Finally, proposed future vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2X) communications systems [5], [6], [7], [25] will only broaden the attack surface further.

Overall, these trends suggest that a wide range of vectors will be available by which an attacker might compromise a component and gain access to internal vehicular networks—with unknown consequences. Unfortunately, while previous research efforts have largely considered vehicular security risks in the abstract, very little is publicly known about the practical security issues in automobiles on the road today. Our research aims to fill this gap.

This paper investigates these issues through an empirical lens—with active experiments against two late-model passenger cars (same make and model). We test these cars’ components in isolation in the lab, as a complete system in a controlled setting (with the car elevated on jacks), and in live road tests on a closed course. We have endeavored to comprehensively assess how much resilience a conventional automobile has against a digital attack mounted against its internal components. Our findings suggest that, unfortunately, the answer is “little.”

Indeed, we have demonstrated the ability to systematically control a wide array of components including engine, brakes, heating and cooling, lights, instrument panel, radio, locks, and so on. Combining these we have been able to mount attacks that represent potentially significant threats to personal safety. For example, we are able to forcibly and completely disengage the brakes while driving, making it difficult for the driver to stop. Conversely, we are able to forcibly activate the brakes, lurching the driver forward and causing the car to stop suddenly.

Rather than focus just on individual attacks, we conduct a comprehensive analysis of our cars’ digital components and internal networks. We experimentally evaluate the security properties of each of the key components within our cars, and we analyze the security properties of the underlying network substrate. Beyond measuring the real threats against the computerized components within modern cars, as well as the fundamental reasons those threats are possible, we explore considerations and directions for reconciling the tension between strategies for better security and the broader context surrounding automobiles.

The paper goes on to describe how the researchers were able to take total control over the target automobile's functions, even to the point of forcing false readings on the instrument panel for speed as well as printing a "hacked" message to the information display. The degree to which the researchers were able to take control over the vehicle is disturbing, to say the least.

The attacks mounted in the paper required physical access to the automobile, at least temporarily, so they could communicate directly with the automobile systems over the government mandated OBD-II connector. By way of example, US regulations require compliance with air pollution regulations and a periodic inspection regimen to verify that any given automobile is within the allowed limits. It used to be the case that the inspector would stick a probe into the exhaust system and physically measure the results, but this has been replaced by a computer that connects to the OBD-II connector and in essence asks the automobile "Are you within limits?". Pass or fail for the pollution test is determined by the automobile itself.

Consider how pervasive such new features such as General Motors OnStar system have become. These systems are no longer restricted to luxury vehicles, but are now supplied across the product spectrum. GM even advertises how the OnStar system can be used to remotely disable a stolen vehicle. Obviously this goes way beyond simple activation of the locking system. The inter-connectivity of the various components and systems on the modern automobile is almost total.

... A combination of time-to-market pressures, wiring overhead, interaction complexity, and economy of scale pressures have driven manufacturers and suppliers to standardize on a few key digital buses, such as Controller Area Network (CAN) and FlexRay, and software technology platforms (cf. Autosar [1]) shared across component manufacturers and vendors. Indeed, the distributed nature of the
automotive manufacturing sector has effectively mandated such an approach—few manufacturers can afford the overhead of full soup-to-nuts designs anymore.

Thus, the typical car contains multiple buses (generally based on the CAN standard) covering different component groups (e.g., a high-speed bus may interconnect powertrain components that generate real-time telemetry while a separate low-speed bus might control binary actuators like lights and doors). While it seems that such buses could be physically isolated (e.g., safety critical systems on one, entertainment on the other), in practice they are “bridged” to support subtle interaction requirements. For example, consider a car’s Central Locking Systems (CLS), which controls the power door locking mechanism. Clearly this system must monitor the physical door lock switches, wireless input from any remote key fob (for keyless entry), and remote telematics commands to open the doors. However, unintuitively, the CLS must also be interconnected with safety critical systems such as crash detection to ensure that car locks are disengaged after airbags are deployed to facilitate exit or rescue.

OnStar is (technically) a subscription based service which requires "activation" but in practice, the system is essentially on all of the time, regardless of the subscription state. The OnStar system consists of a two-way cell phone transceiver and telemetry unit connected to the automobile systems. Obviously to activate remote unlock or stolen car deactivation, the automobile does not, nor can it, stop the OnStar system from interacting with the cell phone network.

Many computer hacking attacks are based on a knowledge of subtle features of various software components. Some hacking attacks are as simple as a malicious attacker posing as a IT professional calling someone on the phone and simply asking for the password.

Other hacking attacks are based on a deep understanding of the way in which software is designed and constructed. The most common example of this is the buffer overflow attack. Most software today is written in a common language, either "C" or "C++". The semantics of C support statically defined storage for information, i.e. storage in the computer memory that is fixed and its location is known or can be known. There are two basic kinds of storage, scalar variables and arrays of scalar variables. An example of a scalar variable is an integer used to count things. An example of an array of scalar variables would be a text string consisting of some number of characters. The semantics of "C" do not directly support "array bounds checking" which means that if the software chooses to try and access array location 1001 of an array consisting of 1000 units, there is nothing to stop it. Obviously array location 1001 does not contain what the program expects to be in the array, but instead contains "something else". That something else is knowable.

Computer programs are composed of three pieces, code or instructions for the computer, statically declared storage for information (which may or may not be transient) and dynamically allocated storage. The buffer overflow specifically targets the interaction of code and static storage. Compiler programs which convert "C" text into computer binary code will place instructions and static storage together in adjacent parts of the computer memory. If the computer program either accidentally or if can be made to overwrite static arrays which are out of the defined bounds, the "data" written there necessarily replaces the expected computer code.

Most computer communication is based on some kind of standard, and it is often assumed by a programmer that the communication according to the standard follows the rules. A buffer overflow attack is based on a communication where the source of the communication deliberately violates the defined standard for the purpose of creating a situation where the computer program will overwrite its own instructions with the instructions supplied by the attack.

What does this have to do with OnStar and automobiles? Well the cellular communication which allows these sophisticated remote control features over an automobile is based on standard communication protocols. If these protocols can be violated in specific ways, one could easily mount the equivalent of a buffer overflow attack on an automobile. Moreover, this may very well be possible over the current cell phone network meaning that it would not require someone to create a unique radio signal, but simply make a specific kind of phone call.

If OnStar can be used to contact remote call centers to establish communication in the event of an emergency, and if OnStar can be used to take remote control over a vehicle, the implication is that it should not be particularly difficult to use the OnStar system to establish a silent connection to any given automobile for the purpose of eavesdropping. Many new automobiles now contain video cameras, sometimes many video cameras. This means that the OnStar system might be used to silently implement a remote controlled total surveillance system. If a buffer overflow attack can be mounted over the cell phone system, based on the researchers results in the above paper, it may very well also be possible to take almost total control over an automobile in real time, remotely, over the cell phone network to almost any automobile. Also based on the results of the research, it seems unlikely that the designers of the overall communication system behind OnStar considered anything beyond the ability to control the communication securely for the purposes defined by the OnStar system and for the purposes of insuring payment compliance. In other words, it is not likely that OnStar has been specifically "hardened" against a malicious attack.

Recently Toyota has received tremendous press because of large recalls of their electronic control systems. There have been many reports of "unintended acceleration" on various vehicles, and while Toyota has implemented various modifications to both to the mechanical as well as electronic systems, they insist that these cases of unintended acceleration cannot have come about because of the natural operation of their control systems. They base this on their knowledge of the underlying implementation of these systems and the protections they put in place to prevent such occurrences. They almost certainly base this conclusion also on the fact that the components which make up these automobiles are not in fact unique to these automobiles, and may not be even unique to Toyota. However, it seems not likely they considered malicious or deliberate attack scenarios.

Consider the possibility that some of these unintended acceleration scenarios were an attempt by somebody to demonstrate the ability to remote control a vehicle, and also consider who might be behind such a demonstration in "the real world". The conspiracy theorist in me suggests a few "usual suspects".

The bottom line here is that we should prepare to witness the transition into an environment where the objects we use on a daily basis and take for granted become the tools for war in a silent and almost untraceable way. We will need to collectively prepare for the day when Osama Bin Laden can take control over any automobile from the safety of his cave in Afghanistan to mount attacks anywhere, anytime. Its going to be a Brave New World...