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.
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:
22.214.171.124 - - [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.
An excellent alternative to Matt’s script is a rewrite in PHP. Now available at Jacks Scripts, the improved FormMail.php is robust, secure, easy to install and runs under PHP. Configuration is similar to FormMail.pl.
Knowing this hack exists, it’s time to upgrade now.
About the author
Glenn Graham has been working with telecommunications since 1977. In 1994 he established inTEXT Communications, a Unix consulting company specializing in system administration, security, and network architecture. Home away from home is deep in the confines of his underground vault where he keeps a careful watch on an array of routers, switches and other strange peripherals. His deep glowing tan can be attributed to monitor radiation, not sunlight. You can usually find him wide-awake at networkinformation.com.