Hax0rz?  Sniffing My Critical Infrastructure?  It's More Likely Than You Think!

by Tim Tepatti

Part One: Building a V2X Wardriving Box for $200

If you haven't heard, both cars and Wi-Fi are going through big changes!  A spicy new topic has been racing through the automotive industry: the IEEE 802.11p standard!  An extension to the 802.11 standard which will add "Wireless Access in Vehicular Environments" or WAVE.

Why is this spicy, you ask?  Because this new 802.11p standard was introduced with the plan of connecting every car, heavy truck,traffic light, street sign, road sensor, etc. to the Internet.

Oh boy!  Nothing could go wrong with connecting critical infrastructure to the Internet, right?

So if I didn't have your attention before, hopefully I do now!  There's one major problem with these new standards, though: There's not enough community information on them!  Sure, you can go buy the IEEE standard.  Sure, you can go look for engineering documentation.  But there's no easy way for security researchers to actually get their feet wet with these new wireless standards in a simple way!

That's where I have to give credit to Harrison Sand1.  He published an amazing blog post fully detailing his forays into Vehicle-to-Everything (V2X) sniffing.  After reading it, I immediately:

This article will speed run you through building your own 802.11p wardriving box,and hopefully answer some questions on how 802.11p works along the way!  It builds off of Harrison's wonderful work, but tries to speed you through the small details to get you up and analyzing faster.  If you really want to do a deep dive into these new protocols, I'll add some handy keywords to search at the end.

Side Note:  If you're an automotive engineer who is disgusted at me breezing over small details, feel free to email me!  I'm always down to hear critiques and publish errata.

First, some background.  Let's get the acronyms out of the way.  Depending on what part of the protocol or standard you're looking at, the names could differ.  DSRC is the technology name, standing for Digital Short-Range Communications.  802.11p is the physical and MAC layer.  WAVE is the application layer, which stands for Wireless Access in Vehicular Environments.

The basic use case of DSRC is cars being able to communicate the road situation to each other to avoid accidents and increase overall safety.  Example:  Your autonomous vehicle malfunctions and the camera breaks.  Oh no, you can't use computer vision to recognize the color of the traffic light anymore!  No problem, the traffic light ahead is broadcasting its status over DSRC/802.11p!  Now your car knows the light is red and is able to brake.  It's a built- in redundancy layer to go with the rest of the sensors in the vehicle.  While it hasn't been put into any current generation cars, many companies are banking on the technology.

In 2018, General Motors stated that they planned on rolling out V2X to a portion of their vehicles by 2023.  That's only a few years away!  Plus, you can find your own sensors placed around town that are still under development, but live and broadcasting...

Now, the technical goodness!  DSRC is in the hella high gigahertz, yo!  It uses the 75 MHz spectrum between 5.850 and 5.925 GHz.  This means you can't use traditional Wi-Fi hardware, as most only does 2.4 GHz to 5 GHz!  Or uh, well - you can, you just need to use one that has hacked firmware and 5.9 GHz capabilities.  We're going to be using a modified Wi-Fi card and a custom-built Linux kernel to create our sniffer.  For software, we'll just be relying on Wireshark and tcpdump.  Easy-peasy!

Hardware

The main reasons for choosing this hardware are:

I ordered all of the above from pcengines.ch - they're a great embedded hardware developer from Switzerland.  While the shipping may take a week or two to get to the United States, I was able to order everything I needed in one purchase.  Alternatively, if you have a laptop with a miniPCIe slot on it, you can forego the APU entirely!  Just pick up the WLE200NX and you'll be able to mess with 5.9 GHz Wi-Fi.  Unfortunately, I won't be able to help you compile Linux for your laptop's architecture.

The only thing I would recommend buying in addition to the APU are some magnetic mounted high-gain antennas.  I opted for a cheap-o set of 7 dBi magnet-mounted RP-SMA antennas from Amazon.  I chose ones that had two coils mid-antenna, since the overall shorter length makes them stand out less when on my car.

Software

We need to build our own kernel for this step.  We're going to use OpenC2X (again, props to Harrison Sand for the recommendation!) and we'll need to be running Linux for the build environment.

First, install dependencies:

$ sudo apt install git build-essential libncurses5-dev zlib1g-dev unzip python

Clone the OpenC2X embedded git repo:

$ git clone https://github.com/florianklingler/OpenC2X-embedded.git

Update the feeds:

$ cd OpenC2X-embedded
$ ./scripts/feeds update -a
$ ./scripts/feeds install -a

Create kernel configuration file:

$ ./create_config.sh x86_64
$ make defconfig

Bring up kernel configuration menu:

$ make menuconfig

Then, select all of the following to add to your kernel:

Network > tcpdump
Network > firewall > iptables > iptables-mod-tee
Network > Time Synchronization > chrony
Utilities > strace
Utilities > grep
Utilities > Shells > bash

Build OpenC2X, where "X" in -jX is your core count + 1:

$ make download
$ make -jX V=s

(for my poor single-core Centrino, I was running -j2)

Now you just wait a million hours and your finished OpenC2X Embedded image will land in: ./bin/targets/x86/64/

Now we just need to flash it onto the APU2.  To do this, we'll use the PC Engines recommended method of making a bootable TinyCore Linux USB.

To do so, download the file TinyCore6.4_2017.tar.bz2 from the PC Engines website2.

Unzip it somewhere like Documents or Downloads - you'll need to copy these files later.

Next, insert a blank flash drive into your computer.  Install GParted and syslinux:

$ sudo apt install gparted syslinux

Open GParted, select your flash drive and click "Device -> Create Partition Table".

Your device will now be 100 percent free space.  Right-click on the unallocated space and click "Create New Partition".

