Chasing Vulnerabilities for Fun and Profit

PERSPECTIVE Cross-site scripting attacks have recently shot into the spotlight following a high-profile MySpace worm and banks taking extra measures to stop phishing. In a guest column for BetaNews, security expert Jeremiah Grossman delves into the XSS problem with a peek inside the world of those hunting down security flaws.

As the CTO of a Web application security service company, 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 Web sites 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 percent 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 many 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 Web site 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 Web site. 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 our office, the prize is bragging rights.

Recently, we penetration-tested a Web site 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 Web site 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 Web site 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 Web site 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 Web site doesn’t function properly otherwise. For example, Shaquille O'Neal, with the apostrophe 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. In classic style, we cried foul because he could arguably only exploit himself with XSS and represented no further risk.

Now that the easy stuff was out of the way, it was onto the tough part.