|
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