In the TRC, we cover the WASC in our search for vulnerabilities on the web. Among this large list of vulnerabilities is SQL injection. The TRC looks for error-based and blind SQL, and does various tests to verify the vulnerabilities found by both scanning and performing PE-level business logic assessments to create the Sentinel service.
Recently, Justin and I received a request from a client to dig deeper and show what could be done with an SQL injection vulnerability. This sort of thing isn’t uncommon, because clients often may want to show developers why a particular vulnerability is a problem, or to explain to upper management why more resources are needed to fix a particular vulnerability in an application.
Justin and I wanted to have some fun with this request. The vulnerability was a blind SQL injection that was particularly annoying to verify due to its behavior and various blacklisting already done. When I discovered and verified the vulnerability, I was able to fingerprint the database server as Oracle, based on the behavior of the SQL injection. Once we established a true/false/error condition that we could rely on, we started building out our exploits. First, we grabbed the database username, then we grabbed the database name. Next, we decided to take our investigation a step further and use some of Oracle’s network capabilities.
Programmatically, we were able to
You are probably wondering why I left that incomplete. Stick around for Part Two of this post to learn more about what Justin and I did next.