A total of either issues impacting various companies in the automotive industry, mix of issues from simple SQL injection to some interesting Single Sign On (SSO) implementation decisions.

BMW/Rolls Royce - Full Account Takeover via Misconfigured SSO. The root of this issue was an API endpoint that would expose the current TOTP for a given user id. Combined with a separate endpoint that would expose a user’s ID and supported wildcards when searching by usernames, any account could be discovered and then the TOTP used to reset their password without access to the TOTP sent to the user. This granted issue to whatever that user had access to, so potentially dealership portal or internal devops tooling.

• /rest/api/chains/account/{acocunt_id}/totp - the endpoint that would expose the TOTP
• /rest/api/users/{username} - username could include a * as a wildcard to expose users without knowing their username.

Mercedes-Benz - insecurely configured SSO. The SSO setup allowed for anyone to gain access to all applications behind SSO. The root of this issue was the flat SSO authentication scheme. There were no entitlements or other more granular protective mechanism. Instead any user that had an account capable of logging into the SSO could access any tooling behind the SSO. This isn’t a terrible uncommon setup, though it is insecure.

Combined with the public registration on umas.mercedes-benz.com a tool meant for external repair shops to register for access to specialized tools to work on Mercedes-Benz cars. Anyone could register on the umas domain, and then access any of the internal applications. Such at git.mercedes.com which had access to source code for their apps and instructions on building an app to talk with customer vehicles, various internals tools like Jekins and cloud compute control panels were also accessible once registered on the public site.

Ferrari - Full Account Takeover. Started off with some recon, finding a webapp with an apiUrl and apiKey int eh Javascript. Exploring that API things got a bit more interesting, it supported creating “connectors” that would connect to yet other REST APIs exposing it over a separate endpoint on that API. These other APIs were configurable using the API, and importantly could be listed by this API. That listing included the remote API’s URL and API key to authenticate with it. This included keys to communicate with the Ferrari production API, and modify their own user’s permissions.

Spireon Systems - SQL Injection and Regex Bypass. This one, frankly is just a silly issue. They came across the admin.spireon.com domain, which was running an out of date PHP panel (copyright indicated 2011). It was vulnerable to one of the oldest SQL injection tricks in the book. username' #. Just a straight forward SQL injection in the username field, only complicated slightly by the WAF. Once in they could access all Spireon devices (by logging into a highly-privileged account).

The Regex bypass allowed them to access the backend admin panel and dashboard for the API the main website used. They noticed they’d get a HTTP 403 on requests with admin or dashboard in the path. With some fuzzing, they found that %0dadmin or %0ddashboard would bypass this block giving them access to the backend panels.

Reviver - Mass assignment. When creating a new account on Reviver, each user would get a JSON document. Inside this document was the type field which would default to CONSUMER. A mass-assignment vulnerability existed The endpoint or how exactly this vulnerability was reached isn’t detailed. Normally this comes with some endpoint that is meant to support arbitrary updates to say a document or table. Taking in a key and value in some format, and updating them. The normal UI would only send requests to update appropriate fields, but an attacker could specify fields not normally exposed to be updated. They were able to use this sort of vulnerable to change their type value to REVIVER which reflects an administrative user, capable acting on any of users and their digital license plates.