_   _ _____ _     ___ _____ _   _
                   / / / / ____/ /   /  _/_  __/ / / /
                  / /_/ / __/ / /    / /  / / / /_/ /
                 / __  / /___/ /____/ /  / / / __  /
                /_/ /_/_____/_____/___/ /_/ /_/ /_/
                           Helith - 0815
--------------------------------------------------------------------------------

Author		 : Rembrandt
Date		 : 2007-04-21
Affected Software: openssh (propably other implementations as well)
Affected OS	 : any
Type		 : Information Disclosure

OSVDB		 : 34600
CVE		 : 2007-2243
ISS X-Force:	 : 33794
BID		 : 23601


OpenSSH, when configured to use S/KEY authentication, is prone to a remote
information disclosure weakness. The issue occurs due to the S/KEY 
challenge/response system being used for valid accounts. If a remote attacker
systematically attempsauthentication against a list of usernames, he can watch
the response to determine which accounts are valid.

If "ChallengeResponseAuthentication" is set to "Yes", which is the default
setting, OpenSSH allows the user to login by using S/KEY in the form of
'ssh userid:skey at hostname'.


Steps to reproduce:

$ ssh user@somewhere
Permission denied (publickey,keyboard-interactive).
$ ssh user:skey@somewhere  
otp-md5 99 some04578
S/Key Password:
               
$  


If the useraccount exist but is not configured to use S/KEY or if the 
useraccount does not exist at the specific system the response looks normal.


$ ssh testuser:skey@somewhere
Permission denied (publickey,keyboard-interactive).       


As you can see clearly OpenSSH discloses the existence of system accounts.


Kind regards,
Rembrandt