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.

That is incorrect.

1) On Windows 2008R2/7 it is possible to prevent downgrade to NTLM using GPO. This is a significant improvement and one we would like to see Apple replicate.
2) Even if you downgrade, it requires an extensive offline attack to recover a strong password from an NTLM handshake. NTLMv2 also has the benefit of being impervious to pre-computed dictionary attacks and contains better protections against relay attacks. DHX2 can be decoded in real-time on a laptop.

NTLM attacks are the bread-n-butter of APT attackers so it's important to limit their usefulness via appropriate GPO.

I think you mean to say that it is impossible to secure a Mac network using Active-Directory services.

No, we mean using the Apple services that are equivalent to the Windows services in most enterprises. Specifically OpenDirectory, AFP, mDNS, Server Admin and Remote Desktop.

Show me this secure Windows network and I'll show you a unicorn that shits glitter.

Windows 2008R2 x64 with all Windows 7 x64 member workstations. 2008R2 functional level. GPO: KerbOnly, NoLMHash, Require RPC Privacy and Integrity, Require SMB signing (Server and Client), Require LDAP signing (Server and Client), Require AD-enabled IPSec with IPAuth on Windows subnet, use smartcards for Kerb Pre-Auth.

As perfect and magical as your fantastical horned equus that defecates metal flakes? No, but much harder and noisier to penetrate than the best you can do with 10.7 Client and Server.

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.

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.

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.

The details of the networks attacks aren't clear in our slides without the associated commentary. One day that will be available online, but only after BlackHat makes it's killing off of DVD sales.

I still stand by my assertion that a well configured Mac network should never have allowed a normal user to install the exploit software in the first place though.

This would be our hope, and it is important to build in technical and procedural controls to reduce the chance that attackers get a foothold on your network. However, our experience dealing with state-sponsored attackers has demonstrated that it's impractical to make local execution your first and last line of defense. These folks are backed up by human intelligence and experienced humint operatives, and their social engineering attacks are quite effective, especially against remote, non-native-English employees. When our clients ask for advice on preventing APT, we do give them tips on preventing the initial infection, but a lot of our recommendations are around preventing and detecting control channels, exfiltration and network privilege escalation.

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.

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.