Most car enthusiasts bemoan the rise of electronic systems in automobiles because they create a layer of interference between ourselves and the direct, mechanical control of our cars. Sure, electronic controls are cheaper, lighter and allow for easier diagnostics, but they rob automobiles of the elemental simplicity which is so often fundamental to their appeal. And, as a study by researchers from the Universities of Washington and San Diego [in PDF format here, via ArsTechnica] shows, the various electronic systems in your car actually makes it vulnerable to hackers who could disable key systems remotely. Titled Experimental Security Analysis of a Modern Automobile, the study explains that the electronic complexity of modern cars actually leaves them extremely vulnerable to all kinds of attack, raising serious concerns about how safe we really are in our cars (especially if we happen to have an enemy or two).
The study focused on accessing on-board computers via the federally mandated OBD-II on-board-diagnostics port, and the study shows that physical access to this port for even a brief period is sufficient to upload “malware” programs, which could compromise on-board systems. Physical access could also be granted by installing something as innocuous as an aftermarket stereo system embedded with malware. And though it’s easy enough for anyone to access these ports or install malware-infected components, there need not even be a physical link to the car to compromise its safety and privacy.
The other vector is via the numerous wireless interfaces implemented in the modern automobile. In our car we identiﬁed no fewer than ﬁve kinds of digital radio interfaces accepting outside input, some over only a short range and others over indeﬁnite 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
Through these vectors to the OBD-II port, researchers were able to access the Controller Area Network bus, a protocol standard to all new vehicles sold in the US after 2008. The researchers developed “CAR SHARK,” a “custom CAN bus analyzer and packet injection tool,” and were able to identify several serious security issues with the protocol.
Broadcast Nature. Since CAN packets are both physically and logically broadcast to all nodes, a malicious component on the network can easily snoop on all communications or send packets to any other node on the network. CAR SHARK leverages this property, allowing us to observe and reverse-engineer packets, as well as to inject new packets to induce various actions.
Fragility to DoS. The CAN protocol is extremely vulnerable to denial-of-service attacks. In addition to simple packet ﬂooding attacks, CAN’s priority-based arbitration scheme allows a node to assert a “dominant” state on the bus indeﬁnitely and cause all other CAN nodes to back off. While most controllers have logic to avoid accidentally pairs: breaking the network this way, adversarially-controlled hardware would not need to exercise such precautions.
No Authenticator Fields. CAN packets contain no authenticator ﬁelds — or even any source identiﬁer ﬁelds — meaning that any component can indistinguishably send a packet to any other component. This means that any single compromised component can be used to control all of the other components on that bus, provided those components themselves do not implement defenses; we consider the security of individual components in Section V.
Weak Access Control. The protocol standards for our car specify a challenge-response sequence to protect ECUs against certain actions without authorization…Under the hood, ECUs are supposed to use a ﬁxed challenge (seed) for each of these challenge-response pairs; the corresponding responses (keys) are also ﬁxed and stored in these ECUs. The motivation for using ﬁxed seeds and keys is to avoid storing the challenge-response algorithm in the ECU ﬁrmware itself (since that ﬁrmware could be read out if an external ﬂash chip is used). Indeed, the associated reference standard states “under no circumstances shall the encryption algorithm ever reside in the node.” (The tester, however, does have the algorithm and uses it to compute the key.) Different ECUs should have different seeds and keys… Furthermore, as described in the protocol standards, the challenges (seeds) and responses (keys) are both just 16 bits. Because the ECUs are required to allow a key attempt every 10 seconds, an attacker could crack one ECU key in a little over seven and a half days.CAN. Given the weaknesses with the CAN access control sequence, the role of “tester” is effectively open to any node on the bus and thus to any attacker.
Moreover, numerous failsafes were easily evaded. Researchers were able to remove all CAN communications from the ECU while the vehicle was moving, and even reflashed the ECU while the vehicle was moving. Moreover, experimenters were able to remove a vehicle’s entire telematics memory, including their keys without authentication, and even cause a car’s Device Control system to disable key components like brakes. And if it seems like any of these attacks would require a deep and intimate knowledge of the inner workings of our cars’ electronic brains, think again.
Much to our surprise, signiﬁcant attacks do not require a complete understanding or reverse-engineering of even a single component of the car. In fact, because the range of valid CAN packets is rather small, signiﬁcant damage can be done by simple fuzzing of packets (i.e., iterative testing of random or partially random packets). In- deed, for attackers seeking indiscriminate disruption, fuzzing is an effective attack by itself. (Unlike traditional uses of fuzzing, we use fuzzing to aid in the reverse engineering of functionality.)
By now, your eyes have either glazed over with boredom, or you’re just starting to get interested. For those in the latter category, we suggest checking out the full 16-page report [in PDF format here], and taking a shot at explaining some of this information in a less technical manner.