Full Report
Telsa uses auth.tesla.com as an SSO provider for external customers. For internal employees, they uses sso.telsa.com as an iDP. Using auth.tesla.com, they user realized it is possible to create emails for both @tesla.com and @teslamotors.com. Trying to create already created emails, like ones from internal employees, was not allowed. So, what can we do with this? So, what about accounts that have been removed? Could we recreate these? So, the author looked on LinkedIn for employees at Tesla that may have had permissions in the past on various websites. Interesting idea! The author had used The Tesla Retail Tool for IT and business data for the dealerships. So, they tried this. After many tries, they found accounts with permissions on this site! The website did not care which iDP was being used; the external vs the internal one. Using this issue, they were able to login as the other employee. If there was a JWT, then the iss field is what was important here. A super interesting bug!
Analysis Summary
# Vulnerability: Post-Employment Account Takeover via Identity Provider (IdP) Confusion
## CVE Details
- **CVE ID**: Not Assigned (Disclosed via Bug Bounty Program)
- **CVSS Score**: Estimated 8.5 - 9.0 (High/Critical)
- **CWE**: CWE-290: Authentication Bypass by Spoofing; CWE-639: Authorization Bypass Through User-Controlled Key
## Affected Systems
- **Products**: Tesla Retail Tool (TRT) and potentially other Tesla web applications utilizing multi-IdP authentication.
- **Versions**: Cloud-based/SaaS instances active prior to April 2023.
- **Configurations**: Applications configured to accept JWTs (JSON Web Tokens) from both the external IdP (hXXps://auth[.]tesla[.]com) and internal IdP (hXXps://sso[.]tesla[.]com) without validating the `iss` (issuer) field or origin of the identity.
## Vulnerability Description
The vulnerability stems from a logic flaw in how internal applications processed authentication tokens. Tesla maintains two separate Identity Providers: one for public customers and one for internal employees.
A security researcher discovered that the external (public) IdP allowed users to register accounts using `@tesla.com` or `@teslamotors.com` email addresses without email verification. While active employee accounts could not be duplicated, the researcher could register accounts using the email addresses of **former** employees.
The Tesla Retail Tool (TRT) failed to verify which IdP issued the user's token. Consequently, it treated a token from the public IdP (controlled by the attacker) as equivalent to a token from the internal IdP. Because TRT maintained static access control lists based on email addresses, the attacker inherited the permissions and access of the former employee.
## Exploitation
- **Status**: PoC available (Validated via Tesla Bug Bounty Program).
- **Complexity**: Medium (Requires OSINT to identify former employee emails).
- **Attack Vector**: Network.
## Impact
- **Confidentiality**: High (Access to network circuit info, local device logins, financial data, and building plans).
- **Integrity**: High (Ability to modify IT and business data for dealerships).
- **Availability**: Medium (Potential to disrupt services via access to sensitive infrastructure login details).
## Remediation
### Patches
- **Vendor Fix**: Tesla updated the external IdP to prevent the registration of accounts using internal domain suffixes (`@tesla.com`).
- **Application Update**: Backend applications were updated to strictly validate the JWT `iss` (issuer) field to ensure only the internal IdP is used for administrative/employee functions.
### Workarounds
- Implement mandatory email verification for all external IdP registrations.
- Purge inactive or former employee email addresses from application-level authorization lists immediately upon offboarding.
## Detection
- **Indicators of Compromise**: Login events to internal tools where the authentication source is the external customer IdP instead of the corporate SSO.
- **Detection Methods**: Audit JWT logs for the `iss` claim. Monitor for account registrations on public portals using internal corporate email domains.
## References
- **Original Report**: hXXps://medium[.]com/@evan.connelly/post-account-takeover-account-takeover-of-internal-tesla-accounts-bc720603e67d
- **Program**: hXXps://bugcrowd[.]com/tesla