BVLog Bryan Voss’ mental synchronization point

6May/070

Email injection attacks

I hadn't heard much about email injection attacks until the sendmail queue on our webserver at work suddenly began running around 3000 messages and the recipient of the "Contact Us" form began complaining about weird emails. The site was designed by a local advertising agency, so I wasn't involved in coding it. I called the technical contact at the advertising agency and didn't get a quick response, so I took at look at the code myself. It was a simple PHP script which took the inputs from the form and slapped them into mail() without any sanitization. I modified the code to dump a copy of the output to a file before sending it. Then the vigil began.

I had to wait a few days before another attack happened. I arrived one morning and checked the file to find several messages with "Content-Type: multipart/alternative; boundary=[whatever]" headers added to the body of the message, causing the message to be parsed by the MTA and sent to a long list of recipients.

I did some research into fixing the PHP code to make it more secure, and even made a couple of experimental changes. Those seemed to work and the injection attacks stopped. I did more research and found a web application firewall called mod_security for Apache. It purports to block email injection attacks as well as a host of other naughty things. I began tinkering with it on a test box, but got busy with other things. I still had a trouble ticket open on the problem and was intending to install mod_security on the production server when I finished testing.

A few months went by. The trouble ticket grew stale and crumbly at the bottom of my queue. Eventually, the advertising agency uploaded a new version of the Contact Us script to handle some new form input and overwrote the changes I had made. A couple of days later, I heard from the lady in Customer Service who receives the "Contact Us" mail. The spammers were back.

So, I installed mod_security on the webserver. I initially misconfigured it to log everything and almost filled a filesystem with logfiles before I caught it and turned off debug logging. Using the default ruleset stopped the spam, but also kept people from filling out the form to submit job applications online. The Human Resources department was not pleased about that, so I had to turn off mod_security for a while as I debugged the issue. Not particularly easy to do when I wasn't the one who coded the site in the first place, but it looks like it's working fine now.

I guess mod_security is another tool I can add to my arsenal. Works well when you can't necessarily control the code running on a site but need to secure it. Just be careful not to leave debug logging turned on. :^P

Filed under: apache, php No Comments