10 posts • joined 8 Aug 2011
That's a good plan.........................................
Make sure to set up an authorized_keys file and disable password authentication in the SSH configuration.
I do approve
I have a feeling we have elevated the conversation well above the normal level here. Perhaps next we can attempt a serious conversation on 4chan?
Better, not fixed
"... if there was a fix to stop reversion all would be well in the cupertinoverse?"
A setting to disallow downgrade is a necessary but not sufficient step to securing against network escalation attacks against OS X. Another important step would be to implement "channel binding", which uses a cryptographic key derived by the authentication handshake to protect the integrity of the subsequent conversation. Without this protection, a MITM attacker merely relays the initial handshake and then manipulates the actual data. In some cases (like LDAP or binaries on AFP) this would allow the attack to take over the client machine.
Our suggestion to Apple was to break compatibility in 10.8 Server with downlevel clients and to create a single wrapper protocol for all of the various services offered by OS X server. A good option would be TLS with SRP password auth, and TLS with Kerb Auth in OpenDirectory environments. These protocols (AFP, ARD, Server Admin) could then be easily tunneled over TLS as long as a reasonable multiplexing system was put in place. This would reduce the complexity of fixing these problems one by one on each protocol.
That is optimal
If you read the slides you will see that this is our recommended optimal configuration and how we personally use Macs, as "islands" on the network. No OpenDirectory, no Windows domain integration, no AFP, no screen sharing, all services off in the "Sharing" pref pane, Deny All Incoming set on the Firewall pref pane.
It should be noted, however, that you don't need OS X Server to run afoul of authentication downgrade issues. The AFP and "Share Screen" functions in OS X client use the same protocols and can be used to retrieve credentials. If you HAVE to use network file mounts, I would recommend an SMB share on a NAS that uses different credentials than your real user. This will prevent OS X from automatically attempting to authenticate using your user credentials, and NTLMv2* is harder to crack than DHX. If you want to remotely manage machines, use SSH with RSA keys.
Running completely disconnected, I would judge OS 10.7 slightly safer to use than Windows 7 x64.
I'm not sure where the logical fallacy is, but the point here is that while we applaud Apple's efforts to increase the difficulty of exploiting client-side flaws to seed malware, our experience as well as the well-documented experience of many enterprises is that every large group has somebody that can be tricked into downloading a malicious .dmg/.msi and installing it without the need of an exploit. This is especially true in state-sponsored attacks that utilize human intelligence and professional operatives to improve their social engineering.
If you accept our premise, then it is critical that a corporate network be designed to reduce the methods by which an attacker can hop from machine to machine or escalate to an admin account. That is the basis for our analysis and recommendations.
This has nothing to do with centralized patching. I'm not sure where you got this idea.
"But it's also EXTREMELY easy to compromise a windows network in the same way, get onto one system and you can grab hashes, either of the local users (how many places build from images and all the local passwords are the same), or of logged in domain users... And then you can use these password hashes to access other machines without even having to crack them!"
This is a significant risk on Windows networks, however, the majority of methods to escalate privilege via these types of attacks on Active Directory have been mitigated by default or can be mitigated via centralized configuration settings on Windows 2008R2 and Windows 7. You can build a Windows network with GPO that makes these attacks hard (Kerb-Only, IPSec required, IPAuth, NoLMHash, smartcard Kerb pre-auth) but it is impossible to do so with OS X. That's of little benefit to enterprises struggling with downlevel Windows servers and backwards compatibility concerns, but if you were building a new network today and were concerned about APT-like attacks, I would recommend Windows over OS X.
OS X clients with no servers and no management would probably be the most secure configuration. Obviously that doesn't work for most enterprise IT departments.
Now that you've had a chance to read the slides, please let me know which of our conclusions are not accurate so that I can correct the "FUD".
All of this information was shared with Apple before going public. Per our responsible disclosure policy, we decided to not "wait for a patch" since the issue is architectural, unlikely to be fixed within the next 90 days, and can be mitigated via non-patching behaviors (such as not using AFP or OpenDirectory) if users are aware of the risk.
We also decided not to release our attack tool, since it pretty trivially retrieves a large number of usernames and passwords on an Apple network and has no non-malicious use.
This has nothing to do with centralized patching.
Let's Clear Some Things Up
There is a lot of misunderstanding of our research here, which is understandable, since the article didn't link to our slides:
As you can see from the slides, we used our experience responding to advanced, state-sponsored attacks to divide the attack tree into seven different generic steps that need to succeed for the attackers to "win". We examined OS X and OS X Server to see how they would hold up to each of these stages, compared to a baseline of Win2008R2 and Win 7.
We found that Lion has caught up to Windows on anti-exploit technologies, and has included sandboxing features that make it much easier for ISVs to use privilege separation to protect their end-users. The largest problems with OS X in an enterprise context revolves around Apple's proprietary protocols, like AFP, Server Admin, Apple Remote Desktop, and especially Bounjour/mDNS. Apple offers many password-based authentication options, but in almost any circumstance you can downgrade to unsigned Diffie-Helman, which is trivially decoded by an active MITM. Even if you could force only the use of Kerberos, almost none of their protocols use channel binding to tie to subsequent communication to the initial handshake, opening OS X up to a variety of relay attacks equivalent to the NTLM relay attacks famously used by the state-hackers during Aurora.
The network escalation step is the most important one in this scenario, since it is unreasonable to expect a network of thousands of users to never be infected via malware. Social engineering based upon human intelligence is very difficult to prevent, so it's important for an Enterprise security team to focus on preventing "Bob the HR Guy" from becoming "Sally the Domain Admin".
We are not anti-Mac (this is being typed on a 13" MBA), but we strongly recommend that our enterprise clients not use any of Apple's server technologies at this point, especially if they believe they are playing at the same level as the Aurora and Shady RAT victims.
Let me know if you have any questions.