bugtraq - Re: Multiple Vulnerabilities in SLWebmail

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 7 May 2003 14:57:37 -0500
From: H D Moore <slwebmailpost@...italoffense.net>
To: "NGSSoftware Insight Security Research" <nisr@...tgenss.com>,
	<bugtraq@...urityfocus.com>, <vulnwatch@...nwatch.org>
Subject: Re: Multiple Vulnerabilities in SLWebmail

I found some similar problems back in October 02', the updated versions 
should also fix the issues below. The vendor was notified and the 
majority of the issues were fixed in the test release they provided back.

1) The SLMail application comes with an administrative web service that 
allows the user to instantly gain SYSTEM privileges through a standard 
directory traversal attack (you can launch executables). The wierd bit 
about this is that you must use three dots to traverse the parent 
directory, even on non Windows 9x systems (tested on Win2K).

---
GET /.../.../.../Winnt/system32/cmd.exe?/c+dir HTTP/1.0
Authorization: Basic <base64 auth>

Directory of C:\Winnt\system32

10/20/2002  07:12a      <DIR>          .
10/20/2002  07:12a      <DIR>          ..
09/17/2002  10:50a                 350 $winnt$.inf
---

2) The SLMail admin server directory traversal [1] lets you check for the 
existence of files without providing any authentication. The service is 
returning a second HTTP header after the first that contains the actual 
return code of the request (404, 501, 200, etc).

3) Overflow in the "LANGUAGE" parameter to all DLL's in the 
/scripts/SLWebMail directory. I managed to finally get a second-chance 
(fatal) exception after hitting it about 40 times with different length 
and content.

4) Tons of path disclosure bugs. Set the LANGUAGE variable to something 
invalid and it complains it cant find the error text file, giving up the 
disk path in the process. This variable can be used with a directory 
traversal, but you can only read files named 'ErrorText.dat'. Using a 
null byte after the parameter does no good and overflowing it entirely 
only lets you bleed into an adjacent buffer, which is then overwritten 
with "C:\WINNT\x00" (from the SYSTEMPATH env actually). There are quite a 
few other places where it spits out extraneous path information.

5) A couple GUI applications are installed in /scripts/SLWebMail/WebMail, 
you can just keep requesting these one by one until the server runs out 
of memory. I couldn't find any useful arguments to either of the apps 
(signature.exe and BanWiz.exe). The BanWiz executable takes a file name 
as the first parameter but does not actually do anything with it.

Examples:

-- path disclosure
GET /Scripts/SLwebmail/God.dll?LANGUAGE=TONGUES HTTP/1.0

-- heap overflow
GET /Scripts/SLwebmail/God.dll?LANGUAGE=X[...]X

-- silly remote gui app launch
GET /Scripts/SLwebmail/WebMail/BanWiz.exe
(possible overflow in query string, havent verified)

-HD

On Wednesday 07 May 2003, NGSSoftware Insight Security Research wrote:
> Description
> ***********
> SLWebMail is a web based e-mail system that runs on top of Microsoft's
> Internet Information Server. It is vulnerable to many different kinds
> of issues, such as buffer overflows, arbitrary file access and physical
> path revelation.