Weakness introduced by denying remote logins on AIX, possibly others

From: Scott J (mrbinary_at_yahoo.com)
Date: 02/10/04

  • Next message: Joey Peloquin: "RE: Password changes more than once per day"
    Date: 10 Feb 2004 13:10:50 -0000
    To: security-basics@securityfocus.com
    ('binary' encoding is not supported, stored as-is)

    This advisory was submitted to BugTraq July 2003 - it was rejected as being a known issue / config problem type of thing. I am submitting it to this list as I believe that it is very likely that an individual or group new to the security field will at some point change the configuration of an AIX server to prevent direct login for some accounts (particularly root), and they may be unaware of all of the ramifications that taking this action results in.
    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 (revised) ------------------------
    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 depending upon circumstances
    Vendor Notified: YES
    Vendor Response: Within one day
    Patch Issued: None available.
    Release date: 2003-07-17
    Rereleased: 2004-02-06



    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:


    Vulnerable authentication methods tested and verified:


    Access methods tested and verified:

    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:
    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 on my part,
    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 of
    thousands of years to determine via brute-force using a remote connection.


    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.


    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 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.

    Free trial: Astaro Security Linux -- firewall with Spam/Virus Protection

    Protect your network with the comprehensive security solution that
    integrates six applications for ease of use and lower TCO.

    Firewall - Virus protection - Spam protection - URL blocking - VPN
    - Wireless security.

    Download 30-day evaluation at:

  • Next message: Joey Peloquin: "RE: Password changes more than once per day"

    Relevant Pages

    • Re: sqwebmail web login
      ... would yield a message such as "Remote logins for this account are not ... It's an issue that I have submitted to BugTraq in the past and had rejected ... the valid password for a given account, this type of information is only ... Personally I can only confirm this result on AIX 4.3.3 - AIX 5.1. ...
    • Related to: sqwebmail web login reported on BugTraq
      ... generic configuration weakness I have come across. ... this account are not allowed". ... a given account you will be aware that remote logins are not permitted for ... Personally I can only confirm this result on AIX 4.3.3 - AIX 5.1. ...
    • very strange problem on aix-based system
      ... I'm debugging a system (AIX 4.3.2) delivered to the government for ... which I have no way to contact the original software developers. ... account looks like a normal account created using smit. ... the login name. ...
    • Re: Restrict FTP user to a directory tree (NOT anonymous login)
      ... I have been researching the FTP logins and using anonymous logins for ... A user with an local user account and password should be able to see ... what he/she is allowed if using local login. ... What I am trying to accomplish (using standard AIX FTP, ...
    • Re: AD Security Groups break Authentication
      ... I can do a domain login using my own account & a couple others, but one specific account can't login. ... My ping testing showed that 1430 was the highest MTU setting that wouldn't result in fragmentation. ... As soon as the network engineers changed the MTU from the default of 1500 to 1400, all domain traffic stopped and they detected a ton of errors, so we restored the MTU to 1500. ...