Unit 5: Permissions · Lesson 6 of 6 · 20 min
Case file: a key that stayed public for five years
Deleting a secret from a file does not remove it from history. Find the commit that leaked a key and how long it was exposed.
mission
- You are
- You are reviewing a contractor's repository before it goes public.
- Situation
- The shop-mobile repository in /srv/cases/shop-mobile is about to be published. Today's files look clean.
- Goal
- Prove whether a secret exists anywhere in its history, and for how long.
- Hand in
- Commit, file, first and last date, and what must happen to the key.
case file
Toyota T-Connect Key Exposed on GitHub
Toyota Motor Corporation · 2022
In October 2022 Toyota disclosed that part of the T-Connect source code, published to a public GitHub repository by a development subcontractor, contained an access key to a customer data server. The key was exposed from December 2017 until September 15, 2022, putting email addresses and customer management numbers of 296,019 customers at risk. Toyota could not rule out third-party access and rotated the keys on September 17, 2022.
What went wrong
A hard-coded credential in source code that a contractor published publicly, with no secret scanning or key rotation catching it for nearly five years.
What would have stopped it
- Never store credentials in source code; use a secrets manager and inject at runtime.
- Enable secret scanning and push protection on all repositories, including those of contractors.
- Rotate keys regularly so any leaked key has a short useful life.
- Contractually require and audit secure development practices for subcontractors.
What defenders could have seen
- Secret-scanning alert for credentials in a public repository.
- Database access using the key from IP addresses outside expected application hosts.
- Periodic search of public code hosting for company domains and key patterns.
A secret in git
- CommittedOne push puts the key in history
- CopiedEvery clone and fork has it
- DeletedThe latest file looks clean
- Still thereAny old commit shows it
- RotatedThe only real fix
Today's files
git log --oneline f03aaa3 Document DATAHUB_KEY d9132ab Read the data hub key from the environment e71de8e Bump version 6da8a6b Connect analytics to the customer data hub c364817 Initial app skeleton git grep -n access_key config/datahub.yml:3: access_key: ${DATAHUB_KEY}
you should see Five commits. The current file reads the key from an environment variable.
Search the whole history
-S lists commits that added or removed a string anywhere in history.
git log -S 'DHK-' --format='%h %ad %s' --date=short
d9132ab 2022-09-15 Read the data hub key from the environment
6da8a6b 2017-12-11 Connect analytics to the customer data hub
you should see Added in December 2017, removed in September 2022.
Show it
git show 6da8a6b:config/datahub.yml
datahub:
endpoint: https://datahub.shop.example
access_key: DHK-LAB-7Q2W-9X4E-FAKE
region: eu-west-2
you should see The full key, readable by anyone with the repository.
Check who can read the live config
The same mistake on a server: a secret any local user can read.
stat -c '%a %A %U %G %n' /srv/app/config/db.env /srv/app/config/app.env
644 -rw-r--r-- deploy ops /srv/app/config/db.env
640 -rw-r----- deploy ops /srv/app/config/app.env
you should see db.env is world-readable. app.env is not.
defender tip Scan before every push with a secret scanner in a pre-commit hook and in CI, and rotate anything it finds.
Fixing a leaked key
git commit -m 'remove key'
The key still works and is still in history
1. revoke the key at the issuer 2. issue a new one from a vault 3. add secret scanning 4. rewrite history only if needed
The leaked key is now worthless
What a defender takes away
- 1Search history, not just today's files.
- 2A leaked secret is rotated first and cleaned up second.
- 3Secrets come from the environment or a vault, never the repo.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.