Note to the Moderator: Sorry I send ya a Beta in the first mail :)
_ _ _____ _ ___ _____ _ _
/ / / / ____/ / / _/_ __/ / / /
/ /_/ / __/ / / / / / / / /_/ /
/ __ / /___/ /____/ / / / / __ /
/_/ /_/_____/_____/___/ /_/ /_/ /_/
Helith - 0815
Author: Rembrandt
Date: Known since somewhere in 2005
Affected Software: OpenSSH 4.6 <=
Proppably everything which is based on OpenSSH
Type: Remote
Type: Enumeration of system accounts
Greets go to: Helith and all affiliated People, t3c0, levent, str0ke,
The EOF-Crew, rrlf, herm1t, Solar Designer, softxor,
Packetstorm (Todd, Emerson(Thanks for the Cohiba and beer))
and others
OpenSSH is vulnerable to an information leak which allows remote attackers
to gain informations about system accounts, in case S/KEY is used on the system.
If "ChallengeResponseAuthentication" is set to "Yes", which is the default
setting, SH allows the user to login by using S/KEY in the form of
'ssh userid:skey@hostname'.
The normal behavior for SSH looks like this:
Passwordauthentication is disabled as you can see.
Now you can test about ChallangeResponseAuthentication.
If it`s enabled it will let you determine the existence of system accounts.
===============================================================================
alucard $ ssh user:skey@somewhere
otp-md5 99 some04578
S/Key Password:
If a account does not exist OpenSSH reacts like exspected.
As you can see clearly OpenSSH discloses the existence of system accounts.
A possible solution for this problem would be to print a fake S/Key-Request
even for non existing users as well as it`s done with the
Passwordauthentication.
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/