Ethical Automotive Hacking Simplified (Part 2 of 2)

Welcome back to Part 2, which covers the next 3 phases of ethical hacking. By now, you should have gathered information in the Recon Phase and have results from the Scan Phase. Before continuing to Phase 3, review your logs and notes from the previous phases that were covered in Part 1.

Phase 3 – Gaining Access

The “gaining access” phase may be more difficult than expected without the key fob or manufacturer’s smart phone app to unlock the vehicle. Lock picking tools can be useful when gaining access to vehicles, but may be unsuccessful since today’s vehicles have more advanced locking systems. Therefore, we will discuss some other options for entry to avoid the brick smashing technique.

As highlighted in the previous post, CAN messages communicate and control electronic control units (ECUs). Begin testing by capturing CAN messages from ECUs. With physical access to the vehicle, perform actions which send CAN messages (i.e. open car door, lock car) while logging from the OBD II port. Then map the message header (i.e. arbitration ID) and message data (i.e. reverse engineer CAN messages) which can lead to gaining access to the target vehicle. Tools like Cangen and CaringCaribou can be used to locate weaknesses in ECUs to gain access, as shown in the next image.

Figure 1: Example of CAN Tools for gaining access

Uniform Diagnostic Services (UDS) is a CAN diagnostic communication protocol to control and access ECU data and internal functions. In UDS, functions are defined with the help of Service IDs (SID). Some SIDs can be executed without the need to be unlocked, such as requiring passwords (i.e. Seed and Key process) or digital certificates to authenticate the tester before allowing the SID to be requested. UDS has many known vulnerabilities if poorly implemented. Examples of commonly known attacks are spoofing, password guessing (i.e. brute force, dictionary attacks), session hijacking, man-in-the-middle attacks, timing attacks as well as privilege escalation which may all contribute to you gaining access during this stage.

Carrier-sense multiple access with collision detection (CSMA-CD) is a feature of CAN that allows control of the ECUs. The CAN ID contains a broadcast ID to which an ECU responds with its specific physical ID. The ECU with the least value for its physical ID is given the highest priority. Once the broadcast ID is discovered in the scanning step, you can create various kinds of attacks like denial of service, privilege escalation, spoofing, tampering data, discovering information, and data repudiation. Now knowing the vehicle’s internal communication, you can try executing the attacks remotely (i.e. create backdoors, Trojan files, implant cellular CAN tools).

Another interesting area to research is firmware updates over the air (FOTA). FOTA is distributed by an Original Equipment Manufacturer (OEM) telematics server to the vehicle. Updates are transmitted to a telematics module (TM) which further distributes the update to the respective ECUs. Access to the TM may be possible via USB port with an Ethernet adaptor via your computer. Next, search for any vulnerable features (server open ports, DFU mode). Scanning the USB port for all the supported functionality can sometimes lead to interesting behavior, but requires skill to take it further depending on how the head unit reacts. UART is a common hardware protocol  and using PuTTY will allow your computer to connect and could activate SSH or Telnet session to the ECU. This connection may allow capturing update packets via read-only debug logs. With reverse engineering of the packets, vulnerabilities can be discovered and with physical access to the vehicle, could be used further to reach outside the internal vehicle network to other TM’s. Other types of attacks against OEM’s telematics server are social engineering, spoofing, session hijacking, and password guessing. Gaining access to an OEM’s telematics can also establish a mesh network of various vehicles as botnets.

A different approach of testing the vehicle is by fuzzing. Fuzzing involves sending invalid random data as input to create possible software crashes, memory leaks, or find other possible vulnerabilities. Buffer overflows can also be sent as a part of fuzz testing. Fuzzing requires many hours of testing and results in functional and cybersecurity issues (findings).

Hardware attacks are possible on many ECUs but require advanced knowledge of embedded devices. A warning:  the ECU may be damaged when gaining access to its internal electronics.

Phase 4 – Maintaining Access (Persistence)

Once you gain physical or remote access, you may want to discover ways to maintain access for future purposes. This is accomplished by creating backdoors and rootkits.

Steganography is a data concealment technique to bypass scanners and detection programs. Steganography is the process of hiding information in another file, including video or audio files. Although many steganography tools are available, it is also one of the most overused techniques, and the vehicle might already have a tool that is looking for these types of files.

Rootkit attacks install new software on the system (i.e. rooting) and hide themselves while attacking the system with DDoS or backdoor programs. Usually, rootkits can be hidden in a bootloader, kernel, or within an application. Some rootkits require adding hardware to the existing ECU.

Another way to maintain access is to connect a Bluetooth enabled OBD II dongle and then wirelessly relay CAN messages to the computer. If you always have access to the vehicle (OBD II), then you can program an exploit on a raspberry pi, which remains in the vehicle.

Phase 5 – Covering Tracks (Not involved with pen-testing – only a Red Team activity)

When covering your tracks, save a backup of the original data to a file before reprogramming the ECU ( running dd against the partitions or hdd, flash memory dump, etc.).  This is important to revert to the original version. Also, make sure you leave no traces, as forensic analysts may discover activity through logs or system changes. A simple trace of your existence can go a long way in getting you caught. Always keep in mind that host-based IDS may exist in the vehicle, which can easily raise a flag if you do not properly clear your tracks. Some vehicles send logs to backend servers, therefore disabling external connections while testing may help cover your tracks.

At this point, the blog post has covered the five phases (Recon, Scanning, Gaining Access, Maintaining Access, and Covering Tracks) to hack vehicles. Apply all these phases to win your next car hacking challenge.  Let us know how you did!

And by the way, at ESCRYPT we have many security products and solutions to prevent a vehicle from being hacked.  So if you are unsuccessful in hacking a vehicle, it may well have been protected by ESCRYPT.

See you soon at a CTF event!

Aleksandar Ristoski                      
Douglas Gordon
Automotive Security Test Team

Leave a Reply