the robots are just not smart enough to know that our forms
don't work the way they suspect.
Maybe rename the script? Could be there's a script of that name which is
vulnerable...
All our forms have odd names, we did that when the first Formmail.pl
attacks showed up years ago.
This sounds a lot like the spamming attempts I've been seeing. They seem to
go something like this:
* Attacker finds a form. I'm not sure if they use either a search engine or
just random crawls of some sort. I'm thinking the latter; when I first saw
it, it was on the servers at work (I'm the admin for a small web
development/hosting firm) and the attempts came on sites on the same IP
address (consecutive IPs at that, on two different servers; other sites on
other IPs in another subnet were unaffected). Later, I saw a similar attempt
on my personal site, hosted on my own server somewhere else entirely. I
should note than not all of these forms had common mail form names; the one
on my personal site was feedback.php, which could've just as easily
submitted to the recipient via some other method, not just email. When I
looked at the Apache logs for how they got to feedback form, they hit the
index of the site first and followed a path almost directly to the feedback
form, leading me to think they're crawling and looking for a wider variety
of form name possibilities than you might think.
* Attacker submits the form with all the fields filled in with random
addresses (gibberish usernames followed by the domain of the site), and some
fields (that seem to indicate they'd be inserted into From:, To:, or
Subject: lines) with additional header lines and MIME message separators.
They don't seem to do much with this at first; from what I saw, they supply
a drop account email somewhere in there to test if it worked...
* If the attacker received one of the messages to the drop account, they
start using the form in a more direct spam-like way, supplying Bcc:
addresses in the headers that do go to legitimate addresses. The messages
still look like crap, depending on the original form and what it does.
That's as far as it escalated when I observed it. It was at that point that
we caught the vulnerability in the form script used on the sites at work and
plugged the holes. (I didn't write it, BTW; the one on my personal site only
got a message to me.)
Here's a couple things I did from the server side as a first line of defense
to stop this:
* All the attempts came from proxy servers. Well, I'll assume they were
proxy servers and not individuals all around the world collaborating on the
attacks! I installed an Apache module that would do RBL lookups
(configurable, I use opn.blitzed.org) and deny based on a positive match.
I'm sure the attacker's (or attackers') proxy list is fresher than the RBLs,
but I just wanted to add enough stumbling blocks to deter the current and
future attackers.
* All the attempts came in with blank user agent strings. This is more of a
stretch (as I discovered), but I started denying requests with blank user
agents. PHP's functions that open URLs as files don't send user agent
strings either, so be careful with this one if anything on your server will
be accessed that way. Attackers could just as easily extend their tools to
use random user agent strings.
Hope this helps. I'd really love to track down the tool these attackers are
using, but my hat isn't black enough for that.
- Re: OT Spam sources Mike Jackson
-
