The Web Hacking Incidents Database Blog

XSS have dominated the Web Hacking Incidents Database statistics page since its inception. The immediate conclusion it that XSS is the most dangerous of them all. This is supported by the fact that XSS is the vulnerability most commonly found by pen testers according to the Web Application Security Consortium’s Statistics Project and that new and advanced JavaScript payloads such as Anton Rager’s XSS proxy or SPI’s JS scanner are created daily to exploit XSS.

On the other hand, while it is easier to find XSS vulnerabilities (after all the vulnerability is reflected to the client), it is still harder to abuse XSS vulnerabilities.

An new feature of the Web Hacking Incidents Database statistics page published today shed some light on this question. In addition to the total count, two new numbers are presented for each classification: the number of actual security breaches reported and the number of vulnerability disclosed but not known to be abused. Actual security breaches are more significant as they indicate both that a vulnerability is exploitable and in many cases what the damage can be.

The numbers are interesting: while on the total count, XSS leads by a wide margin (53 incidents vs. 24 for SQL injection), when we look only at the number of security breaches the field levels, with XSS and SQL injection tying for first place (15 incidents each). But the really striking number is the number of breaches for which the vulnerability is unknown: 37, more than XSS and SQL injection together!

What can we learn from this? that XSS is certainly a killer vulnerability, even if not THE killer vulnerability. But probably the main lesson is that we know little. With so little information about the real world attacks, threat modeling requires collecting information from many sources, each providing a partial and somewhat biased view. In addition to WHID information can be drawn from sources such as the WASC’s Statistics Project, Jeremiah Grossman’s Web App Sec survey or WASC’s Open Proxy Honeypot Project and others. Saying that, with so much more hidden than on the surface, we always need to rely on own (hopefully) good sense.

The entry in the Web Hacking Incidents Database FAQ describing which incidents are included in the database and which are not seems simple, but hides a lot of complexities.While it might seem obvious what a web hack is, nothing is further from the truth. Is a hack only a real break-in or any vulnerability discovered in a live web site? We recently changed the criteria for inclusion in WHID. The reason was simple: to make the database more useful. We made two changes:

• Gone are most vulnerability disclosures. They can only marginally be called hacks anyway, and on top of that, the blur the difference between this database and your normal everyday vulnerability registries such as Bugtraq and CVE. A small number of vulnerability disclosers still make their way to WHID, if the relevant web site is of such an importance that justifies that, or alternatively, if the case can teach us something
• The requirement for a court proof for the hacking being web based was removed. The requirement made the database very objective, but severly limited our ability to include incidents in the database. We now include stories that we believe are a result of a web hack, even without hard evidence. We are ready to remove stories if we find out differently, which recently happened in the TJX incident.

The new criteria balance the need for objective selection of incidents with the need to bring good stories that people will find useful. Not having CardSystems in WHID for a long time was just not justifiable. Bottom line: now we have all the good stories and just good stories.

Until today, the CardSystems incident, probably the most well known information security breach ever, was mentioned in WHID only in the FAQ. It was mentioned as an example of an incident that we would like to add to WHID but cannot because there is no public information about how the hack was done. Today, nearly a year after it was initially publicized, it was added to this database. While we always suspected that it was a web hack and industry rumors hinted that, no public information regarding the way in which the hack was done was available until now.

Most are already familiar with the infamous CardSystems incident where hackers stole 263,000 credit card numbers, exposed 40 million more and several million dollars fraudulent credit and debit card purchases had been made with
these counterfeit cards. As a result of the breach CardSystems nearly went out of business and was eventually purchased by PayByTouch. CardSystems is considered by many the most severe publicized information security breach ever
and it caused company share holders, financial institutes and card holders damage of millions of dollars.

Recently new articles about the case revealed that SQL injection was used by the attackers to install malicious script on the CardSystems web application database which where scheduled to run every four days, extract records, zip them
and export them to an FTP site. You can links to those articles in CardSystems entry WHID 2004-17.

This is one of the most stunning examples where a web application security hole was used to launch a targeted attack in order to steal money.

I’ve recently added to the database an old incident. In March of 2003 a hacker broke into the computers of the University of Texas in Austin and stole more than 55,000 social security numbers. Since at universities the networks are many times wide open, I dismissed the incident at the time as another network based hack.

A note posted in one of the mailing list made me go and check the incident again. I found out that the hacker penetrated a database, not a web application, but not a network layer attack either. I continued my research in order to determine what database is was and found out that it was txClass. Now, what database can this be?  I certainly haven’t heard of such a product before. Well txClass is a web based application, which was referred to in the news stories as a ”database” since it does manage a database.

So this was a web application layer hack. I even managed to find out what the hack was: the hacker brute forced the system by trying large ranges of social security numbers.

This incident shows how little we actually know about published incidents and hints that many of the incidents that I do not include WHID might actually be related to the application layer.

If you took a look at the statistics page, you probably saw that in 2005 the number of reported incidents grew rapidly. This is probably at least partially because we started collecting information in 2005. But I believe that there is an additional reason: many more people are concerned with web application security and are inspecting online services searching for vulnerabilities.

When analyzing the 2005 incidents we can see that the bulk of incidents are disclosure incidents, and in many cases they have two common attributes: they where discovered in major sites such as Google and Yahoo and a large part of them are XSS vulnerabilities. The reason for that is simple: researches naturally focus on larger sites, and XSS is the easiest vulnerability to find since the vulnerable code is on the client machine and available to the researcher.

These findings highlights two phenomena: first, the ever increasing interest and knowledge of more and more people in web application security. To understand how strong is this phenomenon one has to inspect the work of Aliaksandr Hartsuyeu from eVuln.com, who has made a point of inspecting every open source application under the sun, releasing a new vulnerability report daily. He started his endeavor around Christmas and already released more than 120 advisories.

The second phenomenon is the iceberg phenomenon. The number of vulnerabilities found in major sites that invest in security provides an indication as to the much larger amount of vulnerabilities yet to be discovered in less popular or less exposed sites. The large number of XSS vulnerabilities indicated that vulnerabilities that are more difficult to find in a black box inspection such as SQL injection are just as common, as SQL injection vulnerabilities are usually found more   than XSS vulnerabilities in source code inspections.