respond. However, even though these responses from the legitimate sensors contained nor-
mal readings, the ECU still flashed the warning signal based on the original spoofed packet
transmitted prior to the two activation signals. Not only did this ultimately make the attack
successful, but this situation also opens up the victim’s car to a battery drain attack: a neigh-
boring car can drain the victim’s car’s sensor batteries by repeatedly sending spoofed packets
that cause the victim’s car to transmit the two activation packets, in turn causing each of the
car’s sensors to send response packets.
After two weeks of experiments, the researchers inadvertently caused the test car’s TPMS
ECU to crash, completely disabling the TPMS service. They were not able to revive the unit
and ultimately had to buy a brand new ECU at the car dealership. This illustrates that the
manufacturer of the ECU did not invest much time into implementing resiliency against
unexpected events and malicious spoofed packets.
This case is yet another example of how security needs to be designed into the product at
the earliest stages. In software, we’ve learned that we need to employ security principles dur-
ing use case design, architecture design, development, testing, and postproduction. In the
case of the test units, it’s clear that the manufacturers did not take security into account in
most, if not all, phases of product development.
As we continue to head toward a world full of interconnected vehicles, we ought to
demand more effort in the implementation of security- and privacy-related controls. Without
this requirement, we are going to continue to put our privacy and physical safety at risk.
Exploiting Wireless Connectivity
As we’ve seen so far, ECUs communicating on the CAN bus make up the connected car.
We’ve looked at the design of the TPMS ECU, but there are many other ECUs that are popular
and critical to the secure functioning of the car. Researchers Charlie Miller and Chris Valasek
have explained the function of many ECUs in their papers titled “A Survey of Remote Auto-
mative Attack Surfaces” and “Adventures in Automotive Networks and Control Units”.
Although some of the news coverage of their work dismissed the impact of their findings
because their demonstrations assumed physical access to the car, their analysis of various
ECUs and the CAN bus ecosystem of cars is quite useful. Furthermore, researchers at the
University of California, San Diego and the University of Washington have already demon-
strated that it’s possible to remotely gain access to a car by exploiting short-range and long-
range wireless networks. This research, coupled with Miller and Valasek’s analysis, leads us to
ponder scenarios that may allow malicious entities to remotely compromise and control targe-
ted cars by exploiting wireless networks used by the cars, and then leveraging their under-
standing of how each ECU works. In this section we will couple the ideas presented by both
research teams to further our understanding of attack surfaces targeting Bluetooth and cellu-
lar networks in cars.
EXPLOITING WIRELESS CONNECTIVITY 163