Contact Us Form - Email Injection Attack
In the last few weeks I've noticed a new attack making the rounds on my CF server. Although it's not an effective attack against a CF server, it does illustrate how spammers are a boil on the butt of humanity. It's called "email injection" and it's actually an attempt to leverage a PHP vulnerability (or perhaps I should say a “bad PHP coding” vulnerability). How do you know if you are being attacked? If you have a web site with a "contact us" form or any other form whose result is a sent email, and you are getting emails "from" your own domain and "to" your own domain - using bogus email addresses you are probably seeing this technique in action. You will also get bounces and if you look in the raw bounce code you will see something like "bcc: *some email address*". That's the tip off. Please note, this technique does NOT work against Coldfusion as far as I know - only PHP seems to be referenced in the various online discussions of the topic. If you are interested read on.
Email injection is an attempt to exploit the file format of an email message. If you've ever looked in the spooler directory of your CF server or had the occasion to examine raw message formats on a mail server you will know that an email is really a file with instructions for delivery. There are a few required parameters (headers) and a number of optional ones. A typical mail message looks like this:
Subject: Car inquiry
From: agitated@customer.com
Bob,
Hey you deadbeat - when's my car going to be ready??
Of course, there's much more to it than that. There are a myriad of required and optional headers that are inserted into the message. These options and headers are interpreted by email clients, servers and other processes. Here's an example of an actual message - with the names changed to protect the less guilty.
To: agitated@customer.com
Subject: Your lousy car is done
Date: Wed, 6 Jul 2005 16:15:28 -0500
Message-ID: <MLEIJGOCGEICCNCMLCDCEEPBFFAB.cheetamsGarage.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_016C_01C58245.EC77DDC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
This is a multi-part message in MIME format.
------=_NextPart_000_016C_01C58245.EC77DDC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Dear Customer,
------=_NextPart_000_016C_01C58245.EC77DDC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2668" name=3DGENERATOR></HEAD>
<BODY>
<h4>dear customers</h4>
</body>
</html>
------=_NextPart_000_016C_01C58245.EC77DDC0--
As you can see the format can be pretty loose - with lots of stuff in there that may or may not belong - and the message can usually still be delivered.
How the Attack is Accomplished
PHP handles email through an email script. Such a script typically builds this file on the fly from the various inputs. As you can see the "linebreak" is the chief delimiter in the file format. If a user added a linebreak to the "subject" parameter, and then added a bcc header (for example) the output might end up looking like this:
Subject: Car inquiry
Bcc: target@nothappy.xxx
from: agitated@customer.com
....
You can see how that might make a bottom feeding spammer salivate. He can send spam messages from you to his victims through your own secure relay. That's sneaky and underhanded - which is why they love it I'm sure.
Additional Options
It get's worse than that. Using this methodology spammers can overwrite the subject, include HTML in the message and obscure text that is intended for the message. This post is one of the best explanations I found (actually more of a how to). It has a much more in-depth discussion of the issue and lots of PHP code samples
Coldfusion Implications
As far as I can see there are no CF implications. CF is in control of the file format sent to the spooler. It clearly defines the sections and headers and I doubt seriously that any attack could be constructed that would work against CF in this case. Please note, I have not tested it - I'm only making an educated guess. If the the attacks against the contact forms on my own site are any indication, we will know for sure very shortly. If you have some information on this subject please enlighten us.
follow up
There is a follow up post to this topic.
12 Comments
-
Yes indeed... it was not helpful. You commented on the fact that it was bad PHP coding and not PHP itself that was at fault - a fact that I had already made plain in the post. Your comment on CF vs. php is an old tiresome argument that I would prefer not to participate in. I've seen thousands of posts on both sides and frankly it's not helpful or useful to anyone but hobbyists who just want to wrangle over something. If you have something specific to add that enhances the information in the post (keeping in mind this is a coldfusion blog) I'll gladly keep it.
I've already linked to an excellent PHP blog for folks interested in that end of this conversation. This blog is to help CF folks who might be seeing those strange bounces from bots using this technique against their sites and wonder what exposure they might have in their own code. CF is not vulnerable to this specific attack - but it seems there are bots who do not differentiate and ply the technique anyway. -
Either i read right over it or you just changed it in the post :)
I agree, don't want to start that discussion either, because I think Coldfusion is definitly the right solution in certain cases. -
Well - it is in parenthasise... so I suppose it would be easy to skip. Anyway - sorry for deleting your original post. I was probably being too surly. I'm not usually like that :)
-
I've received some emails like this coming through a contact page on my site (http://www.waterswing.com/contact.cfm), but I've just deleted them as they came in, thinking maybe it was some moron playing on my site (as there was no meaningfull content in the mails). I'll pay better atention next time, and find out what's really going on. -
I've noticed this sort of nonsense coming through on contact forms of mine and my clients' sites as well. I figured they were trying to do some sort of email injection. However, as they weren't successful, I wrote it off as someone just poking around, being a nuisance. It wasn't until the volume (dozens a day) increased that I started getting more proactive about assessing the risk and doing something to stop it cold with the least impact possible.
As an experiment, I added CAPTCHA to my own contact and email-a-friend forms and the attempts stopped completely. This, in addition to the fact that log files indicate attempts are made only seconds apart and have all manner of headers filled with suspect data, would indicate to me that there's some manner of automated attempt that's being used.
I passed CAPTCHA off as the solution to this problem until I noticed something that came through today. Instead of the usual failed attempts, I saw a message come through that had succeeded in injecting headers. The reason is that I was using the contact's name and email as the FROM header of my mail. That gave the attacker the necessary access to the headers of the email.
So, the solution? Well, if you're using any user-supplied data in the email headers (subject, from, to, cc, bcc, etc.) be sure to check it for suspect data like "Content-Type: ", "MIME-Version: ", and carriage returns. Probably the most obvious is the carriage returns as that's what's used as the termination characters in email headers. -
It's been happening to a lot of web forms including PHP, ASP, as well as Coldfusion. It's been affecting my clients for about 3 weeks now. The spammer makes it seem that the emails are coming from the domain on which the web form resides. The only thing I could do for now, is add some code before my cfmail tag, stating that if the "from" email address contains the domain (clientsite.com), then the email goes to me (the webmaster) instead of my clients email addresses. This way, I am catching all the spam in my inbox and I can see how often this is occuring. It does seem to be happening on weekends. But I've noticed it during the week too. Until there is a stop to this, it's the only "semi-solution" I could think of.
<cfif #form.Email# contains "@clientsite.com">
<cfmail to="webmaster@mysite.com" subject="Spammer" from="#form.Email#" type="html">
Error-Spam
</cfmail>
<cfelse>
<!---put cfmail tag here--->
</cfif> -
Tara - to be clear. The exploit is not in any way effective against CF or CFMAIL. If the spammer get's a "bcc" in his inbox, then he proceeds to use the form to send out hundreds and thousands of mail. What you are seeing is only the "probe" part of the attack - which has no effect other than to send a few messages directly to the "to" user.
PHP is vulnerable because it assembles the message directly by concatenating headers and content. But even then it would be only poorly written PHP that is vulnerable.
Your suggestion works fine, but I would add another possibility. If any form element you are using for "to" "from" or "subject" contains linebreaks (chr(10) or chr(13)) you can safely NOT send the message. linebreaks are what is used to differentiate the headers and they are necessary to make this exploit work.
Thanks for adding to my blog. -
Mark, I'm not sure what you mean. Do you know a way for me to stop this spamming to my web forms with Coldfusion? I am now receiving about 20 "spammer" emails per day for each of my sites. My clients would be receiving them if I had not added the code I inserted before. I have them sent to me instead with "Spammer" in the subject line. Is there going to be a fix for this? I have another site with a PHP form that hasn't gotten any of these yet.
-
Tara, The solution is simple. Check if any of your single-line input fields contain line breaks. If they do, just fail silently.
-
I wonder if this works on older versions of CF (pre MX) can anyone that has an CF 5 or 4.5 server comment on this?
Sites to Watch
Aggregators
RSS
