The safest internal admin tool is one the internet can’t reach. Put it behind a VPN or an identity-aware proxy, give every endpoint real auth, and keep secrets out of the JavaScript you ship. WAF rules alone are the weakest option.
In Unlocking any car from X brand in most of the world, Shubham Shah describes how he and Sam Curry went from a number plate to unlocking an automaker’s cars. The first door was an admin tool. Here are three levels for protecting yours, and what each costs.
Table of Contents
- How a number plate unlocked a car
- Good: WAF rules on the admin paths
- Better: real auth and no secrets in the bundle
- Best: take it off the internet
- Which level fits your tool
- Should the server be able to unlock the car at all
- FAQ
- Sources
How a number plate unlocked a car
Shah started with the automaker’s Android app and listed the domains it called. One subdomain, admintool, served a plain login page titled TEST HARNESS. Its JavaScript bundle described a rich API for customer accounts and production vehicles, and many of those calls needed only API keys hardcoded in the same bundle.
The full chain for Australia, as Shah lays it out:
- Number plate to VIN, through public registration lookups.
- VIN to subscriber ID, through the admin tool’s API.
- Identity platform admin credentials, found in a vendor JavaScript bundle.
- A path traversal past the WAF.
- An MFA bypass through a password grant flow.
- A minted app token for any user, then the remote command API.
The doors unlocked. Combined with Curry’s write-up, the pair could send remote commands to the automaker’s vehicles in Australia, the United States and Canada.
Good: WAF rules on the admin paths
The automaker had invested heavily in WAF rules that blocked /openidm/, the identity platform’s admin API. Shah respects the effort, but reads it as a warning sign: that much WAF work usually means bandaids over something the team knew was bad.
The rules covered the prefixes the researchers tried by hand. After an AI model spent about six hours on the OpenIDM source, it found that /static%2f..%2fopenidm/ wasn’t covered at all.
- Buys: a fast block you can ship today, with no app changes.
- Costs: every rule is a guess about how an attacker will spell the URL. Miss one encoding and the API behind it is wide open.
Better: real auth and no secrets in the bundle
Every admin endpoint should check a real user session, and nothing in the browser bundle should grant access. Here, both failed. The admin tool’s APIs trusted hardcoded keys, and a vendor bundle carried admin credentials meant for staging. Shah and Curry confirmed they worked in production.
- Buys: a leaked URL alone gets an attacker nothing.
- Costs: discipline. Keep staging and production credentials separate, rotate anything that ever shipped to a browser, and scan for secrets in CI with a tool like Gitleaks or TruffleHog.
- Misses: one leaked secret still opens the door, because the endpoint is still reachable.
Best: take it off the internet
Shah asks the obvious question in the article: why were these instances exposed externally at all? An admin tool used by staff can sit behind a VPN or an identity-aware proxy such as Tailscale, Cloudflare Access or Google Cloud IAP. A stranger then can’t load the login page, let alone read its bundle.
- Buys: the whole attack chain above never starts.
- Costs: setup time, and every staff device has to be enrolled.
- Misses: endpoints your public app calls. The mobile app talked to some identity endpoints directly, and those had to stay reachable. They still need level 2.
Which level fits your tool
| Situation | Level | Why |
|---|---|---|
| Emergency, exposed admin path found today | Good | Block it now, fix it properly this week |
| Public API that customers’ apps call | Better | It has to stay reachable |
| Admin tool, staging or QA used only by staff | Best | Nobody outside needs to reach it |
| Identity or admin platform behind a public app | Best plus Better | Split the public endpoints from the admin ones |
What to do this week: list every subdomain your apps call, open each one’s JavaScript bundle and search it for keys and passwords.
Should the server be able to unlock the car at all
Much of the discussion argued that the problem sits one layer down. One developer suggested pairing the phone with the car once, so the car only accepts commands signed by the phone’s key. Then the maker’s servers couldn’t unlock a car from an account alone, however badly the admin tools were protected. Others questioned whether cars should be remotely controllable at all. I think both points are fair, but most teams can’t redesign their protocol this quarter. They can move an admin tool behind a proxy this week.
FAQ
Is a WAF enough to protect an admin panel?
No. A WAF blocks the URL patterns someone thought of. In this case one encoded path, /static%2f..%2f, slipped past rules that blocked the obvious ones.
Why are secrets in a JavaScript bundle dangerous?
Anyone who loads the page can read the bundle. Shah found API keys and admin credentials this way, and the staging credentials also worked in production.
What is an identity-aware proxy?
A proxy that checks who you are before any request reaches the app. Cloudflare Access and Google Cloud IAP are two examples.
Do I still need auth behind a VPN?
Yes. The VPN keeps strangers out, and auth limits what an insider or a stolen laptop can do.
How do I find admin tools exposed by mistake?
List the subdomains your apps and certificates reveal, then check which ones load without a VPN. Researchers start the same way.
Sources
- Article: Unlocking any car from X brand in most of the world by Shubham Shah, with research by Sam Curry.
- Discussion: https://news.ycombinator.com/item?id=50419215, for the signed-commands proposal and the debate over remote car control.
- Related: How two low-severity bugs rooted a car’s navigation unit.