Increase the size until it takes up all of the unallocated space, and set the file system to FAT16.

Now, you'll need to make the flash drive bootable using syslinux.  Open up a terminal and type df -h to find the block name of your flash drive.  If you only have one HDD (/dev/sda1), the flash drive will most likely be /dev/sdb1.

Always be sure to check the size of the device to ensure it matches the flash drive you inserted.  If you accidentally f*ck with one of your HDDs, you won't have a good time!

Since my USB is located at /dev/sdb1, that's what I'll be using:

$ syslinux -i /dev/sdb1

The -i flag will install it on your flash drive, and if you browse your flash drive in your file browser, you'll see new files: ldlinux.sys and ldlinux.c32.

At this point, we're ready to copy the TinyCore files!

Open up your file browser and browse to where you extracted the TinyCore Linux archive from the first step, and copy all of the extracted files to the root of your flash drive.

Your USB should now contain:

autostart.sh
core.gz
ldlinux.c32
ldlinux.sys
syslinux.cfg
vmlinuz

We need one last file!

Copy your new OpenC2X image over to the flash drive as well.  It's located in your OpenC2X Embedded folder at ./bin/targets/x86/64/ and should be called: lede-x86-64-combined-ext4.img.gz

Plug the APU into your computer using the included DB9 to USB adapter and connect to it with the following command:

$ minicom -D /dev/ttyUSB0 -b 115200

(If you don't have Minicom, just sudo apt install minicom)

Plug your TinyCore Linux flash drive into the bottom USB port on your APU and turn it on.  Your Minicom console should come alive and you'll be root!

Browse to the root of your USB (should be /media/TINYCORE/, but it may differ based on your flash drive) and run the following commands:

$ gunzip lede-x86-64-combined-ext4.img.gz
$ dd if=lede-x86-64-combined-ext4.img of=/dev/sda bs=4M
$ sync
$ sync

Congrats, you've flashed OpenC2X!  Remove your USB and reboot, and you should boot directly into LEDE.

Capturing Packets

I highly recommend making scripts for this part.  You're going to be performing four basic steps to start capturing packets:

I've broken it down into three scripts and one command:

This script will set up the wireless interface and join the OCB network.  The 5900 designates the 5.9 GHz band.  Once you run this, you can use iw phy0 info to ensure that it's working correctly, along with: iw wlan0 info

bring_up_interfaces.sh:

#!/bin/sh
iw reg set DE
iw dev wlan0 set type ocb
ip link set wlan0 up
iw dev wlan0 ocb join 5900 10 MHZ

We want to enable Monitor Mode so that we can capture packets using our APU.

This script will put both of the wireless interfaces into Monitor Mode, just to be safe.

enable_monitor_mode.sh:

#!/bin/sh
iw dev wlan0 interface add wlan1 type monitor
ifconfig wlan1 up
# Enable promiscuous mode (not sure if this is necessary on both interfaces,
# shouldn't hurt either way)
ifconfig wlan0 promisc
ifconfig wlan1 promisc

This script will rotate through the channels located in freq.txt.  This is to get proper coverage of the entire 802.11p spectrum, not just a single channel.

This script has to stay running in the background while you run tcpdump.

freq_rotate.sh:

#!/bin/sh
# Credit to Harrison Sand
# All I did was modify it to infinite loop
iw dev wlan0 ocb leave
while :
do
  for freq in $(cat freq.txt); do
    echo "$freq 10MHZ"
    iw dev wlan0 ocb join $freq 10MHZ
    sleep  1
    iw dev wlan0 ocb leave
    echo "$freq 5MHZ"
    iw dev wlan0 ocb join $freq 5MHZ
    sleep 1
    iw dev wlan0 ocb leave
 done
done

This is a list of the different channel frequencies within V2X/802.11p.

For usage with freq_rotate.sh to jump between the different frequencies.

freq.txt:

5850
5855
5860
5865
5870
5875
5880
5885
5890
5895
5900
5905
5910
5915

The final step is to run tcpdump.  This is the tool that will actually dump our packets into a PCAP file that we can later analyze with Wireshark.

It's recommended that you have two tcpdump sessions running - one to send packets to a PCAP file, and the other dumping packets to the terminal, so you can stay aware of what's going on.  Those two commands are listed below.

# output to pcap for later analysis in Wireshark
$ sudo tcpdump -s 0 -i wlan1 -w foo.pcap
# output to console
$ sudo tcpdump -i wlan1

And congrats, now you can capture PCAPs!  I highly suggest throwing your APU in your vehicle and driving around town to hunt for V2X devices.  I was able to find dozens of devices installed around me, usually around automotive suppliers and manufacturer's facilities.  From here, you can also expand the scripts and commands that were given.  Make them start at boot, or even parse the packets and react to them in some way.  The APU runs Linux, so the world is your oyster.

In Part 2 of this article, I'll go over how to parse the results of your sniffing in Wireshark, along with a summary of the current V2X device and transmission security that's been proposed.  In addition, I'll share a few thousand packets that I've captured around town from a few dozen V2X devices so you have some data to play with, even if you can't sniff any devices near you.

For now, I'll leave you with some handy keywords for aiding your research: V2X, DSRC, OSB, IEEE 1609.3-2016, SAE J2735, IEEE PSID Public Listing

As always, if you have any feedback, feel free to contact me.  I'm always open to suggestions or the possibility that I was wrong about something.

Happy hacking!

  1. harrisonsand.com/802-11p-v2x-hunting/

  2. pcengines.ch/file/TinyCore6.4_2017.tar.bz2

Code: bring_up_interfaces.sh

Code: enable_monitor_mode.sh

Code: freq_rotate.sh

Code: freq.txt
Return to $2600 Index