Introduction
This is rewritten article from the bugcrowd report submitted by the security researcher Evanconnelly
During participation in the Tesla Bug Bounty Program, I was tasked with examining and evaluating the security of numerous Tesla web applications. This process required me to generate multiple Tesla user accounts in order to thoroughly assess the potential vulnerabilities and weaknesses within the system.
On one particular occasion, as I was in the process of establishing a new account, my curiosity was piqued by the idea of attempting to register for an account using an email address that belonged to the Tesla domain itself. I wondered whether the system had any built-in security measures to prevent such a scenario, and if not, what potential implications this could have on the overall integrity of the platform.
So, like, Tesla's got a bunch of web apps and stuff.
For SSO to all these applications, Tesla has two main identity providers (IDPs), auth.tesla.com for external users and sso.telsa.com for employees.
My security testing involves auth.tesla.com.
I found out that the external auth.tesla.com allows users to sign up for new accounts using @tesla.com and @teslamotors.com email addresses.
Also, there is no email verification, which means an account can be created with an email address to which I don't have access.
With further testing, any attempt to register an external account with a valid internal Tesla email address reported that the email address was already taken. So at best, my thinking is that under the right conditions, this could be used for pre-account takeovers, which is a fairly low-impact issue.
How to exploit it in other ways?
So what about what is essentially the opposite of a pre-account takeover? If I were able to sign up for an account I have used in the past, instead of creating an account with the email address I want to use in the future, the account is no longer active on Tesla's internal IDP, but may still have internally assigned privileges, what about various web applications? After the account is taken over if you wish.
I'm fairly familiar with the Tesla Retail Tool (TRT) due to a bug I discovered earlier.
TRT stores confidential IT and business information such as network circuit information, local device logins, network logins for ISP and utility accounts, financial information, and details about current, upcoming, and previous Tesla locations, such as lease terms, internal and External contact information, floor plans and interior photos of restricted areas of Tesla properties.
I know TRT allows access from internal and external accounts. For authentication, it takes a JWT that specifies an email address that is authenticated against a manually defined list of users in the application. At Tesla's scale, it would be difficult to manually update that list every time an employee leaves.
In theory, it should be fine if past employees have defined access to the web app since their IDP accounts will be disabled or deleted, so they won't be able to log into the app through Tesla's internal IDP.
But what if it was possible to register an external account using an internal email address of a former Tesla employee who could access TRT and gain access to the web application, while the privileges were still assigned to the now-defunct email address? Will this give me a valid JWT and the victim's email address as if I were logging in through the internal IDP?
I used Google Dorks to search the LinkedIn profiles of ex-Tesla employees in positions that should have had access to TRT, especially sensitive information.
For example,
site:linkedin.com inurl:/in โfield systemsโ โtesla motorsโ -intitle:tesla -inurl:posts
This finds the former on-site IT personnel who should have access to network information
In testing, it was possible to register an account at auth.tesla.com (external IDP) using a former Tesla employee's email, which still had privileges assigned in TRT.
I could then use the identity and permissions of a former employee whose internal IDP account may have been wiped to access the Tesla Retail Tool by creating an account on the public IDP with the same email address. This made multiple attempts against multiple email addresses of the former employee.
Tesla has two Identity Providers (IDPs), auth.tesla.com for external users and sso.telsa.com for employees.
The Tesla Retail Tool (TRT) allows logins from both but does not check the IDP the user is logged into (auth.tesla.com vs sso.tesla.com). This is for Google Dorks, I was able to identify the name and deduce the email address of the ex-Tesla employee, and then register an account with the external IDP using the email address of the ex-employee whose account had been disabled on the internal IDP, but who they Still have the privileges defined by TRT's internal Tesla email addresses, and end up logging into TRT with those user's privileges.
Timeline
- November 19, 2022 - Submit bug reports
- November 20, 2022 - Tesla verifies the vulnerability and begins the fix process
- November 21, 2022 - I notified Tesla and I can confirm that the account I created in the report no longer has access to TRT
- November 29, 2022 - Tesla is marked as resolved, and bounty awarded
Vulnerability disclosure address
Source:- https://tutorialboy24.blogspot.com/2023/05/authteslacoms-vulnerability-leads-to.html
Top comments (0)