Before proceeding to the description of specific cases, let's make a short introduction to the problem. A typical passenger car of the latest generation contains under the hood not only the engine, but also more than 100 million lines of code. Even relatively simple models have about 30 electronic control units (ECUs) equipped with their own processors and firmware. There can be more than a hundred such blocks in luxury cars. To communicate with each other, these ECUs are connected through a maze of digital buses. Here and CAN (Control Area Network), and Ethernet, and FlexRay, LIN and MOST. They all operate at different speeds, transfer different types of data, and provide connections between different parts of the vehicle.
It is the ECUs that control the critical functions of the car: engine, communications, fuel supply, braking system and safety. Part of the control of these components is available through the head unit.
Modern cars are equipped with geolocation modules, can connect to the mobile Internet and even use public Wi-Fi networks. Such a “smartphone on wheels”, like its more compact pocket counterpart, has wireless interfaces and can distribute the Internet to its passengers.
We studied the design of automotive networks from different manufacturers and found that although each vendor implements them differently, all architectures have common components: gateways, ECUs, CAN buses, USB and wireless interfaces. Despite all the differences, they perform similar functions and interact with each other in the same way. Based on this data, we created a generalized architecture for the automotive network.
Block diagram of a typical network of a connected car. Source: Trend Micro
The diagram shows that the connected vehicle has network interfaces that allow it to be attacked remotely. The result of such attacks can be the compromise of one or more ECUs and a complete interception of vehicle control. Let's consider several cases of such attacks and vulnerabilities that were exploited by hackers.
Case 1: Remote Hacked Jeep Cherokee in 2015
In 2015, Charlie Miller and Chris Valasek collaborated with a Wired magazine to remotely hack a connected Jeep Cherokee .
The reporter drove onto the highway, after which the researchers took over control of the systems of his car - they turned on the music and air conditioning at full power, forced the wiper blades to work, and then reduced the speed of the car to 10 miles per hour, so that other drivers honked the participant in the experiment, overtaking him. The worst thing was that he completely lost control: hackers took control of the multimedia system, air conditioning and even the gas pedal.
The researchers discovered a Class A IP network that the manufacturer, Chrysler, was using for its connected vehicles. By scanning the open ports, they found that port 6667 was open in each car, on which the D-Bus messaging daemon received commands via Telnet without authentication. Sending commands to the D-Bus demon, Miller and Valasek completely took over control of the vehicle.
Jeep Cherokee attack chain. Source: Trend Micro
In general, in the process of studying the internal structure of the Jeep Cherokee, hackers found a lot of interesting things, for example:
- , CAN-IHS (CAN Interior High Speed), CAN-C (CAN Critical), Jeep ;
- Jeep , ;
- IP- Jeep -, — , Chrysler D-Bus, 6667;
- Renesas V850 OMAP (Open Multimedia Applications Platform) Chrysler — ( , SPI CAN CAN );
- CAN-, .
- — , , CAN- , V850, - ;
- CAN, ;
- a way to spoof CAN messages from real ECUs or deactivate these ECUs so that malicious CAN messages are executed instead of their commands.
Note that although we are talking about cars of the same manufacturer and a certain generation, this situation is not at all rare in the industry - this is not a Chrysler problem, but a systemic problem.
Case 2: hacking Tesla in 2016
In 2016, experts from the Tencent Keen security laboratory hacked a Tesla Model S. To attack, they exploited a complex chain of vulnerabilities to compromise components of the car's network and inject malicious CAN messages.
Attack chain on Tesla Model S in 2016. Source: Trend Micro
- Researchers have installed a fake Tesla Guest hotspot to which all Teslas are automatically connected in accordance with the manufacturer's standard.
- Tesla, -, Linux CVS-2013-6282. AppArmor.
- , root- «», — , Parrot, Bluetooth Wi-Fi, CAN.
- CAN-.
- Tesla Model S CAN-, . , .
- , / .
- , , CAN-.
- ESP, ABS, .
3: Tesla 2017
A year after a visual demonstration of vulnerabilities in Tesla, Tencent Keen specialists checked how well Elon Musk's company worked on the errors. The result was another compromise of the electric vehicle.
Chain of attack on Tesla Model S in 2017. Source: Trend Micro The
attack started from the same fake Tesla Guest hotspot, to which the car trustingly connected. Next, the researchers again exploited a browser vulnerability based on the Webkit engine. Although the vulnerability was different, the result was the same. Even the vendor update of the Linux kernel did not help: the hackers disabled AppArmor again and gained root access to the CID.
After that, the researchers modified the firmware to ignore Tesla's EDS check, and then hacked several Easter eggs built into the original car firmware. Despite the entertaining nature of the Easter eggs, they had access to various ECUs, which the researchers used.
Case 4: hacking BMW in 2018
To demonstrate that Tesla is not alone in security problems, Tencent Keen developed three attack options for BMW vehicles: a local attack via USB / OBD-II and two remote attacks.
The scheme of the attack on BMW in 2018. Source: Trend Micro
The first attack used remote code execution in BMW ConnectedDrive (a set of electronic car options introduced back in 2008) by intercepting HTTP traffic:
- BMW ConnectedDrive HU-Intel BMW 2G 3G (TCB) HTTP, GSM GPRS- ;
- , , , URL; GSM, WebKit;
- -, root- HU-Jacinto, CAN;
- the result was the ability to use the CanTransmit_15E2F0 function to send arbitrary CAN messages.
The second variant of remote attack is more complex and exploits TCB vulnerabilities via unprotected SMS.
Conclusions and recommendations
Connected cars are just one component of a smart transport network, a complex ecosystem of millions of connections, endpoints and users. This ecosystem has four main components:
- the actually connected car;
- a data network that allows the connected vehicle to communicate with the backend;
- backend - servers, databases and applications that ensure the interaction of the entire smart transport infrastructure;
- a vehicle security center (VSOC), which collects and analyzes notifications from the rest of the smart transport network.
The complexity of the smart transport system has reached such a level that it is extremely difficult to predict which part of the perimeter the next attack will be directed to. In this regard, the protection of connected vehicles is not limited to the software and vehicle electronics. It is also necessary to ensure the security of the backend and data network.
Combined architecture of connected cars. Source: Trend Micro
For car protection:
- to use network segmentation in the car network, separating critical nodes from "entertainment and user" ones. This reduces the risk of sideways movement and improves overall safety.
- ISO SAE. — ISO/SAE 21434 , .
- , , . ISO 31000.
- ISO/IEC 27001.
- ISO/AWI 24089 « — »
:
- ;
- ;
- .
-:
- , ;
- (NGFWs)/ (UTM), , (IPS), (IDS), , -, , ;
- ;
- , -, — ;
- (BDS);
- IPS IDS — , .