Hacking into a Toyota/Eicher Motors insurance company by exploiting their premium calculator website

Eaton

Discussion links: Reddit | Hacker News

News coverage:

January 27, 2024 update: The email account password has been changed. It is no longer possible to log into the account.

Key Points / Summary

New year, new automaker industry hack! As part of my automaker research projects last summer, Eicher Motors made its way up my list to investigate. In my efforts to find interesting exploits on Eicher Motors systems, I accidentally ended up compromising a different company in the process: Toyota Tsusho Insurance Broker India (“TTIBI”). A perfect storm of multiple issues culminated in me gaining control over the “noreplyeicher@ttibi.co.in” Microsoft email account, which not only had a record of everything they have ever sent to their customers, but also provided a foothold into their Microsoft cloud.

Toyota Tsusho Insurance Broker India and Eicher Motors

Everyone knows Toyota, but not everyone knows about Toyota Tsusho Insurance Broker India (“TTIBI”). Toyota is comprised of a vast network of different companies. TTIBI is under the Toyota Tsusho Insurance Management Corporation in Japan. TTIBI was established in 2008 and is “a leading Insurance Broker across India“.

Eicher Motors is one of India’s leading automakers. They manufacture motorcycles under Royal Enfield Motors and commercial vehicles under VE Commercial Vehicles (VECV), which is a joint venture with Volvo Group.

Both companies have some type of insurance partnership because there is a dedicated Eicher subdomain on the TTIBI site.

The Premium Calculator

While analyzing the MY EICHER Android app, I came across an inconspicuous URL inside an API interface Java class that was a link to a premium calculator:

Visiting the link in a browser revealed it:

Looking at the source code of the website (literally right-click, view source), I quickly found some very interesting code:

This caught my eye because this was a client-side email sending mechanism. If it worked, I could send a email with any subject & body to anyone, and it would come from a genuine Eicher email address. However, seeing the Bearer Authorization put a damper on my excitement because it was clear you needed to be logged in somehow to use this API. Despite that, I decided to try crafting the API request to see what would happen. I was expecting it to come back with “401 – Unauthorized”, but what actually came back surprised me.

Not only did the email successfully send, It came back with a server error that revealed an email sending log:

If you look closely, you can find the base64 encoded password. Being able to abuse this send email function was serious enough, but the leak of the email account password elevated this to a new level of severity.

The email account

This isn’t just any email account – it’s a noreply email account. noreply accounts are generally used for sending automated emails to customers. For example, when you reset a password, the link is likely to come from a noreply account. In many cases it can just be an alias on SendGrid, Postmark, etc, but it can also be an actual account that you can log in to. The noreply account could be the most important account in an organization because it could potentially have a record of everything they have ever sent to customers. In TTIBI’s case, that is exactly what it is and the amount of information revealed is enormous:

Exploring the impact

The email account is jam packed with personal/private information. To start, you can see all the insurance policies sent to customers – here’s a few examples from different insurance companies:

You could also view one-time-passwords (OTPs) and password reset links. With this, you could easily take over someone’s insurance account.

And you could of course access resources on their Microsoft cloud, such as the corporate directory, SharePoint, and Teams:

A perfect storm of security issues

The vulnerability was so severe because it was enabled by 5 unfortunate security issues/oversights. Developers and IT administrators should take note of all of these and make sure similar issues do not exist in your organization.

Issue #1: Client-side sending email mechanism

Don’t create an email sending function that the client has control over. Someone malicious can abuse it to send bad emails from your genuine account, leading to email reputation loss and phishing.

Issue #2: Missing API authentication

It looks like the frontend developer knew the email sending API should have been authenticated, but the backend developer missed the memo. If the server had actually checked the token, it might have entirely stopped this exploit.

Issue #3: Leaky API response

If something goes wrong when processing an API request, don’t give too much information back to the client. In this case a password managed to leak out, which is one of the worst things that could happen.

Issue #4: No two-factor authentication

Logging into the Microsoft account was surprisingly easy. There was no two-factor authentication set up or any other login verification prompts. If there was, it probably would not have been possible for me to successfully login.

Issue #5: Email retention

The final issue is that all emails the account had ever sent/received were retained, making it easy to access substantial amounts of customer information. Retention policies vary by industry, but this is a great example where having a policy in place could have softened the customer data exposure impact.

Password remains unchanged

January 27, 2024 update: The email account password has been changed. It is no longer possible to log into the account.

More than 5 months later, TTIBI still have not changed the password of the email account despite being aware of the vulnerability. I checked it again today (January 17, 2024) and I am still able to log in (proof). If I were them, I would not want a random stranger having access to their corporate cloud for 5 months. This is very disappointing, and I hope they improve their security posture so their customers’ data doesn’t leak out.

As an aside, I’m a little surprised that they weren’t alerted by Microsoft in some way to the unusual login. Or maybe they were, and the alert was ignored or not seen.

Timeline

TTIBI is not covered under Toyota’s HackerOne vulnerability disclosure program, which is a shame because the team behind that has been quick to resolve several issues I have reported to them in the past. I reported the issue to India’s CERT-In instead.

Everything after October 18 is a back-and-forth between CERT-In and me trying to determine if there would be a bug bounty reward. TTIBI never responded to the question, so I decided to close the case on December 22 and CERT-In sent me a nice appreciation letter.

Subscribe to new posts

Get an email notification every time something new is published.
📧