I helped the top Indian health benefits management platform from major PII leak by hacking their…

In this article I’m going to show how I was able to alert a major Indian health benefits management platforms to protect their more than 50k customer contacts data, Personal Identifiable Information (PII) and insurance claim details etc.

Though the company decided to not reward me for what I found and close the report as internally known bug, I’m happy that I have at least stopped some big data leak.

A few weeks ago I got to know about a public bug bounty program of a Indian private insurance and health benefits management platform through a twitter follower. He was looking for help as he stuck in a vulnerability he found, and told me about the program.

I always hesitant to hack on Indian bb programs as majority of them are just fake and do not pay what published in the scope or tend to close critical reports as duplicate/ internally known issue.

However, a couple of programs like, Ola and PayTm are somehow exception to this.

Since I found the organization is a major and having an interesting business, I decided to hunt for high and critical issues only and avoid any low hanging ones. This program “M” recently raised $190M in investments, so this is as well made me start hunting.

Initial Reckoning

The scope including their main domain, ( *.maindomain.com) and their android and iOS apps.

I run the subdomain enumeration to find as much as subdomains as possible. Though they had a wildcard scope, but I managed to get only 10 subdomains after running httpx. Each major apps/web-apps found to be having a mobile version page like; m.app.maindomain.com, m.maindomain.com, m.app2.maindomain.com, poor guys couldn't afford a developer that can design a fluid UI…lol.

Well, having a two different code-base for a same web-app UI that runs separately on desktop browser or mobile browser is a major failure in the first-place.

I started browsing the apps using my desktop and mobile phones, I normally do this to see how the app’s response in different browsers. I realized that, the mobile version runs on desktop browser in a mobile mode.

This shows how badly the UI is designed, any UI designer knows how to redirect to full version of page, if the mobile version of UI is browsed on a desktop browser or vise-versa.

Attacking Mobile Version Apps

With initial recon done, I found the apps are ASP/ASPx based. One of the endpoints has a search feature that used to search insurance claims using ClaimID, UserID, Email, MobileNumber or PolicyNumbers. This page as well had an option to login to the portal, also uses SSO using Google.

WayBackURLs

A part of my methodology is, is WayBackURLs. I run WayBackURLs in the beginning of the recon with all the subdomains I have using -dates flag to see if there are any old cached pages. This helped me a lot in finding SQL injections. I did the same here.

Sometimes devs forget about hidden pages and they are pose vulnerability after sometimes.

WayBackURLs returns around 5k archived URLs. I do not want to test everything, so I grepped password, Pass, Password pass to filter the results that contains “password” in the urls to attack on login and forgot password pages to see if there are any vulnerabilities.

Grep filtered around 50 archived pages that has “Pass”, “pass”, “Password” and “password” in the urls.

Among them I noticed a page that said “https://target.com/Login.aspx/GetEncryptedPass” and “https://target.com/Login.aspx/ReAuthWithPass”. I browsed the page, but the page redirected me to “login” page.

I opened the same page in my mobile, strangely, my mobile browser displayed “Password-reset” page instead login page like it did in the desktop browser. I opened the mobile version page from my desktop browser “https://m.target.com/Login.aspx/GetEncryptedPass” I have the same password-reset page. So, this means the either is buggy or there is something interesting I could find.

The run ParamSpider to see if I could find any other version of the page other than WayBackURLs, I have only reference to this mobile page.

I copied the whole site using HTTrack just to see of these links are are being used in any pages, but I couldn't find a single link that referring to it — so this is confirmed /Login.aspx/GetEncryptedPass is a dead link, but dev forgot to remove it.

I opened the source of the page and found a couple of parameters used in the password reset form and rest is just a regular page:

I start the Burp Suite and started to browse the site. I insert the random username and date-of-birth in the field and sent it through and started to analyze the HTTP requests in Burp Suite.

After a while, in the HTTP requests I noticed the following POST request and the same parameters I found earlier.

