Introduction
The emergence of drive-by-wire, in-vehicle sensors for ADAS, and connected infotainment has added massive complexity and weight to a connected car growing in cable harness weight under the load of Ethernet and CAN cabling running throughout the car. WiFi helps address this growing problem and is commonly used not just to provide a roaming hotspot for in-vehicle passengers but is also used for connectivity between the head unit (HU) and Telematics Control Unit (TCU).
When performing a penetration test of a HU, you'll first want to understand the network topology. By running a tool, such as airodump-ng (part of the aircrack-ng suite) or if you have a bigger budget and can use a WiFi Pineapple Tetra from Hak5, you'll be able to identify wireless access points (APs) that are beaconing out an ESSID as well as hidden wireless networks
that have clients attached to them.
In this article, I will explain WiFi, why the Evil Twin attack is capable of being employed, and explain man-in-the-middle attacks and what they aim to accomplish. I'll explain some of the Evil Twin tools available to you to employ this type of attack and how to successfully employ one against a HU/TCU.
In-Vehicle Hotspots
In-Vehicle Hotspots
Some of you may have walked up to a vehicle and seen the WiFi symbol sticker on the driver's side window indicating that there is a mobile hotspot running inside the car. This was added by automakers to provide internet access to in-vehicle passengers.
While mobile data plans have become far cheaper than they were in the late 90s -- many cellular phone providers now offering unlimited data plans (at least within the United States), automakers wanted to provide passengers who may not be able to fire up a mobile hotspot on their phones, access to the Internet with a wireless hotspot running inside the car. In most implementations, this AP is typically running inside the HU and is often a paid subscription with the automaker. For somewhere in the neighborhood of $40-$50/mo, you can have internet access with your in-vehicle hotspot.
In addition to using the wireless network for passenger internet access, it is also leveraged by the OEMs for communication between the HU and TCU. But I'll digress for a moment and come back to this later.
A Quick WiFi Primer
WiFi stands for Wireless Fidelity. It is a wireless network technology that allows computers and other devices to be connected to each other into a LAN and to the Internet without wires and cables. WiFi is also referred to as WLAN, which stands for wireless LAN, and 802.11, which is the technical code for the protocol. In my previous article in the Hitchhiker's series on V2X Networks, I decompose the application of 802.11p employed in V2X/V2V communication between vehicles and roadside units (RSUs).
WiFi is in actuality a protocol, a series of rules governing how data transmission is carried on a network between wireless client(s) and wireless access point(s). The name given to the family of protocols that govern WiFi by the IEEE (The Institute of Electrical and Electronics Engineers) is 802.11 followed by a letter to indicate a version of the specific protocol implementation, each with varying improvements to the speed and range of the implementation.
WiFi implementations in connected vehicles will vary from OEM to OEM but in general, you'll typically see the use of 5Ghz channels over 2.4Ghz as the reduced range of 5Ghz is a nonissue due to the size of the vehicle as well as the fact that you don't want the signal bleed to be too far outside the vehicle.
WiFi operates on two separate spectrum bands 2.4 Ghz and 5Ghz, each with their own unique channels.
The tradeoffs between 2.4GHz and 5GHz have to do with interference (almost entirely in 2.4GHz), range, and speed, three properties that all relate to one another. The more interference, the less speed and range; the greater range you want, the less speed you can have; the greater speed you want, the more you have to mitigate interference and work closer to an access point.
In a connected car, the HU typically acts as the wireless AP and the TCU will typically act as the client. When you're performing a penetration test, every implementation will be different, but I've found that more expensive HUs (the ones that go in more expensive car models) will typically have (2) wireless interfaces in the HU, with one operating as the WiFi network for the passengers that broadcasts its ESSID, and a second hidden wireless network on a separate interface that acts as the wireless network for the TCU to connect to. That network is typically not broadcasted, though I've see this only once before. While the wireless network is hidden, there are ways to find it, which I'll explain later in this article. But just know that hidden doesn't really mean you can't find it.
Demystifying Man-in-the-Middle Attacks
A man-in-the-middle attack, as first made famous by Kevin Mitnick in the now infamous "Mitnick attack" on Shimomura where Mitnick used TCP sequence number prediction to perform a man-in-the-middle (MITM) attack purporting to be a host in a trusted communication session between two of Shimomura's systems in order to gain access to it, is simply the use of a third host to relay and even alter the communication between two hosts who believe they are directly communicating with the other. The attacker in this case is purporting to be one of the hosts in the trust relationship and the host is used to relay messages between the two others not realizing the entire conversation/communication is being controlled by the attacker. One such type of MITM attack in wireless networking is an Evil Twin attack, which we'll discuss in the next section.
Uncloaking Evil Twin Attacks
The etymology of the term "Evil Twin" originates in many different fictional genres as the antagonist that are physical copies of the protagonist in the story but with radically inverted moralities. Though there may be moral disparity between actual biological twins, the term is more often a misnomer. In many cases, the two look-a-likes are not actually twins, but rather physical duplicates produced by other phenomena (e.g. alternative universes). In others, the so-called "evil" twin is more precisely a dual opposite to their "good" counterpart, possessing at least some commonality with the value system of the protagonist. Comic books contain some other early appearances of evil twins, such as the one seen here in the cover of 1968's Wonder Woman #176 which explicitly references the "Evil Twin" of Princess Diana of Themyscira.
The concept of an Evil Twin attack in wireless networking is not much dissimilar from its original use of the term in film and storybooks -- the concept of broadcasting the ESSID and BSSID of a legitimate wireless AP that an existing client has already connected to and trusts by projecting a stronger signal than the legitimate or "good" twin causing the wireless client to connect to the "evil" twin instead.
Evil Twin Employment Options
There are numerous tools available for employing an Evil Twin attack against a legitimate AP, some free, open source downloads, others not-so-free, commercial off the shelf (COTS) tools, such as the Pineapple Nano or Tetra from Hak5. I've successfully employed an Evil Twin attack against a HU between the HU and TCU in a connected car as shown in the screenshot below from a Pineapple running PineAP. This article is not how to leverage a Pineapple to perform this attack. I'll only be focusing on the use of open source tools, such as Aircrack-NG and Fluxion.
A note on use of the Pineapple to employ an Evil Twin attack against a connected car: Because many of the implementations you'll find of WiFi in a vehicle will typically be 5GHz, you'll need to purchase the Pineapple Tetra and NOT the Nano as the Nano does not support 5Ghz.
It is without contestation that you not rely simply on the wireless adapter inside your laptop to perform these types of attacks. You'll want a good external wireless NIC capable of performing packet injection as most do not support this capability. As you can imagine, wireless adapter manufacturers are not looking to add features to their standard wireless adapters to suit the needs of a hacker.
Other things to consider include how far you'll be from the target. External wireless adapters such as the Yagi are instrumental when targeting HUs from long distances away from the target. The critical decision here is to ensure the right chipset is used that supports the distro you've decided to use. For example, here are a list of chipsets supported by Kali Linux as of this writing:
Atheros AR9271
Ralink RT3070
Ralink RT3572
Realtek 8187L (Wireless G adapters)
Realtek RTL8812AU (newly in 2017)
Research performed by null-byte also suggests the Ralink RT5370N is compatible
While numerous adapters are available with these supported chipsets and capable of performing injection, you need to again be careful to select an adapter that supports 5 GHz networks, which unfortunately are slightly pricier than the other adapters. One such adapter is the Alfa AWUS051NH Dual Band, which you can buy on Amazon for about $48.87 as of this writing.
The RT5370N is an 802.11a/b/g/n Wireless USB adapter that provides users the ability to fire up a rogue AP over 802.11a/b/g/n at 150/300 Mbps in the 2.4GHz or 5.8GHz band, which is also compatible with 802.11a/b/g wireless devices at 11/54 Mbps. You can configure AWUS051NH with ad-hoc mode to connect to other 2.4GHz/5.8GHz wireless computers, or with Infrastructure mode to connect to a wireless AP or router for accessing to Internet.
Step 1: Reconnaissance
The first thing you'll need to do when performing an Evil Twin attack is to perform reconnaissance. You need to first determine if the HU and TCU are connecting over the same wireless network used for the passengers of the vehicle or if it's running a hidden wireless network. To perform this reconnaissance, we can use airodump, which ships with the Aircrack-NG suite.
First, put your wireless NIC into monitor mode (passive monitor mode) using airmon-ng, which also ships with the Aircrack-NG suite. In these cases, I assume you are using Kali or another debian-based distro and that your interface name is wlan0. To determine what the interface name is of your wireless NIC (network interface card) is, run the 'iwconfig' command. $ airmon-ng start wlan0
This will put the wlan0 NIC into monitor mode so it can "sniff" the air looking for the HU's wireless networks and as a result, will create a new NIC called mon0. This is the interface you need to run tools, such as airodump-ng on in order to sniff the air. To start airodump-ng simply run: $ airodump-ng mon0
The output from airodump-ng will show all of the APs that are beaconing out their ESSID and BSSID. In this screen, it's possible to also see any clients associated to a BSSID that has no associated ESSID (hidden wireless network).
Every HU is going to be called something different. For example, Chrysler's uConnect system will have a different ESSID by default then say, Mercedes-Benz or BMW's iDrive. The hotspot name (ESSID) can be found in the settings menu of the HU. Find the ESSID used by the HU if it's a single wireless LAN HU that shares the passenger hotspot with the TCU or the BSSID of the hidden wireless network as you'll need this information for the next step when employing the Evil Twin attack.
Step 2: Delivery Time for The Evil Twin
airbase-ng It's time to deliver the Evil Twin! (Sorry, I couldn't resist the reference). To do this, we simply use another tool that ships with Aircrack-NG called airbase.
$ airbase-ng -a <BSSID> --essid <ESSID> -c <CHANNEL> <interface>
Airbase-ng will create a wireless AP using the parameters that you specify in the above command. In my experience across numerous OEM penetration tests, the TCU will typically be configured to connect to only a specific BSSID and channel and will typically require WPA2 encryption to be turned on. I've attempted to disable it in the past but failed to get the TCUs to connect to me when this was turned off. It's absolutely critical you get all of the connection parameters right in your airbase-ng command line that the TCU requires in order to connect to you. This is the most time consuming step -- so be prepared to give this step the time it needs. This isn't a ./ autorooter or other form of quick exploitation. You need to take your time and get this right.
There have been numerous engagements where I was not able to get the client to authenticate with my rogue AP until I sent de-auths to the client. This can be done using aireplay-ng:
$ aireplay-ng --deauth 0 -a <BSSID> mon0 --ignore-negative-one
What this effectively does is forces a disconnect/de-association to the TCU to tell it to disconnect from the HU in hopes it will connect to our rogue AP instead so we can capture the WPA handshake.
To assist as many penetration testers as possible, I'm going to digress for a moment and explain quickly how to do the same attack using Fluxion for my readers out there who prefer Fluxion over other manual methods, which automates much of these steps.
Fluxion
Fluxion is a remake of linset by vk496 with (hopefully) less bugs and more functionality. It's compatible with the latest release of Kali (rolling). The attack is mostly manual, but experimental versions will automatically handle most functionality from the stable releases. Fluxion works by scanning for wireless networks, captures handshakes for offline cracking (which is automated by Fluxion), uses a web interface to launch a FakeAP instance to immitate the HU's wireless network, then will spawn a MDK3 process to deuathenticate the TCU from the HU so it can connect to our FakeAP and pass over the WPA key. A fake DNS server is also launched by Fluxion to capture all DNS requests and redirect them to the host running the fake AP.
Fluxion automates a lot of what use to be tedious, manual steps in the employment of an Evil Twin attack. To install Fluxion, simply perform the following steps: wget https://raw.githubusercontent.com/FluxionNetwork/fluxion/master/install/install.sh && bash install.sh
The other method is to simply clone the git repository: $ git clone https://github.com/FluxionNetwork/fluxion $ cd fluxion ; sudo ./fluxion
NOTE: If you have unmet dependencies when attempting to install via git, simply run sudo ./Installer.sh
Once fluxion is fully installed, simply run it by typing sudo ./fluxion. You'll be asked a set of questions, including what wireless adapter you want fluxion to use. You'll then see an airodump-ng window named Wifi Monitor which looks for APs and clients. Once you identify the wireless network used by the HU, use the close window button to stop the monitoring.
Next, you'll be prompted by fluxion to select a target and prompted to select attack. If all goes well, you'll be provided the handshake and if all else fails, fluxion will automatically send the de-auth packets to try and force the TCU to connect with you.
What method do I prefer? I always prefer the manual approach so I can see and understand everything that's happening. I've even simply spun up hostAP myself and fired up Wireshark and went on with my day.
Putting It All Together
In the below screenshot, you'll see a successful Evil Twin attack I launched against a TCU. The far left window is the output of APs and wireless clients around me. The first row shows the BSSID I was broadcasting and evidence of the TCU associated to my rogue AP. In the top right window you'll see where I was able to successfully grab the WPA2 when the TCU associated to my rogue AP/evil twin and began attempting to crack it. In the bottom right-hand corner you'll see a running tail of the log file evidencing the association between the TCU and my rogue AP.
There you have it, an Evil Twin attack successfully launched against a connected car, forced connection of the TCU to my rogue AP, where I then successfully grabbed the WPA handshake sent by the TCU thinking I was the HU, then sent to a separate process for offline cracking. And yes, the OEM in this case used an English word with no numbers or characters, which was successfully brute forced with the rockyou.txt file -- yes -- it's still a thing.
Attack Mitigation
Since I'm not one of those "sky is falling" gals that likes to freak you out and send you to our 1800-sales line for help, I'm going to try and explain how an OEM can protect against this type of attack.
There are tools beginning to surface now, such as EvilAP_Defender, which detects Evil Twins in the vicinity and even launches a DoS attack against it in an effort to knock it offline. While I'm unaware of how this might be implemented into a connected car, it does certainly create the potential for a new startup idea for those fellow serial entrepreneurs out there ;)
As usual, if you liked this article, please support me by clicking LIKE and share it to your own feed! This is the best possible way that you can support me and my continued research in this area. If anyone has any comments or additional ideas for mitigating evil twin attacks in a connected car, please feel free to share it with everyone below in the comments section!
Meet Alissa Knight Alissa Knight is the Group CEO of Brier & Thorn and heads its Connected Car Division where she and her team perform penetration testing and risk assessments of cyber-physical vehicles (CPVs) from OEMs in the United States, Europe, and Asia. As a recognized thought leader in the new Internet of Everything economy, Alissa can be found speaking at security conferences in North America and EMEA, vlogging, blogging, and writing contributed articles on the idiosyncratic cybersecurity issues affecting IoT that matter most. Learn more about Alissa Knight at her homepage at www.alissaknight.com, LinkedIn, listen to her weekly podcast episodes, or follow her on Twitter @alissaknight.