Chasing Vulnerabilities For Fun and Profit
*Names have been withheld or changed to protect the innocent
As the CTO of a web application security service company (http://www.whitehatsec.com), much of my time is spent educating companies on how to reduce the risks of conducting business online. Most of the people I speak with are stunned to learn that nine out of ten websites contain vulnerabilities. Think about it. Every time you visit your favorite online store, check your account balance or participate in a chat, there’s a 90% likelihood that the site can be compromised in some way. Despite the statistics, many IT/security professionals still believe that firewalls and SSL can protect their web applications, or that their developers write perfect code. Whatever the reason, many organizations will learn the hard way that web applications are the new point of entry into their systems, by getting hacked. Consider MySpace, the social networking site. Exploitation of a common cross-site scripting vulnerability affected roughly 1 million users and cost 20 hours of downtime. What company can afford that?
When speaking with organizations, WhiteHat is often asked to justify the need for a web application security service, especially on an ongoing basis. IT/Security employees typically request a way to convince those who control the checkbook (management) that web application security is something worth spending time and money on. What we’re really being asked is to demonstrate how someone could hack a company’s website and cause serious harm. In the industry this practice may be referred to as a “penetration test.”
Penetration tests are often used to quickly spot security weak points and compromise a system as fast as possible. The results are far short of a “security assessment” where the review is more exhaustive and the analysis is more comprehensive. Penetrations tests attempt to find and exploit a few vulnerabilities, while assessments identify all the risks. A benefit to those performing penetration tests is that it keeps the skills sharp, improves automation technology, and validates testing methodology. Plus, they’re fun. And having fun as only security people could, at WhiteHat Security we like to race.
As a spontaneous office activity, a few of us will race to find the first and best vulnerability in a never-before-seen website. “Cross-Site Scripting” (XSS) or better is the lower bar we’ve set. Most of the time identification of the first vulnerability occurs in less than two minutes, which adds to the adrenaline rush. The second challenge is to find the first and best high severity vulnerability. Normally high severity vulnerabilities allow you to access someone’s account data, execute administrative level functions, or circumvent important business logic process. These issues take more time to find, although the average is still less time than it takes to have a pizza delivered. At WhiteHat’s office, the prize is bragging rights.
Recently, we penetration-tested a website that hosts thousands of enterprise-level customers. I’m not able to give many details about the exact nature of the system, except to say that it was nothing less than mission critical. Companies depend on the web-enabled service for core business operations. Hacking this website would reveal sensitive information about thousands of diverse company and network infrastructures. It would be a company’s worst nightmare if someone nefarious exploited the system and took control. We were informed that the website had been examined for security issues previously, even scanned, yet nothing questionable was found. Our penetration test was not expected to succeed. As one might expect, there was extreme interest on the client’s part in any security issues we’d find and great anticipation on WhiteHat’s side for the challenge ahead.
This website was built using ASP.NET which you can always identify by the familiar “aspx” file extension. ASP.NET (1.1) makes finding XSS and “SQL Injection” significantly harder because the default configuration blocks special characters in the URL required for exploitation. But on many ASP.NET installations, the security configuration is turned off in certain areas, most likely because the website doesn’t function properly with them. For example Shaquille O'Neal, with the apostrophe (special-character) in his name, might have trouble logging in.
With the necessary paperwork signed and account credentials generated, we were ready to go. The URL and username/password were revealed to the racers and the symbolic green flag dropped. The next several seconds we heard nothing but mouse clicks and keyboard tapping. From past experience we’ve learned that the fastest way to victory is to target the search boxes first and try for a speedy XSS win. Search boxes are notorious for such insecurities. It’s a cheap trick, but it works. Next, it’s best to look for input parameters and determine if any of them echo URL query data, indicating another potential spot for XSS.
The first 60 seconds of the race flew by. Nervousness set in because we knew that at any moment someone was going to claim speed-hack victory. Bill Pennington (WhiteHat’s VP of Services), in what is becoming a trend, identified the first vulnerability (XSS) in about 1 minute 30 seconds. We’re convinced he’s got some kind of bug-finding E.S.P. In classic style, we cried foul because he could arguably only XSS himself and represented no further risk. But the ruling on the field was that the office rules cited no such provisions, thus giving Bill the win. Time to change the rules for next time. Now that the easy stuff was out of the way, it was onto the tough stuff.
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 website 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 code messages were devoid of the common SQL debug error messages. 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 website 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 websites have these issues. The key is to acknowledge that these holes exist, know the vulnerability status on all your websites and fix the issues in a timely manner. With that, you can be the exception rather than the rule.
Full story...