Spammers looking for vulnerable web forms

[tomp]

In the last couple of weeks we've seen an alarming trend where spammers are attempting to inject code (SMTP data) into a web based form used by our customers. Just this morning they attempted to exploit our contact form at http://www.myriadnetwork.com/contact/contact.php

The warning signs are pretty clear - the person who is suppose to receive the output of your web based contact form will receive a bunch of emails similar to the following - this is a real example of an attempt against our contact form:

A user just filled in the contact form with the following message:

First Name: msfrtaulu@myriadnetwork.com
Last Name: msfrtaulu@myriadnetwork.com
Email: msfrtaulu@myriadnetwork.com
Content-Type: multipart/mixed; boundary=\"===============1725395920==\"
MIME-Version: 1.0
Subject: be293541
To: msfrtaulu@myriadnetwork.com
bcc: mhkoch321@aol.com
From: msfrtaulu@myriadnetwork.com

This is a multi-part message in MIME format.
--===============1725395920==
Content-Type: text/plain; charset=\"us-ascii\"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
nbvbozeiu

--===============1725395920==--
Phone: msfrtaulu@myriadnetwork.com
Current URL: msfrtaulu@myriadnetwork.com
Interests: msfrtaulu@myriadnetwork.com
Message:
msfrtaulu@myriadnetwork.com

These spammers are making multiple attempts to exploit the form, thus you will typically see multiple emails going to the intended recipient.

If you see something like this PLEASE immediately contact support@myriadnetwork.com and reference this post. We need to immediately investigate all such incidents to determine if your web form is vulnerable.

Most typically we see these spammers exploiting these web based forms to send massive amounts of spam to AOL customers which in turn may get us blocked for a period of time by AOL.

We are investigating further safe guards but we need your assistance.

-Tom

[tomp]

http://www.computing.net/webdevel/wwwboard/forum/1994.html


http://www.nmmm.nu/spam-form.htm

http://www.anders.com/cms/75/Crack.Attempt/Spam.Relay


Possibly Secure Contact Form - http://ostermiller.org/contactform/

[Jeff]

It is also strongly recommended to stay away from http://www.thesitewizard.com for generating email forms. If you are a Myriad Network customer and have used this site to generate an email form for your website, feel free to contact me - jeff ( at ) myriadnetwork dot com for an explanation.

Update: It is also recommended to not use "FormToEmail" from ScriptsThatWork.com, unless you know how to properly filter the variables it uses for sending email ;) Again, if you are using any of these forms, feel free to send me an email and I will be happy to fix them. The fix should only take a minute or 2 for implementation and testing.

[Jeff]

Also, if you have any form that can be used to send email in any way at all, you should ensure you are filtering line feeds, amongst other things, from the variables used in the form.

For more information, see this: http://securephp.damonkohler.com/index.php/Email_Injection

Although the URL above primarily covers attacks against PHP forms, the methods used by spammers are the same for other styles of coding as well. Thus, this is not a flaw in PHP, or Perl, or anything else - it is a (simple) design flaw that can be easily corrected with proper filtering.

A few things worth filtering are (all case insensitive):

%0D (carriage return)
%0A (line feed)
Bcc
multipart/

For example, if you have a form that has a variable called "$name" which the user's name is placed into via the form, the strings listed above should be stripped from the variable. The same goes for all variables used for the form - $name, $email, $message, $url, etc.

To understand why those strings should be stripped, let's look at a real example used against someone's form (the form and domain names have been changed by me):


POST /cgi-bin/form.pl HTTP/1.0
Host: www.website.com
content-length: 296
content-type: application/x-www-url-encoded
referer: http://www.website.com/index.html

email=o2afte3%40prodigy%2Enet%0ASubject%3A+rLmhxdC j+zquyqmke%0Abcc%3A+Homeiragtime%40aol%2Ecom%0A%0A Jduycva+zA+iibrTfRy+YvJexaa+cq0aqEZdpYgpxyA+qfabkG lvzbpkvLvG+ySzcifnptGfLFso488uRexktfVieWhMyyejie+G cjqh%0A&name=75e8@website.com&url=f9l@website.com&comments=ub7vk14@website.com



The quoted portion is from the raw packet capture, cleaned up a little for readability. If you notice the following string:


%0Abcc%3A+Homeiragtime%40aol%2Ecom%0A%0A


or, cleaned up further, and with line feeds:



bcc:Homeiragtime@aol.com




You can see that the spammer is attempting to place a line feed into the form (the first %0A), add a bcc: field with their email address, then add 2 more line feeds. Thus, if the spammer receives an email to that AOL account, they know they have a form they can use to spam from. Fortunately in the case above, the email was never sent to the spammer's AOL address, because "%0A" and "Bcc" have been filtered in a such a way that all %0A and Bcc characters are stripped before the form is submitted.

For reasons on why to strip the string "multipart/", refer to the first post of this thread.


If you don't know how to do the filtering yourself and decide to use a different form entirely, you should check to see if the form implements any types of checks such as those outlined above.