Hacking the Healthcare Industry: My First Critical Vulnerability

The story begins with HackerOne, one of the leading bug bounty platforms. For those that don’t know, many companies accept vulnerabilities as part of public vulnerability disclosure programs, or they invite established hackers to private programs. The good ones even offer rewards. This is a big change from hacking twenty years ago, when a company responded to a vulnerability report with the threat of a lawsuit.

The first question to ask when entering the bug bounty world is which company should I hack? I chose the newest public program on HackerOne: a healthcare company that specializes in medical distribution and supply chain services. I began by enumerating the company’s subdomains, and then I started digging into each website. After many hours of staring at dense JavaScript files, I hit the jackpot—plaintext credentials embedded in a .js file.

Bonus Tip: The JS Miner Burp Suite extension will catch things like this, but be prepared for many false positives.

At this point, any hacker’s heart would start beating faster. But the question becomes, do the credentials actually work? The JavaScript file points to a website where suppliers can manage their contracts with this healthcare company. I quickly found the login endpoint and tried the usernames & passwords one by one—the admin account, the supplier account, the product manager account—but none of them gave successful logins…

Until the last one: readonly@readonly.com.

And just like that, I’m inside the supplier management dashboard. And not as a customer—as an internal user with (apparently limited) administrative functionality. Most web applications have a test/guest/readonly account that should have restricted permissions. But should and do are key distinctions in cyber security. I start by searching for hidden functionality; the inspect feature on Chrome (and the HTTP response via Burp Suite) reveals the existence of a few hidden endpoints.

These pages don’t appear in the UI due to the data-ng-show="!vm.isGuest" in the JavaScript, but this alone doesn’t constitute an authorization check. Sure enough, navigating to /#admin/users reveals a full list of users on the website.

We now have the option to glean emails and limited personally identifiable information (PII) of every use, delete all accounts, and more. At this point, it was clear I had found a critical severity vulnerability, and I figured I better inform the company ASAP. I wrote a report, submitted it through HackerOne, aaaaaand…

It was previously reported by someone else. The sad truth in bug bounty hunting is that only the first person to discover a vulnerability gets any credit. But I was not deterred. There was still plenty of functionality left to test and more vulnerabilities to be found.

I turned my attention back to the admin endpoints. At /#/admin/new, there appears to the ability to invite new users (and admin users at that). However, there was no button to actually trigger the request.

In situations like this, there are two things to try:

1. Analyze the JavaScript and craft a POST request based on the variables and format found in the .js files

2. Trick the web application into sending the request so you can see what format the request takes.

The second option is easier, but often impossible. My eyes were already bleeding from looking through so many .js files to find the credentials, so I prayed the front-end developers were lazy, and as luck would have it:

If I remove ng-hide and disabled="disabled" from the HTML, a fully functioning “Invite For Registration” button appears. After filling in my information, I received an email invitation to the portal as an administrator.

Bonus Tip: You can use the LazySec Chrome tool to automatically reveal disabled fields and hidden elements. Or you could write your own extension!

Since I was duped on my first report, I knew at least one other person had accessed this management console before I had. I put myself in the mind of an attacker; once I had admin access to this website, I would want to gain persistence in the system. That way, if the company’s IT team deleted all of the accounts I made, I’d still have privileged access.

I started testing persistence techniques, and found one quickly—even if my account was deleted, the “setup account” link from the invitation email still worked. This means that no matter how many times my admin user gets deleted from their system, I can reactivate the account by following the setup steps in the email. I wrote up this finding (along with a few others), and I received my first triaged, non-duped report.

As a cherry on top, administrative users had access to the full database of users. This included the email, phone number, password hash, and account metadata for 2,793 users. This was my first real experience hacking, and how could I not be hooked after this?