Attacks
The vehicle seemingly on a cursory review from the
layperson is a mostly mechanical piece of equipment. The person may see the
tires, door hinges, and part of the engine. The car provides a much more
complete machine upon further and more in-depth examination. The computer
networks and systems allow for many more endpoints and communications intra-
and inter-vehicle than what had been experienced. The communication between the
endpoints and the endpoints allow for points of attack where the system had not
been hardened. Each attack vector noted may not be applicable across all of the
manufacturer lines for all vehicles. The attack is dependent on the model’s
information security architecture.
The attack surfaces for the vehicle have been getting
much worse (Simonite, 2016). This is a function of the increased use of
technology in the vehicles. In a recent study, 62% of people are worried their
vehicle may be easily hacked (Vanian, 2016). The attack surfaces may be divided
under separate facets, such as the equipment involved (Checkoway, McCay,
Kantor, Anderson, Shacham, & Savage, 2011). As an example, this could be
sectioned by the physical equipment (CD, DVD, USB, auxiliary jacks,
touchscreens, and the head unit (HU)) or wireless attack vector (blue tooth,
cellular, digital radio, GPS, WiFi (Koscher, Czechis, Roesner, Patel, &
Kohno, 2010)).
An alternative would be to view the individual attack
points. The vehicle’s diagnostic trouble codes (DTCs). Each manufacturer has
their respective diagnostic codes, which are proprietary. The manufacturers and
dealerships need these to read and manipulate reports, messages, and use these
for informational purposes. Under normal conditions the DTCs are erased after
checked three times and the soft DTCs may be cleared with a scan tool.
The vehicle can be fuzzed for DTC and freeze frame data,
which is a temporary condition. The attacker may be able to view the
proprietary interface with the proper tool. In this action, any unexpected
items noted in the interface may be indicative of a vulnerability. This may
also show nothing out of the ordinary.
The attacker may also monitor CAN Bus communication for
data leakages. This may show enough data for the attacker to understand how the
model’s components communicate with each other. This may be done with
monitoring the CAN packets with an OBD connector. This would also show the size
of the packets moving and the relevant data in the packet. The packets can also
be grouped together to review for trends. The OBD-II port is much like an
Ethernet jack. This connects to the different computer systems (Vanian, 2016).
This is often used by mechanics to retrieve diagnostic information.
Each manufacturer has different equipment and protocols.
As this is the environment, the attacker will have a varied set of tools to
attack the different models and manufacturers. With the proper tools for each
model, the packet flow is easier to read and analyze. This may show the
accelerator pedal position, brake pedal status, fuel level, location, odometer,
and many other data fields. After the initial review, the attacker may be able
to message the CAN Bus and other the data in the fields. The attacker may be
able to replay the packet.
The attacker may also modify the ECU. This mode of attack
may be very effective. The attacker may use as the links a third party piece of
equipment plugged into the OBD-II port, which is connected to the ECU. The ECU
could be reprogrammed maliciously. The attacker could monitor the API calls on
your laptop or watch and analyze the packets. The access, dependent on the
model, maybe limited by an authentication algorithm. This may be bypassed by
analyzing any keys being exchanged.
There may be the opportunity for a successful attack when
the vehicle receives an update or patch. This update may be to the overall
system, program, app, or functionality. At several points during the lifetime
of the vehicle, there will be updates to the app, O/S, or other areas.
Generally this is done through over the air (OTA), much like with your cell
phone. These updates could be with .zip, .cab, .bin, .dat, .exe, or .dll files,
dependent on the manufacturer. The update could be a few files or a bundle.
Once the attacker knows the O/S, its architecture and how the updates are
managed, the next step is to analyze the possibility to modify an update or
create a new update packet. This may be difficult if the packet is sent in a
secure communication channel (TLS 1.2 for now) and/or appropriate level of
encryption.
Vehicles are connecting with each other at this point.
This connectivity is not far-reaching yet as this is being actively tested
across the US. As one vehicle drives in the far right lane on I-75, the vehicle
would communicate with the other vehicles approaching the middle lane. This is
much like the vehicles in I, Robot
and other movies with driverless vehicles. This communication may be within the
cellular network, IP traffic, dedicated short range communication (DSRC) or a
hybrid method.
The standard security for these includes the cellular
provider’s security already in place, encryption for the non-cellular traffic
and other security measures. Each of these provides an avenue for attack or a
vulnerability. As an example, the DSRC uses the 5.85-5.925 GHz band based on
the 802.11p protocol.
The attacker could also look to the tire pressure
monitoring system (TPMS). This was one of the first attacks, however it is
still good to verify this vulnerability is closed. This communication from the
tire to the ECU and may use Bluetooth or simple radio to communicate. The
Bluetooth can use a secure communication channel. The attacks can sniff the
communication from the TPMS. The signal is relatively weak, and the attacker
needs to be proximate to the vehicle.
A recent attack involves the key fob for the vehicle.
This uses a RFID for the key fob to communicate with the vehicle. This poses an
opportunity for a vulnerability and an attacker to exploit. This uses a 315 MHz
signal generally in North America. The code to unlock the vehicle is not sent
in the clear text. Most late model vehicles use a rolling code or a challenge
(e.g. a task such as a calculation). This traffic can be monitored and analyzed
with a tool. This attack could jam the key fob signal to the vehicle. The owner
would be unable to enter the vehicle. If the attacker had the time and a safe
place to sit, the attacker could brute force the code. The attacker would need
to write their own code using an SDR, customized hardware to do this, or a
hybrid of this. There also is a known MitM attack available (Doctorow, 2015).
A new version of the attacks involves sideloading the
attack. In this case there is a device infected with malware. This device is
attached to the vehicle via Wi Fi or a cable of some form. The vehicle is then
infected with the malware, virus, or ransomware. There may be MP3 malware from
unauthorized downloaded music to infect the vehicle (Barry, 2011).
The late model vehicles do have available for review the
addressable channels. This is more familiar as the remote telematics systems
(Ford Sync, GM Onstar, Toyota Safety Connect, Lexus Enform, BMW BMW Assist, and
Mercedez-Benz mbrace).
The hardware in the vehicle could be hacked. This is
defined as physically manipulating some of the equipment. This may be shown as
the attacker taking apart part of the dash to reach a port that needs to be
modified or connected with. Other methods generally are much more covert. This
avenue is not being fully explored at this junction due to the act being so
overt, the mass amount of time generally needed for these, and the legal issues
associated with physically touching and manipulating the tangible asset.
References
Checkoway,
S., McCay, D., Kantor, B., Anderson, D., Shacham, H., & Savage, S. (2011,
August 10-12). Comprehensive experimental analysis of automotive attack
surfaces. USENIX Security 2011.
Retrieved from http://www.autosec.org/
Koscher,
K., Czechis, A., Roesner, F., Patel, S., & Kohno, T. (2010). Experimental
security analysis of a modern automobile. 2010
IEEE Symposium on Security and Privacy. Retrieved from http://www.autosec.org/
