Unix Security: The FormMail Hack
by Glenn Graham - inTEXT Communications - Monday, 9 June 2003.
Is your Web server being used as a Spam Mail relay? It could be, and it doesn't even need a daemon listening on the SMTP port. How's it done, and how do you prevent your system from becoming a target?

Last year while monitoring our SMTP stats, I noticed an unusual amount of input traffic to our Webserver. Curiosity got the best of me, so I started looking at the Web logs only to find thousands of attacks targeted at a Perl script known as FormMail.pl. A short time later, I started getting thousands of bounced email and complaints from hundreds of people blaming me for acting as a Spam relay. I questioned how this could be, as my Web server wasn't even listening on the SMTP port… or so I thought.

The FormMail.pl Hack

A Spam hack many administrators are still not aware of, takes advantage of a well-known perl script called FormMail.pl, used for processing Web-based forms. Originally written by Matt Wright, the popular version 1.6 allows an attacker to send a malicious URL to the Web Server thus accessing the mail binary and turning your otherwise harmless machine into a spam Mail relay. Millions of Web servers around the world still use version 1.6, despite the release of newer more secure replacements.

Until recently, FormMail.pl was considered reasonably safe due to the implementation of "Referrers" that [only] allowed access based on a specific ruleset of allowable domains and IP's.

# Config code

# @referers allows forms to be located only on servers

# which are defined in this field. This security fix

# from the last version which allowed anyone on any

# server to use your FormMail script on their web site.

@referrers=('net-security.org', 'another_domain.com');

A single machine could handle several thousand referrers at a time including Virtual Hosts. The script however, wasn't entirely perfect; not that it didn't work, but it was very easy to hack.

Detecting the Hack

The worst part of this exploit is the administrator usually won't suspect anything's wrong until he starts receiving mail informing him about his so-called Open Relay - that is, if he bothers to read it.

The theory behind the hack is simple: The attacker sends a string to the web server, fools the server into processing the data, and relays via the internal mailer in a similar manner a regular form would be processed. Afterward, a mile long trail is usually left in the apache server log.

Here's a typical example of a logfile after an attack: - - [20/Mar/2002:18:43:57 -0700]

"HEAD / HTTP/1.1" 200 0calnet21-109.gtecablemodem.com - -

[20/Mar/2002:18:45:56 -0700]

"GET /cgi-bin/FormMail.pl?email=bigpenis@aol.com&subject=









Morrellsthug87@aol.com, HTTP/1.1"

200 538

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.


MagSpoof: A device that spoofs credit cards, disables chip-and-PIN protection

The device can wirelessly spoof credit cards/magstripes, disable chip-and-PIN protection, and predict the credit card number and expiration date of Amex cards after they have reported stolen or lost.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Thu, Nov 26th