Here's a typical example of a logfile after an attack:
188.8.131.52 - - [20/Mar/2002:18:43:57 -0700]
"HEAD / HTTP/1.1" 200 0calnet21-109.gtecablemodem.com - -
The string is obvious in its form. First the attacker sends the header with a "GET" to the path of FormMail, followed by his bogus return address, followed by the subject line, followed by the message that links you to a Web site, and finally a list of recipients at (in this case) aol.com. The server then writes code 200, indicating the transfer was successful along with an easily identifiable IP trail.
How do they find you and what do they do?
Attackers scan entire networks for hosts listening on port 80 with a "get" script that detects the presence of FormMail.pl. If you haven't already encountered this problem, it may be a good idea to rename the generic filename to something else, like ParseMail.pl or something not quite so obvious.
Once your host has "scanned positive", you are then added to a database for later reference. In most cases the Spam process [itself] runs in stealth mode, this is to say two databases are used simultaneously and in random order: First the database containing the hostnames is processed at random, along with the addresses in the email database. This helps spread traffic over thousands of hosts at a time while ignoring a small percentage that may block the spam.
My First Ideas for a Temporary Fix
During the attack, our server was handling approx 2000 Spam-Mail per minute; time was of the essence in stopping the attack.
1: After determining the primary source(s), I dropped the IP blocks using the route command. Next I was faced with the problem of determining how my users would access their Web forms while keeping the spammers away. With little time to spare, I immediately loaded another web server that listened on another port rather than 80. I then changed each users form to match the temporary server and port number. This quickly segregated the web server from relaying. In addition I renamed FormMail.pl just to confuse any automated scanners.
See the code here.
2: After reading the security groups and consulting with other admins, one bright fellow came up with a simple fix that altered the check_referrer integer, preventing long line input. Although brilliant, not an end all solution.
See the code here.
Updates and New Releases
Since news of the FormMail hack, Matt has published several new releases. According to recent information published on his site, FormMail.pl has undergone yet another upgrade that fixes several more holes. It is my opinion that FormMail.pl has a way to go before being considered secure.
By subscribing to our early morning news update, you will receive a daily digest of the latest security news published on Help Net Security.
With over 500 issues so far, reading our newsletter every Monday morning will keep you up-to-date with security risks out there.