Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Automotive Security: It’s More Than Just What’s Under The Hood

True auto safety can only be achieved by knowing what every piece of code and hardware is that goes into the car.

It’s a cool Saturday evening as I head out for a night on the town with my wife and some friends. We’re in a late model German made vehicle driving – below the speed limit – as we drive onto the open road. While focusing on the road I notice a strange effect happening to the radio as I accelerate down the highway. The faster I drive, the radio turns itself up to account for the road and wind noise made against the car. Surprisingly this has been a standard feature on mid-to-premium cars for the past 10-15 years.

What it illustrates is even more interesting. The physical push of my foot against the gas pedal does two things in this case. It pulls against the throttle valve letting more air into the engine, increasing the car’s speed; and it sends a signal to one of the computer boards that handles messages between the engine control unit and the radio control unit, thus increasing the volume of the radio accordingly.

Vehicle Attack Surface -from the Car Hackers Handbook

A decade ago, these computer control boards were separate from each other and independently controlled. Now, these control units all talk to each other through a central brain box – typically running a version of an embedded Linux operating system. The need for a more significant operating system, and the need to have all these control units talk to each other, is at the heart of the modern day auto-hacking craze.

The vulnerabilities that have come to light in the past four-to-five years are significant, but also generally harder to exploit for the average attacker. Over the past decade, vehicles have become even more digitally connected – with many of them now including always-on 4G connectivity. While driver and occupant safety have always been of paramount concern, the new technology has had its fair share of attention given to it, but not enough.

Many concerns continue to be uncovered, such as a simple flaw in how API calls were handled by the Nissan Leaf, allowing anyone on the internet to remotely turn on or turn off the air conditioning system by knowing the VIN number.

Say someone in a Nissan Leaf parked poorly at the local electronics store. Instead of leaving a nasty note, you could simply send this:

By just using this string from any browser, the vehicle would automatically turn on its air conditioning. As you can see from the reply (status: 200 “success”), the call to the ACRemoteRequest (as seen above) function is less a security flaw and more of an application design failure. A similar request can be sent to ACRemoteOFFRequest to turn the AC off.

I know that turning someone’s AC on or off doesn’t really make for an exciting episode of CSI, but if you were to look at where this simple API call falls in relation to the below threat pyramid, it would be at the bottom, as it’s Remote Code Execution (RCE).

Now, if a similar request was crafted for a service that was also poorly protected, and that service was responsible for controlling the vehicle’s acceleration or brake system, this would be a front-page story.

You might think that making secure code is the sole answer. But with APIs, and the deserialization process, more insecurities lay beneath. Insecure de-serializers are known to be susceptible to RCE attacks. As the de-serializers work on the layer before the application logic starts, developers typically have no control over it. In fact, this problem has been so pervasive that OWASP has added Insecure Deserialization as number eight on the latest OWASP Top 10.

2API Client Request Process Flow

There will always be complications arising from the intersection between software and hardware. There are some flaws that seem like a simple lack of foresight, and how easy it can be to take advantage of simple workflows.

Take, for example, the AutoCode program. AutoCode allows for the ability to input a vehicle VIN number, and for a small fee after accepting the “conditions of use” agreement, you get everything you need to program your own key fob for that vehicle. Luckily for the bad guys, the MVP Pro Universal Auto Key Programmer is available for anyone who wants to do this themselves. A simple search on eBay will reveal many options for purchase.

Now, it’s possible these problems could be fixed with software updates. However, the auto industry is racing to catch up with the idea of making over-the-air (OTA) updates freely and efficiently available instead of manual updates at the dealer. One of the challenges in this area was highlighted by Dave Bares of Lear Corp, who said, “One of the reason that OTA updates are hard is because we don’t have a good software inventory.”

Having the ability to reliably monitor software versioning and ensure that software packages are not tampered with before they are delivered to the vehicles is of paramount importance. It’s one of the more interesting things CDN platforms are perfectly made to support.

There have been two large leaps forward in the last two years: One has been the introduction of Automotive Grade Linux. It was introduced in the 2018 Toyota Camry, with the aim of making the underlying software that goes into these vehicles more secure.

The second advancement is the formation of the Automotive ISAC organization. Their goal is to introduce best practices from Secure by Design methodologies to Security Awareness training for the industry.

As we work toward the removal or correction of insecure software and hardware components in the automotive ecosystem, we must be mindful to ensure that every step in the supply chain is secured.

Making advancements in this area can only be done by knowing what every piece of code and hardware is that goes into the car, and what third-party resources are being relied on to complete this process.

(TonyLauro manages the Enterprise Security Architecture team at Akamai Technologies. With over 20 years of information security industry experience, Tony has worked and consulted in many verticals including finance, automotive, medical/healthcare, enterprise, and mobile applications. He is currently responsible for Akamai‘s North America clients as well as the training of an Akamai internal group whose focus is on Web Application Security and adversarial resiliency disciplines. Tony‘s previous responsibilities include consulting with public sector/government clients at Akamai, managing security operations for a mobile payments company, and overseeing security and compliance responsibilities for a global financial software services organization.)

The vendor also issued a patch schedule for the still-unpatched bug in its Secure Boot trusted hardware environment, which affects most of its enterprise and SMB portfolio, amounting to millions of vulnerable devices.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.