Threat Actors, Car Systems, and Weak API Security

Executive Summary

The comfort of interior pre-heating, pre-warning of car failures, and the integration of GPS systems are all amenities that car owners have experienced and enjoyed. Nevertheless, these joys come at a cost other than the actual cost of the car.

In the fall of 2022, a group of white hat hackers found at least 20 vulnerabilities within application programming interfaces (API) of various auto brands and automotive-related products. An API is typically behind any interaction between a vehicle and its user. The discovered vulnerabilities affected well-known brands such as Toyota, Mercedes, Porsche, Ferrari, and others.

While many people appreciate the features offered by automobile manufacturers, few are aware that they are operating a device that could become a target for a malicious attacker. To understand the risk, let's examine how threat actors can compromise car systems and the drawbacks of automotive companies relying on the third-party management of their APIs.

TIR SNAPSHOTS

• In early November of 2022, security researcher Sam Curry and his team discovered vulnerabilities in the mobile apps for Hyundai (MyHyundai app) and Genesis (MyGenensis app) car models after 2012.

• The vulnerabilities allowed unauthenticated remote attacks that involved unlocking and starting vehicles.

• Hyundai's apps were compromised due to vendor failure to properly authenticate/authorize users and filter/interpret output data.

• Over several months, Curry and his team documented their work exploring the security of third party telematic systems, automotive APIs, and the supporting infrastructure. They found as many car vulnerabilities as they could, and their findings were startling.

• The analysts were able to access personally identifiable information (PII) of the owners of Kia, Honda, Infiniti, Nissan, BMW, Ferrari, and Acura by exploiting API flaws.

• Researchers attribute the widespread vulnerabilities to weak APIs run by third parties and the pressure for automakers to be innovative with what they provide consumers.

• Rushing to launch new API releases in the market can result in shortcuts being taken in security implementation.

• API attacks are the result of weak application security, but there are ways that organizations (not just car manufacturers) can identify their weaknesses and ensure they aren’t victims.

Car System Compromises

Hyundai

In early November of 2022, security researcher Sam Curry and his team discovered vulnerabilities in the mobile apps for Hyundai (MyHyundai app) and Genesis (MyGenensis app) car models after 2012. The vulnerabilities allowed unauthenticated remote attacks that involved unlocking and starting vehicles. During the same year, Curry discovered a flaw in the telematics and infotainment systems for SirusXM. The security researchers found that the issues in the mobile apps were similar to the attack surfaces in the SiriusXM “smart vehicle” platform used by Honda, FCA, Nissan, and Toyota. The SirusXM flaw allowed him to remotely unlock and start cars.

Image 1: Hyundai Vulnerability

Curry explained that the journey began when he and other analysts were eager to explore potential security issues affecting vehicle telematics services. Prior to Curry’s efforts, most research on the subject focused on crypto attacks on physical keys, but there was limited research regarding website attacks. Curry and his team of analysts used Burp Suite to proxy all app traffic and observe the API calls taking place.

Image 2: HTTP Request to Unlock the Car

After investigating, the analysts discovered that the owner is validated based on the user’s email address, which is included in the JSON body of POST requests. The analysts also discovered the MyHyundai app didn’t require email confirmation during the registration process. They were able to spoof the target’s email address by creating a new account using the email address with an extra control character at the end.

The final step of the attack involved bypassing the validity check by sending an HTTP request to Hyundai's endpoint with the spoofed address in the JSON token and the victim's address in the JSON body. After following the multi-step attack steps, the analysts were able to unlock a Hyundai car. The analysts eventually built the attack into a custom Python script that only needed the target’s email address to launch an attack.

Image 3: Python Script

Following this discovery, the analysts contacted Hyundai. The automobile manufacturer informed them that they collaborated closely with third-party consultants to investigate the vulnerability and that there was no evidence of malicious actors accessing customer vehicles or accounts.

Hyundai's apps were compromised due to vendor failure to properly authenticate/authorize users and filter/interpret output data. Curry's research showed that basic security measures, such as email address authentication and VIN number protection, were overlooked by Hyundai. To improve the security of the apps, vendors should enhance output data interpretation techniques to ensure accurate and secure output data.

