Who needs credentials, when you have the phone number…?

Hello World, as I said in my previous article, I’m back with yet another write-up.

This write-up is about certain vulnerabilities I found in a prominent vehicle manufacturer’s mobile application. Even though there were multiple vulnerabilities in the app, here I’ll be only focusing on a few of them.

TL;DR,

I was able to access and tamper with the PII and other data of any user/customer of the particular entity. These data include name, address, insurance number, license number, engine number, vin number, etc., and much more.

Long version

Well, I’m not going to explain the whole backstory behind how I landed on this app. But the summary is, I was frustrated with the services provided by a dealer of this particular vehicle manufacturer.

And that’s when I came to know about this particular mobile application.

So, I opened the app, and I logged into it. As with most of the apps on the market, this one too was using a phone number-OTP login logic. I fired up burp suite and started to tweak with the app. As with most of the apps, this one too had a basic SSL-pinning and all.

After bypassing those, as most of us would try, I too tried to brute-force the OTP received on the phone number. But the app was blocking me after multiple tries. And so I thought the app might have strong security measures implemented, and I won’t be able to get anything fruitful.

Guess what?

After successfully logging into the app, I checked all the requests, and I saw a request where the app sends my phone number and fetches all the details associated with me and my vehicle.

Now, I used that request and changed the phone number to one of my friends (with their permission).

Well, to my surprise I got all the details of my friend’s vehicle. The app which I thought would be a secure was not having the basic access control implementation… Also, the app didn’t have any rate limiting mechanism inside it (except the initial login). So, an attacker could easily brute-force phone numbers and could fetch the details of any customers associated with the entity.

Now this was interesting.

I started to check other requests too.

In a particular request, where I was trying to change my phone number from the app, I saw many other parameters passing in the request, along with my phone number.

I used that request, changed the phone number to my friend’s number and just changed the value of a single parameter (Since app was a live production application, I didn’t want to cause any other issues).

Even though the request gave a success, I was still a bit skeptical that the data would be tampered or not.

But guess what?

The updated parameter was saved successfully in the user’s profile. To double check if it will only work with the shown parameter, I tried tampering with some other parameters, and that was also successful.

I tweaked with the app for some more time and I got multiple other severe issues too but let’s stop it here.

Finding the issues was the easier part, reporting this vulnerabilities was the tedious part.

Even though the affected entity was a vehicle manufacturing giant, they didn’t have a VDP or any other way to report vulnerabilities on their platform.

Initially I mailed to an mail addresses I found on their website. But they redirected me to other other department and none of them actually understood the issue.

Tired of this, I went to X and asked for the entity’s assistance. They asked me to DM and I gave the summary of the situation and asked me to direct to their security department. They gave another email address and I send the mail stating the situation.

Well, they also didn’t understand the issue and was asking me for my phone number and vehicle’s chassis number to resolve the issue.

Now I was confused and I asked why do they need that and I got an automated reply…

As a final try, I tried to reach them via linked In but that too failed…

Since there was no other way, I reported the issues to CERT-IN and CERT-IN was able to reach the affected party. After multiple emails and 4–5 months, the affected entity informed that issue was fixed…

And that’s all for now, See ya later…