Subject: FTP password cracking

From: "Roger A. Hanke" <[email-masked]>
Date: Fri, 30 May 1997 11:36:29 -0400

Dear WUFTPD'ers

 In trying to check some possible security holes, ran across one that WUFTPD
seemed to make worse. Hope someone can possibly point out a way around 
this. 

 Normally with UNIX, on purpose, they do not give you any feedback during
the login process until after you enter both the user id and password. 
This increases the number of permutations exponentially required to crack
into an account.

 But with Beta 11 version at least (and I strongly suspect all versions) if you
enter a "garbage" user name you get the following response:

530 User garbage access denied....
Login failed.

 Of course if you enter a valid user id that has proper access authorization
you get the password prompt. So it is very easy for a computer program 
being used to crack in, to realize when they have discovered a valid id.
Then can then shift to cracking the 8 character (on UNIX anyway) password
for this account. Even if you limit their consecutive logon tries to 3 like I 
do, this just slows them down a little, they just try 3 iterations at a time before
doing another open and 3 more tries....

 This scenario can occur on any WUFTPD server but in our case it is a FTP
download server that is on the internet. Many of our customers have been
given guest class ids that they use to setup private download areas. But since
their end users can come from any possible IP address, there is no way
to use guest class IP restrictions.

  Thought of using the UNIX account LOCKOUT mechanism (despite the
recent CERT on SGI's ;-(  but this introduces the possibility of denial of
service attacks on all accounts on this server. Which could render this
server useless if someone cracked valid user ids and then started cracking
the password resulting in account lockouts.

 Am not able to go to a skey implementation because our customers do
not want to put up with the extra inconvenience. But even this just means
an internet cracker would need to crack a 28 (or so) character password
instead of an 8 character one. It does not prevent them from discovering
valid user ids which is the real problem as I see it.

 So anyway to have WUFTPD suck in user id and password and then do
its access checks? So that valid user ids could not be discerned at least.
So that no access denied, or invalid password, or any other error messages
would come out prior to entering both user id and password?

 Thanx for hearing me out,
	Roger Hanke

---

From: Kent Landfield <[email-masked]>
Date: Fri, 30 May 1997 12:17:08 -0500 (CDT)

# But with Beta 11 version at least (and I strongly suspect all versions) if you
# enter a "garbage" user name you get the following response:
# 
# 530 User garbage access denied....
# Login failed.

I tried that with the Beta-13 version I run and did not get the same results.
It was asking for a password every time.

I also found the following at the top of the user() function. 
 
/* USER command. Sets global passwd pointer pw if named account exists and is
 * acceptable; sets askpasswd if a PASS command is expected.  If logged in
 * previously, need to reset state.  If name is "ftp" or "anonymous", the
 * name is not in _PATH_FTPUSERS, and ftp account exists, set anonymous and
 * pw, then just return.  If account doesn't exist, ask for passwd anyway.
 * Otherwise, check user requesting login privileges.  Disallow anyone who
 * does not have a standard shell as returned by getusershell().  Disallow
 * anyone mentioned in the file _PATH_FTPUSERS to allow people such as root
 * and uucp to be avoided. */

I did not see any mention of it in the CLOSED-TICKETS-13 or FIXES* files.
Best suggestion I can give is upgrade to beta-13. 

-- 
Kent Landfield                        Phone: 1-817-545-2502             
The Landfield Group                   FAX:   1-817-545-7650             
Email: [email-masked]             http://www.landfield.com/
Please send comp.sources.misc related mail to [email-masked].
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/

---

From: Kent Landfield <[email-masked]>
Date: Fri, 30 May 1997 17:44:23 -0500 (CDT)

I stated that this did not happen here in the version of Beta-13 I'm running.
Well.... :)  When using HOST_ACCESS what I found was that if you put records
such as the following...

	allow  kent    some.domain    
	allow  anonymous    *
	deny	*	*

you will get the type of behavior Roger described.  The HOST_ACCESS code
should ask for a password on failure as well so as to mask what is a 
valid and invalid user as Roger described.  FWIW.