Before you read any further, I must caution you that the weaknesses described in this article impact multiple ECUs on the market today and therefore have had all identifiers, such as references to specific automobile and ECU manufacturers removed in the interest of responsible disclosure. While topics in this article will be discussed at a very superficial level, My talk at Cyber Secure Car 2016 conference in Munich, Germany on this topic was on June 14 - but you can watch the video of the talk now.
I’d like to start out defining some terminology to get both of us on the same page. Electronic Control Units or an ECU is a generic term for any system that controls one or more of the electrical system or subsystems in a transport vehicle.
Connected automobiles, like any transport vehicle, is built with numerous ECUs. Any connectivity, with either an infotainment system inside the car (the head unit) or an ECU will require connectivity to a back-end, which is typically the automobile maker, who is able to “push” patches and data to the system remotely. This is typically done through cellular base stations (BTS).
A cellular base station provides connectivity between mobile phones and the wider telephone network, also referred to as a cell tower. The first thing you need to remember is that any IoT device should be viewed from the vantage point of a hacker attempting to compromise a regular computer system. It, like any networked host, has an identifying address on the network and is therefore susceptible to being identified and further targeted. The same goes for cellular networks, where instead of an IP address like on computer networks, the identifiers are the IMSI of the SIM chip and the ARFCN beacons from the MSP base stations. Like any networked node, exploitation of vulnerabilities is not relegated to just the device itself, but also the communication infrastructure it is connected to that it relies on for connectivity to other devices.
As a result of penetration tests Brier & Thorn has performed over the years of IoT devices, including connected transport vehicles, IT security related to IoT is almost like Marty McFly jumping into the DeLorean and going back 20 years in IT security when the worse thing we had to worry about was skript kiddies defacing our web site by using WuFTPD exploits and rexec to compromise our servers. Similar to the inherent flaws in IP version 4 of nodes implicitly trusting anything it communicates with when IPSec isn’t being used for transport security, connected automobiles fall victim to the same types of attacks affected by a lack of authentication with its peers. Like a mobile phone, an ECU that uses cellular to communicate with its backend is going to automatically associate with its closest base station or cell tower and trust it. You can see where we’ll be headed first in our kill chain; a pattern of transaction activities that are linked together in order for a successful compromise to occur.
The Kill Chain Model (KCM) that we will be employing in this article in demonstrating the numerous attack vectors against a connected automobile is: intelligence collection; threat modeling; vulnerability analysis; and exploitation.
In our Intelligence Collection phase, we footprint the target, in our case an ECU that is connected to its back-end over cellular using a built-in SIM chip. Therefore, the intelligence collection phase provides us vulnerabilities in not just the ECU, but also the cellular network it is associated to as well as information we can harvest from the ECU itself through stimulus and response.
The attack vectors for an ECU depend on its communication capabilities with the outside, in our case, SIM chips for connectivity to mobile service providers (MSP) cellular base stations, WIFI for connectivity with its head unit within the car, Bluetooth, and the physical attack surface.
Before we go any further it’s worth noting that an ECU within an automobile, is connected to the CAN bus to be able to send and receive
CAN signals. A CAN-Bus (Controller Area Network) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in an application without a host computer. It is a message-based protocol, originally designed for multiplex electrical wiring within automobiles. Simply put, having the ability to send or receive CAN signals in a car gives you “root” privileges in the ability to control the car and make it do whatever you want. It gives the system within the automobile the ability to send/receive commands with the car itself.
This article decomposes the vulnerabilities to connected automobiles into two separate sections: infrastructure vulnerabilities and application vulnerabilities.
Infrastructure Vulnerabilities
ECUs inherently trust any BTS it associates with over cellular networks. This is because it has to in order to be able to communicate with its back-end system. The BTS is the network infrastructure that the automobile uses to communicate with any outside system.
Therefore, should the ECU automatically associate with a Rogue BTS, than you could feasibly perform a “man-in-the-middle” attack against the ECU by being able to intercept the messages between the ECU and the back-end system. This is demonstrated in the below scenario using a Rogue BTS we created using a software defined radio (SDR) from Nuand — the BladeRF. Using the BladeRF we were able to successfully create a rogue base station and have the ECU automatically associate with us as the stronger signal. It should be noted that a similar device is being used by the U.S. Intelligence Community to intercept and monitor cell phone calls by exploiting the configuration in cell phones that automatically hop to the base station with the highest signal strength that is within the proximity of the phone referred to fondly as “dirtboxes,” which it uses to eavesdrop on cell phone users.
The same concept can be applied here as the ECU using its SIM chip, much like a mobile phone, can be fooled into associating with our rogue BTS.
Application Vulnerabilities
Like any system, its security is only as strong as its weakest link. In the case of end-to-end communications between two nodes on a cellular network, that would be the encryption cipher employed on the network. Many ECUs will leverage SMS (Short Message Service) to send and receive commands to its back-end servers. This leaves it open to attack via the cellular network it is currently associated to.
We’ll now digress shortly into baseband networks, discussing 2G, 3G, and 4G/LTE as it has a great deal of implication here with this topic.
Each one of these technologies employ different encryption ciphers on the baseband network depending on the cellular provider (see figure to the right for providers in Germany). Depending on the network the ECU is camped on, A5/0, A5/1, or A5/3 encryption will be used to secure the communications on that network. When the automobile is in an A5/0 where there is no encryption or an A5/1 network, its SMS text messages can then be captured and rainbow tables can then be used to perform offline cracking against the messages, giving the attacker access to the messaging between the back-end and the ECU. Numerous tools such as Kraken are available that provide this capability as well as the corresponding rainbow tables for cracking A5/1 encryption.
When the connected automobile is camped on a cellular base station, it is susceptible to numerous attack vectors, including the ability to capture the IMSI of the SIM chip, intercept traffic to and from the ECU via SMS, downgrade attacks from 3G to 2G where insecure or no encryption ciphers are in place, IMSI attach/Detach messages (Denial of Service), Rogue Base Station attacks, and other information leaks.
ECUs are more secure when camped on LTE networks, but unfortunately, especially in the EU, the prevalence of LTE networks is low and because automobiles of course have unrestricted travel capacity to areas with spotty coverage, the probability of it camping on a 2G or 3G network is quite high.
Session key cracking between the ECU and back-end is possible on 2G/3G networks, and is further complicated when the manufacturers are using weak key algorithms, such as Symmetric Key encryption or fail to encrypt the SMS messages.
We’ve just skimmed the surface in this article of the vulnerabilities prevalent in ECUs but I will certainly be publishing more research and articles on this new attack surface over the coming months as I speak on this topic at numerous security conferences.