Ferrari, Honda, Mercedes Benz, Porsche, and More

Around the same time as the Hyundai discovery, Curry and his team of analysts discovered vulnerabilities within an electronic scooter brand’s mobile app. After tinkering with the app, the analysts were able to turn scooter headlights on and off and honk the horns. It didn’t take them long to figure out that the same vulnerabilities they discovered in API endpoints for the scooter brand, were also present in automobile brands.

Over several months the researchers documented their work exploring the security of third party telematic systems, automotive APIs, and the supporting infrastructure. They found as many car vulnerabilities as they could, and their findings were startling. They discovered that when they found one vulnerability and reported it to the appropriate auto maker, they would find the same vulnerability (in addition to others) in a different auto brand.

The brands included in the team’s research were:

• Mercedes-Benz
• BMW
• Rolls Royce
• Spireon
• Honda
• Ford
• Ferrari
• Porsche
• Jaguar
• Land Rover
• Kia
• Infiniti
• Nissan
• Acura
• Hyundai
• Genesis
• Reviver
• Toyota

The most serious vulnerabilities were discovered in BMW and Mercedes-Benz. BMW and Mercedes-Benz had a single-sign-on (SSO) vulnerability that could have enabled malicious actors to join almost any channel on a company-wide chat tool named Mattermost, potentially giving the attacker access to the brand's internal systems. Curry and his team were also able to remotely execute code on multiple Mercedes-Benz car systems, accessing multiple private GitHub instances and servers.

Image 4: Internal Mercedes-Benz Portal

The analysts were able to access personally identifiable information (PII) of the owners of Kia, Honda, Infiniti, Nissan, BMW, Ferrari, and Acura by exploiting API flaws. These flaws also enabled the analysts to remotely take control of accounts through VIN numbers, allowing them access to email addresses, physical locations, names, and phone numbers. The ability to unlock doors and flash headlights is a concern, but the danger increases when vulnerabilities give threat actors access to the physical location of the owners.

Curry's report revealed serious vulnerabilities in Spireon, a GPS tracking solution. The team was able to remotely execute code on core systems for user accounts, devices, and fleet management. They also gained full control over these fleets, which would have allowed them to track and dispatch police, ambulance, and law enforcement vehicles for several large cities and even shut off their starters. The team gained full administrative access to all Spireon products, including LoJack, FleetLocate, and GoldStar, which have a total of 15.5 million devices and 1.2 million user accounts.

Toyota

In October 2022, security analyst Eaton Zveare of Eaton Works gained access to Toyota’s Global Supplier Preparation Information Management System (GSPIMS) – a web app used by Toyota’s employees and suppliers. The app allows users to coordinate projects, parts, surveys, purchases, and other tasks.

According to Zveare, he was able to enter the system through a backdoor. The backdoor mechanism allowed him to log in as any corporate user or supplier simply by knowing their email address. After entering, he had read and write access to the systems global user directory of more than 14,000 users.

The analyst discovered a vulnerability in Toyota's system that allowed him to escalate to an administrator level by exploiting an information disclosure flaw in the API. By guessing a valid Toyota employee email address, he was able to generate a valid JWT, giving him access to corporate user account details, confidential documents, projects, supplier rankings and comments, and more. This also included full access to Toyota's external partners and suppliers such as Michelin and Magna.

The analyst reported the vulnerabilities to Toyota in November 2022, and the company resolved the problem. If a threat actor had taken advantage of the API weaknesses in the GSPIMS app, they could have copied data undetected, as the changes would have been unnoticeable.

API Flaws

You may be wondering how reputable brands like Mercedes-Benz and Honda have security flaws that could allow threat actors to take over vehicles. Researchers attribute the widespread vulnerabilities to weak APIs run by third parties and the pressure for automakers to be innovative with what they provide consumers. APIs are a type of software that facilitate communication between two applications. They are widely used in everyday activities, such as checking the weather on your phone, using social media, or sending instant messages. When you use a mobile app, the app sends data to a server through the internet. The server retrieves the data, interprets it, and sends it back to your phone. The app then processes the information and presents it to you in a readable format. Today’s APIs adhere to HTTP and REST standards and are developer friendly. They are also designed for consumption for particular audiences and are documented for consumption and versioning. Curry's extensive report included his team's testing of BMW assets. During their testing, they identified a bespoke SSO portal for BMW employees and contractors. The portal was utilized to access internal tools and related DevOps infrastructure. The team's first step in compromising BMW's API was to gather information about the host using Open-Source Intelligence (OSINT) tools like Fluff and Gau.

