Mac OS X Lion LDAP Vulnerability Emerges 97
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.
Actually.... (Score:2)
Re: (Score:2)
just turn off bonjour with iservebox , but that might be a new bug because I dont even think the new macs come with bonjour.
And I haven't had to do that since 10.5 IIRC. In short, that problem no longer exists (well at least on my .local domain).
Re: (Score:2)
...because I dont even think the new macs come with bonjour.
Say wha...? If anything, Apple's increasing its use of bonjour. It's baked into iOS and certainly still being pushed in the latest OS X.
Re: (Score:2)
.local is there for a reason. It ensures that if you do not want any internal DNS to resolve externally and are not answering DNS requests from the outside, that your Domain Controller's DNS doesnt supercede legitimate domains.
Take for example a company that wants to use foo.com as their internal domain. If they host all external foo.com services "in the cloud", naming their internal dns domain "foo.com" will hose the ability for anyone on the domain to properly resolve the external addresses. To fix it
Re: (Score:2)
It makes very little sense to combine the two into one, when they share completely seperate address space, are on completely separate ISPs, and one half is supposed to be unresolvable by design. Putting them in the same DNS domain would be bad design; you will either have a non-authoratative DNS server claiming to be authoritative for a domain, or you will have unreachable RFC 1918 addresses in your public DNS.
The first scenario leads to the breakage I mentioned, and is the worst kind of kludge since it m
Re: (Score:2)
Add ".local" to the front of your search domains, and you'll be back in business.
Signed, another admin who got screwed when they decided to use .local for Bonjour.
Re: (Score:3)
It's actually a client problem. Lion may allow you to logon using any username/password combo, or refuse to allow you to logon regardless of your username/password combo if you're using an LDAP backend. AFAIK this won't allow you to access similarly secured network resources using the bogus credentials.
Re: (Score:2)
Thanks, now I know what LDAP is (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
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
Re:Thanks, now I know what LDAP is (Score:4, Informative)
Re: (Score:2)
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
Re:Thanks, now I know what LDAP is (Score:4, Informative)
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.
Re: (Score:2)
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.
Re: (Score:1)
I agree with what you said. ((Please moderate parent up.))
Wow, so that's how the moderation works on Slashdot. I knew it!
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:1)
If by "secure" you mean it won't execute W32.Blaster.Worm then yeah, it's secure.
Re:but... (Score:5, Insightful)
Well the Mac in this case is the threat and not the vulnerability. So from that perspective, the Mac itself remains secure.
Re: (Score:1)
Well the Mac in this case is the threat and not the vulnerability. So from that perspective, the Mac itself remains secure.
Actually, in this case the Mac is a vulnerability, and thus becomes a threat. From what users are reporting, the Mac doesn't even try to authenticate against the LDAP server. It just accepts any password blindly and let's the user login.
Not a bug with LDAP - just a failure with how Apple has implemented LDAP authentication in OSX Lion.
Re: (Score:3)
No, you remember wrong. The Mac commercials say that, unlike a PC, everything just works and you won't get viruses.
Now if I try and access "Important Trade Secrets.pdf" and get told "Access Denied," that's not "just working," is it? So instead, with the new Mac OS X Lion, instead of giving you an "access denied" message when you try and access that file, it just loads it up! It just works!
OK, so I'm really confused as to what the vulnerability actually is. And given that the article starts off with "LDAP se
Re: (Score:3)
I guess that's what happens when you use OpenLDAP.
Silly Apple.
Re: (Score:3)
I think. Who knows. The article is awful.
El Reg is a rag, a fun rag but a rag nonetheless. There's been a spate of articles lately attacking Apple's enterprise readiness because of bugs (in a month old OS.) I wonder if that's because they are being used more in enterprise and it's becoming more of a problem or someone's just worried that they might get some traction in business ?
Re: (Score:3)
They may not be a "shill"... but their bias is very clearly marked on their collar. :) I have seen them put out false stories and, upon finding they were fake, taking their own sweet time to post a retraction... dunno if that has gotten better over time or not. To be fair, it's not a normal practice, but it sure did seem a while before they retracted...
It's rather like the decided BeOS bias of osnews.com. :) It's obvious, unhidden, and taken with a grain of salt. Their level of scrutiny for anything not BeO
Re: (Score:1)
Wow, somebody has insecurity issues.
Re: (Score:2)
Of course, the best (and hardest to achieve) security comes from smart vigilant system admin and smart users. The best operating systems can do is to make their work easier and not undercut their efforts (with serious vulnerabilities, autoplay, weak permissions, etc).
Re: (Score:2)
I've been running Fedora Core on an iMac for a good while. Mostly to play Doom 3 and Quake 4 -- somehow those games never get tiring for me. Yep, I'm too cheap to shell $50 or so out for an OS X version of the same :)
Re: (Score:2)
User Error (Score:1, Funny)
Security theater a little (Score:4, Informative)
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: (Score:1)
Re: (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Security theater a little (Score:5, Informative)
*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: (Score:2)
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
Re: (Score:1)
Storm, meet Teacup.
Worst X-Men episode ever.
Re: (Score:2)
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.
Re: (Score:2)
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)
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.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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...
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
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
Is this AD or just straight LDAP? (Score:2)
Re: (Score:2)
It's an LDAP only issue. If you're using Kerberos/AD, then it's a non-issue.
Re: (Score:2)
This sounds like an ACL issue. (Score:3)
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)
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.
Re: (Score:2)
Or it will be patched within weeks and will be part of the next Software Update. What precedent can you provide that would suggest otherwise?
Ergh, horrible article is horrible. (Score:1)
This has been on a few sites (Score:5, Informative)
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.
Brilliant cover up (Score:1)
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
Doesn't work with OpenDirectory (Score:2)
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.
Servers? (Score:1)
You use mac OSX on servers? and what do you do with linux then?
Re: (Score:2)
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.
Possible Solution (Score:1)
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