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: No --, 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


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.