I'd suggest converting your web form program into a spam trap. If the spam makes it through your organization, there is a good chance you'll be BlackListed by the ISP at the bcc'd list. If you let the spam escape your network, you may be held responsible for the spam. They are using hacked computers to relay through exploitable web forms, which conceals the true orgin and makes it appear as if your site is responsible for the spam. All the other headers appeared to be forged. As the spam run ensues, check the BCC list for that "test account". The initial test messages reveal who the spammer is.
The BCC'd list always seems to contain the spammers verification account. Unless you need to preserve formatting in some special cases, you might as well kill them everywhere as a rule of thumb. Commonly with cgi forms on the Internet, the subject line, which is part of the email headers, comes from a cgi posted variable and hence can be exploited.Īs I say, the fix that will work 100% of the time is to kill all \r and \n characters in cgi variables that are used in an email header. Adding additional header lines, including a BCC: lists is possible whenever an unchecked field is used in the header of an email. Some clarification on questions posted: even if your forms are hard-coded to send you the email, you are still possibly vulnerable to this attack. In the case of perl, you could do it with a regular expression this way:
How to actually do this depends on the language used in your cgi. What you as a site admin need to do to be 100% safe is strip carriage returns (\r) and liefeed characters (\n) from form fields in your cgi scripts. Posted by Anders Brownworth Friday, J12:00 AM Has anyone else seen attacks like this? Looks script-kiddie-ish as most of the phishing hits came within a two second period.ĮDIT: I have written a more concise article covering this issue called Form Post Hijacking.ĮDIT: A project of mine called can help control form spam through image based verification. If the form doesn't set reply-to before the exploited field or the reply-to is a bad address or nobody pays attention to logs, the site owner may never know his site is compromised and enslaved as a spam bot. Once a vulnerable script is found, the BCC line is filled with 25 or 30 addresses to spam. To: is a multi-part message in MIME format.Ĭontent-Transfer-Encoding: is an attempt to BCC to report a successful breach. Notice how the email field contains a newline character and finishes off the email header fields. Form field data is presented between brackets in the example hit below. There are many hits from a number of different IPs which I assume are other compromised hosts. This is an attempt to exploit my comments form. If you run a site, you should check and strip fields for carriage return and newline characters used directly in email headers. I had an old perl script which didn't check for new lines in the "email" field which alerted me to the problem and allowed me to quickly fix it. An initial test sending a BCC copy to has been used on most forms on my site to phish for vulnerable scripts. Appending a newline character and a few more carefully crafted header lines with a BCC list and a spam message body might trick the underlying mail system into relaying spam for the attacker. The attack works by assuming a field used in an email header (such as the "From:" address or the "Subject:") is passed unchecked to the mail subsystem.
I'm seeing an interesting new attack on my website where the attacker is hoping to exploit unchecked fields in a "web to email" form.