After recently moving a client’s site to a new host, I was fortunate enough to receive several exploit attempts from their contact form. Seems some software was auto-configuring itself to a vulnerability I had overlooked in the form. The nature of the attack is the suddenly infamous email header injection attack. I shameheadedly admit to having known nothing of this particular exploit until a couple months ago when my successor notified me that about 50 forms I had written over the past 5 years were mostly vulnerable and all needed to be manually updated.
Ninja
Nary pausing to stuff a keyword, I sprung into action armed with a shiny new Transmit 3.5 and trusty TextMate deploying a robust detection and notification system complete with a scathing message about contacting the appropriate authorities. I also fire off an email containing the POST request and IP address and UserAgent so that I can examine the technique.
Scary
The anatomy of the spam attempt is disturbing. It’s hit the form every 5 minutes for the past 12 hours, each time from a unique IP address, the same tired HTML message, and each time with 300 BCC’ed recipients, all with email addresses that don’t vary until the third, sometimes fourth character. What does this tell me?
They’ve got a huge network of zombies. They’ve got a huge list of email addresses. And its all automated so they just have to sit back and get rich off a one in a million click-thru rate.
The Problem
I currently have 3 different shared host accounts. All of them have their occasional downtime / server load issues. So I got to thinking. Email injection exploits have been around for a long time, but the awareness was pretty low. Now that hardcore distributed zombie spambots are becoming prevalent, this really has the potential to wreak havoc on shared hosts everywhere. They’re all running PHP, and every shared server has got to have at least one shmuck running a form mail script from 1996.
Now it escalates… web hosts are getting blacklisted for spam abuse, so the shared host customer has no email. Webmasters begin tightening security, thus driving spammers to fewer and fewer targets, resulting in unintended DOS effects on the uninitiated—and anyone who happens to be sharing a server with them.
Web hosts are forced to take drastic action just to maintain some semblance of uptime. Mod_security becomes ubiquitous and the header injection attack is stemmed, at least until the next PHP exploit is fed into the spambot hivemind. In the meantime 412 Precondition Failed is the new black, and censorship takes the form of such arcane expletives as bcc and MIME-Version.
The Solution
I don’t want that. This article wouldn’t be possible with such rigorous mod-security settings. I hope we can come to a better solution. The first thing to do is take the computing power out of the criminals hands. Would this kind of arms race be feasible without millions of zombie PCs available for free thanks to the miracle of Windows and broadband at home?
Microsoft can do a lot to help stem the tide of zombies, but it will take time. Even with their best attempts, ease-of-use and security tend to always be at odds. Is a secure all-purpose consumer desktop computer a realistic goal?
The other half of the problem is the difficulty of web security in general. While not exactly a software monoculture, PHP is running an awful lot of sites, and the core language has a number of features that invite the kind of mass exploitation that we’re seeing now with the email header injection.
We never saw this scale of problems with Perl CGIs because the language encouraged so many different ways of doing things. There’s a certain critical mass of diversity that keeps zombie nets from finding profitable exploits. Right now I’m just wishing that my shared servers had that kind of diversity instead of 100 customers plugging holes with fingers.
Subscribe
Spam Injection Attack
After recently moving a client’s site to a new host, I was fortunate enough to receive several exploit attempts from their contact form. Seems some software was auto-configuring itself to a vulnerability I had overlooked in the form. The nature of the attack is the suddenly infamous email header injection attack. I shameheadedly admit to having known nothing of this particular exploit until a couple months ago when my successor notified me that about 50 forms I had written over the past 5 years were mostly vulnerable and all needed to be manually updated.
Ninja
Nary pausing to stuff a keyword, I sprung into action armed with a shiny new Transmit 3.5 and trusty TextMate deploying a robust detection and notification system complete with a scathing message about contacting the appropriate authorities. I also fire off an email containing the
POSTrequest and IP address and UserAgent so that I can examine the technique.Scary
The anatomy of the spam attempt is disturbing. It’s hit the form every 5 minutes for the past 12 hours, each time from a unique IP address, the same tired HTML message, and each time with 300 BCC’ed recipients, all with email addresses that don’t vary until the third, sometimes fourth character. What does this tell me?
They’ve got a huge network of zombies. They’ve got a huge list of email addresses. And its all automated so they just have to sit back and get rich off a one in a million click-thru rate.
The Problem
I currently have 3 different shared host accounts. All of them have their occasional downtime / server load issues. So I got to thinking. Email injection exploits have been around for a long time, but the awareness was pretty low. Now that hardcore distributed zombie spambots are becoming prevalent, this really has the potential to wreak havoc on shared hosts everywhere. They’re all running PHP, and every shared server has got to have at least one shmuck running a form mail script from 1996.
Now it escalates… web hosts are getting blacklisted for spam abuse, so the shared host customer has no email. Webmasters begin tightening security, thus driving spammers to fewer and fewer targets, resulting in unintended DOS effects on the uninitiated—and anyone who happens to be sharing a server with them.
Web hosts are forced to take drastic action just to maintain some semblance of uptime. Mod_security becomes ubiquitous and the header injection attack is stemmed, at least until the next PHP exploit is fed into the spambot hivemind. In the meantime
412 Precondition Failedis the new black, and censorship takes the form of such arcane expletives as bcc and MIME-Version.The Solution
I don’t want that. This article wouldn’t be possible with such rigorous mod-security settings. I hope we can come to a better solution. The first thing to do is take the computing power out of the criminals hands. Would this kind of arms race be feasible without millions of zombie PCs available for free thanks to the miracle of Windows and broadband at home?
Microsoft can do a lot to help stem the tide of zombies, but it will take time. Even with their best attempts, ease-of-use and security tend to always be at odds. Is a secure all-purpose consumer desktop computer a realistic goal?
The other half of the problem is the difficulty of web security in general. While not exactly a software monoculture, PHP is running an awful lot of sites, and the core language has a number of features that invite the kind of mass exploitation that we’re seeing now with the email header injection.
We never saw this scale of problems with Perl CGIs because the language encouraged so many different ways of doing things. There’s a certain critical mass of diversity that keeps zombie nets from finding profitable exploits. Right now I’m just wishing that my shared servers had that kind of diversity instead of 100 customers plugging holes with fingers.