NetworkingNon platform-specific networking thoughts December 11, 2003 passimWhat happens when you don't understand the problem:Well, thanks to William Carrel, and his advisory, the Mac community is now getting slings and barbs from the PC community, who are now starting to say "See...Macs are vulnerable too, ha-ha!" In fact, there's been one article in PC World that has almost that exact title: "Eureka, Mac's are not invulnerable", by Lance Ulanoff. Lance has a fine time dishing up all the crow he expects Mac users to eat. In fact, he ends his article with "...How cocky are you feeling now, Mac elite? Hmm. Suddenly it's gotten pretty quiet around here." Lance's apparent inability to deal with the proper use of an apostrophe aside, he's missing many points in his "neener-neener" article. First of all, the Mac community has never (well, not the sane members) claimed that Macs are invulnerable to crackers. What they have claimed, and correctly so, is that the Mac OS is far harder to crack than Windows. But since Lance and some others are having a good time with their new-found realization that the Mac OS is a computer operating system, not a magic spell, let's take a look at the problem, something Lance and a few others haven't bothered to do. The heart of the problem is that by default, the ability to bind to an Open Directory system that is discovered via DHCP is enabled in Mac OS X. This is nothing new. Being able to bind to a directory with no manual configuration out of the box has been a feature of Mac OS X since it was still NeXTSTEP. This is something that is a great convenience to any network administrator, the ability to have a machine be a part of your directory structure with as little work as possible. Since DHCP allows for the integration of LDAP as a part of the spec, Apple takes advantage of this, and so you have LDAP binding via DHCP, automagically. That's an important point, so let's stress it. Apple's implementation is in compliance with RFC 2131, the DHCP RFC. They are not doing anything non-standard, nor are they extending the standard in a proprietary fashion, ala Microsoft and Kerberos. The reason this is important is because it points out the real source of the vulnerability. Not Apple's code, or really even their implementation. But the DHCP standard itself. DHCP, as defined by RFC 2131, has no security. None. In fact, I'll quote you the entire security section of 2131, section 7: "7. Security Considerations DHCP is built directly on UDP and IP
which are as yet inherently Unauthorized DHCP servers may be easily
set up. Such servers can Malicious DHCP clients could masquerade
as legitimate clients and Just in case you aren't getting the deeper implications of this: Anyone running DHCP has a security hole on their network. Now, there are ways of restricting who can get a lease from a server. But that's not security. That's access restriction. That's no more security than not allowing people in the door who don't work there. It's kinda security but not really. You still aren't verifying that the server you're getting your configuration information and settings from is the server you're supposed to be getting them from. You plug into the network (virtually in the case of wireless) and get your configuration from the first server you find. If it's the right one, hooray! If it's the wrong one, you're screwed. Any competent network administrator knows this, or should. That's why you make sure that your users know there are dire consequences for setting up a rogue DHCP server. It also doesn't take long to find a rogue DHCP server on a network. Usually, about five minutes after it goes up, you get calls from users complaining the Internet is broke. (Amazing how a human being can crawl three miles after their arms are ripped out, but five seconds without Amazon, and you'd think they were on the wrong end of the Spanish Inquisition.) So, who's at risk from this lack of security? Well, everyone using DHCP is. No, really. I'm serious. The only difference to Apple is that they also use DHCP for LDAP discovery. But even if all you use DHCP for is IPv4 addressing, and DNS, you're still at risk on a rogue server, because that server now has your IP address, and your MAC address, which can be of great convenience to a cracker. But the truth is, Apple's not that unique in using DHCP for more than just assigning TCP/IPv4 information. Microsoft does it too, in particular for RIS, or Remote Install Services. This is a process by which you can boot from your network card, and if you have a properly configured DHCP / RIS server on your network, the network card (NIC) binds to the RIS server, and commences installing software. This can include the OS. RIS can repartition your drive, and format your drive too. It can set the Active Directory domain your PC binds to. It can do this all unattended. All it needs is a DHCP server with the right settings. There's no picking the DHCP RIS server. You don't verify that you're on the right server. You reboot your machine from a PXE-Enabled NIC, and you're RIS'd. Why would anyone do this? Heck, why doesn't Apple do this now? I mean, NetBoot's almost there. Look, I've used RIS. It rocks. It's amazingly handy. As a network administrator, I always cringe at what PC vendors decide I need on my machine by default. But face it, even with a fast external drive, reconfiguring a hundred machines sucks. You can only do one or two at a time. Not with RIS. With RIS, you boot from the NIC, and go start the next machine. RIS lets you customize a hundred machines in the amount of time you can do one manually. What network administrator doesn't love RIS? Only the ones who don't know about it. But what happens if someone inserts a rogue DHCP RIS server on your network, and you don't realize it? Well, you're screwed. Not only does the cracker own that machine, but they have their own custom OS installed. All it takes is for that machine to be set up for real evil, and your network could be quickly hosed, hard. So do you never use RIS or take advantage of PXE booting? Don't be silly. You simply spend some time making sure that you don't have rogue servers on your network. You do the basic security things you should have been doing before the Carrel warning. So now we have Microsoft (and Intel too, PXE is their baby) creating a potentially bigger problem. So how doe they fix this? Well, honestly, right now they can't. The problem isn't DHCP, RIS, or Open Directory. It's that DHCP, the basis for all this convenience, is insecure. Now, Apple, or Microsoft, or Intel could create a bunch of proprietary extensions to DHCP to provide for authentication of the server to the client. Of course, that creates multiple incompatible DHCP implementations, and the advantages of DHCP quickly die off. There is a proposed standard for securing DHCP. It's RFC 3118, and its been in work since 2001. It is designed to allow for authentication of servers to clients and vice versa. Now, 3118 isn't the ultimate answer, but it's a darned good idea. However, even if it were ratified the second you read this article, it would still take a massive effort on the part of hardware and software manufacturers to rewrite and update both DHCP server and client software and implementations, along with management software. So it would be a year at best for updates, and that's assuming that there would be no bugs, etc. I'm pretty sure that Apple is taking a hard look at this, but in all honesty, the best thing they can do is work with the IETF and other standards bodies to fix the real problem, aka the lack of security in DHCP. What they should not do is create some bizarro DHCP implementation that only works right with Mac OS X - based DHCP servers. They've correctly pointed out the simple way to disable the DHCP discovery of LDAP servers. They may consider turning that off by default in the future, but that's got implications of its own as well. Look, if you use DHCP, you need to read RFC2131 and understand the risks. You need to communicate with your peers and keep up on new techniques of discovering ways to subvert DHCP networks. You need to prod your DHCP server and client vendors to help get RFC 3118 ratified and implemented. Carrel didn't find anything "new". They found something that has always been there, but they hadn't thought about. So while they may get points for highlighting the computing world's reliance on an insecure protocol, they lose points for acting like they're some kind of hero. Because if Apple has a "massive security hole" because of DHCP, then so does Microsoft, Intel, and everyone else. And they always have. Posted by
John C. Welch
at December 11, 2003 10:32 PM |
TrackBack
I wonder if PC World would be willing to
print THIS article?
Posted by: DEMJ at December 12, 2003 10:41 AM Well, I did
post something similar in their forums, and emailed the author. I don't
think he wanted to hear about it, as it would interfere with his little
party.
Thank you for
your lucid explanation of the issue. Much better than most of the crap
coming form the so-called 'professionals'.
DD Posted by: DD at December 12, 2003 11:11 AM
Thanks, John. I
was thinking of posting on PC World's forums in a similar (although far
less lucid and technically accurate) manner. Your article was an excellent
examination of the issue and increased my understanding of the problems
involved.
Matt Posted by: Matt Fosberg at December 12, 2003 12:24 PM
I hope you were
criticizing his use of the apostrophe in "Mac's [sic] are not..." and not
"Suddenly it's gotten..."
I guess one out of two isn't too bad. Posted by: kevin at December 12, 2003 01:16 PM
It was for the
incorrect use in "Mac's" "it's" is a contraction for "it has" (or it is,
ed) and is therefore correct.
John Posted by: John C. Welch at December 12, 2003 01:57 PM
It is clear the article was flame-bait,
designed to spread FUD and garner hits from Mac users. Correct it and move
on ... The PC vs Mac debate will continue as long as the two markets
exist. It is a facile and pointless argument. As long as what you use
works for you, then surely that is all that matters ...
Posted by: Lachlan at December 12, 2003 07:23 PM
Well, honestly,
you're right about the pointlessness of the argument.
That's why I avoided it. What bothers me is less the finger pointing, and more the lack of understanding that this is a problem everyone has, and that barring changes to DHCP, we're going to have it for a long time to come. I was attempting to give people some insite into the nature of the problem, not solve it for them. John Posted by: John C. Welch at December 12, 2003 08:27 PM
If you want to
get in touch with the editor of PC World magazine, I can give you his
personal e-mail address. He's quite a nice guy, and he really likes Macs.
In fact the magazine is put together on Macs.
Just let me know and I'll reply privately. Posted by: Chip Winter at December 12, 2003 10:35 PM
What you wrote
about RIS and it's security implications are accurate enough as far as it
goes. Thing is, for a rogue RIS/DHCP server to cause the kind of damage on
a Windows network that a rogue DHCP server can cause on an Apple network
you have to:
- Set up a new AD forest - Somehow trick the end users into booting from their network card (requires a reboot and entering the CMOS setup). - Leave the rouge RIS server up long enough for the OS and your custom applications to install. - Keep the end users in question from complaining that they cannot access any printers, network applications, shared files, or the servers they are used to using. Once you have accomplished all that, you own however many Windows boxes you have compromised. Cool enough. But how much damage can you do to the rest of the network? - You can't use the machine to connect to the 'real' Windows servers because that machine doesn't have a trust relationship set up with the 'real' servers. - You can't easily compromise more boxes because you aren't benefiting from the trust relationship that would allow you to remotely log on to them. - You could launch man-in-the-middle attacks, but if you wanted to do that, you could do it more easily by using the rogue RIS server to do the packet sniffing without making your presence known as soon as the help desk starts fielding calls about missing printers and files. On an Apple network you need to: - Set up a rogue DHCP/LDAP server and leave it up long enough to compromise some boxes. - Take the rouge server down and use your compromised boxes to launch attacks against the 'real' servers. Yes, Microsoft uses DNS for AD and LDAP discovery, apparently just like Apple does. The difference, it would seem, is that on a Microsoft network you need to have a pre-existing trust relationship in place before the clients and the servers can make use of the services discovered. Apple's problem is that they are using an insecure service to advertise secure services without using additional authentication to ensure that the secure services offered are the correct ones. Posted by: Rick Damiani at December 13, 2003 12:59 PM
Not that I am unaware of how to set up RIS.
but...
What you wrote about RIS and it's security implications are accurate enough as far as it goes. Thing is, for a rogue RIS/DHCP server to cause the kind of damage on a Windows network that a rogue DHCP server can cause on an Apple network you have to: - Set up a new AD forest Aside from the fact that there are easier ways to do a Windows network than RIS, setting up a simple Active Directory forest is quite easy to do if you only want to set up one machine. MS makes this very easy to do, as does Apple. Why? because it makes sense. Why make things hard if you don't have to? - Somehow trick the end users into booting from their network card (requires a reboot and entering the CMOS setup). Actually, it doesn't on Dell laptops. Hold down a key, and pick from a Menu. But then again, in a situation where people use RIS to re-image new machines to get rid of the crap they come with, this happens a lot. - Leave the rogue RIS server up long enough for the OS and your custom applications to install. Set the DHCP server to only accept one client at a time. Then wait. Anytime you see a non-RIS client, kill their connection, ban their MAC address. If you're fast enough, they'll never really notice enough to alert IT. If you expect that your RIS will be totally automatic, you'll ignore it, because that's what you normally do. - Keep the end users in question from complaining that they cannot access any printers, network applications, shared files, or the servers they are used to using. Which applies to the Mac DHCP issue as well. Again, there are ways to hide this. But that's not the point of the article. Once you have accomplished all that, you own however many Windows boxes you have compromised. Cool enough. But how much damage can you do to the rest of the network? Um, I can DDOS the entire network. I can use it as a packet sniffer for unencrypted data, I can run SNMP or other network monitoring tools to check for other machines, I can see what machines aren't patched... - You can't use the machine to connect to the 'real' Windows servers because that machine doesn't have a trust relationship set up with the 'real' servers. Actually, the only thing that would prevent me from doing that is to not have a UID and password that lets me add machines to Active Directory. But, if you have servers that don't require Active Directory authentication for access, then that wouldn't apply anyway. - You can't easily compromise more boxes because you aren't benefiting from the trust relationship that would allow you to remotely log on to them. Nonsense. I can easily port scan them, patch scan them, and if they have RDP services open, see if they have a bad password i can hack. - You could launch man-in-the-middle attacks, but if you wanted to do that, you could do it more easily by using the rouge RIS server to do the packet sniffing without making your presence known as soon as the help desk starts fielding calls about missing printers and files. I can pay the janitorial staff off and have them collect password stickies far easier than either the Apple or MS exploits. But you seem to be missing the point of the article. However, onward we go. - Set up a rogue DHCP/LDAP server and leave it up long enough to compromise some boxes. Which would cause the same interruptions that a rogue MS DHCP server would have if you weren't careful. You also have to have Open Directory correctly configured on your machine, which can be just as hard/easy as an AD RIS server. You also have to then see what machines are bound to your system, and add them in WGM, then set up DA to explicitly authenticate against the Rogue server. That of course, is not as easy as you think to do remotely. - Take the rogue server down and use your compromised boxes to launch attacks against the 'real' servers. You haven't worked with Open Directory much, as shown by that statement. If you're talking about Jag machines, thanks to a piss-poor implementation of things, as soon as the OD server goes down, so does your login. This is because there are no mobile/cached accounts in managed Jag machines. (A real pain in the ass too). So you have to have clients running Panther. Now, even with Panther, you have to log into them once to create the cached account. So there's a bit of manual work. If you take down your server prior to that, then you're screwed. So, contrary to what you'd like to think, there's considerably more than "two steps" to pooching a Mac box. As well, on an Open Directory network, if the owned client isn't binding to the 'real' network, then you have no trust relationships with the other machines on the network, creating the same problems with accessing them that you do on the windows model. The first time the Mac reboots, and your server isn't there, it's going to bind to the real network, and your access is gone, unless you created local accounts. If you have local NetInfo accounts, they can't easily access the network accounts, since they aren't kerberized (under Panther), nor would they work with Password Server, (under Jag). Local Root doesn't equal network root, and if you have multiple domains, even root on one server isn't root for the domain. So the damage you can really do is just as limited, or not limited as it is on the Windows network. Probably more limited, since XP still ships with some dangerous ports open by default. But THAT'S NOT THE POINT. Cripes, anyone with knowledge and patience is going to crack your network. Whether you are talking RIS & DHCP, or Open Directory and DHCP, the real root of the problem is that DHCP is totally unauthenticated. On a wired network, you have no idea if the DHCP server you're connecting to is legit or not. At least on a wireless network, the SSID is a bit of a clue, and if you have the SSID hidden, then you have to manually connect, so it's hard to hide a wireless network. Read the article. DHCP, not RIS or Open Directory is the problem here, and it's everyone's problem. John You wrote: Apple's client software trusts DHCP when it ought not, and that is the real problem. Relying upon DHCP the way Apple apparently does, without requiring additional authentication, is a significant security issue. Pointing out a far-fetched and ultimately pointless 'exploit' that is possible with RIS fails to make the point that DHCP is at fault. First of all, if Apple is 'wrong' here, then go yell at the IETF, it's their standard, they allowed what Apple is doing. Pretty specifically, too. Go yell at MS, they *invented* DHCP. Any service that relies on DHCP is insecure. That includes RIS, Open Directory, or IP configuration assignment. All of them are. There is no way to have a standards - compliant DHCP service and require authentication. That would then be a non-standard DHCP implementation, and Apple would be (correctly) raked over the coals for it, just as MS was (correctly) raked over the coals for their non-standard Kerberos implementation in Active Directory. If Apple is wrong for not requiring DHCP auth. for what is a lot harder of a takeover than you would like to think it is. (Really, Open Directory ain't that easy. In fact, it's a damned pain in the ass, because you have to do some manual work to get the authentication to work properly. Try it sometime, you'll see. It's kinda broke.) Again, the relative difficulty or lack thereof, of pooching RIS or Open Directory IS NOT THE POINT OF THE ARTICLE. You may wish to review the ENTIRE article rather than jumping on what you evidently see as an attack on something you like. Quite honestly, even if RIS was easier to subvert, I'd STILL use it. It's too damned useful NOT to use it. Besides, it's not like you're running Open Directory OR RIS on the public internet, unless you're a fool. If you're a moron, then nothing will protect you. Again...the services an OS or environment uses with DHCP, (and it doesn't matter which services they are), are always going to be inherently insecure because DHCP is inherently insecure. If the world would get off it's ass, and push for full adoption and implementation of 3118, then we wouldn't be using an insecure protocol. But am I going to abandon an DHCP protocol that is useful? No. What I am going to do, is be a responsible network administrator, and not assume that I'm invulnerable because I have {insert stupid magic spell here} running. I'm going to be constantly checking for rogue machines, and illicit wireless networks all the time, because that's what a responsible network administrator does. Hell, these days, you have to deal with idiots bringing Linksys wireless routers from home ANYWAY, so catching rogue DHCP networks is almost a daily occurrence. But I'm sure you'll keep missing the point, and trying to veer this into a RIS vs Open Directory argument. So, to maybe save me some time. Dude...I used RIS as an EXAMPLE of a USEFUL DHCP service. It's one on the Windows side that I'm familiar with and like a LOT. It wasn't an attack on Windows, RIS, or MS. If you really read it, you'll see that. John
Microsoft invented DHCP? Maybe you should
take a look here:
http://www.more.net/technical/netserv/tcpip/dhcp.html
Microsoft lifted their TCP/IP stack from BDS Unix. In '93 when RFC1534 was written by Ralph Droms of Bucknell University, Microsoft was most concerned about interoperating with NetWare networks. I think you have your information wrong. Back to Apple: Service location should not equal service authentication. Period. In AD or in Windows NT domains your Windows NT-based client does not trust a Windows server just because it was able to find it. A trust relationship must be established, and that trust relationship is verified via challenge and response before access is allowed in either direction. If Apple's clients don't do this, it's not the fault of DHCP. After all, anyone who can read the RFCs *knows* DHCP isn't secure. BTW, you might want to take another look at RFC 3118. Key generation, storage, and security of the master key is a non-trivial issue that RFC 3118 doesn't address. It also fails to address the issue of mobile computers, a significant oversight. Implementation of this could create far more problems than would be solved by an authentication method similar to Microsoft's trust relationships. Posted by: Rick Damiani at December 14, 2003 02:30 AM
Microsoft invented DHCP? Maybe you should
take a look here:
http://www.more.net/technical/netserv/tcpip/dhcp.html
Microsoft lifted their TCP/IP stack from BDS Unix. In '93 when RFC1534 was written by Ralph Droms of Bucknell University, Microsoft was most concerned about interoperating with NetWare networks. I think you have your information wrong. It's BSD, and Information. Nitpicky, but it does matter. And no, actually I don't. Microsoft did most of the early work on DHCP, because I remember all the Unix twits wondering why we needed it when we had bootp. And other than maybe AT&T, and OS 9, *everyone* lifted their IP stack from Berkeley. Hence the name "Berkeley Sockets". Back to Apple: Of course, because you are trying to prove some point that someone who isn't me didn't write about here. Service location should not equal service authentication. Period. In AD or in Windows NT domains your Windows NT-based client does not trust a Windows server just because it was able to find it. It does for DHCP. It does if you're RIS'ing off it and locating it via DHCP. It blindly trusts that the Domain it's binding to is the one you think it is. You punch in a domain name, a UID and password, and you're bound. You have no way of verifying that the DC for that Domain is the right one, or that you're in the right domain even. you just assume that if it takes your UID, Password, and lets the machine bind, then it's good. You don't even have to pre-register the machine to the domain, that happens auto-magically. So, none of the trust relationships mean anything until you're bound. Period. A trust relationship must be established, and that trust relationship is verified via challenge and response before access is allowed in either direction. You show me where the client is verifying anything when it initially joins the domain. I join machines all the live long day, I only need three things: A domain name, a valid UID, and a valid password. I get my IP info via unverified DHCP. So, at joining, an Active Directory network is very insecure, and eminently stealable. Just set up a rogue with the right domain name, (easily found) and let *any* UID and Password bind a machine. Bang, you reboot, and you're owned. You don't get anything that says, "Binding to DC with host name (foo) at IP address (blah) verified by md5 hash (yadda). If Apple's clients don't do this, it's not the fault of DHCP. After all, anyone who can read the RFCs *knows* DHCP isn't secure. Rick...really man...you're really stretching. It's late. Go hug your family. it's late, and your spelling is going straight to hell (which I am correcting for this example! ed). You're never going to show how DHCP is magically safer on windows because you cannot. John
BTW, you might want to take another look
at RFC 3118. Key generation, storage, and security of the master key is a
non-trivial issue that RFC 3118 doesn't address. It also fails to address
the issue of mobile computers, a significant oversight. Implementation of
this could create far more problems than would be solved by an
authentication method similar to Microsoft's trust relationships.
Which is one reason why it's not a formal standard yet. As well, MS's networking model is not one that is really any better. It relies on total control of the client and the server, which an RFC cannot do. MS trust relationships totally break down for non-Windows machines, something an RFC cannot do. So using MS as an example only works if we all run Windows, which we don't. Of course, MS is the same company that released XP to set up local administrator accounts with no password on install. So forgive me if I'm rather unimpressed with their thunder and noise on security, because they have yet to show me anything real. John
John,
I'm trying to understand the particular issue here. I don't have extensive knowledge of LDAP or DHCP, but I'm under the impression there is a subtle difference between your article and Carrel's warning, one that has already been pointed out by posters but not really addressed by you. It's acknowledged that DHCP and LDAP are not secure, and this isn't an Apple specific issue. However, from what I can gather, even if a user has specified uid 0 attributes locally (like name and password), a remote LDAP server can override that setting because of the implementation in OS X. Does the LDAP specification require this? Are there any systems using LDAP that are not vulnerable to this? I'm having difficulty comprehending that an RFC would require the loss of local user control. thanks in advance, Tim Posted by: Tim Kelly at December 14, 2003 10:49 AM
Well, first, LDAP can be very secure when set
up. There are a number of things that you can do, to ensure that you are
only binding to the specific server you want to bind to, you can use SSL
for further security, etc.
As far as the DHCP requiring the loss of local user control . . well, that's what it's supposed to do. Take over the setting of network parameters from the user. It's called automation. The second part is maybe. First, by default, UID 0 on an Open Directory system isn't a part of Open Directory. It's a local Netinfo account only. You can of course override this, but normally, you don't use root to administrator Open Directory. You use an Open Directory administrator account. In fact, you don't want to make root an Open Directory account, because then it can't administrate local NetInfo accounts, since NetInfo can't play well with the new password setups. Now, In our scenario, you have a rogue DHCP server with the proper LDAP attributes set, and it's using DHCP to advertise itself as an Open Directory master, is there a danger? Theoretically, yes. Practically, no. For one, you couldn't afford to leave the DCHP server running for long, unless the network administrators were total idiots. It's just, as Rick and others have pointed out, too destructive to the network. You'd have to be set up to server DNS, router info, etc. So you can only leave the server running for short periods of time, or you have to be really active about kicking people off who you can't grab. If you're in an all Mac network, this is a little easier, if you're in a heterogenous network, this gets harder. Much has been made about the dangers of wireless networks here, but I would say they're less dangerous. For this to work from a wireless attack, you can't hide the SSID or wireless network name, unless it's the same as the legit name. You again, have to have a DHCP server that can act as a legit server, or people are going to start having troubles that will call attention to you. Even if the network name is hidden, it's still going to show up in any machine that connects to it. Again, you're going to be pretty obvious here. Then you have to serving the correct address range, on the correct subnet, and not be replicating any other addresses on that subnet, or you get noticed. Finally, you have to be close enough to be stronger than the base stations inside the network you want to subvert, as if you have two base stations with the same SSID, the one with the stronger signal tends to get picked first. Even with a big antenna, you still need line of site to the building for a good signal, and you then have to deal with building construction, etc. I've been dealing with RF for almost two decades now, it's a little trickier to set this up than people think, because higher frequency signals get blocked by everything. So actually *doing* this on the stealth is pretty hard. On a wired network, hiding is a little easier, but getting connected is not. However, you can set up a wired DHCP server out of some pretty small parts, so it's probably easier to hide than a wireless one. So now, you have your rogue DHCP/LDAP server in place. Now what? Well, you wait. You have to find a client that's going to meet some fairly specific criteria. For one, it has to not be already bound to an Open Directory domain. If it has, then this is like Windows Active Directory networks, it's looking for a specific DC, or DCs, and you're not them. Next, it has to be booted on the same subnet as your rogue server. You can't just take over a system with this as you can with other remote exploits. It has to be booted while your system is up. Otherwise, nothing happens. You have to have the user name for the bad UID 0 not be root, as then you get overridden by the local NI database and you're out. Now, you have a machine. What can you do with it. Well, not much. The things that Rick pointed out about Windows Active Directory networks keeping you from doing much also apply here. First of all, if it's a Panther client and a Panther server, you are not doing anything to the network. That's all Kerberized, and you aren't cracking Kerberos anytime soon. If you can't get tickets, you can't access any Kerberized services. Now, if the services are not Kerberized, you *may* be able to crack the passwords, but again, not very easily, unless it's all old school NetInfo crypt, in which case, 5 monkeys, ten minutes. You still won't have a user that can do much on the network, unless you get really lucky. If we are talking about Jaguar clients, the first time they reboot, and your server isn't up for them to bind to, you aren't doing anything anyway. Jag doesn't cache logins for mobile users, so without your server up, it's going to just stall on boot. (Jag sucks SO bad that way.). Then what happens? You get noticed. So you have to have panther clients if you want to not have to leave your server running. So at best, you have a machine that can make a damned nuisance of itself, and you can get data from that machine, and maybe use it to subvert others, but that's it. Oh, and if on a panther client, they're using the Active Directory plugin? That requires you to set up a manual authentication and contact path. So this exploit won't work then, you won't be on the path. I've also found that to get Open Directory binding working correctly, you have to do the same thing. The automatic authentication path and contact path stuff doesn't really work for beans. If you have manual paths set up on Jag, this won't work either. This isn't a Code Red - scale thing, where . It's pretty damned tedious to get working, it's going to be pretty damned fragile to KEEP working. It's something to be concerned about, and if you don't need DHCP LDAP directory services, turn the bloody thing off, as per Apple's instructions. But as remote exploits go, this is far more theoretical than anything else. John John, According to your statement about "automation," LDAP's usage places a higher authority on remote servers than local user preferences. I asked specifically if this is required by LDAP. Your response was regarding DHCP, but DHCP can be limited to services that do not include LDAP. I may be wrong, but I'm pretty sure there are other operating systems that place local user preferences ahead of LDAP info. I'd be stunned to learn that an OS vendor would accept an RFC based protocol as a higher authority than their own authentication process. A local preference on UID 0 should always override a centralized server, and authentication on a remote UID 0 should only be accepted if it matches the local preference or if there is none (and by inference, defers to LDAP and DHCP). LDAP itself may not be secure, but as several people have pointed out, the problem with Apple's implementation is that they trust it over other secure resources like the local user's NetInfo Manager database. Tim Posted by: Tim Kelly at December 14, 2003 04:03 PM
Let me backtrack a bit from my statement "A
local preference on UID 0 should always override a centralized server, and
authentication on a remote UID 0 should only be accepted if it matches the
local preference or if there is none (and by inference, defers to LDAP and
DHCP)." and drop the last clause:
A local preference on UID 0 should always override a centralized server, and authentication on a remote UID 0 should only be accepted if it matches the local preference. I was reviewing some of how Open BSD handles failed authentication and a few threads that discussed the results of empty preferences for authentication and realized I was being too broad with my statement. Tim Posted by: Tim Kelly at December 14, 2003 05:29 PM
John:
One thing that's missing in your comparison between RIS and Open Directory is that for your RIS exploit to work you have to reinstall the OS. That's bound to be noticed, especially in large orginazations that have custom apps installed as part of the RIS image. For the Open Directory exploit to work, all you have to do is wait for an existing client using the overly trusting default config to boot up and find you. Once you have root, you can install backdoors and keyloggers, take your server down, and comprimise the rest of the network at your lesure. If you use the 'correct' DNS/Net/Subnet (not hard information to discover) they might not even notice for a while unless the unexpected disk activity alerts them. Unless the end user in question is religous about checking thier checksums and monitoring thier running processes, they won't know they've been rooted until after the damage is done. You point out that it's easy to work around the problem. The existance of mitigation stratigies dosn't really address the core issue, which is the fact that the exploit exists in the default configuration. As Tim points out, the spec may allow such configurations. It's extremely unlikely that the spec *requires* clients to exhbit this level of trust. Your reasoning on wireless clients is correct enough for wireless clients that never leave the office, provided the end users know how to check the SSID and bother to do so. On my PowerBook, the only time I check the SSID is when things ain't working. Same as with my Windows clients. I suspect my end users are even less dilligent in that regard than I am. For those wireless clients that do roam the issue is different. Go to any trade show and set up an insecure, open access point and you'll get dozens of Wi-Fi clients trying to connect. (I have done this, I know it works). Or go to any public hotspot. Folks in these environments either don't notice the 'alien' SSID, or they *expect* the SSID to be a different one than the one they are using. Once I've installed my rootkit/keylogger/spam zombie/whathaveyou, I don't even care if the logon I used is not cached. My exploit code will let me know where they are when they next connect to the 'net, and it will let me know what logons are valid. Once your box has been 0wn3d, it stays 0wn3d. Posted by: Rick Damiani at December 14, 2003 07:25 PM
You didn't really answer my question, as
far as I can tell. You're rehashing the process, rather than specifically
addressing if the exploit exists. According to the warning by Carrel, "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." This
contradicts your statement "You have to have the user name for the bad UID
0 not be root, as then you get overridden by the local NI database and
you're out."
There's some argument there, and I'm not sure that Carrel did a good job of explaining. First...you can have multiple root users. one one the local domain, one on the Open Directory Domain. What you can't have are two users with the same short name. The local UID 0 name is always root, so you, as the attacker, have to use something else, otherwise, your root won't work. now, you don't have to make UID 0 have a short user name of root. That's convention, but not required. So what you would need to do is simply change the username for UID 0. According to your statement about "automation," LDAP's usage places a higher authority on remote servers than local user preferences. I asked specifically if this is required by LDAP. Your response was regarding DHCP, but DHCP can be limited to services that do not include LDAP. I may be wrong, but I'm pretty sure there are other operating systems that place local user preferences ahead of LDAP info. There are indeed. but they don't use Directory Services the way that Novell, MS, and Open Directory do then. If you allow the local user to easily override all the settings, then you don't have any way to keep them out of dangerous ones. I'd be stunned to learn that an OS vendor would accept an RFC based protocol as a higher authority than their own authentication process. A local preference on UID 0 should always override a centralized server, and authentication on a remote UID 0 should only be accepted if it matches the local preference or if there is none (and by inference, defers to LDAP and DHCP). LDAP itself may not be secure, but as several people have pointed out, the problem with Apple's implementation is that they trust it over other secure resources like the local user's NetInfo Manager database. LDAP is secure if implemented securely. DHCP is not, because there's no way to do so and have it be DHCP. You're kind of not getting how a managed network works. If you have a directory system, then the Directory authority has to have 'more' authority than the local user, otherwise you can't manage the machine. The local user can simply say "bugger off" and you're stuck. Secondly, anyone calling a NetInfo database secure doesn't know much about NI. It's not secure, and it's native crypt passwords are just as insecure as NTLMv1. The problem here is that this isn't an exploit. It's a caution. If you run your network correctly this will never bother you. If you don't, then you are going to get owned anyway by other, easier methods. But yeah, if you're running any kind of directory system, the directory takes precedence over the local prefs, it has to, otherwise manageability goes away. John
Let me backtrack a bit from my statement "
A local preference on UID 0 should always override a centralized server,
and authentication on a remote UID 0 should only be accepted if it matches
the local preference or if there is none (and by inference, defers to LDAP
and DHCP)." and drop the last clause:
A local preference on UID 0 should always override a centralized server, and authentication on a remote UID 0 should only be accepted if it matches the local preference. I was reviewing some of how OpenBSD handles failed authentication and a few threads that discussed the results of empty preferences for authentication and realized I was being too broad with my statement. Then how do you keep anyone with local administrator access from locking out the directory administrators? Being able to allow for local administrators while still maintaining control is a good thing. Especially for any laptop users, you almost have to if you wish to keep your sanity. Computers may count in binary, but administering them is rarely so black and white, and you can't realistically say things like "never" and "always" because you're going to get bit by it. John
One thing that's missing in your
comparison between RIS and Open Directory is that for your RIS exploit to
work you have to reinstall the OS.
It depends on how subtle you want to be. You can also just randomly erase drives and be done with it. Being annoying is still exploiting the weakness. But then, why would you set up a machine to be RIS'd if you weren't going to do that anyway. That's why a bad RIS server would be evil. It would be behaving in an expected fashion. That's bound to be noticed, especially in large organisations that have custom apps installed as part of the RIS image. Only if the application is big enough to take any time. You can do a lot with a series of small applications that are under a meg in size. they wouldn't be noticed at all. Ping can do a lot of damage, and it's quite tiny. For the Open Directory exploit to work, all you have to do is wait for an existing client using the overly trusting default configuration to boot up and find you. Assuming that you're not discovered, are physically on the local subnet, or have a powerful enough wireless signal with the correct SSID to punch through exterior walls, and are able to devote enough time to know that a client that is not already bound to an OD domain has booted and is now talking to your server. So you pretty much have to ride the server continuously. Not so simple. Once you have root, you can install backdoors and key loggers, take your server down, and compromise the rest of the network at your leisure. Um...right. Because you're going to be able to pooch the entire domain structure and authentication paths how? Once your server is down, you don't exist. As soon as the machine binds to a real domain, your user has no domain authority. Key logging won't do you any good if the applications don't run, so you can't attach them to the user login. that means they have to be startup items, and setting those up again, takes time. That's why neither this nor my hypothetical RIS attack are worth the effort. They take far too long, are far too risky for what is too little effort. Even if you get someone's kerberos password via key logging, that doesn't mean much. If your 'evil apps' don't authenticate correctly, they're limited in their ability to do more than be a nuisance. There's far better ways to do a network. If you use the 'correct' DNS/Net/Subnet (not hard information to discover) they might not even notice for a while unless the unexpected disk activity alerts them. Unless the end user in question is religious about checking their checksums and monitoring their running processes, they won't know they've been rooted until after the damage is done. The same applies to any kind of trojan attack. Hell, if you want to do that, you don't have to do any LDAP work. Mac users are morons about virus checking, you could trojan most Mac users without trying hard at all. Just create some idiot application that removes metal from windows, and you'll be on a thousand Macs by Tuesday. You point out that it's easy to work around the problem. The existence of mitigation strategies doesn't really address the core issue, which is the fact that the exploit exists in the default configuration. Then really be safe. Don't use any DHCP at all. Don't allow it on your network. Period. That avoids the entire issue. As Tim points out, the spec may allow such configurations. It's extremely unlikely that the spec *requires* clients to exhibit this level of trust. Actually, it does. A DHCP client is required, by the spec to blindly trust the DHCP server for all DHCP - configured services. There's no authentication in either direction. Of course, it was never designed with modern network setup in mind, and it's been in need of a rev for a while. Unfortunately, the mood of the IETF seems to be "IPv6 will make everything perfect", so getting anything done wrt IPv4 is very hard. Your reasoning on wireless clients is correct enough for wireless clients that never leave the office, provided the end users know how to check the SSID and bother to do so. On my PowerBook, the only time I check the SSID is when things ain't working. Same as with my Windows clients. I suspect my end users are even less diligent in that regard than I am. Apple does make it easier to check at least. getting the name of your current SSID on some windows setups is painful comparatively. For those wireless clients that do roam the issue is different. Go to any trade show and set up an insecure, open access point and you'll get dozens of Wi-Fi clients trying to connect. (I have done this, I know it works). Or go to any public hotspot. Folks in these environments either don't notice the 'alien' SSID, or they *expect* the SSID to be a different one than the one they are using. Once I've installed my rootkit/key logger/spam zombie/what have you, I don't even care if the logon I used is not cached. My exploit code will let me know where they are when they next connect to the 'net, and it will let me know what logons are valid. Once your box has been 0wn3d, it stays 0wn3d. Well, no, actually, it doesn't. as well, you have to get the client to *boot* into your system. Most folks just put stuff to sleep, so your network will get ignored. Then you still have to ride your server to see if someone has bound to it. Then you have to get your stuff loaded. You also have to write it so it only runs on port 80, because that's the only thing that you can guarantee will work. you also have to hide the startup process of it, etc. You also have to hope they always are on wireless or Ethernet, because if you try to establish a connection otherwise, the modem starts to dial. and your chances of getting busted go way up. If they are on a corporate LAN doing any kind of network DNS monitoring, you're going to get noticed. I really don't get why you locked on to the whole RIS thing, because it was just an example. Again, if DHCP were properly authenticated, and allowed for user notification of server connections, we wouldn't be having this conversation at all. John
I locked on the RIS thing because you claim
that it's of equal severity to the Open Directory problem. It ain't. Your
RIS exploit won't allow a hacker to backdoor an existing machine without
reinitializing it - something everyone involved will notice. Not because
they will notice the things you have added. They will notice the things
you *haven't* added and *cannot* add because you can't add them until
*after* you've penetrated their system. The LDAP/DHCP exploit allows you
to add stuff to an existing system in a way that the system's owner won't
be able to easily see, without removing stuff that's already there. That
makes it a lot more dangerous.
The DHCP spec requires that clients accept the information they are presented with. It does not require the clients to act on that information to grant network users remote access to the machine that accepted that information. That is the problem with Apple's implementation. That no other OS vendor is having this difficulty makes it extremely difficult to support that the problem is a protocol issue, rather than a default-configuration issue. i.e. If I were to manufacture an automobile that was 15' in width, I would not be justified in claiming that existing roads were the reason my car could not be operated safely when other traffic was present. After all, no other manufacturer is suffering from that problem. As for the wireless bit: Without getting into details, let me re-state that I have been to trade shows, I have set up open wireless networks connected to no useful services while I was there, and I have observed them granting IP addresses to Apple clients. I am not speculating that this works. I *know* this works, as I have personally observed it. It's so common that it actually can be quite a nuisance at larger shows. It's not much of a stretch to assume that this behaviour is not confined to the exhibitor's hall of convention centers. As for the difficulty of writing a root kit that will satisfy our requirements - there really is no need to go to all that trouble. Scripts and the like can watch your server for you easily enough. Root kits are also pretty easy to get your hands on once you know where to look. Rooted once is rooted until the disk is wiped. Until script kiddies stop trading kits written by others, that will just about always be the case - even if the login originally exploited is erased. Some kinds of exploits won't even require that level of complexity i.e. how often do you check your hosts file? Before every on-line transaction? Why do I keep following up on this? Because it's linked on the front page of Macintosh. I'm concerned that other, less sophisticated Mac users will read your disclaimer and discount the risk associated with this vulnerability, as Macintouch seems to have done. I get way too much traffic from spam zombies as it is. I really don't want more of it from the artist community. Posted by: Rick Damiani at December 14, 2003 11:51 PM John, is consistent with Carrel's statements that the attacker can insert any name for UID 0, regardless of what the local user has specified, and even if root is disabled. The emphasis is that UID 0 has the privilege, not "root." "LDAP is secure if implemented securely. DHCP is not, because there's no way to do so and have it be DHCP."
You state: "You're kind of not getting how a managed network works. If you have a directory system, then the Directory authority has to have 'more' authority than the local user, otherwise you can't manage the machine. The local user can simply say "bugger off" and you're stuck." Also, you ask: "then how do you keep anyone with local administrator access from locking out the directory administrators? Being able to allow for local administrators while still maintaining control is a good thing. Especially for any laptop users, you almost have to if you wish to keep your sanity." With OS X, we're still talking about a consumer desktop operating system, not a pure network OS (or even one that is focused on being in a managed network). Having an authentication scheme that places higher authority to remote servers over the local user's preferences is contrary to that, and as far as I can tell, not standard industry practices in other BSD implementations (although I am not able to find specific documentation as such, just descriptions of authentication processes). It is, however, consistent with Apple's zero configuration philosophy and their "We know best" approach (I'm a longtime Apple user and MacOS programmer, btw). I believe that this is only the first of many methods to exploit this decision. Tim Posted by: Tim Kelly at December 15, 2003 06:57 AM
I locked on the RIS thing because you
claim that it's of equal severity to the Open Directory problem.
Re-read the paragraph. I make no claims as to severity. I use it as an example of a DHCP service that can be compromised thanks to the lack of authentication in DHCP. And if I'm guilty of glossing over the work involved in a RIS attack, you seem to have no problem in glossing over the actual work involved in the LDAP attack. you reduced it to two steps, and we both know there's more to it than that. Your RIS exploit won't allow a hacker to backdoor an existing machine without reinitializing it - something everyone involved will notice. Which is the only time you'd be using RIS. So it would be behaving as expected. In a fully automated RIS operation, (a damned handy thing it is), once the RIS starts, you go do other stuff...that's the idea, unattended OS installs. Alas, you don't know for sure that you're talking to the correct RIS server. The LDAP/DHCP exploit allows you to add stuff to an existing system in a way that the system's owner won't be able to easily see, without removing stuff that's already there. That makes it a lot more dangerous. Maybe. I have yet to see anyone even do it in a test situation with the "1-2-3 you're my bitch" ease you insist that it has. It's a very manually intensive pain in the ass exploit, and not one that gets you a lot of return. The DHCP spec requires that clients accept the information they are presented with. It does not require the clients to act on that information to grant network users remote access to the machine that accepted that information. That is the problem with Apple's implementation. Apple's implementation is in line with the spec. They're not extending it in any way. If they were, you'd have a point. But they aren't. They're using it in a legitimate manner, in the way it was designed. Now everyone discovers that DHCP has no security. Duh. And that anything based on DHCP has no security. Duh. Where's the newness here. That no other OS vendor is having this difficulty makes it extremely difficult to support that the problem is a protocol issue, rather than a default-configuration issue. i.e. If I were to manufacture an automobile that was 15' in width, I would not be justified in claiming that existing roads were the reason my car could not be operated safely when other traffic was present. After all, no other manufacturer is suffering from that problem. Because you'd have a totally different automobile. That's not even close to what Apple's doing. Apple's using the standard correctly. it's in line with what the standard allows. Unfortunately, the level of mobility and access that laptop users now have was not even close to reality, and like anything that has not kept up with the times, the weaknesses of the standard are coming to the front. That still doesn't make Apple wrong here. Nor is anyone else using DHCP. It's an insecure configuration standard, and until it's fixed, these potential problems exist. Without getting into details, let me re-state that I have been to trade shows, As have I and almost anyone who's in IT. I have set up open wireless networks connected to no useful services while I was there, and I have observed them granting IP addresses to Apple clients. How did you know they were Macs unless you were at a Mac-heavy show, or you watched them connect. More correctly, you watched a DHCP server handing out configuration information to DHCP clients. Congratulations, you saw the standard work. You also noticed that at no time was your server required to identify itself, or authenticate in any way, shape or form to any client, regardless of the client environment. Thanks for proving my point. I am not speculating that this works. I *know* this works, as I have personally observed it. It's so common that it actually can be quite a nuisance at larger shows. It's not much of a stretch to assume that this behaviour is not confined to the exhibitor's hall of convention centers. What, you've verified the correct operation of DHCP? Because that's all you've done here. You've implemented one of the most widely used internet standards and seen it work. You've seen that it's totally insecure. You were also, as the person running the DHCP server in a great position to run a network packet analysis utility, and start sniffing traffic for passwords, user ids, etc. You didn't need LDAP, RIS or anything else. You were in a great position to analyze what companies are using VPNs and which ones aren't. You could have created a list of MAC addresses, mapped them to the companies so that you could insert yourself in the network easier. None of this required LDAP or anything else. You also discovered that people with wireless access look for networks to connect to. If you did it on a Mac, you also know that Apple allows you to easily differentiate from computer- to - computer networks and base station - run networks. That's one of those "user feedback" things so that you can tell if you are on the network you want to be on easier. As for the difficulty of writing a root kit that will satisfy our requirements - there really is no need to go to all that trouble. Scripts and the like can watch your server for you easily enough. Root kits are also pretty easy to get your hands on once you know where to look. Rooted once is rooted until the disk is wiped. Yes...windows users are well aware of this. Happens to them all the time, and the difference is, they can't just click on a checkbox to be safe for 99% of them. Again, you keep speaking of this as though it's a three second hack, and it isn't. It *requires* the target to boot in a location where your server can see them. It *requires* you to then take action to get your root kit on the client, start the processes, and insert them into the startup configuration so they always start. That's not a two second process. It's not evilly difficult, but it's far harder than most Windows remote hacks. Until script kiddies stop trading kits written by others, that will just about always be the case - even if the login originally exploited is erased. Some kinds of exploits won't even require that level of complexity i.e. how often do you check your hosts file? Before every on-line transaction? Oh look, the internet is a dangerous place. No fooling. But you know what? Do you diff your Registry every morning on boot? Before every online transaction? Regardless of platform, a minor amount of due diligence keeps you happy. It's no different than owning a car, a house, or anything else more complex than a rock. Everything takes maintenance. You lock your car doors, you change the oil, etc. If you own a computer, you keep up with the things that affect your platform. One real problem with windows is that you can't trust what the update checks tell you. Slammer is a great example. Depending on which MS update check you used, you could have been told you had the correct patch applied, even though you did not in fact have that patch applied. MS has a VERY real problem with patch management, even Ballmer says it's one of the biggest problems that Windows has in keeping secure. You have to check your patch status with multiple tools to be sure that you're really patched correctly. Why do I keep following up on this? Because it's linked on the front page of Macintouch. I'm concerned that other, less sophisticated Mac users will read your disclaimer and discount the risk associated with this vulnerability, as Macintouch seems to have done. Well, your concern is appreciated, but where do I tell people to ignore the problem? I don't. I tell them to be aware that DHCP is totally insecure, and that anything riding on DHCP is similarly insecure, and that they need to be aware of this. That's not discounting it. It's saying don't panic. But then I ALWAYS say "Don't panic". Panic prevents clear thinking, and reasoned reaction, and those are the two things that HAVE to drive your reaction to a problem. So I DO tell them to proceed calmly and logically. I get way too much traffic from spam zombies as it is. I really don't want more of it from the artist community. Riiiiiight...those damned artists...dude...that last sentence makes no sense, and you know this. you really gotta stop posting stuff so late ;-) John
The trade shows I set things up at are
attended by educators, so there are a lot of Macs. When a client uses a
client ID of 'PowerBook' it's pretty clear what kind of computer it is,
even without bothering to check the manufacturer ID from the MAC address.
When you wrote "Nor is anyone else using DHCP. It's an insecure configuration standard, and until it's fixed, these potential problems exist." Did you really intend to say that no one else is using DHCP? 'cause that's pretty obviously wrong. If you meant to say that no one else is using DHCP to authenticate LDAP servers, without requiring any out-of-band information, then you'd be correct. Perhaps Apple should take a lesson from that. As Mr. Kelly pointed out above, Apple's zero-configuration philosophy is to blame for the unfortunately chosen defaults, not the IETF. Posted by: Rick Damiani at December 15, 2003 01:41 PM John, Page 24 of RFC 2251 describes the unsolicited message that a LDAP server can send, which is to inform the network that it is shutting down and to use an alternative server. William Carrel is pretty inundated at this point, so I haven't been able to talk to him about whether or not OS X will transparently do a discovery process for alternative LDAP servers upon receiving the shutting down message from the DHCP listed LDAP server. I'm going to posit that it's script kiddie level to obtain the appropriate info from the true LDAP server and forge a packet that mimics it. I'd also posit it would be fairly easy to mimic the true LDAP server and relay information to clients that connect to the rogue LDAP server. This would make notice of the rogue LDAP server quite difficult because with the exception of a small change in the UID 0 info, everything else is just like its supposed to be. If OS X does an automatic discovery process upon receiving a shutting down message, the user would not have to reboot to be rooted. Perhaps you can give counter examples or points to indicate where I'm missing something. I'm in agreement that the RFC for LDAP can allow the behavior OS X is displaying. I can not, however, find anything that says it is _required_. It tends to infer that one should not trust the information blindly. You have made a convincing case that LDAP should not be trusted. The rest of us are trying to point out that Apple has done so over its local user settings. Tim Posted by: Tim Kelly at December 15, 2003 02:05 PM
Historically, there were a number of DHCP-related
security problems on Linux . Just to mention a few:
https://rhn.redhat.com/errata/RHSA-2002-162.html https://www.redhat.com/support/errata/archives/rh50-errata-general.html#dhcp See www.redhat.com for more links.
There is nothing new in dhcp -related
security problems. Posted by: Peter at December 15, 2003 03:32 PM
Thought I'd chime in and address some of what
I've read here, and provide some other random thoughts.
In most responsible deployments of LDAP that I've seen, clients have needed to see a signed SSL certificate on the server in order to trust it for authentication information. Your deployment mileage may vary. Apple also has this support built into their LDAPPlugin, it is just turned off by default. I don't want to sound like I'm defending that guy at PC Magazine (because it's pretty obvious he was just trying to draw page views rather than expound any sort of rational thought). But Windows, to its credit, does ask you at first whether you really mean to associate with the supposed authorities on the network or not. And, unless I am mistaken, there is some crypto keys that are exchanged at that point to make sure that the next time it goes fishing for the domain controller, it actually is legitimate. This isn't to say there aren't 10 other remote access holes in Windows discovered every week due to some poor design decisions that were made early on, but the kids over in Redmond did actually get this part right. At the risk of rehashing the "philosophical details" section of the advisory, the problem here has to do with what DHCP is being trusted for. In the case of trusting it for network information, in a worst case scenario your network connection will be man-in-the-middled. But man-in-the-middle attack risks are inherent in nearly any network configuration scenario. This is why we have SSL, to authenticate that the other end is who we think it is and no one else. So you haven't really lost anything that you had originally in the first place. On the other hand, Apple was trusting DHCP for login/authentication and mount point information. The worst case scenario for misuse of these settings is much worse than a man-in-the-middle attack, hence my advisory. The fact that LDAP is being used for the attack that I pointed out is really tangential, the only thing to note is that by default the LDAP Plugin does no other authentication that the server is somehow legitimate. (It could ask the user, certificate approaches seem inadequate since I can't think offhand of how you would know if a given certificate was really authorized by a given network.) There is a similar attack vector using a DHCP response with a NetInfo server field, although that seems to be turned off by default in some configurations. (It seems to depend on what upgrade path people followed.) I have no idea as to the behavior of LDAP Plugin when it is given a shutting down message from the LDAP server. There is no room in that message for giving the name of another LDAP server to try. The list of other LDAP servers to try could possibly be established by returning more than one ldapServer field in the DHCP exchange. While people make lots of noise about rogue DHCP servers being instantly detected, the truth is that you can setup a rogue DHCP server without disrupting the proper functioning of a network. (Take out some leases from the real DHCP server and then hand them out to victim clients. Hand out NATed addresses and NAT traffic through legitimately leased addresses. Etc.) Most networks do not have adequate NIDS to detect another DHCP server serving up requests, and errors from the legitimate DHCP server are stored into log files that are rarely read. I've yet to see someone bother to stick ACLs on a switch to block DHCP server replies from all ports except for the one legitimate one. Of course, some people are better than others at mitigating these risks, but anyone with reasonable exposure to corporate or higher-ed IT knows that these environments generally are not given adequate resources to tackle these sorts of issues to this sort of detail. Mainly because DHCP usually only represents a man-in-the-middle risk and is cheaper to mitigate through use of SSL than flogging the network switches with extra ACL work and buying some sort of NIDS. As far as ordering of lookups goes: In my testing, the values coming from the LDAP server were given greater precedence than the local NetInfo store by default. That means that lookups for accounts first go to the LDAP server before they move to looking up locally. Even if this wasn't true, as has been pointed out, you can just pick a different short username. I don't think its quite right to point the finger at the RFCs (and the IETF working groups that created them) when someone implements them in a way that presents a security problem. One could implement an FTP server that accepted any password as valid and still be within the legitimate confines of the RFC for the protocol. It would not be particularly wise and people would probably complain about the implementation. But it would certainly be the implementor's fault, not the RFC or the group that wrote it. (An absurd example I know, but I think it's a shades of gray issue. I think the RFC authors were cognisent of the potential misuse and did take the time to warn of it in the RFC. Woe be to the person who doesn't heed such warnings.) This is just my opinion, your mileage may, of course, vary. My apologies for rambling on quite so long here, hopefully I'm not 300 miles off-topic. -- William A. Carrel Posted by: William A. Carrel at December 15, 2003 04:07 PM
William,
Welcome to the discussion! From Apple's documentation: In summary, lookupd calls Open Directory when its local cache and NetInfo cannot find an answer. Whether Open Directory is called by lookupd or called by another application, Open Directory always searches its local NetInfo database first and then conducts other searches using whatever search technology it has been configured to use. Most of the time, that search technology is LDAP. But you've found: Am I interpreting this correctly? Additionally, to support my inference that Apple would likely implement a relook up of LDAP servers upon receiving a shutting down message: From documentation : "Mac OS X 10.2 and later include support for Rendezvous, Apple’s implementation of zero-configuration networking. Rendezvous makes the dynamic discovery of file servers and printers much simpler and truly more plug-and-play. Using Rendezvous, computers can create ad-hoc networks over Ethernet or Airport connections." From the first reference: From http://developer.apple.com/darwin/projects/opendirectory/, it appears Rendezvous uses Open Directory for discovery purposes, and since Rendezvous is dynamic, I'd be willing to make the leap that Open Directory is dynamic as well. The overall point is that a shutting down message could induce an OS X box to do a rediscovery and at that time get the rogue LDAP server. In that case, it's not necessary to boot into this environment - the movement into the environment by the attacker could be all that's needed. Could this be tested by setting up the scenario you used to test this originally, but shutdown the correct LDAP server, bring up the rogue LDAP and DHCP afterward, and then try the login without rebooting? The idea being to test if a legitimate shutting down message triggers a rediscovery and if it does, can the rogue DHCP interject itself at that time, without the client rebooting? I could be way off, of course. To both John and William, I appreciate the efforts you're putting forward in discussing this issue. Tim Posted by: Tim Kelly at December 15, 2003 05:27 PM
The trade shows I set things up at are
attended by educators, so there are a lot of Macs. When a client uses a
client ID of 'PowerBook' it's pretty clear what kind of computer it is,
even without bothering to check the manufacturer ID from the MAC address.
So by that logic, to avoid you hacking my
system, i just have to name it "HP Omnibook"? Um ..considering my article was about using DHCP, I don't even see why you would assume that. If you meant to say that no one else is using DHCP to authenticate LDAP servers, without requiring any out-of-band information, then you'd be correct. I didn't say that either. What I meant was that Apple isn't wrong for using the spec the way it was designed. Nor is anyone using DHCP the way it was designed, wrong. Again, if the spec is broke, change the spec. Apple has shown, over the last 5+ years, that they are much better about playing to spec than MS. Good or bad, it means you can anticipate how their implementations of IETF standards will work. Secondly, when you *first bind to a domain*. The *first time* mind you, the initial binding, you have no way to verify that the server handling your binding is in fact a member server of that domain. You tell the machine "become a member of Domain "foo", enter a UID and password and you're in. In fact, the only authentication is the client verifying it has the right to join the domain. That's not even remotely secure. That's the server being picky, which can be turned off. Give everyone the right to add machines to a domain, set yourself up as a rogue DC, and while you can't stay up for too long, you could use GPOs to root a client just as fast, if not faster than an Open Directory server, because Apple doesn't have GPO equivalents with anything close to the sophistication of Active Directory. Which is actually quite sucky IMO. GPOs rule. Perhaps Apple should take a lesson from that. As Mr. Kelly pointed out above, Apple's zero-configuration philosophy is to blame for the unfortunately chosen defaults, not the IETF. Nonsense. They implemented an IETF standard according to the standard. The standard happens to be totally insecure, and is configuring more machines on more platforms than you can shake a stick at. A rogue DHCP server has always been a great way to start an attack on a network, yet it doesn't seem to happen very much, if at all. hmmm... John John, In theory, no. but here's a test. Go do it on a real world network. It's a lot harder to implement than you think. Page 24 of RFC 2251 describes the unsolicited message that a LDAP server can send, which is to inform the network that it is shutting down and to use an alternative server. Again, actually do it, not in a lab. Do it in the real world. Labs are easy, theory's easier. Do it in a real world situation. Report back your results. William Carrel is pretty inundated at this point, so I haven't been able to talk to him about whether or not OS X will transparently do a discovery process for alternative LDAP servers upon receiving the shutting down message from the DHCP listed LDAP server. That's only going to work after it's bound. I'm going to posit that it's script kiddie level to obtain the appropriate info from the true LDAP server and forge a packet that mimics it. I'd also posit it would be fairly easy to mimic the true LDAP server and relay information to clients that connect to the rogue LDAP server. This would make notice of the rogue LDAP server quite difficult because with the exception of a small change in the UID 0 info, everything else is just like its supposed to be. Cool, so you should be able to root an OS X network before Xmas. I await a full report. If OS X does an automatic discovery process upon receiving a shutting down message, the user would not have to reboot to be rooted. Perhaps you can give counter examples or points to indicate where I'm missing something. First...you can't issue a shutdown unless you're already using root privileges. That requires a machine to be *booted* while your evil server is running. You have to run an unnoticed rogue DHCP/LDAP server that conforms to Apple's OD schema to do this. You have to leave it in place long enough to have a machine boot with your LDAP server in place, as a primary Open Directory DC. then you have to root it. Getting a machine to be an unnoticed DHCP/LDAP server is *not* trivial. It's tedious, and rather difficult to do at random. So it would almost have to be an inside job. At that point, just gain physical access, it's far simpler. Ten minutes with a CD, and you really own the box. Why go through all the trouble? I'm in agreement that the RFC for LDAP can allow the behavior OS X is displaying. I can not, however, find anything that says it is _required_. That's because I'm not talking about the LDAP RFC. You are. I've been talking about the DHCP RFC. That's why you're missing my point. It tends to infer that one should not trust the information blindly. You have made a convincing case that LDAP should not be trusted. I'd like to know how I did that when I was talking about the insecurity of DHCP. LDAP is designed to have good security. It's part of the spec. It's not *required*, which I think is a mistake, but SSL, Kerberos, it's all there. But I'm not saying that LDAP is insecure, and always will be. that would be incorrect. I'm saying that DHCP is and always has been insecure. That is correct. There is no room for argument there. I'm saying DHCP needs to be made secure for DHCP services to be secure. If you've been arguing LDAP security, you really should find someone talking about that, because it's not me. The rest of us are trying to point out that Apple has done so over its local user settings. The funny thing is, I've a lot of friends running some pretty big Open Directory networks. They already knew this. They've understood the risks of DHCP for years. Of course, they RTFM before they implement a network architecture. John
Thought I'd chime in and address some of
what I've read here, and provide some other random thoughts.
Not on initial binding onto an Active Directory network. Only after binding do you get the cert. The initial binding is totally insecure. I don't want to sound like I'm defending that guy at PC Magazine (because it's pretty obvious he was just trying to draw page views rather than expouse any sort of rational thought). But Windows, to its credit, does ask you at first whether you really mean to associate with the supposed authorities on the network or not. And, unless I am mistaken, there is some crypto keys that are exchanged at that point to make sure that the next time it goes fishing for the domain controller, it actually is legitimate. This isn't to say there aren't 10 other remote access holes in Windows discovered every week due to some poor design decisions that were made early on, but the kids over in Redmond did actually get this part right. It asks you if you really want to bind to the network, because you need to provide client auth. to prove that you are allowed to attach to the network. I've never once, on Active Directory or NT 4 Domains, ever been asked, "You are about to bind to a domain run by server FOO with . Is this the server you want to bind to?" As long as I have the right domain name, and the right UID and password, I'm in the domain, and the domain controls me, up to and including the ability to override local administrator wishes. Active Directory is VERY ruthless here, or more properly can be. Once you're *bound*, THEN you get all the certificates, Kerberos, etc. But that first time, you don't get squat from the server proving it is who it says it is. So subverting that wouldn't be hard. Tedious, with a high risk of discovery, but not hard. At the risk of rehashing the "philosophical details" section of the advisory, the problem here has to do with what DHCP is being trusted for. In the case of trusting it for network information, in a worst case scenario your network connection will be man-in-the-middle'd. But man-in-the-middle attack risks are inherent in nearly any network configuration scenario. It also provides you with the intelligence to do long term packet analysis of traffic that host can see, making password cracks and other subversions far simpler. Man-in-the-middle is the fastest crack, but not the only one that a rogue DHCP server could set you up for. This is why we have SSL, to authenticate that the other end is who we think it is and no one else. So you haven't really lost anything that you had originally in the first place. But that doesn't work until the SSL certificates, CA and otherwise are installed, and the SSL services are enabled. Out of the box, and for that first connection with the Domain, Active Directory is no more secure than Open Directory. On the other hand, Apple was trusting DHCP for login/authentication and mount point information. The worst case scenario for misuse of these settings is much worse than a man-in-the-middle attack, hence my advisory. The fact that LDAP is being used for the attack that I pointed out is really tangential, the only thing to note is that by default the LDAP Plugin does no other authentication that the server is somehow legitimate. (It could ask the user, certificate approaches seem inadequate since I can't think offhand of how you would know if a given certificate was really authorized by a given network.) Right. Until you've done one binding, you *don't know*. That applies to Open Directory, Active Directory, Novell, OpenLDAP, and SunONE, (or whatever the hell they call it this week.). That first binding is STILL a crapshoot, no matter how you spin it. There is a similar attack vector using a DHCP response with a NetInfo server field, although that seems to be turned off by default in some configurations. (It seems to depend on what upgrade path people followed.) Oh Christ, NetInfo is a security nightmare, and I'll be having a party the day Apple finally puts the bullet in that POS's head. I have no idea as to the behavior of LDAP Plugin when it is given a shutting down message from the LDAP server. There is no room in that message for giving the name of another LDAP server to try. The list of other LDAP servers to try could possibly be established by returning more than one ldapServer field in the DHCP exchange. Well, if you figure out how to do it without using the CLI shutdown command, ARD, Timbuktu, VNC, netOctopus, or some other third party tool, let *me* know. I'd love to be able to reboot clients via LDAP, and so would a lot of other people. From what I can tell, you can't do it. You can tell the client that the LDAP server itself is shutting down, and that you need to bind to a replica, but that's about it, barring some fact that I'm not currently aware of, and would LOVE to know about. While people make lots of noise about rogue DHCP servers being instantly detected, the truth is that you can setup a rogue DHCP server without disrupting the proper functioning of a network. (Take out some leases from the real DHCP server and then hand them out to victim clients. Hand out NATed addresses and NAT traffic through legitimately leased addresses. Etc.) Most networks do not have adequate NIDS to detect another DHCP server serving up requests, and errors from the legitimate DHCP server are stored into log files that are rarely read. I've yet to see someone bother to stick ACLs on a switch to block DHCP server replies from all ports except for the one legitimate one. Of course, some people are better than others at mitigating these risks, but anyone with reasonable exposure to corporate or higher-ed IT knows that these environments generally are not given adequate resources to tackle these sorts of issues to this sort of detail. Mainly because DHCP usually only represents a man-in-the-middle risk and is cheaper to mitigate through use of SSL than flogging the network switches with extra ACL work and buying some sort of NIDS. MIT spots them inside of ten minutes. The net security team is ON and they're total pricks. They rule, Bob and Linda both. Even a properly configured one. Inside of ten minutes the switch port was shut down. And no, we never warned them. That would have made it too easy. Spotting rogue DHCP servers is not hard. You just have to be doing the job right. That's something that doesn't happen a lot. As far as ordering of lookups goes: In my testing, the values coming from the LDAP server were given greater precedence than the local NetInfo store by default. That means that lookups for accounts first go to the LDAP server before they move to looking up locally. Even if this wasn't true, as has been pointed out, you can just pick a different short username. Right. Otherwise, any directory authentications would take a LOT longer. That's why you bind to a directory system. You're giving up local control to a (presumably) better managed and more organized system. If you think about it, there's no other way to do it. I don't think its quite right to point the finger at the RFCs (and the IETF working groups that created them) when someone implements them in a way that presents a security problem. One could implement an FTP server that accepted any password as valid and still be within the legitimate confines of the RFC for the protocol. It would not be particularly wise and people would probably complain about the implementation. But it would certainly be the implementor's fault, not the RFC or the group that wrote it. (An absurd example I know, but I think it's a shades of gray issue. I think the RFC authors were cognisent of the potential misuse and did take the time to warn of it in the RFC. Woe be to the person who doesn't heed such warnings.) But that bad FTP implementation wouldn't be a new vulnerability, nor would it be automatically a bad thing. (Anonymous FTP, while risky, still has its uses.) The people using FTP need to be aware of the risks of FTP. If you use DHCP, regardless of the level, you need to be aware of the risks. It's not like Apple hides this away. It's right in Directory Access. The checkbox is right there in the LDAP settings. Could they make DA a part of the network settings? Maybe, via an "advanced tab", but then, that would probably get ignored as much as DA does now by home users. People on networks who run machines are paid to know better. So I expect them to. This is just my opinion, your mileage may, of course, vary. My apologies for rambling on quite so long here, hopefully I'm not 300 miles off-topic. Not at all. My point in the article wasn't that Apple was doing anything wrong or bad. But they are basing a service on an very insecure protocol. As are a lot of people. But there's no real practical way around it, if you want the benefits. In one of Apple's main markets, K-12, a full-time IT staff is a rarity. So they have to make this as brain - dead as possible. Unfortunately, there's, as of yet, no secure way to do this. that needs to be fixed, but it has to be done by the IETF, and done once. Not done 3-4 times, incompatibly, by 3-4 different vendors. that simply leads to people deliberately bypassing security to get work done, and then you're REALLY screwed. John William, Discussion is right, I'm about to install phpBB here ;-) From Apple's documentation: In summary, lookupd calls Open Directory when its local cache and NetInfo c |
Absolutely the best and the last word on this Mac DHCP "vulnerability" issue!
Great!
AM
Posted by: AM at December 12, 2003 10:27 AM