As a result, they were able to identify a WADL file which exposed API endpoints on the host via the following HTTP request:

GET /rest/api/application.wadl HTTP/1.1
Host: xpita.bmwgroup.com

By sending mock HTTP requests to the REST endpoints listed in the HTTP request, the team enumerated the available functionality. They then queried all BMW user accounts by sending asterisk queries in the user field API endpoint, allowing them to retrieve user information without having to guess the exact username, for instance by entering "John" to retrieve information for a user named "John.Doe". Take a look at the HTTP response below:

HTTP/1.1 200 OK
Content-type: application/json

{“id”:”redacted”,”firstName”:”Example”,”lastName”:”User”,”userName”:”example.user”}

Trusting Third Parties

Curry's success in compromising BMW's API highlights a major concern in the cybersecurity industry regarding API security. Unfortunately, the automotive industry is struggling in this area, partly due to the pressure to quickly release multiple applications with diverse functionality.

Up until this point we have primarily focused on weak API security and car systems. However, API usage is not limited to car systems, and it can impact other technology. Video conferencing equipment, CCV systems, and other devices that contain computer systems are all vulnerable to attacks if the API is not secure. Typically, APIs are run by third parties and not by brands themselves. Most of the time, the third parties running the applications don’t adhere to API best practices and they are not testing them regularly for flaws.

This does not mean that all third-party API hosts are not to be trusted, but if you are going to trust them, you should ask a few important questions:

• How do they go through the development process?
• Do they work security into their lifecycle?
• Do they test their APIs for vulnerabilities? If so, what do they use?
• What is their documentation process for testing?
• What is the process and the methodology behind the way they staff?
• What is their vendor management process?

Rushing to launch new API releases can result in shortcuts being taken in security implementation. In the era of cloud computing, it's not feasible to have a completely secure application. This lack of feasibility leads to a lower priority placed on security. Developers should prioritize security over meeting set deadlines or being the first to launch, as releasing a vulnerable application is more detrimental than missing a deadline or not being the first.

avertium's recommendations

Traditional security methods are not effective in protecting API management platforms against attacks that target the unique business logic of APIs. Organizations that only rely on gateway alerts, web application firewalls, and log file analysis are susceptible to attacks as these tools have proven to be inadequate in detecting API attacks, leading to a false sense of security. API attacks are the result of weak application security, but there are ways that organizations (not just car manufacturers) can identify their weaknesses and ensure they aren’t victims:

• Broken Object Level Authorization (BOLA) occurs when an attacker manipulates the ID of a resource in the API to belong to another user. Without proper authorization checks, this can result in granting the attacker access to resources they should not have access to.
• BOLA = IDOR (insecure direct object reference) - Reference is not the issue, authorization to unknown users is the issue.
  • The Solution: Conduct authorization checks and implement random/unguessable IDs.
• Broken Authentication - This occurs when passwords are weak, authentication is poorly implemented, or access tokens are used in the URL.
  • Solution: Adopt secure authentication methods, implement multi-factor authentication, use temporary tokens, establish rate-limiting and lockout policies.
• Excessive Data Exposure - This happens when too much data is disclosed.
  • Solution: Filter responses, including error messages, limit data exposure, and do not rely on clients to filter sensitive data.
• BFLA (Broken Function Level Authorization) - A lack of clear separation between administrative and regular functions can be exploited by threat actors to gain access.
  • Solution: Avoid function-level authorization and deny all access by default.
• Security Misconfiguration - Unsecured default configurations, open cloud storage, and unnecessary HTTP methods can result in security misconfiguration.
  • Solution: Consistently apply patches, disable unnecessary applications, restrict administrative privileges, and regularly test/scan systems.
