None of these problems are new and were reported
602software earlier last year. BTW you missed
several serious flaws related to what you were
talking about. Here are some of the e-mails in
which I explain in great detail these and more
vulnerabilities in Lansuite, some of which were
not fixed apparently. These were for Lansuite 2002
but some of them still work in Lansuite 2003.
From - Wed Aug 28 13:11:51 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
Message-ID: <3D6D0456.8070900@xxxxxxxxxxx>
Date: Wed, 28 Aug 2002 13:11:50 -0400
From: Stan Bubrouski <stan@xxxxxxxxxxx>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: james@xxxxxxxxxxxxxxx, candy@xxxxxxxxxxxxxx,
hotline@xxxxxxxxxxxxxx, brandon@xxxxxxxxxxxxxxx
CC: mhuston@xxxxxxxxxxxxxxx, tomas.holcik@xxxxxxxxx
Subject: 6 VERY SERIOUS Vulnerabilities in LanSuite 2002
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Hey guys,
I've been in contact with Brandon Sturgeon (brandon@xxxxxxxxxxxxxxx)
about the previous bugs I discovered and the following is
information I have disclosed soley to him over the past two days.
Basically I have found several more serious issues with
LanSuite's webmail interface than the previous bugs I found.
They are disclosed below, and I hope that you will guys will
at least recognize and acknowledge these bugs unlike the
previous ones I reported to you, which your American counterparts
were able to reproduce. The problems are outlined below.
Problem #1 - It is possible to view any file on the drive
the server resides on.
To explain how its done, let's take the form below,
which is from the message window frame that appears
right after I login:
<form name="FormAction" action="/mail" method="POST">
<input type="hidden" name="A" value="ChkMsgsAction">
<input type="hidden" name="U" value="7921605887934D43712126E88F5583">
<input type="hidden" name="FolderLevel" value="0">
<input type="hidden" name="FolderName" value="Sí?ové pøihrádky">
<input type="hidden" name="FolderDir"
value="G:\LANSUITE\mboxes\769B388F\fldrs\">
Notice that FolderDir tells remote webmail users
the physical location of the LanSuite installation
the server...this is not good, and will come into
play later. Right now we are interested in the second
line in the above text which is the parameter "U".
"U" is the session number (apparently) of the user
who is logged in. It is used in all the webmail
forms to identify the user. Now moving on, when
you click on a link to view an attachment, your
client sends a string like this to the server:
/mail?A=GetFile&U=6E14256E5847A586314259A9630&DL=1&FN=2D1B7A69\myfile.txt
At the end of the request is the FN variable which
specifies the location of the attachment. If we
change it to something like:
/mail?A=GetFile&U=6E14256E5847A586314259A9630&DL=1&FN=..\..\s082702i.log
And boom I am reading today's logfile on my server.
As you can see it let me use ..\ to climb down the
directory tree all the way to G:\LANSUITE directory
and I could go anywhere on the drive if I wanted and
view any file whose name I know. As you can see this
is a serious problem... but it also opens the door
to more problems...
Problem #2 - Deleting other people's mail/folders
In order to do this you need to have the other user's
User ID (i.e. the name of their actual mailbox directory).
Using the bug above you can get this by looking in
files like:
\LANSUITE\M602.AC1 (or the other M602.xxx files) or
better yet \LANSUITE\M602.XII file.
Once you have the other user's ID, it is a trivial
matter to delete their folders and the mail in them.
Also Problem #1 you can easily read their mail as
well once you have their User ID. But moving on,
when you click the delete button to delete a folder
you send a POST to /mail which looks like this:
A=DELETEFOLDER&U=9A56344224D58F89A67959A96E1&FolderLevel=1&FolderName=folder&FolderDir=G%3A%2FLANSUITE%2Fmboxes%2F769B388F%2Ffldrs%2FF0&NewFolder=&NewFolderName=&MsgType=2&MsgListMsgType=2&SortBy=0&ChkMsgsAction=&MsgID=&MsgTime=&Edit_New=&Edit_Rename=
Broken down into it's unencoded components it looks
like this:
A=DELETEFOLDER
U=9A56344224D58F89A67959A96E1
FolderLevel=1
FolderName=folder
FolderDir=G:\LANSUITE\mboxes\769B388F\fldrs\F0
NewFolder=
...etc...
Now if we replace the 769B388F with User ID of the
other user, we can delete THEIR folders without
even having do anything else...it's as simple as
changing the FolderDir parameter. That's all there
is to it. Even though "U" is my session ID it
doesn't matter, it has nothing to with sessions. It
has to do with the fact that LanSuite trusts the
value of FolderDir and thus deletes the other user's
folder.
Problem #3 - Creating folders/mailboxes ANYWHERE
By modifying the form used to create mailboxes, and
again just by changing the FolderDir parameter you can
create directories all over ANY drive. For instance
say I changed FolderDir from G:\LANSUITE\mboxes\769B388F\fldrs\F0
to C:\DUMB\AND\DUMBER\AND\DUMBER it will happily create
all those directories and put mailfolder files in the
the last subdirectory. Obviously this is a bad bad
thing...
Problem #4 - Renaming other user's folders...
Once again, same problem as above, you can change
the value of FolderDir on the rename folder form
and rename other people's folders...not too interesting...
Problem #5 - Buffer overflow...
There is a buffer overflow in the CGI handling code
which could possibly result in remote code execution.
You can reproduce it as follows:
GET /mail/<BUF> HTTP/1.0\n\n
replace BUF with 5000 chars and the overflow occurs. It
could possibly be exploitable, but I'm not sure.
Problem #6 - Buffer overflow in HTTP Authorization
I just found another buffer overflow, this time in
authorization code. To reproduce:
GET /admin/ HTTP/1.0
Authorization: <BUF>
Where <BUF> is 2000 characters.
To reproduce use the example I used above.
Please let me know any feedback or questions you
guys have, I'm always willing to help fix problems.
-Stan Bubrouski
======================================================
From - Thu Aug 29 16:11:33 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
Message-ID: <3D6E7FF4.1050102@xxxxxxxxxxx>
Date: Thu, 29 Aug 2002 16:11:32 -0400
From: Stan Bubrouski <stan@xxxxxxxxxxx>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: brandon@xxxxxxxxxxxxxxx
Subject: Re: 6 VERY SERIOUS Vulnerabilities in LanSuite 2002
References: <2CF592042D1D5DA240@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Well,
Found more bugs, this time in FTP server:
Problem #1 - FTP Server crash (user command)
$ perl -e'print "user ","A" x 8000,"\n";' | nc localhost 21
220 Proxy602 Gateway ready, enter user@host[:port]
331 Password required for
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAÉ?¡?ï.
530 Please login with USER and PASS.
Right after printing this message LanSuite drops dead.
No crash, nothing logged...it just silently closes down.
A clue though would be the characters at the end of the
message it prints out, it would seem that a buffer is
getting overflowed, or the string is not null-terminated
and a function is being used to print out the message
which expects one... I can't tell exactly what's going
on so...up to you guys...
Problem #2 - Long command DoS
If you login to the FTP server as a local user in my
case test, and issue a long command like CWD or DELE
the FTP session stop responding. At this point nothing
seems to be happening, but immediately when the client
disconnects from the server the CPU usage shoots up to
100% and seems to remain there. Sample:
220 Proxy602 Gateway ready, enter user@host[:port]
user test
331 Password required for test.
pass newtest
230 User test logged in.
cwd <BUF>
I used 2500 chars for <BUF>...then disconnected and CPU
usage remained at 100% indefinately...I waited 3.5 mins
before killing the process. Actually further testing has
shown that just sending something like:
<2500 chars>\n
causes this behaviour.
Problem #3 - Null input incorrectly handled, serious
Some commands like DELE will accept NULL as input and
then attempt to output an error message. This however
does not work, because it tries to plug in the NULL
value supplied by the user and what it ends up doing is
reading in memory from previous commands, for example:
220 Proxy602 Gateway ready, enter user@host[:port]
user test
331 Password required for test.
pass newtest
230 User test logged in.
cwd IAMBROKEN
550 IAMBROKEN: No such file or directory.
dele
550 AMBROKEN: No such file or directory.
: No such file or directory.help
500 command not understood
dele a
550 a: No such file or directory.
Notice how the first time I did the DELE command I
provided no input and it still tried to output that
message...and look at the message...it contains the
contents of the previous output. And if you do it
repetitively it keeps appenting ": No such file or directory."
on to the end of it. By supplying shellcode it may
be possible to execute arbitrary command this way,
just like a buffer overflow, in fact you can cause
an overflow although it appears it may be a heap
overflow.
-Stan
======================================================
From - Thu Aug 29 14:55:57 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
Message-ID: <3D6E6E3D.1020206@xxxxxxxxxxx>
Date: Thu, 29 Aug 2002 14:55:57 -0400
From: Stan Bubrouski <stan@xxxxxxxxxxx>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: brandon@xxxxxxxxxxxxxxx
Subject: Re: 6 VERY SERIOUS Vulnerabilities in LanSuite 2002
References: <2CF592042D1D5DA240@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Brandon,
If you make a request containing lots of '/'
characters the processes CPU shoots up to 100%
and stays that way for about 30 seconds...
I don't need to tell you what happens when
you do this in succession...100% for a long time.
This only happens with '/' character so clearly
it is just poor parsing somewhere that is using
exponential running time (i.e. loops). This needs
to be fixed.
And about the device name thing... you were right
the problem is caused by LanSuite's inability to
handle rapid connections, BUT there is more to it.
If you request say /aux.html then that connection
will hang until LanSuite is restarted. But just
the first instance of trying aux.html...after that
you will get a 404 because the device is in use
by LanSuite which seems to lock the device...the
same goes for all other devices...the initial
request for those devices will hang and NEVER
close, subsequent requests for those files will
return 404.
There are A LOT of things that I'd like to test
but cannot because I do not have a registered
version, so all the testing I've done is limited
to what I can do in the trial version. I've managed
to skip my way around some restrictions by simply
editing .ini files but there is still a lot I cannot
test. Hopefully if you can send me a beta at least
I'll be able to try out some of those things.
-Stan
Phuong Nguyen wrote:
TITLE
=====
602Pro Lansuite 2003 - Multiple Vulnerabilities
DESCRIPTION
===========
“602Pro LAN SUITE is an easy-to-install and manage
all-in-one server application. Its standards-based
SMTP/POP3 e-mail server provides effective e-mail
communication without the risk of destructive virus
infiltration and productivity robbing unsolicited
e-mail. Fax services seamlessly integrate into user
mailboxes to unify e-mail and fax message access.”
More information at http://www.software602.com
PROBLEMS
=========
Version : 602PRO LanSuite 2003, build 2003.0.3.0828
(latest build)
Tested Platform : Windows (2K/XP Pro)
Multiple vulnerabilities in the LanSuite 2003 software
(WebMail interface) which could allow attackers to
view
sensitive information about the users (Mailbox number,
Message ID, Login Time etc...) and read any file on
the server.
DETAILS
=======
[Vulnerability #1] Sensitive Files Exposure
When a user logins to LanSuite 2003 WebMail server,
m602cl3w.exe will create a temporary file and folder
holding sensitive information about the current user
and they are accessible through the LanSuite WebMail
interface http://www.victim.com/mail/. Tempdirs.lst
file holds the temporary folder name of current users.
The temporary folder contains two files named
MSGlist.mid and MSGlist.mil. Messages ID are written
to MSGlist.mid file. The username and mailbox number
are written to MSGlist.mil.
Log files are also accessible by anyone at:
http://www.victim.com/mail/S030904L.LOG (YY/MM/DD).
Attacker might gain sensitive information of username,
user's IPs, login time etc... This information could
be useful to assist in further exploit once they
obtained the file.
[Vulnerability #2] Arbitrary File Reading [required
valid user credential]
Malicious user can read any file on the server if they
have a valid LanSuite WebMail username and password.
M602cl3w.exe does check for dot-dot-slash most of the
time but not when the action "GetFile" is used. For
example, a malicious user can read the boot.ini file
by sending a request like this:
http://www.victim.com/mail/m602cl3w.exe?A=GetFile&U=7921604D7A587937986E24242C0588&DL=0&FN=../../../boot.ini
where "U" is the current user handle’s string.
Malicious users can also read other user's mails by
using the information they got from exploiting the
vulnerability #1.
For example:
http://www.victim.com/mail/m602cl3w.exe?A=GetFile&U=7921604D7A587937986E24242C0588&DL=0&FN=../../mboxes/605e5d4d/2f2284fd.dat
VENDOR STATUS
==============
You can obatain the patch to fix those vulnerabilities
above at http://download3.software602.com/ls2003.exe
Phuong Nguyen
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com