Macs More Vulnerable Than Windows For Enterprise

sl4shd0rk writes "At a Black Hat security conference in Las Vegas, researchers presented exploits on Apple's DHX authentication scheme which can compromise all connected Macs on the LAN within minutes. 'If we go into an enterprise with a Mac and run this tool we will have dozens or hundreds of passwords in minutes,' Stamos said. Macs are fine as long as you run them as little islands, but once you hook them up to each other, they become much less secure."

Comments

NNNGGGHYAAA!!!!

[Anonymous Coward]

Macs Good! Microsoft BAD! MACDOR THE BARBARIAN SMASH THE HEATHENS!!!!

--
Filter error: Don't use so many caps. It's like YELLING.
(really? you'd almost think that was the intent

Re:NNNGGGHYAAA!!!!

[sacridias]

Mac is a evil pathetic dogmatic corporation. Mac BAD, Microsoft BAD. I also hate mate because they bastardized the greatest OS ever, Free BSD. Mac needs to stop child labor and labor camps associated with their company, and stop suing people because they are jealous of their success. They are a bunch of cry babies that need to be put down.

Re:NNNGGGHYAAA!!!!

[The Dawn Of Time]

I don't know anyone who elevated Steve Jobs to god status. I guess it's indicative of someone who's drastically out of touch when they get upset about something that doesn't really exist outside of their own head - while clearly dreaming of how wonderful everything would be if only he were worshipped.

I guess what I'm saying is that your comment says a lot more about you and your dreams than it does about the actual, real society we live in.

All computers are less secure

[improfane]

...when you hook them up.

I have no love for Apple but even this article smells like astroturfing.

Re:All computers are less secure

[WrongSizeGlass]

All computers are less secure ... when you hook them up.

If that were true then hooking my computer up to the internet could end is disaster! It's a good thing I'm using a Siemen's SCADA firewall.

Re:All computers are less secure

[Anonymous Coward]

...when you hook them up.

I have no love for Apple but even this article smells like astroturfing.

Can we please stop this Slashdot trend of calling everything that don't immidiately fit into our worldview for astroturfing. The article is sensationalist (duh, it's The Register!) but these are security researches presenting at the Black Hat conference, check out other sources and the actual basis for their claim before immidiately jumping to the astroturfing cop-out.

I've seen people with posting histories long as a mile proving they are Linux users and supporters getting called M$ astroturfers because they tried to be nuanced about facts and opinions in a discussion.

Re:All computers are less secure

[NatasRevol]

You might want to go read the actual presentation.

It starts out with an exploit called Aurora, which compromises AD.

Whoops.

Re:All computers are less secure

[NatasRevol]

And the Mac exploit STILL REQUIRES AN ADMIN PASSWORD. Which is not typically given to users in a corporate setting - at least by sane sysadmins.

Re:All computers are less secure

[hansraj]

The whole point of TFA is that if even one computer gets infected on the network then it can be used to infect other machines without requiring the admin password on the remote machine. All it would take is one malicious person with physical access to one mac, or one careless click from someone who does has admin access to their own mac in the building.

Re:All computers are less secure

[DrgnDancer]

It's also worth pointing out that the "exploits" for Macs these guys found require an amazing amount of stupidity on the part of the system/network admins. We're supposed to worried about using Macs in "Enterprise" level exploits, but the configuration required for exploiting is distinctly amateur.

They claim DHX is vulnerable, Kerberos is not; but it's "trivial" to change the scheme. This is true if you have root on the server box, but getting there should not be "trivial" in the first place. Even with DHX, you need to get admin privileges on a workstation box to start sniffing passwords. Again, that shouldn't be trivial in the first place. Admin accounts should only belong to trained administrative users, whether your OS is Windows, MacOS, or Linux. Sure, if you make every Tom, Dick, and Sue an admin you're highly vulnerable to social engineering attacks. On any OS. OSX permits and encourages privilege separation like any other OS; if you chose not to use it, you're an idiot, not "Enterprise IT".

A competently administered Mac network, with proper encryption, privileged separation, threat training , etc should be no more vulnerable than any other if I'm reading this right (I read the slides form the presentation in addition to the almost useless article). The take home point shouldn't be "Don't use Macs", it should be "Treat Macs like every other client and server." They're not more vulnerable, they're just not full of magic hacker repelling pixie dust.

