Overview
========
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.

Background
==========
Although these vulnerabilities are obvious to many and similar holes
have been found in mailers on other platforms, we at Xato felt that it
was an issue that needed to be addressed because of the widespread usage
of these tools. In our research we 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.

We 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 our dismay, we found that the majority of
them had one or more vulnerabilities. As the number of mailers on our
list grew, we faced the dilemma of how to approach this. We did not
want to release twenty different advisories nor did we want to make one
large advisory that included all our research. We 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 we decided that our 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. We hope that this
advisory serves as a lesson for both developers and web admins about
using DOS applications on web servers.

As we mentioned before, this is a vulnerability that may seem obvious
and some of the individual problems in specific mailers have been
addressed but we thought this should officially be documented because
people sometimes do not fix things unless they are told specifically
what to fix. We hope 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.
We expect to follow up this advisory with additional details about
specific vulnerabilities. We 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. We are keeping this advisory general to
emphasize the nature of the problem rather than the specific
weaknesses.

Details
=======
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:

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 joeexample.com -t meexample.com -a c:\logs\web.log

This same command can be run from the server by using the following
command:

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.

We tested the following mailers and found all of them vulnerable to one
or more holes:

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 we have 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. We strongly felt that because of the scope of
the problem and the number of vendors affected that it would be better
to distribute the advisory immediately.

User 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. We will not be addressing all the specific
holes nor will we answer e-mails about specific problems. 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. Resources such as
BugTraq (www.securityfocus.com) can also provide insight into specific
security problems with your particular mailer.

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.

Developer Solutions
===================
This is a good opportunity for software developers to look at their own
tools and the security holes they may contain. The biggest problem with
most of these mailers is that they trust input that should not be
trusted. Some use http referrer variables for security and others depend
on hidden form variables. All of these things can be easily modified by
the client. Many of the tools allow for a configuration file but often
those settings are overridden by the command-line options when in fact
the reverse should be true. Everything should default to the most secure
settings unless explicitly disabled. Finally, developers should include
good documentation on how to properly secure their application.
Commentary
Certainly this is nothing more than a brief overview of a very big
problem but the solution is one that involves mailer developers, web
hosting companies, e-commerce developers, system administrators and end
users. I have only lightly touched on the vulnerabilities and solutions
yet the scope of the problem prohibits any more detail than this at
this time. I would expect the security community to research this more
and I would like to know of any other mailers that are vulnerable. I
will probably send out an addendum to this advisory that lists more
mailers as well as the actual filenames and more specific exploit
information. I would hope that web administrators realize the seriousness
of these problems and take the time to evaluate their own mailers,
whatever form they take. Many of these tools are freeware or unsupported
so the burden of fixing them is spread out among us.

-----------------------------------------------------------------------
THE INFORMATION PROVIDED IN THIS ADVISORY IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY KIND. XATO NETWORK SECURITY, INC. DISCLAIMS ALL
WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.