Forgot your password?
typodupeerror
Bug Desktops (Apple) OS X Security Apple

Mac OS X Lion LDAP Vulnerability Emerges 97

Posted by Soulskill
from the mash-keyboard-for-access dept.
hypnosec tips a bit of Apple news from late last week that got overshadowed by the headlines about Steve Jobs. According to El Reg, "People logging in to Macs running OS X 10.7, aka Lion, can access restricted resources using any password they want when the machines use a popular technology known as LDAP for authentication. Short for Lightweight Directory Access Protocol, LDAP servers frequently contain repositories of highly sensitive enterprise data, making them a goldmine to attackers trying to burrow their way into sensitive networks." Initial reports about this bug cropped up less than a week after Lion was released.
This discussion has been archived. No new comments can be posted.

Mac OS X Lion LDAP Vulnerability Emerges

Comments Filter:
  • and I dont even have to read the article!
    • by _xeno_ (155264)

      Plus I learned that IT is using LDAP wrong where I work! They use it to authenticate user accounts on the various servers that contain "repositories of highly sensitive enterprise data" but apparently those are supposed to be stored on the Lightweight Directory Access Protocol server itself.

      What do you know - I'll have to fire off an email to IT and ask them to transfer our SVN repository (accessed via SSH) to the LDAP server.

      • Technically you can use LDAP to store information. Being an an auth/user database is only part of what LDAP does. It's more like a lightweight non-relational database than anything (I realize that isn't quite right, but it's a reasonable comparison). One of the things that nearly any LDAP tutorial has you do is create a shared address book for instance. Indeed, if you look at the most popular LDAP system currently available (Microsoft's Active Directory) you'll see that it can store all sorts of potentia

        • by interval1066 (668936) on Monday August 29, 2011 @05:33PM (#37246724) Homepage Journal
          LDAP is a (what I always thought was) a pretty cool hierarchical directory type data server; its really good at storing data that is in a tree structure. But it will do relational duty as well. A company I worked for that did an enterprise web portal back in the 90's stored its stuff in a relational, but than we got a request for all its data to work on an LDAP server, so it got done. Worked pretty well as I recall. But I wonder if the NoSQL cloud dbs are better for that now. Seems like couchdb would do it just well too.
        • It's more like a lightweight non-relational database than anything (I realize that isn't quite right, but it's a reasonable comparison).

          It's actually a heavyweight pre-relational (hierarchical) database of the type used in the 1960s before relational databases were invented. Many LDAP servers actually use an RDBMS underneath, with LDAP being an additional mapping layer on top of the standard database (others use key/value stores like Berkeley DB, but again you have to add a hugely-complex mapping layer because LDAP isn't anything like the key/value store that it's using for its storage engine). The only LDAP server I know of that uses a st

    • by elsurexiste (1758620) on Tuesday August 30, 2011 @01:22AM (#37250224) Journal

      Thanks, now I know what LDAP is, and I dont even have to read the article!

      I don't know if you really know it, but just to be sure: it's a piece of shit.

      LDAP means Lightweight Directory Access Piece-of-Shit-Protocol. It was created as a lightweight replacement for another protocol. Either the oldest one was designed by Cthulhu itself, or the designers were trolling the hell out of ourselves.

      So, what's the deal with this PoS? The idea is to access data in a hierarchical storage. This was a system administrator's wet dream: every piece of information and configuration for a user, person, service, computer, and organizational unit, and everything neatly organized and in a single place. Even more, everything is Standard(TM)! Cool, you imagine. Yeah, I thought the same... but here ends the coolness. What follows is what happened at the IETF headquarters, just after the original idea was presented:

      Someone said, "Surely not everyone should access the database! We must add authentication!". So, we bloated the protocol a bit, and now it's a directory access protocol that also handles authentication. Ok, maybe it's an acceptable tradeoff, everyone thought. But then someone else said "Since we added authentication to this protocol, we should use it as the central authority for all authentication purposes in our organizations!". WTF, this was designed for directory access, not for authentication. So, after this kludge, someone reasoned, "Since we now have to handle authentication, we need to use TLS on the same port where we handle the directory access! We wouldn't want authentication without an encrypted channel!". And then, another engineer, who was clearly stoned, said "Yeah, let's have that AND let's have an LDAPS protocol that is just like that but on another port". At this point, we can assume that he shared his drugs with the rest of the people involved and everyone said "YES!". And then, someone else, clearly influenced by object-oriented design and abstract data types, said, "We should have defined types, so people won't forget to add data that's important and everything stays consistent, even across organizations". And another one, clearly influenced by Stalin, demanded, "Ok, but people can add only what's explicitly defined, nobody is allowed to enter new data unless we allow it, no deviations whatsoever". Another engineer, clearly influenced by Evil(TM), added "Not only do they have to enter just the data that we will allow them to enter on our defined type, should they want new types for their organizations... they must ask an ID from IANA. Nobody is allowed to share their custom types on demand, they must first come to us". Finally, Cthulhu itself showed up, saw what they did, and said, "Puny insects, you can't design a protocol even if you tried. Protocols are tame unless they are difficult to manage and fail often". And everyone lost their minds and yelled "Let's make it painfully difficult to administrate! Let's add the worst databases the world has seen! Let's make it the most unaccessible service on Earth! Let's make DNS look like a failsafe service!".

      This photograph [imgur.com] was taken at the end of this meeting. It was 4th of July, and the engineers went outside while Washington DC was having a parade. A peaceful photo is superimposed to reduce trauma on the unlucky ones that choose to see it.

      • I agree with what you said. ((Please moderate parent up.))

        But I can't help but wonder if they're talking about Lion Server, which is optional and costs significantly extra. I don't see "PoS Directory/Authentication Mess" in the Sharing preference pane.
        • by rakaur (984920)

          I agree with what you said. ((Please moderate parent up.))

          Wow, so that's how the moderation works on Slashdot. I knew it!

      • Wow. That's one very pessimistic view of LDAP, from someone who probably hasn't spent enough time using LDAP in the way it should be used in order to appreciate it's featues. So lets just address a few of your complaints (sorry if I miss anything, but it's sort of hard to quote and address things when you basically turned your post into work of literary fiction).

        1) Supporting authentication is a bad thing? Really? So you have a DB-like source with loads of info about everything and everybody in your organiz

        • To be honest, I was aiming for "Funny", but got "Informative" instead. Since we are serious, I guess I'll answer like an adult :) . Believe me, I spent too many hours on LDAP to have any love for it. I even contributed a few scripting lines to the OpenLDAP page in Ubuntu. Just look at Amplicate and you'll see I'm not alone ;) .

          I'm not against authenticating. I would have liked authentication and LDAP to be defined/handled separately, though, not in a single protocol. Everything ends up cleaner. LDAP remains

  • Don't worry, I am sure Apple will soon release a statement explaining that LDAP works on Lion as long as you hold your laptop in the correct way.
  • by vlm (69642) on Monday August 29, 2011 @04:06PM (#37245842)

    Once we own an LDAP server we own everything

    Uhhh, say what?

    I guess you could learn my cellphone number, but seeing as its somewhere in between 000-000-0000 and 999-999-9999 its not top secret. I suppose you could change my home directory to /tmp, just to piss me off, at least for a little while. You could delete my ldap account, now that would thoroughly annoy me until I restored the ldap server data from its backup...

    Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it. I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file. Maybe there exists a linux PAM module to change passwords etc inside LDAP, creating ldif files and running ldapmodify to change my password would get old real quick. I would guess the testers probably didn't even set up to do something that weird, assuming everyone would use kerberos with ldap.

    I suppose if you consider nuclear missile launch codes to be "directory information" and thus keep them in your ldap, or more realistically keypad door combinations, then you could be in big trouble. Medical records at a hospital in a LDAP?

    • by boxxa (925862)
      LDAP if interfacing with AD can get you user credentials for domain admins, server admins, server name objects, login history with IP ranges, etc. Simply a user login can get you email access to anyone in the company and I am sure no matter what company you work for, your CEO would not be happy with their emails getting leaked.
      • by vlm (69642)

        ah ha. I'd never used LDAP / kerberos / AFS on a microsoft platform. Sounds like they built themselves a mighty single point of failure there... login history via ldap? Geeze.

        • by Kalriath (849904)

          Actually, the login history is stored in the event log if auditing is enabled - the LDAP user store contains only the last login date, nothing more. You also cannot get the password from Active Directory (you have to crack the SAM on the server). You certainly can't access the mailboxes using only the details in AD since you have to authenticate with the Exchange server using a valid Kerberos ticket (NTLM requires you already have the password) to get those.

          • I dont believe that the user password hashes are stored in the local SAM of a domain controller; Im fairly certain it is stored within directory services. Certainly samdump does nothing on a DC.

            • by Kalriath (849904)

              You might be right actually - I believe there is an attribute within ADS which is only visible to administrators which may contain the (irreversible) password hash.

              • I found this out when we had to do password recovery on a DC, without either the domain password or the AD repair mode password. Its a multistep process, where you first have to use a boot disk to reset the recovery mode password, boot into directory services restore mode, and then change the domain admin password. The bootdisk is unable to do anything to domain passwords, because theyre not stored in registry.

      • by Spad (470073) <slashdot.spad@co@uk> on Monday August 29, 2011 @04:21PM (#37245996) Homepage

        *IF* this vulnerability allowed you to authenticate to AD Domain Controllers with administrative rights then you would be able to dump the SAM database and potentially gain access to all of the user credentials, but then if you could authenticate to a DC as an admin why would you bother when you can just setup your own credentials or modify account permissions directly?

        But it doesn't, so you're getting usernames, machine names, a bit of contact info, a lastlogontimestamp and a few other bits and pieces that in most cases anyone with regular user credentials on the domain would be able to access anyway (Most people don't seem to realise that a lot of fields on AD accounts are readable by any authenticated user).

        Except you're not even getting that because as far as I can tell this only affects logging on locally to an OSX Lion client.

        Storm, meet Teacup.

        • by v1 (525388)

          it's also worth noting that the LDAP database, though encrypted, can have its password reset if you know which bits to twiddle. the server has to be able to access it, after all.

          But that's true of any system that doesn't require a password during boot

        • by Jeremi (14640)

          Storm, meet Teacup.

          Worst X-Men episode ever.

    • They're using LDAP for authentication.

      Meaning if we have a network of linux, windows, mac, etc machines all served by a LDAP backend run on Lion, then I can login as you.

      • by vlm (69642)

        They're using LDAP for authentication.

        Meaning if we have a network of linux, windows, mac, etc machines all served by a LDAP backend run on Lion, then I can login as you.

        Yeah that's exactly what I meant, I didn't know anyone did that. Currently and always LDAP for directory stuff (full name, uid, home dir) and kerberos for password auth everywhere I've ever been. Never seen a place with just ldap deployed, but then I've pretty much avoided hard core microsoft areas, per posts above thats just how those guys roll. I would imagine doing password auth over ldap is kinda like serving up web pages on the internet over nfs instead of http, I mean you could do it, but isn't it

        • Re: (Score:2, Informative)

          by Anonymous Coward

          Yeah that's exactly what I meant, I didn't know anyone did that. Currently and always LDAP for directory stuff (full name, uid, home dir) and kerberos for password auth everywhere I've ever been. Never seen a place with just ldap deployed, but then I've pretty much avoided hard core microsoft areas, per posts above thats just how those guys roll. I would imagine doing password auth over ldap is kinda like serving up web pages on the internet over nfs instead of http, I mean you could do it, but isn't it ... just wrong? I mean outta the box, ldap isn't even authenticated and encrypted itself, is it? Is ldap even theoretically capable of preventing a MITM attack (maybe using SSL?) Use the right tool for the job and do auth in kerberos...

          I've worked where LDAP is used for authentication, lots of applications support using just plain LDAP for authentication. However, these applications also support SSL-encrypted LDAP, so the data is secure in transit. LDAPS is what that's called, and it's on port 636.

          So companies do use LDAP for authentication, yes. And it can be secure in transit, yes.

        • You're acting as though system/network admins are usually qualified and know what's going on. I usually see guys that talk a lot as if they know what they're doing but don't actually understand what they're saying and rely on people lower on the totem pole to actually get anything done. Now you just have to rely on those guys to know what they're doing which isn't always the case.
          • by deniable (76198)
            To be charitable, we're not all incompetent. We're just under-staffed and under-budget. We then get the Boss With Ideas telling us how to run deployments and requiring easy access for the important / loud / connected users.
        • by Kalriath (849904)

          Contrary to boxxa's completely fabricated post, NT domains aren't that insecure. For a start, Windows uses LDAPS for communication with the LDAP server, and second the authentication is all done using Kerberos v5. Logon history is not accessible over LDAP or even remotely at all short of remote event log viewing, user passwords cannot be retrieved via LDAP and you cannot access anyone's email just by getting some details out of LDAP.

          • by deniable (76198)
            It would be an interesting training exercise to figure out how you'd make all of that true. You'd most likely have to extend the schema with an 'unencrypted password' field and a direct link to web mail.
            • by Kalriath (849904)

              Well, if you're running Exchange 5.5 it's easy - if you authenticate as an administrator, Exchange 5.5 will let you open any mailbox.

              • by deniable (76198)
                You can do it with the right group memberships on the later versions. OK, so we need the administrators password unencrypted in the LDAP.
          • by smash (1351)

            hush, don't let the facts get in the way of a good headline.

            I believe the largest use of LDAP only auth is actually in.... free software. Anything semi-professional generally uses kerberos for auth...

      • No. This is a vulnerability in the client-side portion, as if you had configured a linux client with:
        auth sufficient pam_permit.so

        It should have no effect on any other clients.

    • by ulzeraj (1009869)
      I've seen quite a few mid-sized companies storing passwords on pure ldap and controlling access through LDAP ACLs allowing only the admin to see the userPassword field besides its owner. You can consult everything else anonymously. Thats pretty common on smbldap-tools and some samba domains managed by SuSE YaST that I've met.
    • by jimicus (737525)

      Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it. I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file. Maybe there exists a linux PAM module to change passwords etc inside LDAP, creating ldif files and running ldapmodify to change my password would get old real quick.

      I have. There is a PAM module that does an LDAP password update. The biggest problem is that there's about a hundred different ways you can configure it, every Linux distribution makes different assumptions about your environment - assumptions which can change between versions - and this almost invariably leads to interoperability problems. Fortunately they all use the same libraries so you can generally dump a known-good set of config files in the appropriate place in /etc and away you go.

    • by bk2204 (310841)

      Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it.

      Debian uses LDAP and does not use Kerberos. I presume that they store the passwords in LDAP in the standard fashion.

    • Firstly, this vulnerability has nothing to do with the LDAP server, or owning the LDAP server. It is effectively as if Mac OS X, when configured for LDAP authentication, has a 'auth sufficient pam_permit.so', so the client will accept any username or password. However, this doesn't imply any access to the LDAP server ...

      Once we own an LDAP server we own everything

      Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it.

      I have a few, where Kerberos is not really viable, and (since almost all access to anything is via ssh with public keys - but stored in LDAP), the passwords aren't really the issue, but the

  • I've been unable to reproduce this with AD authenticated Lion 10.7.1. The stories I've read referenced OpenLDAP and LDAP in general, but I haven't seen AD mentioned yet. Has anyone gotten this to work with AD?
  • by Zombie Ryushu (803103) on Monday August 29, 2011 @04:32PM (#37246118)

    A few pointers. Don't use LDAP for authentication. use Heimdal Kerberos for authentication (PAM) and use LDAP for authorization. (NSS). Don't let machines bind as cn=Manager. That is very bad should a machine become compromised. Generally, SASL LDAP binds are recommended over simple. Kerberos should bind

    And most relevent. Only let users in the People OU bind to their own uid in the suffix.
    If you are binding to the tree with cn=Manager, on a regular basis, you deserve what you get, set your ACLs right.

  • Uh.. What? (Score:4, Insightful)

    by synthesizerpatel (1210598) on Monday August 29, 2011 @04:33PM (#37246130)

    I'm not quite sure what the 'bug' here is.. First off, Apple's LDAP is 'OpenLDAP'. So. Is this a flaw in OpenLDAP or Apple's configuration for OpenLDAP?

    Also.. LDAP is kinda like DNS, except most places don't secure it. To see this in action, download Apache LDAP Studio, connect to your friendly local LDAP server and start browsing around (without authentication).. Most times you can get an almost full LDAP dump from a remote server without authenticating at all. Generally the only 'protected' elements are the passwords. You can enumerate users, groups, etc.

  • Seriously, would it kill them to do better then forum reading and printing post almost verbatim. The issue as i understand it is that if you have a mac os 10.7 open ldap server or apple open directory it will either not let user login or let them login without password. but nobody has any details, or my googlefuu failed me... Still that should have been caught in beta.
  • by jimicus (737525) on Monday August 29, 2011 @05:07PM (#37246476)

    IMV, it's not as bad as it's made out.

    The way LDAP authentication is supposed to work is:

    1. Client connects to server to find exactly where in the tree the user's information resides (the user's DN). This is not particularly sensitive - it's usually done either anonymously or with an account with very little privileges.
    2. Client drops the connection then tries to re-connect using the DN it found out in (1) and the password supplied by the user.
    3. If the server responds that the login has succeeded, let the user use the service. If not, refuse.

    A number of people have followed the logs on their LDAP servers and established that OS X Lion isn't carrying out step 2 at all. So provided the user ID supplied is valid, the user can log into the computer.

    It's important to note that this process is repeated for every process you want to use. Kerberos makes life a little easier (the server supplies a token to say "This user has logged in OK" and that token can be used to authenticate against services that support Kerberos). In any case, the person is logged into the computer but cannot access network resources. Nevertheless, it's an absurd fault that should have been picked up in testing, I have no idea how it could possibly slip the net.

  • a bit of Apple news from late last week that got overshadowed by the headlines about Steve Jobs

    1. Discover an embarrassing vulnerability in your OS.
    2. Relapse into fatal cancer and resign as CEO, drowning your goof in media noise.
    3. ???
    4. PROFIT!!!

    You have to admire the guy's genius, dedication, and unmatched PR skills ...

  • I just tried it with a Lion client bound to an OS X 10.6 server using OpenDirectory, and I couldn't replicate the problem.

    So is Lion doing something non-standard when connecting to OpenLDAP servers? I noticed that in the main thread it was mentioned that they weren't using the full Apple LDAP schema.

  • You use mac OSX on servers? and what do you do with linux then?

    • and what do you do with linux then?

      Linux is for Windows fail. Microsoft breaks it... Linux fixes it. That is its prime reason for existing. The fact that Linux makes a fast, stable server platform is purely an unintended side-effect, call it a happy accident, of not being Windows.

  • My company uses OpenLDAP for user authentication in the datacenter and ran across a strange problem that seems very similar to this. It was present in at least OpenLDAP 2.4.16. We tracked it down to a weird problem in the password policy overlay. If I recall right it was the password policy overlay was returning a successful response to updating the last failed login time attribute but that was being passed up and causing binds to return true also. Our solution was to remove the password policy overlay

The economy depends about as much on economists as the weather does on weather forecasters. -- Jean-Paul Kauffmann

Working...