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.

Admins can't fix this. There is no way to restrict OS X clients (and it's the clients we care about in auth downgrade attacks) from using DH.

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

There are several methods of escalating to domain admin once you have Local Administrator access on a member workstation. It is our experience that most large Enterprise AD networks are vulnerable to at least one of these issues:

1. Crack a common local user with a shared password, like "MACHINENAME\ITAdmin". Alternatively, you can use an NTLM hash as a password equivalent with custom tools, like my colleague Jesse Burns demonstrated in 2005.

2. Crack the cached hash of a domain admin from the SECURITY hive. This hash is created by an interactive login to the machine, i.e. via the local keyboard or RDP. These hashes are not stored after remote RPC, SMB, etc...

3. Install a keystroke logger and wait for an interactive login by an Administrator. A good technique is to open an IT ticket as the victim, which often triggers an admin to remotely access the machine via RDP.

4. Wait for an automated process to touch the box with domain admin credentials. Common tools that do this are patch management systems, vulnerability scanners, software licensing compliance tools and event log aggregation systems. When the handshake for the network service begins (say over DCE RPC), the attacker rejects the Kerberos ticket and requests a downgrade to LanMan or NTLMv1. Either one of those protocols will allow an attacker to use a pre-computed time-memory trade-off to quickly recover the password (aka Rainbow Tables).

5. Wait for an automated "touch" and perform a pass-the-hash attack. This is possible on services that do not enforce at least "Packet Integrity" security. The admin and the victim machine legitimately exchange credentials, but the resulting authenticated connection can now be modified by the attacker. Again, see Burns 2005.

While the origin of the issue is the virtualization layer, it is more specifically a cloud problem because most IaaS/VPS providers use standard images with a public random seed file, so everybody's machine initializes up to the same state (RTC + random seed + handful of interrupts).

Actually, /dev/random and /dev/urandom have their own, separate secondary pools that are fed off of a main pool when entropy is "depleted" in the second level pools. This is an area of research for us as well, since Linux's entropy estimation algorithm fails in situations where the timing deltas of entropy gathering events (IRQs and disk IOs) are actually predictable, so it's possible that the second level pools are not being refreshed at appropriate times.

If you write to /dev/urandom, it goes into the primary pool by tradition. This is what the rc scripts do on bootup with the random seed file on disk.

BTW, it's absolutely the wrong solution to get entropy from another source on the network (for many reasons, but one is that you can't do a secure HTTPS handshake without, you guessed it, unguessable random numbers). The whole point here is that we are looking for a way for 500 Linux instances on EC2 to have different entropy pools before the kernel completes boot. The only possible solution is for the hypervisor (Xen for Amazon) to provide a simulated HW RNG that pulls entropy from a real HW RNG or from an entropy daemon in the hypervisor.

The best way to learn about Linux RNG basics is Gutterman et. al. Analysis of the Linux Random Number Generator. Several of the issues they describe have been addressed, such as their PFS concerns, but their description of the entropy pools is still accurate.