Why should you hack a car?
Maybe you want to learn about car communication, participate in automotive capture-the-flag (CTF) events, or you’re worried about the overall security protection of the car. Where do you start? We’ll cover five phases of hacking a car – ethically – and what to consider in each phase. This is Part One of a two-part blog post. This first part will introduce phases one and two. Part Two will cover phases three, four, and five.
When you approach a vehicle or enter a car hacking CTF event, you will first need to determine how to get started. You do this by splitting up the vehicle attack surface into focus areas. Automotive hacking can be approached with methodologies that are already practiced by penetration testers in other fields along with some techniques that are specific to vehicles. You don’t need to be an expert at every attack surface; you just need expertise in one area and divide the others between a team where each team member focuses on a different protocol.
The areas of expertise can include:
- Hardware Reversing (firmware extraction, side-channel analysis, etc.)
- Software reversing (de-compiling images and binaries, software updates, etc.)
- Interfaces (CAN, Ethernet, Diagnostics, USB, SD Cards, and radio frequencies for Bluetooth and key fob, etc.)
- Operating Systems (QNX, Android, Real-time OS’s)
- Mobile (Apps used to communicate with your car’s infrastructure)
Step-by-step methodology for hacking a vehicle or succeeding in a CTF event
We will focus on easily accessible interfaces and common challenges that you may encounter when faced with the task of hacking a vehicle. To ensure success, we recommend a step-by-step methodology.
For most vehicles, a method of how to interface with them will not be obvious. Therefore, you will require some hardware and software tools such as a CAN adapter with CAN open-source software (Socketcan, python-can or PCAN view) which allows you to read/write CAN frames or USB access available on the USB hub. USB-TTL cable is a serial UART connection to your computer through TX, RX, GND pins. UART is provided to gain head unit control or command line interface CLI.
If you happen to have physical access, plug into the ODB port for the CAN Bus. Then check if it broadcasts its own device CAN ID. If you have to rely on remote access to the head unit or display, then try to connect to the vehicle Wi-Fi or Bluetooth network. You can also take steps before even getting close to the vehicle to obtain some publicly available data and resources, leading to Phase 1.
Phase 1 – Reconnaissance
Reconnaissance or recon is the first step in penetration testing in which you try to collect information about your target – the vehicle itself. You research technologies used (and their versions) and try to obtain information about the manufacturer or device. Employee information, location, news articles, functionality, specification and datasheets can all prove useful.
Recon can be done passively (obtain information without direct interaction with the target) or actively (obtain information through direct interaction with the target). Performing recon passively includes gathering information through search engines (Google hacking), job application sites, forums, news articles, and social networking sites. Passive recon is not yet hacking. However, once you start performing recon actively, you have officially started hacking, and may be held responsible for your actions. This step includes “whois” lookups, traceroute analysis, social engineering, web scraping, and mirroring.
Passive recon includes searching online for files related to automotive and embedded electronic control units (ECUs):
- DBC – database file describes the communication signals of CAN frames on the network
- A2L – file defining XCP communication parameters from tool to ECU
- ARXML– XML config file for CAN ECUs with AUTOSAR
- PDX / ODX – XML config file for diagnostics ECUs
- Bin – Image files, application bins, etc.
- Car forums – flash files, USB updates, calibrations, etc.
Knowing how to Google hack can help sort through the massive amount of search results and allows you to focus on what you are really after.
Passive recon also includes reading online resources:
- Search Google for important file types: filetype:”xls | xlsx | zip| bin| ppt | pptx | pdf” Car Spec
- Read car forums like Reddit Car Hacking https://www.reddit.com/r/CarHacking/
- Follow security Blogs: https://securitybyescrypt.com/
- Ebooks – “The Car Hacker’s Handbook” – A guide for the penetration tester by Craig Smith
More easily acquired items, for example, could be – depending on the manufacturer – head unit USB update files, obtained from either tuner forums or simply by registering with repair shop sites that support the manufacturer vehicle. Depending on what you discover will lead to our next phase – Scanning. To sum it up, recon is the step that helps you decide various ways to enter (attack) the car.
Looking to the Future:
As vehicles become more complex and require larger data handling functionalities, developers are relying more heavily on Ethernet for internal communications related to diagnostics, flashing, and sensor data. Leading to more commonly seen protocols such as HTTP, TCP, UDP, FTP, etc.
Phase 2 – Scanning
Scanning is the second step in which you try and gather further information about the services present in the vehicle as well as the possible vulnerabilities that may exist as a result of those available services. Finding the version of services used can help you concentrate on specific exploits, which have already been proven vulnerable to the specific version.
An automobile has a Controller Area Network (CAN) that creates various networks in a car. (In a way, it is like a LAN). The nodes are ECUs (Electronic Control Unit) in this scenario. ECUs are embedded devices that perform various tasks in a vehicle. For CAN Bus testing, we recommend using Peak-PCAN tool. There are cheaper alternatives that can be more hassle than they are worth for long term scanning and ease of use. CAN buses commonly uses baud rate 250 and 500 kBit/s, however, other baud rates do exist. The Bus sometimes requires more resistance and adding a 120 Ohm resistor usually works. A multi-meter is good when having connection issues.
You can typically scan an automobile through:
- Multimedia Head Unit (Bluetooth, Wi-Fi or USB)
- OBD-II diagnostics port (Network messages, Diagnostics, CCP/XCP)
Common scanning for Wi-Fi services would be using ‘nmap’ port scanning utility. By default, nmap will only cover the 1000 most common ports. If time allows, try the example below.
- “nmap -vvv -p- 192.168.0.220” – scan entire port range and print verbosely to screen. (and dont forget UDP ports)
Scanning USB can sometimes lead to interesting behavior. Plugging a keyboard or mouse is a simple test to check for more functionality. As mentioned before, UART is a common protocol for USB and using PuTTY will allow your computer to connect over SSH and Telnet. We talk briefly on approaching USB in an earlier post.
Bluetooth is commonly known for pairing smart phones and playing music, but Bluetooth has interesting security functionality like pairing pin, data encryption, and storing personal contacts. From our experience, we have not seen challenges at Vehicle CTFs for these flags. Tools for Bluetooth scanning are BlueSnarfer and hcitool,
Through the OBD-II, you can try and scan the ECUs and retrieve as much data as possible. Some automakers are starting to come out with gateway devices that will filter and block any unwanted ODB2 communications that can reach the internal network. Based on the recon previously you might have ended up with the OBD2 pin-out for how many can buses are available, the diagnostic protocol used and diagnostic IDs used.
The most common diagnostic protocol, Universal Diagnostics Service (UDS) contains many different services like $22 read data by identifier and $27 security access. It is important to understand how many services are accessible and if they require security access mode to utilize them. A simple scanning script using python-CAN could be used to help locate possible UDS services shown in the next image.
However, some services might provide Negative Response Codes (NRC) values. This can point to some valuable data for the ECU talking back, indicating your scan was not correctly formatted, service unsupported, or security access is not passed.
The last step in this phase is to create a vulnerability assessment by making a Threat and Risk Analysis. This is a useful step as it gives you a clear diagram of all the work you have done so far, as well as help you decide various attack vectors, exploits, and vulnerabilities that are possible.
At this point, this post has covered two out of five phases to hack cars. Stay tuned for the next article to where we continue with phases three (Gaining Access), four (Maintaining Access), and five (Covering Tracks).
Tune in next time…
ESCRYPT Automotive Security Test Team
Part 2 of this post is now available! Continue reading …
[…] 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. […]