Subject: RE: user account cracking status

From: "Roger A. Hanke" <[email-masked]>
Date: Mon, 9 Jun 1997 10:54:57 -0400

Bonjour Alain,

----------
From: 	Alain Magloire[SMTP:[email-masked]]
Sent: 	Friday, June 06, 1997 6:03 PM
To: 	[email-masked]
Cc: 	jev@lynxhub; jag@lynxhub; rah@lynxhub
Subject: 	Re: user account cracking status

Bonjour Roger

> 
>  First new piece of info, is try the same exercise on your native FTP server.
> On IRIX 6.2 I was prompted for password as expected.
> On Solaris 2.5.1 I got the same result as with my WUFTPD B13 version:
> 
> 220 hdpst01 FTP server (UNIX(r) System V Release 4.0) ready.
> Name (hdpst01:rah): garbage
> 530 User garbage access denied.
> Login failed. 
> 

..

>  Does anyone with more familiarity with the code have any guesses on how
> difficult a patch this might be?

A patch should not be hard to do. In ftpd.c, the fucntion user() 
calls access_ok() which will return 0 because they're is no class
directive in the ftpaccess file and logs you out with :
>> Well I am still very hesitant to hack code I am not familiar with.
Also have only been doing Perl programming lately, so C is a little rusty.
But this does explain exactly the behaviour I have been reporting.
But the important issue that remains is, is it reasonably simple to store this
failure return, continue with processing, then fail them after the password
check (wouldnt happen to know where that is done would you ;-)
because of the previous access list failure? That is the only way I can
think of always seeing the password prompt before any error is returned.
Do you agree that should always be the case? I would like to make sure
the design is acceptable to the list in general as I see this as something that
should be incorporated in the next version.
"530 User .."

ftpd.c ----
user(char *name)
.
{
..
    if (access_ok(530) < 1) {
        reply(530, "User %s access denied....", name);
        syslog(LOG_NOTICE, "FTP LOGIN REFUSED (access denied) FROM %s [%s], %s",
               remotehost, remoteaddr, name);
        return;
..
}

access.c----
access_ok(int msgcode)
..
    /* if user is not in any class, deny access */
    if (!acl_getclass(class)) {
        syslog(LOG_NOTICE, "ACCESS DENIED (not in any class) TO %s [%s]",
               remotehost, remoteaddr);
        return (0);
...

> I am also open for suggestions on any
> workarounds besides putting in "class everybody real *" in my ftpaccess file.

when compiling set use_accessfile to 0, so you  won't have to use
the ftpaccess file.
>> I do use guest logins and other stuff which of course all require ftpaccess
so cant get away with this :-(
> 
>  Thanx for your patience if you made it this far ;-)

Sure :-), this mail was forward to me by a coworker. I did not see any
previous posting, but I think you came up with some valuable info.
>> Yeah I am not sure why more people werent concerned about this.
Yours was the only response I got once I had finally nailed down the 
problem. I guess most people are using reals and expect to continue to
do so, so feel this wont ever affect them. But I cant believe they aren't using
some access controls on their reals, and if a user comes in from an invalid
IP or domain the same problem does occur. And unfortunately it is very easy
to crack the username and password when you can attack them in separate
steps. 
 Perhaps noone is allowing guest class logins from * (the internet) like
I am, and it is a guest class login they would be cracking into in my case.
My whole problem seems to be in ftpaccess where I only allow guest class
logins from *. This means the only way to get past the access control list
checking in ftpaccess is to enter a valid guest username. And of course 
this leads to the two distinguishable responses, when you enter an invalid
username and a valid guest class one :-( 
	Roger

please CC me on any followups, many thanks

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

---

From: Alain Magloire <[email-masked]>
Date: Tue, 10 Jun 1997 13:25:58 -0400 (EDT)

Bonjour Roger

> should be incorporated in the next version.

to be brief --

case (1) :  class directive
  If there is no class directive in ftpaccess, wu-ftpd will refuse
access to user with no account on the system:

ex:
220 spock2 FTP server (Version wu-2.4.2-academ[BETA-13](1) Sat Mar 29 09:29:21 EST 1997) ready.
Name (spock:alainm): garbage
530 User garbage access denied....
Login failed.

Caveat - an attacker can obtain valuable information on the system.

case (2) : ftpusers
  if a loggin name is part of ftpusers file, ftp server will not ask the passwd

ex:
220 spock2 FTP server (Version wu-2.4.2-academ[BETA-13](1) Sat Mar 29 09:29:21 EST 1997) ready.
Name (spock:alainm): adm
530 User adm access denied...(bad shell)
Login failed.

Roger, I believe that you're argumenting that wu-ftpd is giving out
too much info. Although not leading to breakin, someone
could scan ftp for all the valid users and then use 
crack later... inconvenient :-(

IMHO, I agree with Roger, and ftpd should always ask for passwd
regardeless. Make it harder for the bad guys.

any other comments or suggestions ?