Good morning, Worm, Your Honor

[This was originally posted August 2003 on the now-defunct site before the Samy worm and sophisticated XSS attacks appeared. In the five years since this was first posted, web applications still struggle with fixing XSS and SQL injection vulnerabilities. In fact, it’s still possible to discover web sites that put raw SQL statements in URL parameters.]

With the advent of the Windows RPC-based worm, security pros once again loudly lament the lack of patched servers, security-aware power users once again loudly blast Microsoft for (insert favorite negative adverb here) written code, and company parking lots at midnight still have a few sticker-laden cars of sysadmins fixing the problem. Of course, there are a few differences such as Joe and Jane’s home computers have been caught red-handed showing vulnerable ports (unlike SQL Slammer or the IIS worm of the month which targeted servers not usually found in home networks), but the usual suspects still linger.

In fact, we could diverge onto many different topics when talking about worms. For starters, what’s the point of arguing against full disclosure when worms arise weeks (SQL Slammer, our RPC friend) or months (Nimda and Code Red) AFTER the patch has been released? Obviously, that sidesteps many arguments against full-disclosure but it’s food for thought. What about the plethora of port scanners and one-time “freebie scanners” that security companies pump out to capitalize the hysteria? Yes, there are administrators who don’t know what’s on their network, but I’m willing to bet there’s a larger number of administrators trying to figure out how to test, update, and manage a patch for 100, 1,000, or 5,000+ systems. You can’t release a patch and expect it to be applied to 1,000 servers within 24 hours. The tools to manage the patch process are too few, while the number of scanners is overwhelming. That’s not to say that security scanning isn’t necessary — it’s just a small part of the process. Administrators need help with patch testing, installation, and management.

Okay, so I’ve diverged onto a few topics already; but the one I wanted to highlight is what happens when a worm exploits a Web Application vulnerability? has a nice essay on one concept of such a worm. How easily could one spread? It may not be hard with a SQL injection and xp_cmdshell(). Who will be the scapegoat? It probably won’t involve cute references to “Billy Gates.” You can’t blame administrators for not being able to download a universal patch (although some ISAPI filters or Apache modules could prevent a lot of attacks). In the end, you have to return to the programmers. They must be aware that Web applications have vulnerabilities that don’t fall into the bloated category of “Buffer Overflow.”

Buffer overflows are sexy to report when they involve popular software. Plus, it’s nice to see a group doing security research for fun. Yet when a worm finally targets Web applications, nmap and vulnerability scanners in the nature of nikto or nessus probably won’t cut it when administrators want to check if their Web applications are vulnerable. Instead, they’ll want web application-aware tools to check live systems and code review tools to audit the source code. The proliferation of buffer overflows has led to some useful code review tools and compilers that can spot a minority of potential overflow vulnerabilities. The OWASP is a good start. Hopefully, the tools to audit web applications and review source code will reach a point so that the next worm won’t spread through e-commerce applications. Everyone talks about how much worse a buffer overflow-based worm could have been, but a worm that gathers passwords and collects credit card numbers from an e-commerce application has more implications for the average Internet user than a worm erasing a company’s hard drives.

So…so you think you can tell

[This was originally posted July 2003 on the now-defunct site. Even several years later no web application scanner can automatically identify such vulnerabilities in a reliable, accurate manner — many vulnerabilities still require human analysis.]

Sit and listen to Pink Floyd’s album, Wish You Were Here. “Can you tell a green field from a cold steel rail?” Yes. Could you tell a buffer overflow from a valid username in a Web application? Yes again. What about SQL injection, cross-site scripting, directory traversal attacks, or appending “.bak” to every file? Once again, Yes. In fact, many of these attacks have common signatures that could be thrown into Snort or passed through a simple grep command when examining application log files. These are the vulnerabilities that are reported most often on sites like or And they pop up for good reason: they’re dangerous and quickly cripple an e-commerce application.

On the other hand, a different category of attacks has not yet crept far enough into the awareness of security administrators and application programmers: session attacks. There are several reasons for this relative obscurity. No automated tool does a proper job of identifying session vulnerabilities without customization to the application. There are no defined signatures to try, as opposed to the simpler single quote insertion for a SQL injection test. Most importantly, session state vulnerabilities vary significantly between applications.
The consequence of session attacks is no less severe than a good SQL injection that hits xp_cmdshell. Consider last May’s Passport advisory in which an attacker could harvest passwords with tools no more sophisticated than a Web browser. The attack relies on selecting proper values for the “em” (victim’s e-mail) and “prefem” (attacker’s e-mail) parameters to the emailpwdreset.srf file. It should really be stressed that nowhere in this attack were invalid characters sent to the server. Both parameters were attacked, but the payload contained valid e-mail addresses – not e-mail addresses with single quotes, long strings, Unicode encoded characters, or other nefarious items.

The attack succeeded for two major reasons. The e-mail addresses are exposed to the client, rather than tracked on the server in a session object. The four steps ostensibly required for a user to complete the password reminder process did not have to be performed in sequential order, which demonstrates lack of a strong state mechanism.

It seems that most buffer overflow-style attacks against operating systems or Internet servers such as IIS or Apache have led to site defacements or denial of service attacks. Yet as e-commerce has grown with Web applications, so have the vulnerabilities moved on from buffer overflows. Plus, the attacks against Web applications no longer lead to site defacement, but to identity or financial theft (credit cards). Thus, vulnerabilities that used to affect only the server’s owners (and perhaps annoy users who can’t access the service for a period) now include Web application vulnerabilities that quite directly affect users.
As administrators and programmers, we need to be aware of all the vulnerabilities that crop up in Web applications – not just the easy (yet still important!) ones that currently populate the Web vulnerability encyclopedia.