Slashdot Mirror

Cripes... I take a few years and don't read about the latest RC4 attacks, and someone finally figures out an attack that can make use of the super-low long-term biases found in RC4. I guess I'll have to switch to something else. I've been using message authentication MACs in P2P protocols when messages are not encrypted. The combination seems like a good idea for stream ciphers.

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.

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

That's your problem? That the protocols that are being discussed are also used by other operating systems? If you are looking at the security of a platform, should you ignore some security holes because they also exist in other platforms too? Or does being an open, cross platform standard somehow make it inherently secure.

If you have a look at iSec Partner's old press releases you can see that they are aware that Kerberos is used by Windows too and that its problems can affect different platforms. With the number of black hat events that these guys participate in, if they did not know what they were talking about then someone more knowledgeable than either of us would have ratted them out before now.

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.

Well, the EFF gives a shout out to browserspy.dk for the font detection code and to breadcrumbs for supercookie help, so I think it's safe to say those guys had thought of this idea. Good to see that the EFF is still relying on tried and true methods of tracking, though. The Panopticlick site drops a session ID cookie to track users.

You could try iSEC Partners. It's pretty much what they do. Training, design review, pen-testing, and so-on.

First links I tried, after reading the header of the paper, saying:

                    Cleaning Up After Cookies
                              Version 1.0
Katherine McKinley – kate[at]isecpartners[dot]com
                            iSEC Partners, Inc
                    444 Spear Street, Suite 105
                      San Francisco, CA 94105
                https://www.isecpartners.com/

would be ... I don't know, maybe http://en.wikipedia.org/wiki/@stake ;-) ?