3 min read

Toyota Customer Data Leaked Due To Software Supply Chain Attack

Featured Image

On Oct 7th, Toyota announced a possible data leakage incident stemming from a code repository in their software supply chain. The compromised data contained 296,019 customers' private information, including customers' personal email addresses.

Toyota Motor Corporation is a multinational automotive manufacturer headquartered in Japan. The automotive company is a giant corporation that invests massive resources in software R&D. The Japanese company uses subcontractors to develop some of its technologies including its connected car project - TOYOTA CONNECT.

During the development of the TOYOTA CONNECT application, website, and infrastructure, a subcontractor accidentally uploaded some of the code to their account. The code was uploaded to a public repository, and the code contained critical and sensitive information (i.e. hard-coded secrets for a database). Until more information surfaces, experts recommend assuming that the leaked data has been obtained by a malicious actor who might conduct sophisticated phishing attacks. For this reason, all users of T-Connect who registered between July 2017 and September 2022 are advised to be vigilant against phishing scams and avoid opening email attachments from unknown senders claiming to be from Toyota.

At Legit Security, we have previously described how you can detect secrets in your source code and why hard-coded sensitive data (I.e. secrets) in source code is a very common attack vector prevalent in software supply chain security incidents. In this blog post, we will provide a quick recap of secrets, the risk of keeping secrets in your source code, and how to mitigate this risk. We will also show how to prevent forks and other parts of your source code from being published to public repositories.

What are secrets in code?

Secrets are any data that is sensitive to an organization or person and should not be exposed publicly. A secret can be a password, an access key, an API token, a credit card number, and more. In this incident, it was discovered that the published source code contained an access key to the data server.

With an exposed secret, an attacker could access applications, machines, APIs and more. For example, if an AWS S3 access key is leaked, an attacker can have privileged access to critical information. And, of course, after gaining access to a single entity or service, a skilled attacker can also attempt to move laterally across the network to obtain control of more critical environments or resources.

Check out a previous blog if you're looking for a deeper dive into secrets in code.

Why are secrets in code an urgent problem?

When a secret makes its way to a Git repository, it stays there forever, sitting in one or more of your commits, waiting to be found and used against you. Developers often forget that Git-based repository history is never deleted. Not only do the secrets sit in a Git server, but every clone and fork saves this secret on different machines without the clone or fork creator being aware of it.

As we can see in this incident, the subcontractor had access to the code, and there are two ways that subcontractor could have made the code public:

  1. The code was forked to a public repository directly.

  2. The code was cloned locally and then pushed to a public repository.

In both cases, damage is done as soon as the code goes public.

Further, this Toyota incident highlights another major problem: the data center access key remained undetected (to our knowledge) for over five years. Modern software supply chain security solutions (like Legit Security) detect these risks in real-time to drastically reduce the risk of the threat. The longer secrets remain in code, the higher your risk of breach or software supply chain attack.

3 Steps to Protect yourself from being the next victim

There are many risks with secrets in your source code. Fortunately, there are several steps you can take in order to keep your organization secure and your code clean of secrets.

1 - Continuously scan for secrets in your code

Secrets can be scanned and detected as part of continuous integration and deployment (CICD). You can use pre-commit hooks to integrate secret scanners and prevent bad commits from going into your repository.

2 - Manage your forking policy

You must be aware of your organization’s current forking policy to prevent your code from leaking. Each source code management system (SCM) vendor (e.g., GitHub, GitLab, Bitbucket, etc.) has an option to enforce a forking policy and prevent forks of private repositories. See GitHub’s documentation as an example: Managing the forking policy for your organization.

3 - Make sure developers' privileges are limited

Separating development and production environments, preventing access to secrets, and restricting pushes to default branches can ensure that your organization will suffer minimal impact if one of your developer's accounts gets compromised.

Legit Security Detects Sensitive Data in Development Pipelines and Much More

The Legit Security platform automatically scans your development pipelines to detect sensitive data like hard-coded secrets and PII. Our SaaS platform alerts you in real-time when security policies across a wide range of potential attack vectors (including embedded secrets) are violated in your software supply chain – including real-time alerts for detected secrets and suspicious events (like a private repository being forked and made public).

To learn more, schedule a product demo and check out the Legit Security Platform.

Related Blogs

Novel Pipeline Vulnerability Discovered; Rust  Found Vulnerable

The Legit Security Research Team discovered a new class of software supply chain vulnerabilities that leverages artifact poisoning and attacks the...

Read More

Top Software Supply Chain Security Solution Approaches: Pros and Cons

What are different solution approaches to software supply chain security and what are the Pros and Cons for your organization? What is the modern...

Read More

1 min read

Critical and Time Sensitive OpenSSL Vulnerability - The Race Between Attackers and Defenders

Update: On November 1st the OpenSSL project maintainers released their fix for the vulnerabilities. There were two vulnerabilities discovered. After...

Read More