The Hitchhiker’s Guide To Hacking Connected Cars: Methodology and Jump Kit Readiness
“Abashed the devil stood and felt how awful goodness is and saw Virtue in her shape how lovely: and pined his loss” ― John Milton, Paradise Lost
After four years of research and culling together lessons learned from over two dozen penetration tests of telematics control units (TCUs); head units; and speaking at connected car conferences in the US, Germany, Sweden, UK, India, and Japan, I have been picked up by a book publisher to author the first book on hacking connected cars, which will hit the book shelves around the world in early 2018. As a harbinger to my upcoming book, I’m publishing a series of articles I’m calling “The Hitchhiker’s Guide to Hacking Connected Cars.”
In this first article to the series I explain in-vehicle network architecture, how the infotainment system (“head unit”) communicates with the telematics control unit (TCU), and how the entire in-vehicle network ecosystem is structured. I then go on to explain what a rogue base station is as we begin to build our jump kit for performing penetration tests of head units and TCUs.
Unfortunately, the fact of the matter is, if you want to get into connected car penetration testing, your lab and “jump kit” is going to be more expensive than a traditional penetration tester targeting computer networks instead of in-vehicle and v2x networks.
That said, we will cover some of the items you’ll need in your kit as we go through these tutorials and videos over the next few months.
What you’ll need:
Head Unit: The head unit (or infotainment system) is the nerve center of the car’s audio and video system and in recent years has been expanded to include the capability for the driver to control different aspects of the car’s functionality, including Bluetooth, GPS navigation, door chimes, lighting, trouble warnings and odometer information. Head Units are now serving as a secondary instrumentation control panel.
Laptop + LinuxOS: Many of the tools we will be using in our kit are Linux tools. While using Kali Linux
may be appealing to you from a time availability and headache perspective, I never recommend Kali as a preference to building your system from the ground up using your favorite distro. For my articles, we will be using my distro of choice, Linux Mint 18.2 (Sonya), which is based on Ubuntu Xenial.I will explain later why I recommend building your own system. At the end of the day, the decision is up to you. You can also take a look at Parrot OS which seems to be growing in popularity among penetration testers.
Retail Price: Free
Wifi Pineapple: While this device by Hak5 is traditionally used for targeting wireless access points in a computer network, we’ll be using it to insert ourselves between head units and their connection with the TCU inside the vehicle used for internet connectivity inside the car. Oh and yes, another reason to purchase a Pineapple is it was used in Mr. Robot and Silicon Valley :)
Pineapple Nano Retail Price: $99.99
BladeRF: N — , not HackRF, but BladeRF. I will explain the differences in later articles, but for now, you’ll want to pick up a BladeRF (the x40 will suffice just fine). Make sure to pick up (2) duck antennas on Amazon.
Retail: $420.00
Duck Antennae: $6.00 each
Methodology
Before we do anything, I want to explore the O.C.D. side of me and talk a bit about methodology before we jump right into “pwning” cars. While your overwhelming desire may be to immeditely jump into Metasploit and start “pwning” I want you first to take a step back and realize that no penetration test should be performed without first having a modus operandi (read: methodology) before doing anything. I personally subscribe to the Penetration Testing Execution Standard (PTES).
The concept here is a step-by-step process that should be followed by first starting out with intelligence gathering, reconnaissance, vulnerability analysis, exploitation, post-exploitation, then finally, reporting.
In-Vehicle Terminology and Network Architecture
This architecture is quite common across OEMs.
Figure 1: Head Unit (HU) connectivity in the in-vehicle network
It goes without saying that this depends on the implementation by the manufacturer. However, in most of our penetration tests, we’ve found the Head Unit maintains connectivity with the TCU over a hidden wireless network that doesn’t broadcast its ESSID. The head unit (HU) will operate as the access point or base station (AP) while the TCU acts as the wireless client. In most implementations, the wireless information containing the ESSID and WPA2 key are transmitted to the TCU over the CAN bus. Once this has occurred, the TCU writes that information to a configuration file that is used for connection information to the HU moving forward.
Understand that the HU will always connect to the OEM backend through some kind of gateway (TCU) and in newer HUs, can use the driver’s cell phone for internet connectivity for the driver as an alternative connection to the Internet, either via WIFI or Bluetooth. We’ll explore this later :) Note that updates are pushed to the TCU from the backend over what is called OTA, or, Over-the-Air.
We will explore ways to find these hidden networks later, but just take note that it’s possible to find that hidden wireless network even if the ESSID isn’t being broadcasted.
The hidden WIFI network is traditionally used by the TCU for communication with the HU. We’ve seen implementations where this wasn’t being encrypted, so yes, you should check for this. Note that on lower-end systems with lower cost-points, margins don’t typically allow for the OEM to create multiple wireless NICs so you may find that the TCU actually shares the same wireless network as the ESSID being broadcasted to the passengers in the vehicle.
Let’s discuss the procedure you should try and stick to when performing the penetration test.
Step 1: Intelligence Collection
Meet with all the stakeholders and receive and actually read the engineering documentation you are given. This will help better equip you as you enter the penetration test. Remember that every OEM and every implementation is different. Don’t assume the same implementation, threats, and vulnerabilities for every head unit you target.
The first thing you are going to need to do is understand how head units are connected to the rest of the in-vehicle network as well as how they connect to the Internet.
In this stage, you’ll want to meet with as many internal folks as possible to ensure that the architecture for communication between the HU, TCU, and other ECUs is accurate. Having a better understanding of the topology will help you as you determine potential attack vectors and ingress points.
In most cases, you’ll be performing what’s referred to as a “white box” penetration test, where you will be given as much engineering documentation and information necessary to ensure less time is spent trying to figure it out. While “black box” penetration tests are pretty common in traditional penetration testing targeting computer networks, I’ve rarely, if ever, seen one performed against a TCU or head unit. Having said this, you should ensure that all communications with the head unit are documented and understood as those will be your potential attack vectors.
Goals of this step:
1. Create a drawing of the communication architecture between the HU, TCU, and other components to better understand the topology
2. Document all communication with the HU (both beaconed and hidden WIFI networks, etc)
Step 2: Reconnaissance
Next we’ll attempt to establish connectivity with the head unit and use nmap or other tools to attempt to identify open ports/services listening on the head unit such as HTTP, SNMP, DNS, etc that we could possibly target. Additionally, you will want to verify that the firewall (if one exists) is properly filtering ports and protocols as planned taking into consideration traffic direction of your packets.
Goals of this step:
1. Document all services/ports that are open that you’re able to connect to while connected to the HU. If any applications are running on the HU, such as a web browser, determine version numbers of those apps and if any browser plugins, etc are installed that could lead to exploitation of the HU via a client-side attack. For example, in one engagement, we discovered scp and wget was installed on the HU that allowed us to transfer an ELF metasploit binary created with MSFvenom to the HU for a remote shell.
Step 3: Vulnerability Analysis
Sorry girls, in this stage, you’re simply not going to start up Nessus or Saint and run a vulnerability scan against the HU. I wish it were that simple. This step in a HU penetration test is more theory than practical. Meaning, you’re going to want to think of all the potential vulnerabilities exist in the implementation for later attempted exploitation. Think outside the box here (no pun intended)! In other words, don’t limit yourself just by what exploits you think you can run in Metasploit. Think of all the potential ways to hack the HU, even if that means things you can do while using the touchscreen or in the shell provided in development mode. Don’t limit yourself to just what you can find on exploit-db.com. Just because you don’t have an exploit for it or it requires a lot of other things doesn’t mean it shouldn’t go in the report or that the OEM shouldn’t be informed about it.
Let me get you started. The most obvious threat in the diagram from above is the potential for a wo/man-in-the-middle (W/MITM) attacks against the HU. There are 3 potential W/MITM attacks in this type of scenario:
- Between HU and TCU
- Between HU and Passenger
- Between TCU and OEM
My suggestion is to always diagram potential vulnerabilities that we’ll attempt to exploit later using Attack Tree Diagrams.Please don’t go out and buy attack tree diagramming software, that’s just ridiculous. My preference is anything cloud-based — I prefer LucidChart.You can easily create an attack tree simply by using an Org Chart template.
Keep on top of the vulnerabilities disclosed for “traditional” computer networks during your penetration test. During the writing of this article, the “Krack” vulnerability was recently published on attacking WPA2 encryption in WIFI networks. It just so happens that the company I’m performing a penetration test for of their head unit is vulnerable. As a penetration tester, you must stay on top of the latest disclosed zero-day/new vulnerabilities being published. I lost count of how many times a new zero-day exploit was published that helped me while in the middle of a penetration test. It happens!
Goals of this step:
1. All vulnerabilities that exist in the system that you can confirm later with exploitation, or can potentially be exploited given the right circumstances.
2. Attack tree diagrams of vulnerabilities and potential outcomes
Step 4: Exploitation
Yes, this is the fun stuff. This is where you put the “pedal to the metal” and attempt to actually exploit the vulnerabilities you’ve identified in the last step. Again, don’t just limit yourself to whatever exploits are available. Try everything, even if that means diagramming out exploitation steps in an attack tree diagram if an exploit was published or created by an attacker. People have this misconception that penetration testing always has to be limited to the findings of what you successfully exploit. Yes, penetration testing is exploitation of discovered vulnerabilities (put down your guns mudslingers) — but that doesn’t mean you have to limit your exercise to the exploits you have.
Goals of this step:
1. Results, screenshots (evidence, pcaps, etc) of successful exploitation of vulnerabilities from the previous step
Step 5: Post-Exploitation
Here we will be attempting to take our established foothold on the head unit further by pivoting to other ECUs or potentially begin sending CAN signals onto the CAN Bus (if the TX cable is there) or seeing how much further we can take our access established in Step 4 (if any).
Goals of this step:
1. Pivoting to other ECUs or taking actual control of the vehicle via the CAN
2. Cracked keys if any
Getting our BladeRF Ready
When performing penetration testing against TCUs, we’ll want to be ready to spin up a rogue base station in an attempt to cause the TCU to associate with us so we can capture the packets between the TCU and the OEM. While this is not directly in scope of a penetration test of a HU, I’m including it anyway as you’ll still be working with TCUs when performing penetration tests against HUs. Just be careful in how you report the vulnerabilities in the final report to ensure in-scope and out-of-scope vulnerabiliites are clearly identified. In any case, you’ll need a rogue BTS in your jump kit for connected car penetration testing.
As mentioned, you’ll need to purchase a BladeRF x40 from Nuand to setup and run your rogue BTS. This is what is referred to as an RTLSDR, or software defined radio. The BladeRF is unique in that it has the capability to both receive and transmit over GSM. This will allow us to setup and run our own cell tower that the TCU will hopefully associate to for us to collect and analyze packets between it and the backend. The video in this article (above) demonstrates how we setup and flash the BladeRF with the latest firmware. Here are the commands for performing this.
More information is available at: https://github.com/Nuand/bladeRF/wiki/Getting-Started%3A-Linux
Install libbladeRF and BladeRF-cli
Easy installation for Ubuntu: The bladeRF PPA
$ sudo add-apt-repository ppa:bladerf/bladerf $ sudo apt-get update
$ sudo apt-get install bladerf libbladerf-dev bladerf-firmware-fx3 bladerf-fpga-hostedx40
Additional Stuff
$ sudo apt-get install libusb-1.0–0-dev libusb-1.0–0 build-essential cmake libncurses5-dev libtecla1 libtecla-dev pkg-config git wget
# To install documentation
$ sudo apt-get install doxygen help2man pandoc
Reboot your BladeRF and you’re ready to go on to the next article.
This article ended up being a bit longer than I had anticipated it being, so I’ll go ahead and end here before you, my faithful readers, end up too fried to read the next inculcation of this series. In the next article, we’ll begin with configuring our BladeRF, setting up and running our rogue base station using Yate/YateBTS, and capturing the packets from the mobile equipment connected to our rogue base station using Wireshark and 2 mobile phones.
In the words of the great Bob Barker, “Help control the pet population. Have your pets spayed or neutered.”
Originally published at www.alissaknight.com on November 4, 2017.
