AIX password enumeration possible
This advisory first submitted to BugTraq July 2003 - rejected but since a less
detailed post on this subject made it to the list as a reply and there have
been subsequent inquiries regarding it off-list, there may be interest in
placing this on the list now.
Email exchanges with BugTraq personnel (in July of last year) were the source
of info that indicated Solaris may suffer from the same issue.
Currently, BPR personnel can neither confirm or deny this behaviour exists in
any OS other than AIX of versions mentioned below.
---------------- BinaryPowered Research advisory 2003-01 -----------------
This advisory may be reproduced and redistributed in any manner.
BPR and the author(s) of this advisory assume no liability for any misuse
of information contained in this advisory. Neither BPR nor the author(s) are
in any
way liable for any damages caused by or believed to arise from
this advisory.
---------------- BinaryPowered Research advisory 2003-01 -----------------
Abstract: Remote password enumeration possible for
accounts not permitted direct login in AIX
Affected Systems: AIX 4.3.3 and AIX 5.1, likely other levels of AIX
Vendor: International Business Machines Corporation (IBM)
Severity: Low
Result: Privilege escalation possible in some circumstances
Vendor Notified: YES
Vendor Response: Within one day
Patch Issued: None available.
Release date: 2003-07-17
Rereleased: 2004-02-06
--------------------------------------------------------------------------
Discussion:
During some configuration change and testing of AIX for a client, BPR
discovered that it is possible to remotely enumerate the passwords of a known
AIX account. The only configuration change required to allow this to happen in
AIX is to disable remote logins for a given account (via the command "chuser
rlogin=false a_userid"). If a remote attacker tries to connect to the
vulnerable machine with an incorrect password (but a known correct account
name), the response from AIX will be:
"3004-007 You entered an invalid login name or password."
In the case that the correct password is provided, the response is as follows:
"3004-306 Remote logins are not allowed for this account."
This different, unique response allows an attacker to determine the password of
the account in question.
Known Vulnerable:
AIX 4.3.3 maintenance level 10 applied - assume all levels of AIX 4.3.3
AIX 5.1 maintenance level 4 applied - assume all levels of AIX 5.1
Rumored Vulnerable:
Solaris (no version information available - not tested by BPR)
Completely Untested / Unknown:
Linux
OpenBSD
NetBSD
FreeBSD
BSD/OS
HP-UX
IRIX
SCO
Other OS'es
Vulnerable authentication methods tested and verified:
Local
LDAP
Access methods tested and verified:
telnet
rlogin
rsh
ssh ( OpenSSH - no commercial SSH variant tested )
++ Note: OpenSSH version most recently tested was the prepackaged version
for AIX 5.1 currently available (as of Feb. 2004) on DeveloperWorks at:
http://oss.software.ibm.com/developerworks/projects/opensshi
It's not known for certain if this weakness would exist for an in-house
compiled version of Portable OpenSSH on AIX but as the weakness is
believed to be in the response from the login program after authentication
has taken place, it would also likely be affected. Also, it makes no
difference if sshd is configured to allow or disallow root login via
the PermitRootLogin option.
Exacerbating Factors:
AIX only stores the first 8 characters of the password - if those first 8
characters are correct, the login will succeed, despite the fact that AIX's
login program will accept passwords longer than 8 characters. I believe that
the login program only stores and encrypts the first 8 characters (this is
specualation, others on the list may know more definitively). This "weakness"
also applies to the remote evaluation of a password of course, since the value
stored for a password is only the encrypted equivalent of the first 8
characters.
Mitigating Factors:
To "exploit" this the attacker would have to have the ability to log on to the
host in question with another userid since the account whose password has been
enumerated obviously cannot be used for remote login. Alternately the attacker
would require local (ie tty-equivalent) access to the machine. Worth noting is
the fact that as long as the password is complex and is 8 characters, it will
take a significant amount of
time to determine the password of a target userid, possibly thousands or
hundreds ofthousands of years to determine via brute-force using a remote
connection.
Severity:
In a relatively "safe" environment such as a small business where external
network logins are blocked this can be considered low priority but in a more
hostile environment such as a service provider that permits shell-level access
and has a relatively untrustworthy userbase it should be considered much more
dangerous if short or weak passwords are used
for critical accounts.
Solution:
The correct solution would be to change the messages so that the response is
consistent whether a correct or incorrect password is supplied. In AIX the
messages that are returned for the various login actions can be found in
/usr/lib/nls/msg/$LANG/tsm.cat and /usr/lib/nls/msg/$LANG/libs.cat. To change
them, perform the following:
dspcat -g /usr/lib/nls/msg/$LANG/libs.cat > /tmp/new_libs.msg
Change message in /tmp/new_libs.msg to make the messages consistent with one
another
Create the new catalog file, issue:
gencat CatalogFile SourceFile
Finally, copy message catalog back to it's intended location and test. This
"customized" message catalog will quite possibly be wiped out by maintenance
level upgrades etc. to AIX, so this would need to be verified and possibly
repeated whenever an OS upgrade is performed, if it makes any changes to the
relevant message catalogs.
Other suggestions to reduce exposure (but not eliminate it entirely):
Give accounts that have been restricted from remote logins strong passwords.
Change accounts that have been restricted from remote logins such that only
specified groups can su to that account (similar to the "wheel" group concept
in BSD).
Change the delay for unsuccessful login attempts (via the "logindelay" parm in
the login.cfg file). For every second that you increase the logindelay value,
you make a bruteforce attack less likely to succeed by a corresponding
magnitude.
If your site is not already doing so ensure that unsuccessful login attempts
are monitored with alerts sent to a human-montitored facility when unsuccessful
login counts become too high.
Where practical, suspend / lock accounts automatically when unsuccessful login
thresholds are exceeded.
Ensure that critical accounts have strong passwords, and have password strength
enforcement in place.
Vendor Response (paraphrased):
=This is the expected response of AIX. This behaviour can be changed by
performing the following.... (outlined above) To have this default behaviour
changed, contact an IBM marketing rep to initiate a process called "Design
Change Request".=
BPR Response:
It is disappointing that this is the out-of-the-box behaviour of an operating
system that is a current offering of one of the largest computer hardware and
software vendors in the market. Furthermore, it is quite bizarre to suggest
that a customer should have to contact a marketing representative to request
such a change in behaviour, technical people and security professionals at IBM
should realize the need to change this behaviour, especially given how easy it
would be to correct it.
Closing Remarks:
As the root account is the most powerful account on the system logic dictates
that if a site is trying to improve the security posture of their AIX host(s),
root accounts are among the most likely to be disabled for remote logins. This
is generally a good measure to take, but particularly so when the password
strength is effectively limited to 8 characters. Also, it is highly unusual to
have the root account automatically
suspended (if in fact this is possible - untested) because of invalid login
attempts as this would require rebooting the server and bringing it into single
user mode to correct. Taking these factors into account, root becomes the
most likely to have attempted enumeration of it's password performed via
brute-force methods. Furthermore, it is rare that the account with UID=0 will
have had the account name associated with it changed from root, it can
introduce difficult-to-diagnose problems including but probably not limited to
idiotic major software vendors whose software install scripts do not validate
that it is UID 0 invoking the install scripts, but instead perform a whoami
inquiry expecting "root" to be the returned value.