Welcome back! We hope you’re enjoying our series on Simple Security Fails. If not, or if you have any topics that you’re interested in learning more about, hit us up! We’re reachable via email, LinkedIn, or carrier pigeon. Whatever works.
Today’s topic will be extraneous server content. During penetration tests, White Oak Security often discovers that clients have more content available on their servers than they intended to share. That content can be anything from backup files, to default server or configuration pages, or even content that the teams were unaware of entirely. Because it’s so common for companies to unintentionally leave extra content on servers, attackers have developed pretty great techniques for searching for extraneous server content. The more information that a team has left exposed on a given server, the greater the attack surface – and likelihood of an attacker finding something juicy. In this blog post, we will explain why it’s important to audit the available content on servers frequently, and to remove all content that is no longer required.
On a recent engagement, I was asked to perform security testing on a web application. During the reconnaissance phase of testing, I ran a number of scans to learn more about all servers in scope. One of the tools that I like to use during engagements is dirb. It’s a great command-line tool for discovering web content on servers. The tool works by iterating through a wordlist of common server files (either a default wordlist, or one of your own design) and by making HTTP GET requests to the server of your choice to determine if the files or directories in the wordlist exist on the server.
For the sake of this post, I will refer to my client’s domain as https://example[.]org. Using a default dirb wordlist on https://example[.]org, I was able to pull the following information about the server:
After an initial inspection of the results, I proxied each of the discovered pages through Burp Suite. Upon reaching the https://example[.]org/search.php page, I was presented with some descriptive text, and the ability to search for information about particular states/provinces by entering a keyword:
As it turned out, this page could be used for much more than pulling back interesting information about geographical locations. It could also be used to view database schemas, dump tables, and to view production user data. That’s right folks – SQL injection.
When I performed an active scan on all web content for the example[.]org domain that I was testing, Burp flagged a possible SQL injection (SQLi) on the search.php page. The request/response is shown below. It was suggested that the highlighted “state” parameter could vulnerable to SQLi.
Using sqlmap, a tool for testing and exploiting SQL injection vulnerabilities, I was able to confirm that the “state” payload was in fact vulnerable to SQLi. You can see that I was able to determine the database type, variant of SQL injection vulnerability, and was able to pull the schema data for the tables using this particular command.
In addition to pulling the schema, I was able to view the data in most tables. Fortunately for the client, I determined that the user I was able to access using this injection vulnerability was not a database administrator. Furthermore, I was unable to either privilege escalate or to pivot to an OS shell. With the access granted, however, I was still able to view sensitive business information.
Although the techniques used in this attack are not novel, it served as a great reminder to remove extraneous services and files from web servers. The client was no longer using this page within their application and was unaware that it remained on the server. During our call, they were able to immediately remove the content from the site, thus remediating the issue on the spot. If they had properly audited their server content regularly, perhaps this would have been removed from their site sooner.
For any developers out there, I highly encourage your teams to audit the content that is publicly available on your sites occasionally. This can be done in a number of ways, but the most efficient way is probably to pull a full directory listing of the web root for your application and by going through each item to determine if anything should be removed. It’s possible that extra services or pages could be available that could either provide information to attackers or could even broaden your attack surface – as was the case with the SQL injection on the page that I discovered.
Cyber Advisors specializes in providing fully customizable cyber security solutions & services. Our knowledgeable, highly skilled, talented security experts are here to help design, deliver, implement, manage, monitor, put your defenses to the test, & strengthen your systems - so you don’t have to.
Read more from our technical experts...