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.

Perimeter

8/24/2015
09:30 AM
Ken Munro
Ken Munro
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Keyless Cars: A New Frontier For Bug Bounties?

With up to 100 million lines of code in the average car today -- and growing -- security vulnerabilities are bound to become the new normal.

Convenience always seems to come at a cost and never more so than with the keyless car. News emerged last week that car manufacturers using the Megamos Crypto transponder electronic vehicle immobiliser, used by Audi, Citroen, Fiat, Honda, Volvo, and Volkswagen in over 100 models of car, had suppressed information on a security flaw for two years. The argument for public non-disclosure was to prevent compromises but is this a case of manufacturers putting their heads in the sand?

Well, yes and no.

It's not that manufacturers have a cult of secrecy when it comes to publicly disclosing security issues. It’s more that they need a decent time window in which to assess and remediate problems. Think of the complexity of identifying exactly what the problem is, depending on how a researcher approaches a manufacturer and what sort of information they provide. Then consider the logistics of putting together and deploying a patching/update solution that'll work perfectly 100% of the time. Automakers may also need to change a range of product roadmaps for other models and for future releases. It's a big job, and not one that I envy.

One big challenge is deploying security updates to the vehicle. Tesla, for example, has the ability to roll out over the air (OTA) updates, which makes fixing bugs relatively easy. Others without this facility are reliant on updating the car when it comes in for a service, or a costly recall. That could mean a year or more before it gets an update.

OTA also comes with challenges: Does it encourage an attitude of security complacency  -- "It’s OK, we can fix bugs later" -- rather than "get it right first time?" Yes, to a certain extent, although, as we all know, it’s tough for any developer to write code that defends against all current and future security issues.

At Pen Test Partners, we've privately disclosed similar vulnerabilities to manufacturers in the past and have had varied responses, ranging from those eager to hear us out and implement a solution to the apathetic or downright hostile. In my mind, private, responsible disclosure to a manufacturer is always the right thing to do. Sitting on information simply widens the window for the vulnerability to be discovered, publicly disclosed, and exploited. Procrastinating for two years, after which just a single sentence was removed from the research teams’ paper presumably for legal reasons, has made these manufacturers look out-of-step with security and unwilling to put the customer first.

So how should the Megamos Crypto vulnerability have been handled? These are all huge brands and the fallout could be highly damaging both in terms of customer confidence and product recall. Even more important, the recall cost could have gone into more proactive security initiatives such as a bug disclosure program. A nice example is the United Airlines bug bounty program, which gives away frequent flyer points to researchers who point out flaws. A simple web page, an email address, and someone to handle it are all it takes to create a clear avenue for bug disclosure, in effect giving the manufacturer access to a free resource of intelligence.

But what do you do if, like me, you’re one of those that owns a keyless car? How do you ensure you don’t become a victim of car theft, given that four out of ten thefts in London last year were down to electronic hacking, and that’s before this exploit was publicized? (One could argue that these statistics alone should have motivated the manufacturers to disclose). Unfortunately, as with any product, the customer is very much at the mercy of  a manufacturer notifying customers of security vulnerabilities and software updates.

Still, there are steps individuals can take to protect  themselves. For one thing, we recommend that owners of "keyless" cars treat the smart key differently than regular keys. Consider getting a radio frequency (RF)-shielded pouch to keep your smart key in, and only get it out when you want to get in your car. Keep your smart key far away from your parked car, i.e. not in the hallway that is two metres from your car outside on the drive. I'm rolling both of these ideas into one and having a key cabinet made for my kitchen: it'll be lined with shielding fabric and it's at the back of the house, so it should do the job nicely.

With reports suggesting there’s up to 100 million lines of code in the average modern car and set to increase to 200-300 million in future years, we have to accept that security vulnerabilities – and patching them – will become as normal for our car as our PC. The car industry can help make this more streamlined by implementing disclosure programs rather than burying information. And we as consumers will also have to take precautionary measures until they up their game.

 

Ken Munro is Partner and Founder of Pen Test Partners LLP, a firm of experienced penetration testers, all of whom have a stake in the business. He regularly blogs on everything from honeypots to hacking cars and also writes for various newspapers and industry magazines in an ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
8/26/2015 | 11:45:29 PM
They don't build 'em like they used to.
Of course, an easier solution is to simply buy an older, pre-owned car -- saving both security headaches and money.  ;)
mwalters662
50%
50%
mwalters662,
User Rank: Apprentice
8/25/2015 | 12:15:46 PM
RF Shielding
Actually, RF shielding would best be implemented in the FOB itself. A button to activate the transponder or disable it.
Ken_Munro
50%
50%
Ken_Munro,
User Rank: Apprentice
8/25/2015 | 7:59:35 AM
Re: Wow
You're quite right, if it's not OTA then the update needs to be made with a hard-wired or similar local connection, by the dealer.
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
8/24/2015 | 1:19:43 PM
Wow
RF shield may be a good idea. If you could have it hook onto the key ring and have the ease of shielding and unshielding be a few second process, I don't think any would oppose.


As for updating, for the non-OTA updates do you need to return to the dealer to have them cable in updates? Or how is this performed?
For Cybersecurity to Be Proactive, Terrains Must Be Mapped
Craig Harber, Chief Technology Officer at Fidelis Cybersecurity,  10/8/2019
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
USB Drive Security Still Lags
Dark Reading Staff 10/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17552
PUBLISHED: 2019-10-14
An issue was discovered in idreamsoft iCMS v7.0.14. There is a spider_project.admincp.php SQL injection vulnerability in the 'upload spider project scheme' feature via a two-dimensional payload.
CVE-2019-17553
PUBLISHED: 2019-10-14
An issue was discovered in MetInfo v7.0.0 beta. There is SQL Injection via the admin/?n=tags&c=index&a=doSaveTags URI.
CVE-2019-17408
PUBLISHED: 2019-10-14
parserIfLabel in inc/zzz_template.php in ZZZCMS zzzphp 1.7.3 allows remote attackers to execute arbitrary code because the danger_key function can be bypassed via manipulations such as strtr.
CVE-2019-17545
PUBLISHED: 2019-10-14
GDAL through 3.0.1 has a poolDestroy double free in OGRExpatRealloc in ogr/ogr_expat.cpp when the 10MB threshold is exceeded.
CVE-2019-17546
PUBLISHED: 2019-10-14
tif_getimage.c in LibTIFF through 4.0.10, as used in GDAL through 3.0.1 and other products, has an integer overflow that potentially causes a heap-based buffer overflow via a crafted RGBA image, related to a "Negative-size-param" condition.