Foreword
Automotive cybersecurity is perhaps the most unique and challenging security problem humankind has ever faced. We have thousand-pound machines traveling at high rates of speed, carrying human lives and critical cargo, surrounded by other identical machines now becoming fully connected, automated, and even communicating with their surroundings. With a broad spectrum of new technologies entering into the automotive space to facilitate these new capabilities and features, the average vehicle can require 10–100+ million lines of code and need to manage multiple protocols. With the ever-growing complexity of vehicles, it’s easy to imagine how many potential security flaws could exist in any given vehicle.
As the former global lead for the vehicle security assurance program at Fiat Chrysler Automobiles (2017–2019), I was faced with tackling this complex challenge every day utilizing several tools. One of the most versatile tools that I leveraged was an industry outreach program. Through this program I connected with independent researchers to encourage and facilitate security research against our systems. It was through the efforts of that program that I came across Alissa Knight for the first time. Alissa’s efforts and publications fill a huge gap in education and awareness both for automotive industry companies and fellow researchers alike. I personally have grown as a professional and as a hacker directly through watching and reading Alissa’s publications.
This security challenge is a challenge for society; therefore, society as a whole should be trying to solve it, not just the businesses making the product. Alissa is a champion for security awareness and best practices, driving a more secure and safe future for us all. I hope that the contents of this book, and Alissa’s several other publications, help you become a more aware and secure individual. Use the contents responsibly, join a local security research group, and take Alissa’s example to give back to the community so that we all can benefit.
Introduction
“Strategy requires thought; tactics require observation.” —Max Euwe
On May 7, 2002, Bennett Todd announced on a vulnerability development mailing list that he stumbled upon a UDP port when performing a wireless network audit, which turned out to be a port used for remote debugging in VxWorks, a real-time operating system (RTOS) developed by Wind River Systems, now owned by Intel. The port was left enabled by default on some wireless networking products he was auditing. Little did Todd know that his discovery, port 17185/UDP, would later lead to a much more widespread vulnerability affecting a much greater number of different connected devices running VxWorks.
Eight years after his post in August of 2010, HD Moore stood in front of an audience at Defcon 23 and presented his research findings into VxWorks after performing exhaustive testing of every device since Todd’s initial post in 2002.
In a vulnerability note released on August 2, 2010 by Wind River Systems, this port turned out to be its WDB target agent, a target- resident, runtime facility that is required for connecting host tools to a VxWorks system during development. The WDB debug agent access is not secured, and through a memory scraping vulnerability discovered by Moore, leaves a gaping security hole in deployed systems using VxWorks that allows a remote attacker to carve data remotely out of memory without valid credentials.
At the time of his discovery, Todd had only mentioned wireless access points in his post as being affected, not realizing that VxWorks is a real-time operating system for embedded systems used in much more than just his wireless access point. Wind River is used in other systems, including the Thales’ Astute-Class submarine periscopes, the Boeing AH-64 Apache attack helicopter, the NASA Mars Rover, even BMW’s iDrive system for models made after 2008—just to name a few.
In virology, when a virus is introduced into a new host species and spreads through a new host population, it’s referred to as spillover or cross-species transmission (CST). This same thing happens in information security where a vulnerability published for a target device or product causes spillover into other products that wasn’t originally anticipated.
In 1996, the German company Rohde & Schwarz started selling the first IMSI catcher (GA 090) that allowed a user to force an unidentified mobile subscriber to transmit the SIM’s IMSI and later, in 1997, allowed the user to tap outgoing phone calls.
At Blackhat Briefings Asia in April of 2001, Emmannuel Gadaix unveiled the first known GSM vulnerability through a man-in-the- middle (MITM) attack and deregistration Denial of Service (DoS) attack affecting mobile phones.
Later in 2010, Karsten Nohl released a cracking tool for A5/1 encryption used to secure GSM traffic known as Kraken, which leverages rainbow tables for cracking A5/1 encryption, later referred to as the “Berlin Tables.” Nohl’s tool was later usurped by Kristen Paget that same year, who revealed at Defcon 18 how to use a rogue cellular base transceiver station (BTS) or IMSI catcher to intercept mobile phone calls and SMS text messages, which didn’t require cracking at all.
While these vulnerability discoveries in GSM at the time were originally aimed at mobile phones and their users, they would later cause vulnerability spillover into the automotive sector that today’s connected cars and autonomous vehicles heavily rely upon for communication to their backends for OTA (over-the-air) updates and other features.
In her presentation, Paget used a Universal Software Radio Peripheral (USRP) costing roughly $1,500—hundreds of thousands of dollars cheaper than the first GA 090—and presented the idea that instead of sniffing the GSM calls and SMS text messages for offline cracking, an alternative concept was possible. Paget used a cell phone to create the base station hooked up to her laptop, thus was able to disable A5/1 encryption entirely, rendering the need to crack the streams offline superfluous.
Paget, who later began working for Tesla—no doubt applying her previous research in hacking mobile networks to securing connected cars—now works for Lyft as a hacker. Paget’s observation during the conference that the GSM specification itself requires a warning notification to the user when encryption has been disabled (A5/0) on the network, and that this warning is intentionally disabled on cellular networks, is especially alarming and underscores a systemic problem with mobile phone carriers on whom automakers rely for their telematics infrastructure.
Just three years ago in 2015, at DEF CON 23, Charlie Miller and Chris Valasek demonstrated remote exploitation of an unaltered passenger vehicle—different from their first presentation, which required physical access to the car and its diagnostic port. This time, Miller and Valasek demonstrated how vulnerabilities in the automobile’s head unit allowed them to communicate with TCP/6667 (dbus) without authentication, allowing them to send commands to the system to be executed over the head unit’s Wi-Fi hotspot. These attacks became more devastating as they leveraged poor firewalling in the mobile carrier’s cellular network that allowed them access to the dbus port to perform the same attacks over the telematics control unit’s (TCU) GSM interface. By modifying the firmware and reflashing the Renesas V850 microprocessor after downloading the firmware from the internet, they were able to reprogram the microprocessor to send CAN messages directly to the CAN bus that the head unit was connected to and physically take control of the car, such as pushing the brakes, turning the steering wheel, turning the power off on the car, moving the windshield wipers, and manipulating the stereo.
This demonstration of hacking a connected car was the first published research into hacking connected cars remotely. Other published exploitation techniques required physical access or connectivity to the ODB-II (debug) port of the car.
