Re: protecting against exploiting mail forms

[Craig Sanders <cas@taz.net.au>]

On Sat, Nov 19, 2005 at 12:17:20PM +0100, Marek Podmaka wrote:
>   recently one of our customers had a badly written php script for
>   mail form and someone exploited this to send some spam. It is
>   exploited by injecting entire mail (with additorial recipients) to
>   From field - when script doesn't take care of additorial new lines.
> 
>   Detailed description of this attack can be found here:
>   http://www.anders.com/cms/75/Crack.Attempt/Spam.Relay
> 
>   Is there any general solution? I was thinking about using
>   mod_security, but I'm not sure which string to block - not to cause
>   any false positives. The problem is I don't know form field's name,
>   so I can test only value. Would "\nTo: " or "\nBcc: " be a good
>   choice?

there are only two ways that actually work, and both are variants of
each other.

the first is to allow your users to ONLY use your preferred form-to-mail
script. this could be one that you have written yourself, or just one
that you have vetted and/or hacked to be secure. the NMS version of
FormMail.pl is particularly good - especially if you hack it so that it
will only send mail to recipient addresses listed in a config file.

i hacked a copy of NMS formmail a few years ago so that it would only
send mail to recipient addresses that were either:

 - listed in /etc/formmail.recipients

 - with a destination domain hosted by us (any kind of hosting: dns, web,
   mail, whatever).  the Net::DNS perl module was useful for these checks.

this meant that customer forms would work if they sent mail to their own
domains (if hosted by us) without further configuration, but if they
wanted to send mail to hotmail or somewhere else they had to give us a
list of valid recipient addresses. a minor inconvenience, but well worth
it.


the second way is to specify precisely what a form-to-mail script MUST
do, and what it MUST NOT do. make sure your users understand the rules.
vet each script against the rules, and don't allow them to run until
they conform.

some of the requirements i had were that: all mail-sending CGI scripts
MUST add specific headers (X-URL and X-Referer) identifying the URL
of the script and the URL of the referring page; they MUST correctly
set an envelope sender address (so bounces don't end up in www-data's
mailbox); and they MUST NOT be able to send to any arbitrary address
(i.e. recipient addresses must be hard-coded in the script or in a
config file).


in either case, let your users know that you will disable or delete
without notice any non-conforming scripts when you find them. check mail
and web logs regularly.


also, ban known problem scripts, like Matt Wright's FormMail.pl. in
fact, ban all MW's scripts - they're hideous monstrosities that weren't
even good at the time they were originally written (mid 90s).

craig

-- 
craig sanders <cas@taz.net.au>           (part time cyborg)