This article is the first in a series of three about vulnerabilities and attack vectors on automotive platforms and is a collaboration between work done in a team consisting of Coalfire employees Bryan Alexander, Gerardo Iglesias, and myself.
Hands-free calling via Bluetooth was first introduced to vehicles in 2004, and the USB port was introduced in 2006. Web technologies, wireless connectivity, app stores, and smart phone integration has seen explosive rises in popularity over the last few years. As the capabilities of consumer electronics and software continues to grow, so too does our demand for its availability. Fridges can tweet, sprinkler systems can tune themselves to weather forecasts, and vehicles can stream HD videos over wireless connections. This availability of utility coupled to the physical world introduces entirely new vectors of not only use, but also of abuse. In order for these physical things to provide utility, they need to be increasingly more powerful, modular, capable; the ability to process unknown, potentially malicious data and input is of grave concern and yet absolutely essential to consumer usability.
At Coalfire Labs, we’ve spent the last couple of years working with various car manufacturers to evaluate and attempt to compromise implementations of in-vehicle infotainment systems (PDF). These systems are the consumer-facing interfaces to the vehicle’s internal subsystems; all user and device input is funneled and filtered through this and forked out to other subsystems, including the power steering, brakes, and air bag control. These infotainment systems expose GPS, navigation, media playback, phone and MP3 player interfaces among others. If any of these interfaces consumes data in an insecure way, the consequences could be catastrophic. This post will attempt to describe a few of these vectors and their implications, as seen in the wild. Vendor names and identifying information have been removed to protect NDA’s, but the technical details are otherwise unaltered.