Mac OS X Lion LDAP Vulnerability Emerges

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.

Comments

Security theater a little

[vlm]

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?

Re:Security theater a little

[Spad]

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

Re:Security theater a little

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

This has been on a few sites

[jimicus]

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.

Re:Thanks, now I know what LDAP is

[interval1066]

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.

Re:Thanks, now I know what LDAP is

[elsurexiste]

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