Sometimes our assessments surprise us —not because of what issue we identified, but how we identified it.
A client hired Packet Ninjas for a routine External Network Assessment. They gave us their external range, but it was not the most up to date. Some of the included IPs no longer belonged to them. (Please confirm your network ranges are up to date before engaging a vendor for a network assessment!)
We discovered an issue with one IP. Once we realized it was out of scope for the engagement, we sent the owner of the site a bug report so that they could address the issue.
The Issue
Many developers enable debugging and publish an application without turning the feature off. However, if debugging is enabled in production, it can lead to issues on the site. Not only does it give attackers a lot of information about the website and the backend technology, but some software includes features to allow debugging in real time. This might not seem like a big deal, but it allows ANYONE to perform functionality on the site that should be reserved for the site administrator. This has the consequence of allowing attackers to completely compromise and take over not just the website, but the server that is hosting it.
Our Ninjas were able to identify and help remediate the issue in 3 steps:
1. Hunt Down the Debugging Environment
We first need to get to the debugging environment. This usually involves throwing some random data at the application or visiting a URL that may or may not exist.
In this case, visiting the URL (https://account.tapitag.co/andy) pulled up the error page. The user ‘Andy’ did not exist and threw an error that led to the debugging console.
2. Exploit the Information
During our exploration of these features, we noticed a page labeled “Tinker”. Visiting this page opened a SQL window. This is sometimes referred to as an open SQL window as it will query the database and has no real restrictions on the type of commands that can be executed.
Our first thought was to query for user information and pull down the user database. We tried using the command:
DB::table(‘users’)->limit(10)->get();
Success! Now what?
3. Own the Box
Since we know this SQL window allows us to run almost any SQL query, we decided to try some fun SQL tricks to query the underlying OS. We attempted to use the following command to query a common file:
shell_exec(‘cat /etc/passwd’)
Since our test was successful, getting a reverse shell on the machine would be trivial.
The Outcome
Remember how we said some of the included IPs no longer belonged to our client? Turns out this was one of them! We ceased testing as this was no longer in scope. We then did a bit of research to identify the actual owner of the site so that we could help them remediate this issue before it caused a larger issue.
Our Ninjas shared our findings with the owner of the site, who gratefully turned off debugging in the production environment.
Protect Yourself
Before you go live, disable all debugging and testing modes in the production environment!