Web Vulnerabilities and Disclosure Revelations: The Ship Has Sailed
This is the first article of the series. It's a pretty cool bug, in my opinion, with a little twist at the end. As we progress, there will be more high- (and low-) profile exposures and issues.
Lately, I've given a lot of focus on APIs. I've been researching ways one can exploit them, discover them, and techniques for better recon. Also, a large amount of my free (and working) hours goes into scanning the Internet for exposed APIs. This writeup is about an API vulnerability (or more like an exposure) I encountered when scanning using Shodan.
The organization is a big European shipping company (and one of the largest in the world) based in Switzerland. The company was hit with an unnamed ransomware some years ago that "brought down its data center for days." As we will see later, they are still not quite there when it comes to security.
The vulnerable API was (or is?) an exposed internal endpoint that allowed any unauthenticated user to download internal documents regarding the schedules of ships leaving and arriving at ports of a certain European country, as well as the ships' information, along with documents sent to clients. These documents also exposed email and physical addresses. Also, the API was used for sign-in and signup purposes. Although it was possible to do both, I was unable to find the web application that was utilizing it.
Discovery
Although I usually scan for APIs and I then look for vulnerable ones, this time I went specifically after this company. I was sailing one day, when I saw one of their ships and I got intrigued, thinking how cool it would be to be able to say that I reported a vulnerability to this company.
The first thing I usually do is go to Shodan and look for hosts related to a specific target. I once wrote an article on using search engines for bug bounties and pentesting. To this day, I use the same techniques for passive recon.
A simple-looking Shodan query ssl:"domain.tld" "200 OK" will return all hosts that return a 200 HTTP code and whose SSL certificates are issued for or even just include domain.tld. The results were not that many, so I decided to go through them manually using Shodan's website.
When manually inspecting hosts, the ones that catch my eye are weird/interesting-looking ones. That means hosts with default front pages, specific products, VPN appliances, test/dev/staging apps, etc. After visiting each interesting-looking host, I encountered one that looked really simple: it included two empty lists to select from and two buttons: "View" and "Download". The "View" was useless. But the "Download" button was redirecting me to an API endpoint, namely https://blah.domain.tld/api/document/get/download/undefined/0.
Internal documents, authentication, and surprises.
The undefined part of the URL was causing the API to throw this error. Fuzzing the word `undefined` with a simple wordlist using `ffuf`, endpoints with certain numbers were returning some data, e.g.
https://blah.domain.tld/api/document/get/download/10/0https://blah.domain.tld/api/document/get/download/31/0https://blah.domain.tld/api/document/get/download/44/0
etc.
The specific endpoints were returning exactly what the URL says: documents. Each number represented a port and as you can note at the bottom of the PDF, their scope/sensitivity is limited to internal knowledge.
As mentioned, the information in those documents were not credentials or any high-value secrets, but ship schedule and information. That alone doesn't seem much of a big revelation and maybe it's not. But you have to take into consideration the nature of the company and what the company itself values as important.
It also appears that the documents are being updated regularly. Three weeks after I discovered the API, the same endpoints were returning different documents. So, after the initial ~30 documents, I ended up with ~60 after one month.
Uknown authentication
Continuing my API enumeration, I fuzzed for endpoints and found /login and /signup. Of course, those are POST endpoints that required parameters I didn't have. From my experience, such endpoints require a minimum of two parameters: username and password. And that was the case for /login. For /signup I had to fuzz for JSON parameters to succeed. For this task, I used BurpSuite's param-miner and good ol' ffuf. The ffuf syntax for it was the following (yes, you can fuzz for literally anything with ffuf):
ffuf -u "https://blah.domain.tld/api/auth/register" -XPOST -H "Content-type: application/json" -d {"username":"testUser","password":"testPassword","FUZZ":"blah"}' -w parameter-wordlist.txt"Through the error messages thrown, the size of the response, and some manual inspection, the scan yielded the third parameter confirmpassword (which made sense for a signup page tbh).
The signup and login endpoints worked just fine. The login function returned even a JWT signed with the none(!) algorithm. This means that anyone who had a JWT of this app could forge the token and impersonate any registered user. Unfortunately, I was unable to find the web application that was utilizing this API. But this still remains an issue to address internally.
I am not alone here
While browsing some of the documents I downloaded from the API, I came across some non-PDF files. I displayed them on my terminal
and it appears I am not alone here on this quest...
What surprised me (and kind of intrigued me, ngl) the most was the fact that, apparently, there were other, malicious and non-malicious hackers around, poking and exploiting this API. I can assume that other people have notified the company about this issue. Do you think they did something about it?
Vulnerability Disclosure
With the help of colleagues, I found the email address of their CISO. Also, the PDFs the API was leaking were signed with the name of the author (thank you, forensics CTF challenges)
I found as many authors as I could on LinkedIn and CC'd them to the email I sent to their CISO. The email contained everything I found, i.e., the exposed internal API that:
- leaks internal documents
- allows anyone to login through the API and register into their user database
- was already exploited with webshells
Two months later, there is still no response to the emails me and my colleagues sent, even though we know they opened theme emails. One would think that after the ransomware hit, they would take things like this more seriously and respond. But hey, if they did, I'd be unemployed and/or bored.