Not too long ago I put a whole city on high alert during a security assessment. A tale of caution. Read along to learn my approach & mistakes! I was contracted for a penetration test of a medical company. This company offered a lot of different services. Some were software and some were medical hardware. The scope of the test was vast, all web applications of a certain domain were in scope. No authentication to any services was given though. I started my recon after the 1st kickoff call.
Recon, at this stage and for this type of test, consisted of running tools like Subfinder from
@pdiscoveryio and Amass from @owaspamass to find as many subdomains in existence for the client. I found several subdomains live but most asked for authentication. Some seemed like API endpoints, resembling:
http://signalAPIca.RedactedMedCompany.com
When doing recon to find subdomains there are different methods to find them. One is to query various internet services, which the above tools do. Another is to brute force common subdomain names. There is a deeper method inside of brute-forcing called “permutation scanning.” It is the idea of adding iterative and contextual modifications to find new subdomains, an example could be:
http://dev.signalAPIca.RedactedMedCompany.com
Or
http://signalAPIca1.RedactedMedCompany.com
Some subdomain finding tools have the option to do this, but you have to specify it explicitly.
The one i prefer specifically for this task is Gotator, with run syntax similar to this (from the Github documentation):
On this client, I found a domain similar to:
http://stage-signalAPIca.RedactedMedCompany.com
After requesting several of the found domains by hand I guessed that there were several API endpoints by state (CA at the end).
With most of the endpoints, no API definition docs were available. So I had no idea how to query the APIs but, stage- did have them. Schemas, not descriptions. After fiddling with different requests in the docs, stage- also lacked authentication for several calls.
One of the calls that succeeded was something like:
GET
http://stage-signalAPIca.RedactedMedCompany.com/api/alerts/Which gave back JSON data with latitude and longitude coordinates.
Another call that seemed to work was something like:
POST
http://stage-signalAPIca.RedactedMedCompany.com/api/alerts/queerts/queue/
{
“clientID”:integer
} Responding with a reply of “ok” or some more geolocation data. I assumed I could report a privacy bug here if I later tried to correlate clientids to locations. To prepare for this I used an interception proxy (Burp Suite) to script sending the above POST request to clientID’s 1-5000 to collect any that responded with more data.
I moved on to other portions of the assessment. I was working on some Cross Site Scripting findings and I got a call…
“Hey Jason, we just saw our systems send out a large batch of emergency medical requests across Southern California… do you know anything about that?”
Apparently, the system I found was for those things that elderly people wear to call EMS to their house…
The “stage” server wasn’t so stage-like. The API calls should have required an authentication token. The proxy task I had run queued up sending requests for ambulances to 5000 elderly across California.
In the end, the client sent an emergency email to EMS services to halt the fleet. I could have phoned the client before running the script but, I had so little info to go on. In this case, a white-box testing model would have been much better.
That’s mostly it! I found a bunch of other stuff related to privacy leaks and general web bugs but nothing that left me in a cold sweat like that call.
Comments