Likes: 
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 n
ow.
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 lo
gins 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/develope...jects/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 store
s 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 equival
ent 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 loc
al (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 unt
rustworthy 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.ca
t 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 up
grade 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 goo
d 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 att
empted 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.
Quote
