Automotive security goes beyond the car

There’s been a fair share of attention paid to the security inside the connected car. There’s also been a significant uptick in new devices and apps that communicate with the vehicle from afar. These devices and apps use traditional means of communication (e.g., Bluetooth, Wi-Fi, etc.). They also make some very common software mistakes. For instance, lacking proper authentication of users and commands, potentially putting the end user at risk, both for physical harm and data loss.

Like many IoT products, aftermarket automotive products and services are often rushed to market. Who wouldn’t want to be able to start a car from a mobile phone? However, beyond the infinite ‘cool factor,’ it is clear many of these products can and do use information from the car in ways that supersedes industry best practices and basic security practices.

OBD-II

Located under the steering column of every domestic U.S. car built and sold since 1996 is the On-Board Diagnostics (OBD-II) port. It is similar in look to a conventional RS-236 port. What differs from OBD-I to OBD-II is specific access to the digital internals of a vehicle. Prior to the use of OBD ports, the internal diagnostics of a vehicle where limited to a dealership. The existence of OBD ports also allowed third parties to gain access.

OBD-II ports were designed with emissions testing and vehicle service in mind—not security. They were designed for direct physical access. However, with the affordability of telecommunications-enabled dongles, data that once was available only to a mechanic in a garage, has become available for others as well.

Dongles

The most common example are the dongles that plug into the OBD-II port that automotive insurance companies offer. If a customer agrees to have their driving tracked, the insurance company will generally offer a discount. These dongles can also be used to allow car owners—and car customizers—the ability to monitor vehicle diagnostics on their mobile phone.

This is not without some risk.

Research

Last year, Carnegie Mellon released a study on automotive security commissioned by the Department of Homeland Security (DHS) entitled “On Board Diagnostics: Risks and Vulnerabilities of the Connected Vehicle.” The report called out aftermarket devices. It cited OBD-II devices as a specific risk category. The researchers of that report discovered many vulnerabilities, among them:

• Insecure firmware updates and downloads
• Hardcoded or non-existent Bluetooth PINs
• Weak WPA2 passwords
• Hardcoded credentials
• An Internet-enabled administrative interface

Additionally, the researchers could conduct attacks including:

• Arbitrarily modifying firmware
• Maliciously updating remote firmware
• Locking/unlocking doors
• Turning the vehicle on/off
• Affecting vehicle GPS tracking, speed, heading, and altitude
• Reading the car’s internal data (e.g., temperatures, fuel levels, diagnostic trouble codes, etc.) and injecting arbitrary CAN packets

Drivelog

Other researchers were also looking at OBD-II ports. One recent example involved a vulnerability found in the Bosch Drivelog Connect. In this case, the dongle paired with a driver’s mobile device over Bluetooth. Through an app, Drivelog Connect then displayed the car’s current status. It also displayed information on fuel consumption, error messages, and various tips for drivers.

Researchers found two vulnerabilities. One, the most serious, was the dongle didn’t properly filter commands received from the smartphone app. So, in theory an attacker could inject their own commands. Bosch worked with the researchers and quickly issued a patch.

Apps too

It’s not just the OBD-II that creates risk. Last December, researchers found a vulnerability with Hyundai’s Blue Link app for mobile phones. The app allows car owners to remotely locate, unlock, and start cars. However, a vulnerability in the app itself allowed remote attackers to gain sensitive information about registered users and their vehicles (e.g., usernames, passwords, and PINs). Hyundai also worked with the researchers to quickly patch both the Apple and Android apps.

A similar flaw was identified in the mobile apps for Tesla last November. Researchers in China found a remote vulnerability for Tesla’s Model S. By attacking the mobile app, researchers could locate and track the car, open the doors, and enable its keyless driving functionality from a distance just by stealing the user’s authentication token. Although Tesla said the risk was small, it nonetheless issued a patch quickly via its over-the-air update to the car.

Not just vendors

In 2011, the Car Connectivity Consortium (CCC), representing 80% of the world’s automakers, helped create MirrorLink. MirrorLink is the first industry standard for smartphone in-vehicle-infotainment (IVI) connectivity. In 2016, research funded by General Motors, the National Science Foundation, and the Department of Homeland Security found that even MirrorLink had vulnerabilities allowing remote access to communications between a mobile phone and a car’s infotainment system.

Researchers in this case did not identify the specific OEM containing the vulnerabilities. At the time of the disclosure, a representative of the CCC suggested that the vehicle maker in question might have disabled some built-in security features of the standard. Both the CCC and the report sponsors agreed that more research was needed to test this and other auto industry standards.

PII

While there is appropriate concern about the safe mechanical and electronic performance of any vehicle on the road, there also needs to be concern around the personally identifiable information (PII) of the driver that becomes available with these devices. Apart from remotely disabling safety features of a car while it is on the road (e.g., brakes, lights, etc.), there is soft data (e.g., name, address, email) at risk as well.

Many third-party companies use OBD-II data to track the driving behavior of their customers. What if the collected geolocation data (i.e., the routes the driver takes in the vehicle) was then sold? In this case, businesses purchasing that data can serve the drivers passing by their business locations with targeted ads.

However, there are more ominous implications. With personal contacts and email, and even text visible on the dashboard or available via voice command to the driver, remote attackers can leverage existing vulnerabilities to eavesdrop on potentially sensitive information. Along with physical security, this risk also needs to be addressed by the automotive industry.

Conclusion

The National Highway Traffic Safety Administration (NHTSA)—if not the OEMs themselves—will need to consider the security risks posed by the proliferation of connected aftermarket automotive products. The timing is especially acute as Smart Cities initiatives are working out the details that will define what kind of Vehicle-to-Vehicle (V2V) and Vehicle-to-Grid (V2G) communications should be required. Such communication must be public to be useful, yet still respect the privacy of the vehicle owner.

Just as OBD-II created a thriving aftermarket, so too will these new communications vehicle protocols. And within these opportunities perhaps more risk.

It’s time to take the wheel