I sent the request to repeater tab, and processed it, but I received session expired or session not found error. After a little recon, I understood that each request is sent with “ASP.NET_SessionId” + “_**__***_ses.12.1fef=*” + “__**__***_id.**” + “loginattempt=x” (I hide the cookie-name to avoid any sensitive info disclosure) and those are valid for max 3 attempts. After 3rd failed request, All cookies including ASP.NET_Session_Id resets and need to send a fresh cookie.

I made a new request using my browser and got a new cookies copied them from cookie editor and sent through burp repeater again, now I got Ok 200, but no changes in the response page, just a white blank page.

Time Based Time-based JSON Stacked Query SQL Injection

My first try with this ASPX app is time-based SQL injection attempt. So I sent:

The response was normal, no delay. I again sent same payload for another parameter “key”:

And, guess what, the server delayed response by 7.599 seconds. I made multiple requests with new payload and session cookie, I got delayed response as per the payload + 1sec additional.

Now I know the web-app is vulnerable to Time-based JSON Stacked Query SQL Injection.

SQLMAP

Since time-based SQLi is sometimes considered “high” not critical”, I decided to increase the severity by running the SQLmap. I copied the request file to my Kali machine and ran SQLMap with -p key.

Well, SQLMAP failed to detect even time-based injection, I tried different tamper scripts, but nope — nothing is working. I did not wanted to submit as blind time-based SQLi, so started looking for solutions, I found that I can directly inject JSON stacked queries POST as — data, never tried this method, so decided to test it.

I made a SQLMap query as below and start the injection. I add the — ignore-code=403 after a couple of failures because the server was sending 403 when session expires.

Within a few minutes, SQLMap found the injection point. I have a full exploit done by SQLMap, I retrieved host-name, current-user and current-db.

The Db server was lagging and there was a lot delay in responses, so I increased the delay and hex flags to avoid block. The next step was yo get the full database and see if there anything could increase severity.

I run the SQLMap again with following script:

After DBS was retrieved, I noticed the potential PII it could leak and the value of the data, the production DB has a lot of customer information, PIIs of clients, major insurance companies client details, information about client health, contact details, phone number, email id everything I found in different databases.

The company not only compromised their data but also their major insurance partner’s clients data, PII of insurance holders, their employee information etc ware as well put-in risk.

After this, I noticed a database that contains, AWS instance login-cred and domain controller administrator password, their exchange credential etc.

Reporting

As I have the all required info, I prepared detailed PoC with screenshot, screen-recording and detailed how-to in nice PDF and sent to them.

I got a auto-reply immediately saying they had received my report and the security team would take an action in 5 working days.

After 5 days I received back a reply from security team (Infra Security) saying below:

Hi Navin

Thank you for reporting the issue with us, but after evaluating your issue we have treated it as an internal known issue, as per internal policy known issues are not eligible for any monetary/reward.

Keep up the good work and we look forward to more reports from you in the future!

Thanks & Regards

Infra Security.

It was midnight, I found the email early morning, I immediately started my desktop and run the Burp Suite to see if the issue is still there, to my surprise the time-based SQLi isn't working and the endpoint what I found has been removed.

I ran the SQLMap to see if it can find the vulnerability, nope -I was right, they had fixed the issue and replayed me that issue is internally known.

Well, this was the reason I do not hunt on Indian bug-bounty programs, I tweeted about this and a lot informed me about such incidents they had experienced earlier with similar bug bounties.

Criticality of the data I found

When I saw the information in front of me, I started to think how much the company would have been penalized if this data has been leaked in US or EU. In India its still values peanuts. Though there are laws being made and things are getting better, companies like this must be treated with their own medicine, hence I wrote this long blog to put-out my frustration.

Btw, I replied to the email 3 times asking to prove the issue was internally known, but never got another reply. So I made my mind not to touch another Indian bug bounty program anymore.

That’s all, thank you for reading.