Re: <victim>server formmail.pl exploit in the wild

[Kee Hinckley <nazgul () somewhere com>]

At 1:02 PM -0700 4/15/02, Andrew Daviel wrote:
> True, security through obscurity is not real security. But we're not
> trying to block a determined person from sending one piece of mail, we're
> trying to make it not worthwhile for automated abuse. Currently, many
> formmail scripts are found by scanning for them, just by requesting
> /cgi-bin/formmail.pl. As another correspondent pointed out, renaming
> the thing to cgi-bin/formmailtoo.pl would thwart this.
> While the script is known, and in a known place, the form is not, and
> can have arbitrary structure, and be in an arbitrary place. To find these
> in an automated fashion would require a search engine able to search
> on HTML elements (rather than visible text). Then the hidden field
> would have to be found (different for each site). This is somewhat
> more complex than just trolling  for cgi-bin and would I think
> deter most spammers.

I think you are massively underestimating the determination of spam 
software writers.  First of all, they certainly read these lists--so 
they'll know about such approaches before you've even deployed your 
solution.  Secondly, you are talking about people who think nothing 
of stealing credit card numbers and using them to set up one-shot 
accounts.  Last month a spammer who got shut down sent mail 
threatening to rape my wife.  We aren't dealing with script kiddies. 
We are more and more dealing with out and out criminals engaged in 
theft of services and money.  Some of the people for whom they are 
sending email may not be in that class, or realize what they are 
supporting--but at the core are people who are dead serious about 
this.  Making their job just a little bit harder is not going to be 
sufficient.

What bothers me about your solution is something it has in common 
with most anti-spam legislation.  You're looking at solving the 
current problem.  What you need to *also* do is consider what the 
spammer's reaction to your solution will be.  Let's assume that 
everyone running formmail switches to a new version as you describe 
*and* renames it.  (Not likely, you'd be amazed how many people don't 
even rename the "webmaster () somewhere com" email link in their 
FrontPage template.)  You've just created a problem for the 
spammer--you've closed a nice untraceable (or at least hard to trace) 
spam venue.  Have you stopped them?  Of course not, they just have to 
work a little harder.  The question is--where will they move next?

In detail.

1. Rename the form
As you say, there are programs out there that just hit a site to find 
out if it has formmail.  They do this because it's the fastest way to 
find it.  However spammers also run spiders to find email addresses. 
Those spiders *definitely* know how to read HTML (not to mention 
hacks like "nazgul at somewhere.com").  How long would it take to 
modify those spiders to find formmail scripts?  An hour maybe?

2. Use a custom-per-site hidden field
Is this custom per-isp, or custom per site?  If the former then you 
might as well go back to hard coded config files--they are more 
secure and no harder to administer.  If the latter, you've just made 
life easier for the spammer.  But in any case, this is no harder than 
the first problem.  Now when the spammer scans for formmail scripts 
he also scans for the code.  In his database of formmail scripts he 
now has to also store the code for each one.  I'll give that one four 
hours of coding.

3. Throttle the script
Spammer then customizes software to play round robin with formmail 
scripts instead of just using one at a time.  They already have 
learned to randomize the recipient lists (some spam filters check for 
alphabetically sorted addresses as an indicator that this may be 
spam, and some mail servers block incoming messages if there are too 
many bounces), so now they have to randomize the formmail usage. 
I'll be generous and give that 8 hours of programming.

4. Set a cookie with a webbug
Ignoring the fact that this may block many modern browsers which 
block webbugs from setting cookies, it just means that the spammer 
needs to fetch an image (well, the headers of one) before calling the 
script.  The info needs to go in the database (four hours) and the 
code needs to be added to the spam software (four hours).

So, for three days of coding a spammer now has a system that can 
bypass your fix.  A month after ISPs have started installing it, it 
starts to get broken.  Does the spam go as fast?  Nope.  But given 
that my spam load appears to be doubling every year, I don't think 
we've done much to slow that exponential curve.

I'm sorry this comes across so bitter, but I'm currently bouncing 5-6 
million pieces of spam every year--to accounts that do not, and have 
never, existed.  I'm *very* worried about the unintended consequences 
of half-way solutions.

> The only other solution I can think of at the moment, would be to
> give the HTML authors a private directory that they can write to - either
> outside the Web directory, or password-protected.
> The form script could then read the recipient list from a file
> (directly, or over the net with a suitable client).
> It would have to figure out the
> filename from the referer, or from a hidden field.

1. The ISP provides a password-protected form where the web 
administrator can login and specify the valid recipients.  It updates 
the config file for that site's version of formmail.  To break it, 
the spammer needs to break the password.  You can further limit 
damage by restricting the number of recipients, and the number of 
changes that can be made within a certain amount of time.  Such a 
script should of course ship with formmail, configured for multi-site 
use.

2. Have formmail look in a text file on the site for the list of 
recipients, one per line.  Tell the web admin how to create the file. 
(In some ways not as safe as #1).

But let's back up a minute.  Fundamentally you're trying to fix a 
tool that wasn't a good solution in the first place.  Forget form 
mail, it's a lousy way to get data from a form to a client.  If it's 
a "hello, how are you" message then an email link would have worked 
better.  If it's data, then having the web admin cut and paste from 
email to his database is painful and doesn't scale.

3. Do what I do with my web clients.  When someone submits a form 
it's stored in a comma-separated file and notification mail is sent 
to a single email address (also configured via the admin interface). 
The web admin can then come to the site and download the file into 
their favorite database/spreadsheet whenever they want.
--

Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul () somewhere com

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com