Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

4/5/2016
11:15 AM
Craig Smith
Craig Smith
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

How to Hack Your Own Car

As vehicles become more software-driven, car manufacturers are keeping the inner workings of electronics systems more secretive. Here's one way to maintain security updates and still preserve your 'freedom to tinker.'

Car hacking continues to be a popular news trend -- so much so that hackaday.com named 2015 the “Year of the Car Hacks” -- and the interest does not seem to be slowing down in 2016. Just last month we heard of thieves successfully using keyless entry system hacks on 24 different car models, around the same time the FBI issued its first public safety warnings on malicious car hacks threats.

When an attack like this is made public, auto manufacturers are generally faced with three options: a full recall of the affected vehicles, a mail-out of USB disks loaded with updates, or over-the air (OTA) patches. Manufacturers tend to prefer the OTA option as the least costly (and least conspicuous) of the three. However, OTA updates have their own security risks, and without proper checks in place they can allow a path for attackers to inject malicious data.

In order for OTA updates to be performed securely and effectively, a PKI infrastructure must be in place to encrypt and sign the update packages. When done in conjunction with PKI, OTA updates provide an efficient way to apply patches to an entire fleet of vehicles quickly and quietly. That’s great! But here’s the problem with implementing PKI with vehicles: it makes it extremely difficult for consumers to manage their own software updates.

Freedom to tinker

The fact is, many vehicle owners want to feel that they can do what they want with their cars; if they’d wanted to lease a vehicle they would have signed a leasing agreement. There is a long history of owners “hacking” their cars, going back to the time before vehicles were primarily run off of software, and when home vehicle modifications and Mom & Pop repair shops were on every street corner. We love customizing our vehicles. But as vehicles become more electronic, manufacturers are keeping the workings of the electronic side ever more secret in order to keep their “competitive advantage.” This means that if you want to modify or add a component and have it integrate with the vehicle, you need to be able to reverse-engineer the vehicle network and/or the firmware.

Image Source: Craig Smith
Image Source: Craig Smith

Personally, I feel this extra hurdle is unnecessary and will exclude a lot of people who don’t have the skills or tools. Fortunately, with the adoption of the Class 21 DMCA Exemption ruling last fall, it is now legal to post information online and collaborate on the inner workings of your vehicle without threat of suit. This is great news for digital rights advocates. But when you consider the move to implement a PKI key system for updating firmware, the question remains: How do you implement a private/public key system and still allow people to make modifications? Can you preserve the right to tinker and still maintain a secure update process?

This is one of the new challenges facing the auto industry. People feel very strongly about being able to modify their vehicles, or at the very least buy third-party parts or visit non-manufacturer repair shops to get better deals on repairs. But if there is a lockout on unsigned changes, will these options become virtually impossible?  

Implementing PKI securely

Let’s start with a normal PKI update as an example. The vehicle is in an idle state (perhaps charging at night) and is notified of a software update. The vehicle fetches the update, checks the signature, verifies via a secure bootloader that the update is signed by the manufacturer, and then updates itself. What we want to avoid is a hacker sending unsigned code to the system, but at the same time we as owners want to be able to send unsigned (or at least not signed by the manufacturer) updates and modifications.  

One method to allow this would be to include a physical override switch. If the switch were difficult enough to get to -- for example, someone would need to be able to access the inside of the car to switch it, say, physically on the ECU unit under the glovebox -- then setting this switch to allow unsigned code would provide little security risk while allowing you to make your own modifications. When the vehicle receives an update from you that wasn’t signed by the manufacturer it would check to ensure the switch had been set before allowing you to upload your custom update.

It’s important to note, though, that once you upload code via this switch, you could not go back! The vehicle would mark itself as “tainted” in the secure bootloader so that your warranty is voided. If you then sold the vehicle it would be easy to verify that the vehicle’s firmware has been modified. This is the equivalent of a Void Warranty sticker and uses the same methodology Google used on the original Chromebooks.  

This is just one potential method, and these update systems have yet to be developed, but here’s hoping that as the auto industry reviews newer, safer ways to manage vehicles, they don’t forget about the right to tinker.

Related Content:

 

Interop 2016 Las VegasFind out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Click here for pricing information and to register.

Craig Smith is the author of The Car Hacker's Handbook. He runs Theia Labs, a research firm that focuses on security auditing and building hardware and software prototypes. He has worked for several auto manufacturers and provided them with his public research. He is also a ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
zombieCraig
50%
50%
zombieCraig,
User Rank: Author
4/6/2016 | 12:51:45 PM
Re: Why hack stock?
It will affect diagnostic equipment.  It will not affect the OBD port itself.  However there is a lot of discussion about changing the OBD port for other reasons.  For instance, the only reason OBD-II is a standard is emmissions testing.  All the other things we have done with it are not mandated standards and can be changed at any time.  There is a growing concern about 3rd party OBD dongles being plugged into vehicles that open up the attack surface allowing cellular links direct access to your vehicle bus.  OBD ports may change a bit but not because of encryption.

A lot of the diagnostic service codes (DSCs) that are generated by things like the gas cap will also go to "the cloud" and you will be able to view them on your cell phone or they will be sent directly to the dealer.  They will still be local to the vehicle as well and you will still need a way to direclty access it but queriering DSCs doesn't require the modification of firmware, so they would still function even on updated encrypted systems.
theb0x
50%
50%
theb0x,
User Rank: Ninja
4/6/2016 | 11:56:50 AM
Re: Why hack stock?
Do you think this will change the OBD interface? If that is the case all automotive technicians would need to replace most if not all of their diagnostic equipment. I see this having a negative impact within the industry.

As it is right now on a modern vehicle a diagnostic code must be obtained just to determine that the gas cap is loose.
zombieCraig
50%
50%
zombieCraig,
User Rank: Author
4/5/2016 | 7:39:46 PM
Re: Why hack stock?
You are thinking of the work that has been done now. When all communication on the vehicle is encrypted, those none stock replacements will have to be more than just the ECU but every module that utilizes encryption. Soon, if we don't address the issue the only option will be stock.
theb0x
50%
50%
theb0x,
User Rank: Ninja
4/5/2016 | 7:36:01 PM
Why hack stock?
I don't really see the benefit of hacking a stock ECU when an aftermarket one has no limits to it's functionality. There is nothing to reverse engineer.
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
AWS CISO Talks Risk Reduction, Development, Recruitment
Kelly Sheridan, Staff Editor, Dark Reading,  6/25/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-10133
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The form to upload cohorts contained a redirect field, which was not restricted to internal URLs.
CVE-2019-10134
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The size of users' private file uploads via email were not correctly checked, so their quota allowance could be exceeded.
CVE-2019-10154
PUBLISHED: 2019-06-26
A flaw was found in Moodle before versions 3.7, 3.6.4. A web service fetching messages was not restricted to the current user's conversations.
CVE-2019-9039
PUBLISHED: 2019-06-26
The Couchbase Sync Gateway 2.1.2 in combination with a Couchbase Server is affected by a previously undisclosed N1QL-injection vulnerability in the REST API. An attacker with access to the public REST API can insert additional N1QL statements through the parameters ?startkey? and ?endkey? of the ?_a...
CVE-2018-20846
PUBLISHED: 2019-06-26
Out-of-bounds accesses in the functions pi_next_lrcp, pi_next_rlcp, pi_next_rpcl, pi_next_pcrl, pi_next_rpcl, and pi_next_cprl in openmj2/pi.c in OpenJPEG through 2.3.0 allow remote attackers to cause a denial of service (application crash).