Boffins warn on car computer security risk
Not that difficult – once you’re in
The Register | May 14, 2010
By John Leyden
A typical family car runs 100 MB of binary code spread across 50–70 processors, the researchers estimate. The use of computer technology brings improvements in efficiency and safety, via technologies such as anti-lock brakes, but it also throws up a range of new risks.
The researchers reckon “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”.
The 11-person team based this warning on an array of lab and road tests where they were able to carry out a variety of undesirable actions including “disabling the brakes, selectively braking individual wheels on demand, stopping the engine”. The team were able to easily bypass rudimentary security concerns, using techniques such as maliciously bridging supposedly isolated subnets.
Part of the team’s trickery includes the use of malware as well as reverse-engineering, packet sniffing, fuzzing and a custom tool, called CARSHARK (a car network analyser and packet injection utility).
Cars’ Computer Systems Called at Risk to Hackers
All manner of attacks were possible with these techniques including messing with car radios and dashboards. The researchers were able to “display arbitrary messages, falsify the fuel level and the speedometer reading”.
Throughout the testing the team focused on how attackers might be able to mess with a car’s internal network given access. What they don’t consider is how this access might be obtained in the first place, as they openly state in the research paper. Ways into a car computer network include user-installed subsystems, such as audio players, that link into internal networks as well as vehicle dashboards.
“In the US, 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,” the researchers explain.
Telematics systems such as General Motors’ OnStar that provide services such remote diagnostics, and stolen vehicle recovery, also link into internal networks and might (at least theoretically) provide another way in for attackers. The team suggest two attack scenarios: physical access by a mechanic or valet and hacking into one or other of the wireless networks car systems are plugged into.
In our car we identified no fewer than five kinds of digital radio interfaces accepting outside input, some over only a short range and others over indefinite distance. While outside the scope of this paper, we wish to be clear that vulnerabilities in such services are not purely theoretical. We have developed the ability to remotely compromise key ECUs in our car via externally-facing vulnerabilities, amplify the impact of these remote compromises using the results in this paper, and ultimately monitor and control our car remotely over the Internet.
The research do not name the car used in the test because “we believe the risks identified… arise from the architecture of the modern automobile and not simply from design decisions made by any single manufacturer”.
It’s worth saying, on the remote hacker risk, that no such remote attacks have ever been recorded and experiments designed to load malware onto car systems using Bluetooth have drawn a blank. Inserting a malicious component given physical access to a car appears far more straightforward and, of course, given hands-on access all manner of non-electronic skullduggery is easily possible. The researchers found electronic disruption far easier to pull off than they expected.
In starting this project we expected to spend signiﬁcant 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.
The academics rounded off the study by considering how the security shortcomings they highlighted might be addressed. Their paper, Experimental Security Analysis of a Modern Automobile, which is due to be published in the 2010 IEEE Symposium on Security and Privacy, can be found here (pdf). ®
Independent security expert Ken Tindell has written to us to express his skepticism about the significance of the research.
“I was utterly shocked to discover that apparently if you prise open an embedded system, reflash its program code, you can pretty much do anything to the I/O connected to the system,” he said. “Well knock me down with a feather.”
“Until I sold my company to Bosch in 2003, I was heavily involved in this area of computing, so I can say with some confidence that this ‘discovery’ is sheer foolishness. The only risk they encountered was a theoretical one (viz. that a telematics system connected to the in-vehicle networking could hack the car). It’s highly theoretical because the challenges of hacking a car are vastly more than hacking a banking system. I just can’t see anyone bothering,” he concluded.