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@ccs.neu.edu> Date: Wed, 28 Aug 2002 13:11:50 -0400 From: Stan Bubrouski <stan@ccs.neu.edu> 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@software602.com, candy@software602.cz, hotline@software602.cz, brandon@software602.com CC: mhuston@imagitekltd.com, tomas.holcik@cpress.cz 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@software602.com) 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@ccs.neu.edu> Date: Thu, 29 Aug 2002 16:11:32 -0400 From: Stan Bubrouski <stan@ccs.neu.edu> 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@software602.com Subject: Re: 6 VERY SERIOUS Vulnerabilities in LanSuite 2002 References: <2CF592042D1D5DA240@software602.com> 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@ccs.neu.edu> Date: Thu, 29 Aug 2002 14:55:57 -0400 From: Stan Bubrouski <stan@ccs.neu.edu> 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@software602.com Subject: Re: 6 VERY SERIOUS Vulnerabilities in LanSuite 2002 References: <2CF592042D1D5DA240@software602.com> 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
