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.
Moreover, we’ve observed keycodes and fraudulent key fobs for sale online.
fraudulent key fobs for sale online
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.
(Tony Lauro 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.)
