Message-ID: <3F73D073.3040308@ccs.neu.edu>
Date: Fri, 26 Sep 2003 01:36:51 -0400
From: Stan Bubrouski <stan@....neu.edu>
To: Stan Bubrouski <stan@....neu.edu>
Cc: Phuong Nguyen <dphuong@...oo.com>, bugtraq@...urityfocus.com
Subject: Re: LanSuite 2003 - Multiple Vulnerabilities


Oh,

One more minor buffer overflow/DOS I might as well
mention (I know of many more bugs in Lansuite, but
I think we damaged their product's reputation enough
this week) since its not too harmful.

Making long requests containing periods will cause
a buffer overflow in Lansuite.  IIRC an url consisting
of lots of './' would cause an overflow in Lansuite.

Again IIRC this is not exploitable because anything
other than periods and slashes will bypass the buggy
code and output an error page without overflowing the
buffer.  So as far as I remember this is only a remote
DoS vulnerability in Lansuite 2002, which probably
affects Lansuite 2003 as well...any confirm that?
Somewhere on DVD I have proof of concept scripts, I'll
see if I can dig 'em up.

-sb


Stan Bubrouski wrote:

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

Powered by blists - more mailing lists