A Case Study in Database Security Vulnerability
In this case study, Chip Andrews, an expert in SQL Server security, shared this experience of (ethically) hacking into a client database to uncover security flaws. This example provides a cautionary tale to protect your important information by insisting on sound database security.
During a routine penetration test, Mr. Andrews performed the obligatory Google searches, domain name research, operating system fingerprinting, and port scans, but this particular website was locked down tight. Moving on to the web-based application running on the system, he was immediately confronted with a login page using SSL-encrypted forms authentication.
By checking the source of the web page, he noticed that a hidden App_Name field was being passed to the application whenever a user attempted to log in to the site. Could it be that the developers might have failed to perform proper input validation on this innocent-looking parameter? The hunt was on.
First, it was time to assemble the toolkit. At the time of this penetration test, Mr. Andrews preferred to use the following: Paros Proxy, Absinthe, Cain & Abel, Data Thief, and the Microsoft SQL Server Management Studio/SQL Server (Express Edition), all of which are available free.
For starters, he used Paros Proxy to allow for more control and visibility to the web requests made to the web server.
After spidering the site for available pages and performing a quick vulnerability check for SQL injection, it was confirmed that the App_Name parameter appeared to cause the application to throw an Error 500 exception, indicating an application failure. Penetration tests are one of the rare occasions when an application failure is a desirable outcome.
Because the application failure indicated that Mr. Andrews could inject unintended characters into the SQL code being sent from the application to the database, he could see whether it was an exploitable condition.
A common test that works with Microsoft SQL Server databases is to inject a command, such as WAITFOR DELAY ’00:00:10’, which causes the database server to stall for 10 seconds. In an application that normally returns a page in one second or less, a consistent 10-second delay is a good indicator that you can inject commands into the SQL stream.
Next, Mr. Andrews attempted to use the Data Thief tool to attack the login page. This tool attempts to force the database to use an OPENROWSET command to copy data from the target database to Mr. Andrews’s database located on the Internet.
This is usually a very efficient way to siphon large amounts of data from vulnerable databases, but in this case, his attack was foiled! The database administrator at the target had disabled the OPENROWSET functionality by properly configuring the Disable Adhoc Distributed Queries option.
With diligence as his watchword, Mr. Andrews persisted with the next tool — Absinthe. This tool uses a technique called blind SQL injection to make determinations about data using simple yes or no questions of the database. For example, the tool might ask the database whether the first letter of a table is less than L.
If yes, the application might do nothing, but if no, the application might throw an exception. Using this simple binary logic, it is possible to use this technique to reveal the entire database structure and even the data stored inside — albeit very slowly. Using the tool, he identified a table of sensitive customer information and downloaded several hundred records to show the client.
Finally, it was time to attempt one last act of database dastardliness. First, Mr. Andrews loaded the tool called Cain & Abel and set it to enter sniffing mode. Then, using Paros Proxy and the already identified vulnerable parameter, he used the xp_dirtree extended stored procedure, which is available to SQL Server database users, to attempt to show a directory on his Internet-connected machine using a Universal Naming Convention path.
This forced the target database to actually attempt to authenticate itself against Mr. Andrews’s machine. Because Cain & Abel was listening on the wire, it obtained the hash of the challenge used to authenticate the exposed file share.
By passing this hash to the password cracker built in to Cain & Abel, Mr. Andrews would have the username and password of the account under which the vulnerable SQL Server was running in just a matter of time.
Would this hacked account use the same password as the admin account of the web application? Would this password be the same as the local administrator account on the host? Those were questions for another day. It was time to assemble all the collected data, prepare a report for the client, and put the tools away for another day.
Chip Andrews is a co-founder of security consulting firm Special Ops Security, Inc. and owner of SQLSecurity.com, which has multiple resources about Microsoft SQL Server security, including the SQLPing3 tool. A co-author for several books on SQL Server security and a Black Hat presenter, Mr. Andrews has been promoting SQL Server and application security since 1999.