Re:All computers are less secure

[DrgnDancer]

That kinda is my point. If you do a bad job of building your network, it's going to be vulnerable, regardless of OS. If you do a good job (and MacOS has the tools to do a good job, the presentation points them out indirectly), you will be less vulnerable, regardless of OS. These guys are focusing on: "Don't use Macs in the enterprise" rather than the more obviously lesson: "Treat Macs in the enterprise with the same degree of care as any other machine with any other OS"

Re:All computers are less secure

[NeutronCowboy]

Maybe. But I've heard too often that "Macs are more secure than Windows, so we don't need safety stuff." Mind you, this came from the guy who wanted to install an AV on all their Powerbooks, but handed out same Powerbooks without proper passwords, no password policy, no automatic lockdown and admin accounts to everyone.

I think these stories are valuable because you can show them to the twits in power who think that Macs are magically more secure, and drop every security practice there is.

Re:All computers are less secure

[NatasRevol]

You might want to go actually read the presentation. It does need an admin password in order to get privilege escalation. See pages 32-34 in the presentation.

There is no exploit here on getting the local admin or network admin password. It requires an admin password to ... wait for it ... do admin type things on the network.

Re:All computers are less secure

[recoiledsnake]

Erm. it's ALWAYS big news on Slashdot when the news is anything anti-MS, regardless of it being true or not.

Remember this story(and countless others)? http://tech.slashdot.org/article.pl?sid=09/02/16/2259257

Re:All computers are less secure

[CalTrumpet]

I am the researcher quoted in the article.

This would be easier if the story linked to the real presentation.

Yes, Apple services generally support Kerberos as an authentication scheme. The problem is that it's almost always possible to downgrade from Kerberos to unsigned Diffie-Hellman and retrieve the plaintext password trivially. This requires an active MITM attack on the network. Traditional ways attackers have done this include ARP spoofing, DHCP spoofing and DNS poisoning attacks. Our talk also discussed a Mac-specific MITM which uses Bonjour to temporarily take over the identity of OS X servers and relay or downgrade authentication.

