Default ‘admin’ Password Let Researchers Unlock and Start Customers’ Cars

Two car makers let customers lock, unlock and start their cars from a phone app. Behind the app sat an identity server, and on that server sat an admin console that still accepted “admin” as both username and password. That is the short version of new research by Shubham Shah and Sam Curry, and it is a useful case study in connected car security.

Neither carmaker is named in the write-ups. Both fixed the problem within about two hours of being told, according to Curry’s technical analysis. Good connected car security starts at the server, and the lesson reaches well beyond cars.

Where connected car security failed

Both brands used ForgeRock’s OpenIDM, an identity platform now part of Ping Identity, to sign customers in. OpenIDM ships with an Apache Felix web console at /system/console. Its documented default login is admin and admin.

The console was not meant to be public. The public edge, a web application firewall, blocked direct requests to it. But the researchers found that encoding the path in a certain way made the edge treat the request as a static file and wave it through.

Behind the edge, three components read the same encoded path differently: the Jetty web server, Felix and OpenIDM’s own API layer. The firewall judged the raw request. The backend judged the decoded one. The gap between the two was the way in.

From a default password to a running car

Once in the console, the researchers used its configuration manager to create a scheduled job that ran a short script. That script installed a small component giving them a shell on the identity server. Per Curry’s write-up, the shell environment held OpenIDM admin credentials.

From there the account records were open to them. The researchers could search customers by name, email, phone number or ID. They could change a customer’s email and password, log in as that person and swap the session for the same tokens the mobile app uses. They could also register their own push token, so notifications went to them instead of the owner.

The app then showed vehicles, VINs, location and telemetry, and accepted commands. On a test car, with its owner standing beside it, the team confirmed that unlock, lock, engine start and engine stop all worked. They restored the owner’s email address afterwards. The owner’s existing app session stayed live throughout, so nothing would have looked wrong on their phone.

A second route in Australia

Shah found a separate path against a brand’s Australian systems. He decompiled the Android app and found it called a family of telematics domains for nearly everything. A JavaScript bundle on those domains embedded admin credentials for the OpenIDM instance. He believed they were meant for staging. His write-up says they worked in production too.

The same style of firewall bypass applied. In his tests, a path starting with /XUI%2f..%2fopenidm/ was blocked, but one starting with /static%2f..%2fopenidm/ was not. He also skipped the second login step by using a different OAuth flow, then sent a door unlock command. The write-up gives no fix date for the Australian systems.

According to The Hacker News, which covered the research, the combined work could send unlock and engine-start commands to cars in Australia, the US and Canada. We have not seen that claim spelled out in the primary posts, so treat the regional reach as the reporters’ summary.

No CVE, no patch, still a real flaw

This was not a product bug. Ping Identity’s documentation tells operators to remove or protect the Felix console before going live, and notes that its login is separate from IDM’s own. The default credentials are documented. So there is no CVE to track and no vendor patch to install. That makes it easy to miss in a vulnerability scan that works from lists of known flaws.

Neither write-up says whether anyone else used the path before it was closed. That is the awkward question for any firm in the same position.

What to test in your own estate

Most UK businesses do not need to worry about connected car security directly. Many do run an identity service, a customer portal or an admin console behind a firewall. The same three failures apply to them.

• Default logins. Search your own systems for admin consoles that still use vendor passwords. Our guide to default credentials covers where they hide.
• Firewall rules as the only lock. A WAF blocks known paths. It does not fix what sits behind them. We made this point in a firewall buys you time, not a fix.
• Test credentials in shipped code. Staging passwords tend to end up in app bundles. Check your mobile apps and front-end JavaScript for them.

A penetration test with an automotive focus would cover the backend as well as the vehicle. If you run a connected product of any kind, the backend is where this research landed, and where connected car security succeeds or fails. A scoped test will show whether your admin pages can be reached by an encoded path. You can get in touch to talk through one.