API on Wheels: A road trip of risky vulnerabilities

When was the last time you took a road trip? Depending on where you are in the world, it may only be a recent return to the agenda, but really, nothing is better than the open road and getting a change of scenery. 

Unless you’re a software vulnerability, of course.

We’ve spoken at length about the dangers posed by lax cybersecurity measures in the automotive industry, with the likes of Tesla and Jeep already working with security researchers, finding exploitable bugs that could have lead to serious safety issues if not discovered early and fixed promptly. We’ve also spoken about how, in general, software security is still in the Wild West. Software is everywhere we turn, and for many connected devices, vehicles, and their peripherals, the security measures needed go well beyond end-user education and vigilance. 

API vulnerabilities are becoming especially insidious, with malicious API traffic growing more than 300% in the past six months alone. This is rather concerning, given that modern vehicles are essentially APIs on wheels. They’re connected, very chatty with other applications, and could be caught up in targeted attacks as one of many vulnerable endpoints. 

When your EV charger says too much

Connected vehicles have come under scrutiny for their software safety, but what about their accessories? The genius crew at Pen Test Partners uncovered several code-level vulnerabilities in six home electric vehicle charging brands, as well as a widespread public EV charging network. 

Who cares about a charger? What could an attacker gain? Unfortunately, one of the downsides of powerful, deep tech working overtime for us is that generally, these devices have a bad case of TMI. EV chargers communicate with companion mobile apps via API, in a cloud-based environment, and all of that can be vulnerable to exploitation if not coded and configured securely. APIs, by design, open the floodgates for communication between apps, and if these endpoints are not carefully configured, too much could be shared - or worse - accessed via a vulnerable app backdoor.

Pen Test Partners discovered extremely dangerous vulnerabilities that could have lead to millions of EV chargers being hijacked, several instances of API authorization issues that allowed account takeover and remote control/access to an account, and even the possibility of disrupting the power grid through synchronized control of multiple EV devices. These issues were all patched, but the fact that a few lines of code were all that stood between attackers and complete disruption of core functionality and service infrastructure is deeply concerning. 

It’s not like it’s mastermind stuff, either. Wallbox, for example, had two insecure direct object references (IDOR) in their API, which would have allowed account takeover if exploited. IDOR falls under broken authentication, which sits at number two in the OWASP Top 10 API vulnerabilities. It’s as common as dirt, which points to a failing in the learning and implementation of quality code. We can’t persist with connecting sensitive devices and apps through a myriad of buggy communication pathways, and poorly configured APIs are just that. 

Working securely with automotive APIs takes education and patience

The frustrating thing with API security is that it is touted as a new wave of cybersecurity disaster to try and mitigate, when really, it’s just a new setting for the same old problems we have seen for decades in web development. Cross-site scripting, injection, misconfiguration: sound familiar?

Recent indicators from organizations like NIST are promising, and show that software security is becoming more regulated and standardized. However, we still fall well short of the required experts to even put a dent in the amount of safeguarding that needs to happen on the deluge of code that is written every day. Developers need to be elevated in their security knowledge and responsibilities, and it’s not on them to take the initiative. If you’ve got a team working on embedded systems in appliances, or APIs that could turn a car into someone’s remote control toy, then you must make sure they are equipped with what they need to stop introducing common vulnerabilities. 

The differences between a secure API and one vulnerable due to XSS are minimal, for example, but developers need to be shown the nuances that differentiate a poor coding pattern from a good one. In addition to that, lazy development processes are often business as usual in API configurations, with many given vast permissions over-and-above the minimum requirements for it to perform its set tasks, thus opening so much extra threat surface and potential data theft. These factors need to be considered during the build, but if they are not ingrained into acceptable development practices, the process will continue to be a risk factor.

Avoiding the new threat actor playground

The dramatic increase in APIs as a target of threat actors shows that attention is moving to a perceived low-hanging fruit… and in this instance, it is one that could be a pipeline to significant paydirt, in addition to potential threats to life in the form of potential vehicle takeover. 

Leaving API security up to chance is a sure-fire way to introduce problems later on, with potentially devastating consequences at worst, and frustrating rework and low performance at best. It should be a critical consideration as part of the communication ecosystem of software, and high on the list of a best-in-class security program. The key to this is treating each API as though it’s a human, and assessing what access it should have. Should Jim from Accounting have access to all sensitive legal documents for the entire company? Probably not, and generally, access control is correctly determined in the case of real-world personnel. The same cannot be said for APIs, and it’s important to remember that they are powerful chatterboxes that will let everyone know your secrets if they’re not configured with the same zero-trust methods of everything else.

The organization must be on high alert, and developers are the eyes needed on the ground to create quality code that is free from these vulnerable portals to despair. It’s time to give them the opportunity to grow and thrive as security-aware engineers, with the right mindset for this goal and the hands-on skills to make the right decisions in critical stages of creation.