Even if OS X allowed itself to be limited to Kerberos auth (and it doesn't) most Apple protocols do not perform channel binding, meaning there is no cryptographic integrity protection tied to the initial handshake. This allows an attacker to relay the Kerberos handshake and then modify the resultant communication, which can be disastrous if the communication is security critical, such as LDAP or an AFP mounted home directory.

A competently administered Mac network, with proper encryption, privileged separation, threat training , etc should be no more vulnerable than any other

That is incorrect. Our research has shown that it is currently impossible to secure a network using OS X services. The only secure Mac network is one that runs the machines as separate "islands" without directory services, file sharing, or remote server administration. There are a lot of insecure Windows networks, due to the use of downlevel versions as well as configuration mistakes, but in theory you can build a new Windows 2008R2/7 Active Directory network that is hardened against network privilege escalation using GPO (KerbOnly, NoLMHash, RPC privacy/integrity, AD integrated IPSec, smartcard auth, etc...)

Re:All computers are less secure

[CalTrumpet]

There are a couple of different issues here. Escalating locally (even from inside the sandbox) can be done via impersonating an escalation prompt or by an offline brute-force of the keychain. Our criticism of the keychain is that it provides a decryption oracle that can be moved off of the machine and cracked at the leisure of the attackers. Even though it's relatively strong (1000 round MD5) state-sponsored attackers will definitely recover poor passwords.

There are also often local privilege escalation bugs that are regularly patched, but we didn't discuss these since we were most interested in the architectural issues that are difficult to correct.

On the network there is no cracking necessary. Via a downgrade a user's network password can be recovered with trivial computation resources.

Re:All computers are less secure

[CalTrumpet]

So how is this different from any other OS? sudoer is sudoer.

The escalation prompt impersonation is in no way unique to OS X. We never said it was, although it's a bit easier on OS X than on Windows.

There seems to be some misunderstanding on Slashdot of the purpose of this research. Our goal was to apply our experience with advanced attacks against corporate Windows networks against equivalent Apple technologies so that the defenders could stay one step ahead. We have a lot of clients that are now 40, 50, even 80% Macs on desktops, and it's important that we understand what these networks look like to somebody who has been given a year and a staff to penetrate and completely own the enterprise. Not everything we mention in the slides should be a criticism of OS X, in fact the majority of steps in this attack tree are pretty much identical on either platform. Understanding the details of each of those steps is important when designing countermeasures to prevent or detect each part of the attack tree.

How is this any different than any other hash storage mechanism - /etc/shadow, /windows/Windows/System32/config

These password stores are not accessible to a non-root/admin user. The section of the talk you are referencing is about local privilege escalation. We were trying to come up with ways we could escape after exploiting something like the low-rights Quicktime rendering process, and offline brute-forcing the Keychain is one option. BTW, those passwords stores aren't really equivalent to the Keychain, a better example would be Windows DPAPI, which provides a key that also mixes in a pre-machine secret to prevent this type of attack.

Re:All computers are less secure

[CalTrumpet]

Ah, so... according to your research, if you already have the admin pw and physical access, infiltrating the Mac network would be easier than infiltrating the dream Windows system you envision without having the admin pw or physical access. Truly outstanding and brilliant work.

I have no idea what you are talking about.

The point was that Apple has done a good job preventing initial exploitation and trying to contain exploitation to a low-rights process. If the attacker is able to defeat those protections, which is plausible on both platforms at the skill level we are discussing, then the next step is using network exploits to become other users, possibly administrators. It is this step that is much easier on managed OS X networks.

And?

[Bert64]

Windows machines can be pretty secure on their own too, but once hooked up to an active directory domain they are only as secure as the weakest point...

Also, this seems to be a particular authentication scheme which is flawed, windows has similar flawed schemes (google: pass the hash).

Finally this just seems to be a stupid bug in a service used for pushing updates, and should therefore be relatively easy to fix.

Re:And?

[Baloroth]

Read TFA. It is possible (trivially, supposedly) to force Macs to use DHX (the insecure protocol). So, essentially, even if you use the secure system, it doesn't matter. That is a bit troubling for OS X enterprise users, to say the least.

I suppose the lesson here is that after 15 years of being the #1 target, M$ might finally be starting to get its shit in a respectable state, while Apple, for all its theoretical security, has very little experience dealing with actual security issues. Or maybe it's just a random bug, IDK.

Re:And?

[NatasRevol]

It's not a bug, it's a design difference. On Mac Server, it does fall back to simpler protocols because that's how it was often set up - no real sysadmins means no consistent use of strong authentication.

However, it would all go away if Apple required and ONLY allowed kerberos for authentication of any service from OS X Server. In other words, just like AD.

Having said that, this exploit still requires an admin password to escalate privileges - which isn't typically given in a corporate setting. In other words, admin passwords can do admin things.

Re:And?

[Bert64]

AD doesn't require and exclusively make use of kerberos, it can (and by default does, although which ones depend on the version) use weaker authentication schemes (ntlm, ntlmv2, lanman)... Apparently the hash passing vulnerabilities also exist when using kerberos only, its just that tools to exploit this are not publicly available to do this yet.

Re:And?

[Revotron]

I do have modpoints, but unfortunately there is no "-1, Wrong" rating. And unlike other people, I will not substitute Troll, Overrated or Flamebait.

But anyway, back to the topic at hand... uh, where the hell do you work? I work in a very Windows-heavy environment, and every time we add any Windows boxen to the domain, the domain admins get automatic admin rights. There's nothing we can do to stop it. This is a 10,000+ workstation university, though, so at least they're distant and maybe (only maybe) competent enough to not abuse it.

Re:And?

[Bert64]

Under a typical/default configuration, a domain has full control over a local machine once it has been joined to the domain... Buy that's not the point, the fact that having compromised the *server* you can take control of the *clients* is a given in any distributed authentication scheme, be it nis, kerberos, ldap or whatever...

The problem discussed in the article is that having compromised a single *client* you can take control of the server or other clients. Windows has such problems too, for instance once a domain user is logged in their password hash is stored on the system where it can be retrieved and then used. Also since most machines are built from images, local admin passwords are often the same and thanks to hash passing vulnerabilities can be used immediately without having to crack them (and as such irrespective of how strong the password is).

Windows of today still has NTLM and NTLMv2 enabled by default... It also still supports LANMAN although that is disabled by default in the latest versions. It is also apparently possible to do hash passing attacks even with only kerberos enabled, although i'm not aware of tools for doing that being widely available yet.

Ideally compromising a single client should get you nowhere (and many admins incorrectly assume this to be true)... But as some recent high profile attacks show, a serious attack can easily start from a single unimportant workstation, and there are many ways to compromise a single workstation (social engineering, browser exploit, malicious document exploiting whatever app they open it with etc)...

What is really needed, is a complete rethink of the old perimeter defence model... Although you can (and should) take steps to reduce the chances of the perimeter being breached in the above ways, if you don't pay attention to internal security then once a single small breach has happened its game over for you.

Re:And?

[sl4shd0rk]

...while Apple, for all its theoretical security, has very little experience dealing with actual security issues. Or maybe it's just a random bug, IDK.

Exactly. The bigger picture is concerning because Apple really *is* poised to become the Next Big Thing on the Desktop (Sorry Linux. Your awesome, but slaying the n00bs will never get you on the Desktop). Hopefully Apple will do a better job at fixing vulnerabilities than Microsoft did. The user's are (As usual) going to be key howerver because (FTFA - pdf link):

    * Apple users feel safe because they have no history of exploitation
    * Apple users tend to be just as ignorant as anyone else
          - Go ahead and run this unsigned binary
          - Who needs AV ?
    * 14% of all publicly disclosed OS exploits in 2008 affected OSX
    * 1,151 CVEs in past 3 years affected Apple (Windows was 1,325)
    * Mac users not paranoid like Win users so may be easier to socially engineer

       

Re:A virus? In my MAC?

[Samantha Wright]

A Stuxnet? In my PLC?

It's more likely thank you think! Why would someone write a worm that is targeted at 0.00001% of the user base when they can target 90?

Unpatched vulnerabilities leave open doors for custom-tailored villainy. I would call it a pretty big deal.

Is DHX enterprise grade?

[Midnight Thunder]

Reading the tech note (marked archived) it makes it appear that DHX is an optional install and it is not clear. Also, doesn't MacOS X also provide enterprise grade solutions for authentication? Kerberos is available out of the box if I understand, for example.

BTW With the description "The DHX (Diffie-Hellman Exchange) UAM provides a relatively secure way to transport cleartext passwords..." (emphasis mine),
I am not sure you would want to use this for anything serious.

Easy fix, for lazy administrators

[schmidt349]

defaults write com.Apple.AppleShareClient afp_cleartext_allow -bool NO

There, that wasn't so hard, was it? Oh, and their hack only works if the server is on the same subnet as the other machines, which is a really bad idea for secure networks to begin with.

To be sure, keeping Diffie-Hellman around in an era when sending plaintext passwords is anathema was pretty stupid, but you can bet that it'll be dead and gone in 10.7.1. This hack is not nearly as scary or as "persistent" as all that, and conveniently their paper isn't available for download and perusal. Looks like they just wanted their names in the news.

Next up, these same hackers break DES and show you how to infiltrate BSD 3! What will they think of next?

Re:Easy fix, for lazy administrators

[CalTrumpet]

You can turn off plaintext auth, but you cannot disable unsigned DH.

Even if you could restrict to kerberos, there is no channel binding protecting the contents of these protocols, so auth relay attacks are pretty easy to pull off.

The mDNS MITM attack can be carried out across Layer-3 routing in some circumstances. In situations where this does not work, an attack against clients on the same broadcast domain is just as effective.

I would love for these issues to be fixed in 10.7.1, but that is extremely unlikely as truly hardening OS X against network privilege escalation would require significant architectural and cryptographic changes that would break backwards compatibility. These are equivalent issues to those faced by NT4 networks, although I have faith that if Apple was interested in correcting these issues they could do so much more quickly than Microsoft took to go from NT4->2008R2.

The slides are available here. Please let me know if you have any substantive feedback.

Re:Easy fix, for lazy administrators

[CalTrumpet]

Slide 28 -- I'm not particularly clear on why you would want ASLR or DEP to be configurable -- that just opens another avenue of attack. It should be always on every process all the time to be meaningfully effective.

It's unlikely that any consumer OS will ship with these protections on all of the time. By default, both OS X and Windows 7 apply ASLR and NX protections to binaries that "opt-in". The difference is that on Windows you can force these protections on binaries from legacy compilers and linkers. This will often result in the process crashing, but in an enterprise environment you might prefer to crash old programs than to allow somebody to run Firefox 2, for example. This would be a simple fix for OS X and I wouldn't be shocked if they slipped it into a future patch quietly as a sysctl.

Slide 38 -- you keep calling the attack on the Keychain credential store a "brute force," but it isn't -- it's a simple social engineering attack to get a password. Unfortunately the Keychain keeps (encrypted) passwords in the clear rather than hashes only, but this is so users don't forget their passwords.

There are a couple of issues getting mixed together here. One way that you might escalate your privilege from a sandboxed, low-rights process would be a social engineering attack using an escalation prompt, as we showed. The keychain offers another option, because the encryption key used to protect it is solely derived from the user's password. The keychain file is available from the sandbox, so an attacker could pull the keychain file and send it off-site for a brute-force attack. The algorithm is definitely non-trivial to brute-force (1000 rounds of seeded MD5) but is not out of bounds for state-sponsored attackers, especially if the user is using a weak password. So the keychain isn't only useful to us as a repository of network passwords, but as a decryption oracle that can be cracked off-site (like in a basement in Beijing, cough...).

Our recommendation to Apple was to provide the user keying material that is partially derived from the user as well as from a machine-specific key stored somewhere only available to root. This would at least prevent low-rights and sandboxed processes from using the keychain as an oracle, although it would likely impact compatibility with downlevel versions of migration assistant.

Slide 53 -- "Modify existing binaries and services, which breaks signing but is generally not noticed" -- maybe in your shop, pal, not mine.

How do you regularly check for system binaries being modified? Do you use Tripwire? There seems to be no equivalent technology built into OS X, so we pointed out that one way to persist malware would be to modify parts of the system that are already running. This is, in no way, an OS X specific issue, although the lack of kernel extension signing makes it a bit more problematic than on Windows. (That being said, state hackers have already demonstrated a propensity for stealing Authenticode certificates from hardware makers, so driver signing isn't super helpful on Windows).

Slide 76 -- "Run your computers as little islands on a hostile network" -- FTFY

I disagree with this correction and your summary of our work. Our conclusion is that Apple has evened the score with Windows on anti-exploit technologies and has made it much easier for their ISVs to use the OS's sandboxing capabilities. We also concluded that it is possible to build a secure, managed Windows network that uses integrated authentication mechanisms to provide access to network services, although most organizations will not be ready to take the back-compat hit it takes to do so correctly. We concluded that it is currently impossible to build a secure network using OS X and OS X Server, and that any use of Apple-proprietary protocols makes credential stealing and network escalation attacks easier than it should be.

The Tl;DR is that Apple machines are more secure alone, and Windows machines are more secure when connected and managed.

Users with admin rights?

[Udo Schmitz]

Do I understand their presentation correctly? Users in said Enterprise have admin privileges?

Re:Users with admin rights?

[NatasRevol]

Yeah, which is not the case most of the time.

Users with admin passwords can do admin things. Duh.

Meaning this 'exploit' isn't much of an exploit.

Re:Users with admin rights?

[CapuchinSeven]

No, you got it, this is a load of rubbish and is being presented as some sort of reason to bash Macs. If you're a Admin and you let your users have admin rights, you shouldn't be in your job. Interestingly, as I understand it, the same vulnerability used on Microsofts AD, doesn't need an admin password. So... how does that make any sense that Macs in enterprise are more vulnerable...?

Re:A virus? In my MAC?

[gatkinso]

>> Why would someone write a virus that is targeted at 10% of the user base when they can target 90?

Because they are an asshole?

So... practical linux attacks next?

[mark-t]

It's my understanding that Linux has even more widespread enterprise adoption than Mac does... so does that mean that we get to see a Linux exploit next?

And when someone does... any bets on how many hours it will take from actual publication of said exploit until a fix is available? My money's on it being fast enough that by the time most people who might want to exploit it have heard about it, that a fix will already be available, and attentive sysadmins will have already patched their servers.

Re:A virus? In my MAC?

[asdf7890]

Why would someone write a virus that is targeted at 10% of the user base when they can target 90?

I'm assuming you are implementing sarcasm there, but in case you are not...

How about because you've got as large a chunk on the 90% as you are going to get any time soon in your botnet already, and you are having to fight every other botnet going to keep them? A chunk of that 10% could make a useful difference.

Or if you are installing a key logger to try purloin credit card details or authentication credentials, why not target the more-affluent-on-average users of that 10% who might actually take less effort to infect as they are complacent?

Or how about "just to prove you can". I'm guessing that in lieu of actually making money simple bragging rights still count for something in the hacker/cracker world.

Re:A virus? In my MAC?

[silanea]

Think applications for OS X: Why would someone write software that is targeted at 10% of the user base when they can target 90? Because those 10% are highly profitable and support issues are lower due to the limited amount of different hardware and software configurations. Looking around me I would argue that the more affluent a person, the higher the chance they own a Mac, and I do not know anyone in person who still is on a PowerPC Mac.

Re:A virus? In my MAC?

[BrokenHalo]

Most douchenozzles write virii for kicks.

And much worse, only a total and utter douchebag uses "virii" as a plural form of "virus".

Re:A virus? In my MAC?

[Anonymous Coward]

Also, one can lodge malicious code in a Mac that would require physical replacement of components, such as the flash ROM of the keyboard, or even the battery of a Macbook.

This isn't new to Macs either. Back in the System 6 days, where the OS would read from the SCSI drive code to execute a hard disk driver, it would be trivial to hide a malicious payload there, and because it ran before anything else, there would be no way to stop it. Had a virus that did that been combined with WDEF (which infected machines the second a floppy disk was inserted), it would have caused extreme pain for a lot of users. Think bad MBR code is an issue with PCs, this was a glaring hole. Thankfully, nobody exploited it.

Thankfully's Apple's pants are shown down only at the cons. However it won't be long until stuff that lodges in a keyboard HID ROM or other places hard to dislodge goes to the wild.

Re:Mac's lacking Enterprise tools that windows has

[futuresheep]

With Lion and VMWare ESX 5.0 you'll be able to do this. The license terms were changed in Lion to allow you to run in a VM, and ESX 5.0 will come with UEFI as a boot option.

http://www.ntpro.nl/blog/archives/1786-vSphere-5-Video-EFI-the-Extensible-Firmware-Interface.html

Re:Mac is not for the enterprise

[Caste11an]

I couldn't agree more. I've been using a MacBook Pro in my enterprise DBA job for the last year. In that time, the Enterprise-grade AD has suffered numerous outages and fallen to two viruses. During that time, my consumer-grade laptop has powered through the darkest hours, providing me with quick access to our data centers and generally outperforming the Windows-based machine on my desk. Furthermore, our corporate wi-fi has been nearly unusable for the past two years, and because our overlords are cheapskates, our meeting rooms have four-port Ethernet hubs at best. I walk into a meeting room and set up a wireless hub via my laptop in seconds and everyone in our group is connected and working quickly. I can't even imagine the corporate nirvana that would exist if we qdid away with much of our Enterprise setup and instead replaced all 10000+ employees' machines with Macs. Long live the Mac's non-Enterprisiness!!!

Re:Mac is not for the enterprise

[CompMD]

Oh I don't know about that. I'm an engineer for a large, multinational aerospace and electronics company. For what I do, I need several computers running different operating systems. Out of the 8 machines I have, two are macs, an imac and a 2011 macbook pro. The macbook pro is seriously the best machine I've ever used for work. I really despise Steve Jobs, but I cannot fault a good product, I really like my macbook pro for work.

Re:DHX already deprecated in 10.7

[CalTrumpet]

Slide 41 of the presentation shows the hierarchy of available authentication protocols and the best known attack against each. DHX has technically been deprecated, but it was replaced by DHX2 which has the exact same problem. The MITM tool we demonstrated works just fine on 10.7.