Chasing Vulnerabilities for Fun and Profit

Over the next few minutes I found a few other XSS issues of the "Non-Persistent" variety. More severe vulnerabilities than Bill's find, but I was too slow. The next discoveries were instances of Information Leakage and Predictable Resource Location, essentially uncovering operating system directory structure and notes on application configuration. Still, nothing worth gloating over. That's when I fired up my trusty custom proxy, and began clicking around the Web site while monitoring all HTTP requests for anything interesting.

After ten minutes elapsed, I found a peculiar URL with a parameter name-value pair containing something worth investigating. The URL was hard to spot because it was buried behind a JavaScript enabled link and redirect, so it was never directly visible in the Web browser. Most of the query data portion of the string was obscured by the URL-encoding format. In the URL there was a distinguishable "AND" with "+" symbols on either side, indicating a possible embedded SQL statement. I decoded the URL to observe it further.

Yes, this definitely was a partial SQL statement complete with a "WHERE" clause hiding beyond the immediate view of the location bar. Altering the URL with the usual single-quote semi-colon did not yield anything useful because the code-500 messages were devoid of the common SQL debug errors. Good for security, bad for me. I needed an exploit and it had to be done blind.

The rest of the team was silent, but the furious keyboard pounding signaled that it was only a matter of time before someone spotted the same vulnerability or another one sooner. And that's exactly what happened.

Bill, while parameter tampering, was rotating a query string ID value to reveal the names of other customers (~11 minutes). A very respectable Insufficient Authorization discovery. Not necessarily a harmless flaw, but far short of a system compromise, so the game was still afoot and I knew I was close.

Simultaneously, I was working on the SQL statement embedded in the URL. The SQL statement appeared to be querying the database while combining it with my account ID (also present in the URL). This was done so that only data paired with my account ID would be returned. After several failed hack attempts, I wondered if I simply swapped the AND for an OR, would everyone's data fitting the description dump out? I wanted to find out.

It took me a moment to understand what I was looking at, but that's exactly what happened. A SQL Injection exploit and no errors generated (~15 minutes). I was viewing information that should not be available under my user account. In fact, this was direct backend database access system-wide. It was possible to pull up any information I wanted, an unthinkable and unacceptable business risk.

I stopped short of attempting more sophisticated requests because we could already demonstrate solid proof-of-concept. No need to exploit anything further than what was required. At that point the contest was over; Bill won the speed hack, I got the best exploit. At the end of the 15-minute race the team generated about a dozen vulnerabilities ranging from low to high severity.

During our post-op meeting, we described our findings to the client organization. We explained the vulnerabilities, the potential impact, and the available remedies. For the organization, exposure and/or exploitation of the issues we found would have been devastating for them and their customers.

Naturally, people in this position feel somewhat embarrassed and defensive, especially after claiming the Web site is solid. They spent a lot of hard hours building the system and no one likes to be told that their baby is ugly.

The truth is that there really is nothing to be ashamed of since, as I stated, nine out of ten Web sites have these issues. The key is to acknowledge that these holes exist, know the vulnerability status on all your Web sites and fix the issues in a timely manner. With that, you can be the exception rather than the rule.

Jeremiah Grossman is the founder and Chief Technology Officer of WhiteHat Security, where he is responsible for Web application security R&D and industry evangelism. As a seven-year industry veteran and well-known security expert, Mr. Grossman is a frequent international conference speaker and a founder of the Web Application Security Consortium (WASC), as well as a contributing member of the Center for Internet Security Apache Benchmark Group. Prior to WhiteHat, Mr. Grossman was an information security officer at Yahoo!.