• Injection Flaws - Rarely, developers fail to sanitize user input properly.
  • Solution: Perform input validation and sanitization, filter/limit response data.
• Improper Asset Management - The use of older API versions that may contain vulnerabilities can lead to improper asset management.
  • Solution: Fix all exposed versions or deprecate the old version and manage the process effectively.
• Insufficient Logging & Monitoring - Inadequate logging and monitoring can enable threat actors to further attack systems, maintain presence, and pivot to other systems.
  • Solution: Consistently log and monitor activity but avoid including sensitive data in logs; log failures, particularly in authentication and input validation.

Avertium also recommends:

• Make sure only authenticated users can access your endpoints.
• Only grant the necessary endpoints to users based on their roles.
• The correct information should be returned in the responses for each potential request.
• Reject benign but invalid requests.
• All data transfers should be encrypted.
• Inject NoSQL, LDAP, OS, SQL and other commands in API inputs to test if your API is vulnerable to injections.
• Conduct a Fuzz test by pushing your API to its limits in order to discover any security issues that have not been revealed. This requires sending a large number of randomized requests (SQL queries, system commands, arbitrary numbers, etc.) to see if your API responds with any errors or if it processes any of the inputs incorrectly. This kind of test mimics Overflow and DDoS attacks.
  • Run a parameter tampering test to see if your API responds with the correct error codes.

How Avertium is Protecting Our Customers

API security means shifting your organizations focus from traditional security measures and implementing API specific best practices. Developing a sound API security strategy is the first step to protecting your organization and Avertium can help take things a step further by providing you with the following services:

• To identify the source of your breach and the scope that it reached; you’ll want to include Avertium’s DFIR services in your protection plan. We offer DFIR (Digital Forensics and Incident Response) to mitigate damage from a successful breach.

• Avertium offers VMaaS to provide a deeper understanding and control over organizational information security risks. If your enterprise is facing challenges with the scope, resources, or skills required to implement a vulnerability management program with your team, outsourced solutions can help you bridge the gap.

• Avertium offers Zero Trust Network as a Service (ZTNaaS) for any organization that wants to control their attack surface. The zero-trust security model delivers exactly what the name promises: it's an IT security concept that specifies no access is allowed until the successful completion of authentication and authorization processes.

• Avertium has virtual CISOs who can provide a high level of service by helping you develop a plan to conduct a physical hardware inventory assessment. This service includes a visibility study to help discover what devices are on your network. This can be done remotely or in person.

Supporting DocumentationS

• Web Hackers vs. The Auto Industry: Critical Vulnerabilities in Ferrari, BMW, Rolls Royce, Porsche, and More | Sam Curry
• API1:2019 — Broken object level authorization (apisecurity.io)
• Hyundai app bugs allowed hackers to remotely unlock, start cars (bleepingcomputer.com)
• API Attacks & Best Practices (avertium.com)
• Hacking into Toyota’s global supplier management network (eaton-works.com)
• Researcher breaches Toyota supplier portal with info on 14,000 partners (bleepingcomputer.com)
• 8 API Security Best Practices to Protect Sensitive Data (hubspot.com)
• Toyota hacked again but this time it was a security researcher with no ill intent - SiliconANGLE
• OWASP API Security Project | OWASP Foundation
• API Security Attacks - L7 Defense: API Security Solutions
• What is an API? (Application Programming Interface) | MuleSoft
• Sirius XM flaw could’ve let hackers remotely unlock and start cars - The Verge
• Toyota, Mercedes, BMW API flaws exposed owners’ personal info (bleepingcomputer.com)
• Hackers discover that vulnerabilities are rife in the auto industry | Ars Technica
• Car hackers discover vulnerabilities that could let them hijack millions of vehicles | CyberScoop
• Severe API Security Flaws Affect Millions of Vehicles from 16 Car Manufacturers, Including BMW, Mercedes and Toyota - CPO Magazine
• Attackers increasingly use Microsoft’s OneNote to deliver QakBot malware | SC Media (scmagazine.com)

 APPENDIX II: Disclaimer

This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.

Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.