Ever wondered about the various techniques that can be applied to hack modern cars? This post documents various ways to do so - you can use it as a cheatsheet
Software
There are multiple ways one can interface with the software stack of a car. The easiest one is to use USB-to-Ethernet adapters in order to attach to the network of the car. It’s important to use special adapters that are whitelisted on the car’s head unit. Also, not every adapter may be supported after all. For this, it’s best to do some research to get a hold of the right devices to use. Once attached to the network, assign a static IP to the interface. Once again it’s up to the researcher to get the correct IP range. For a specific car manufacturer, it seems to be 192.168.0.0 according to KeenLab [1]. It’s best to test all IP ranges not being publicly routed. Now, use some nmap to scan for services.
There can be multiple possible results:
- Shells (easy win but rare)
- Forgotten developer or debugging services which may allow command execution
- Challenge/response services that open other ports upon authentication
- (Accidentally) exposed services
All services may run as their own user to prevent compromising the entire system in case a vulnerability is present in one of the applications. Examine the service and fuzz it. For quick tests radamsa can be of use.
It may also be possible to create a WiFi hotspot using the car’s head unit. There may be other services available when entering the created wireless network that are worth examining. If you have a developer unit, using a debugger and examining coredumps can be of use.
From the internal point of view, using netstat, sockstat and other similar tools may reveal other vulnerable services. Potential attack scenarios can be horizontal and vertical privilege escalation, so it’s worth checking out all open ports and tracing running applications. In case more information on a target is required, perform static analysis with IDA or a similar disassembler. Be sure to have the whole package ready, including support for foreign architectures. Yes, there’s also Java on cars, so reverse engineering of these applications should be way more easier. As always when performing static analysis, keep an eye open for static keys, weak crypto and infrastructure related info. This also includes any MQTT brokers the car may be attached to. As with “traditional” pentesting, search for SUID binaries and sudo-like mechanisms that may enable privilege escalation.
OS
Various ECUs and devices may run different operating systems you haven’t encountered before, like QNX [1]. Search for all info you can get. Evaluate the permissions of all users, kernel versions and known vulnerabilities. For example, if the system service qconn on port 8000 is running, it’s a quick win.
Apps
Cars come with their own mobile app and application servers which may be a valuable source of information. In-app purchases for cars, NFC and Bluetooth come to mind. Look out for developer menus and ways the app affects the car and the application server. How does the car unlock process work?
“Apps” also refers to services running in the car:
- Do they run in a browser? Maybe an old browser exploit works
- Are these apps signed and can they be uploaded to the car in any way?
External Media
Some things to check:
- Can you fuzz the USB stack and crash system services? Maybe code execution can be achieved.
- Are all parts of external update packages signed?
- Are files being written to external media devices once they are inserted? Fuzz these files.
- Fuzz media files and their embedded information, such as cover art.
- Fuzz CSV files and try to import them from the car.
Car Network
It may be valuable to apply the old-fashioned CAN fuzzing to uncover potential problems. Also use the internal wires and not just the OBD-II port as it may be “firewalled”. Modern cars use VLANs and IPv6, so using the traditional IPv6 attack tools can be of use. Also, issues in the network segmentation can be severe: You shouldn’t be able to open the car from a isolated network segment that controls media stuff. Hopping from one ECU to another using interfaces listed in ifconfig or devices under /dev is also possible. The worst case would be sending CAN packets from a hijacked unit.
Check for bus wires that are exposed via car mirrors and antennas!
Other Things
- Fuzzing the Bluetooth/GPS stack
- Faking GSM and GPS data
- SMS based attacks [1]