Sounds like a fanboi knee-jerk to me
I rated this article 'pretty poor' because I thought the quality of the article was pretty poor, not because I balked at the mere suggestion that someone said something bad about macs.
Beware of Macs in enterprise, security consultants say
Apple may have built its most secure Mac operating system yet, but a prominent security consultancy is advising enterprise clients to steer clear of adopting large numbers of the machines. At a talk last week at the Black Hat security conference in Las Vegas, researchers from iSec Partners said large fleets of Macs are in many …
What's that?
You gave your (mac) users the admin password and where surprised when things went wrong?
Just Fix It
Although in general an individual Mac is more secure than an individual Windows PC, if a vulnerability that lets an attacker to revert the network from Kerberos to DHX turns multiple Macs into a house of cards, that is very serious. The thing to do is to both fix that vulnerability, and provide a tool with which to remove DHX completely from a Mac.
It's not good enough for the Macintosh to have the potential to be a secure platform if even one flaw makes it less secure.
However irrational this fear may be, though, some people wonder if Apple might not move someday to a closed App Store model with the Macintosh similar to that for the iPhone and its relatives. That, not security, is the greatest threat to the success of the Macintosh at the moment.
Fear not..
Hardly anyone uses macs in the business world, as they are practically useless (unless your job just involves surfing the net all day).
So
"To demonstrate the threat, they developed a proof-of-concept that runs on a Mac connected to a local area network. "
So you have to have a Mac equipped with this tool attached to the network. This is assuming the admin has been so lax as to allow users attach devices from which to copy the tool. Or. Allow someone to bring an unauthorised Mac in and connect it to the network without it showing up in the network admins screens.
"It waits to be contacted by a machine running OS X server and then quickly copies all its authentication credentials."
Huh? Since when do you wait for a server to contact your Mac? Or does it mean you need the credentials to log into the server first.?
Several here have pointed out that it would be pretty lax admin to even get this far. And it assumes that the enterprise uses the now defunct OS X server to admin update. If a company uses, say, Casper, then it ain't gonna happen.
Where I am there are 300 Macs (plus a few PC's) and these are locked down with regard to what they can and cannot run.
More FUD from a 'security' company looking for work.
Hmmm
>More FUD from a 'security' company looking for work.
iSec Partners is not a company that needs to look that hard for work......or given your description above, one which you could afford to hire in any case.
>This is assuming the admin has been so lax as to allow users ....
Dunno about this - is security your number one concern to the extent that you search your users bags and watch them all the time? The US Army did but Bradley Manning still happened.
Personally I worry about any admin who claims their network is secure.
Just Got Here, Did You?
"Since when do you wait for a server to contact your Mac?"
Surely you are aware of the concept of "push"? Whereby (as noted in the article and throughout history) a server "pushes" things to receptive clients? For instance, when OSX Server "pushes" updates out to the clients attached to its network?
Surely, then, you must be capable of understanding the idea that a Mac client on a LAN is ALWAYS "waiting" for the OSX Server that acts as Master Domain Controller on that particular network to reach out and "push" software updates onto it?
If you (a) are not aware of this concept or (b) do not understand its implications, then, sir, you should refrain from posting such drivel. Here's hoping that your AWESOME 300 Mac environment is NOT suffering under your clueless administration ...
To be fair...
...people are stupid. If there's any possible way for a user to fsck up their machine, no matter the OS, they will. That extends to malware, viruses, trojans, etc being installed.
Monoculture
So if they don't recommend lots of Macs then they think the enterprise customers are better off on Windows?
A monoculture of computers and software is what helps viruses take down an organisation's systems.
If OSX was so poor Google wouldn't have dumped all their Windows machines for OSX.
Also...
The lack of any realistic enterprise class servers does kind of prevent anyone running OS X in enterprise anyway.
Hmm...
I strongly suspect that the removal of Windows form Google is a lot more to do with Google's competitor OS than it is with insecurity of Windows. If Windows were really that insecure why do banks run it on ATMs? Why do big pharma and big finance run Windows desktops?
Server Security
Forgive me if I've missed the point, but this article seems to basically amount to: 'Protect OS X Servers because if they're compromised, connected clients can be compromised.' Isn't that true of any server?
It's almost a truism that networking introduces more potential attack vectors. A non-networked Mac is more secure, just as a non-networked Windows, Linux or BSD system is less vulnerable than a networked one. But that's no reason not to use said systems or not to network them. It just means you have to be aware of the additional security risks in doing so and take appropriate measures.
The only possible 'news' I can see in this story is that Macs are typically seen as 'virus-free' unlike Windows systems, so end-users may get a false sense of security using one. Bob in HR might think twice before double-clicking on a binary executable on a Windows system, but might not think twice about double-clicking on a .pkg on Mac OS X. But one would hope that the admins are smart enough to know it's not as simple as 'Macs don't get viruses' and to consider their OS X Servers just as vulnerable as their Windows or BSD boxes and take the time to secure them properly.
Concept
You have, indeed, missed the point.
This particular exploit is made possible by the nature of one the security protocols Apple gear use to exchange credentials within a LAN.
This protocol is only in use on Apple gear, and is proprietary to them.
When any system within a Mac-oriented LAN is compromised, the next domain controller connection made using that protocol reveals EVERY credential associated with that controller/server, allowing the compromised machine to capture and relay all of those credentials, or simply to incorporate them into whatever malicious payload is waiting on the compromised machine.
This doesn't happen with Windows-based LANs, or with Posix (absent OSX) LANs because none of them use that protocol. Only Apple gear is susceptible.
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:
http://www.isecpartners.com/storage/docs/presentations/iSEC_BH2011_Mac_APT.pdf
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.
Wow. Haven't seen that for a while.
A coherent, well thought-out piece of writing made of full sentences with punctuation I mean.
You must be new to the intertubes.
um
"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"
I believe Server Admin uses HTTP, Apple Remote Desktop uses VNC, and Bonjour/mDNS is an open standard that anyone can use. The protocol draft will have a very familiar name in it if you go to the IETF.
Zeroconf/mDNS isn't remotely proprietary. Even Ubuntu uses it for service discovery. If you don't want it, you don't have to use it in any event. It's optional.
YAWWWN
MAC VS PC is sooo nineties. And the occasional 'I run my stuff on linux' squeak is almost as tired.
Its about time people actually engaged each other productively and took all their 'great' ideas and created an OS that works.
....
Oh you can't, because your all sys admins and couldn't write a kernel if your sorry little lives depended on it.
Fanbois (of any OS) really need to step away from the keyboard
Good article. I find (as usual) the fanbois - this time Mac ones, once again don't actually read the entire thing, but just see "my favourite toy is being dissed, must defend!!!" - This is typical of so many uneducated fanbois of ***all** platforms.
Given there has yet to be a perfectly secure computer network, the very fact of a security article pointing out a flaw in a particular platform should not be met with derision or putdowns, but rather a scramble back to the readers' own networks to see if the vulnerabilities listed exist within their own demesnes.
Of course, those who do exactly that tend not to post in response because, well, they're busy securing their networks thanks to the new information. The fanbois, of course, still have their leaky sieves on the 'net, vulnerable as always, but thinking they're still secure "just 'cuz".
Brilliant.
Hmmmm....
This "Avoid the Mac Platform" advice seems to hinge on use of a MacOSX server to provide OS updates for client Mac's? What if you aren't using an OSX Server and pushing out Mac OS updates from an OSX Server to your Mac user base? What if they are updating on their own from Apple Servers? That pretty much negates this entire argument and renders the author's point pretty mute, doesn't it? Who do you know who is still using an OSX Server? None are in use where I work and no malware has gotten through to any of the Macs on our network. This article is a BIG FAIL, probably written by a Microsoft Shill.
To Alex
Quote
Let me know if you have any questions.
Unquote
(If you are able to say or answer)
Was the OS X server potential attack vector shared with Apple before going public?
Yes
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.
If there is no OSX Server to connect to, what then?
And again I ask, what if no Mac OSX Server is in use on the network? But let's go one better. Let's say that you have Macbooks that are ONLY connected to the Internet via WiFi access points but aren't logging into any domain, NOR any Mac OSX server and are therefore NOT getting updates from any Mac OSX Server? What can your tool do under those circumstances? This is a situation under which I've worked previously. The Windows PC's logged into the Domain. The Macbooks did not. Since these Macbooks weren't connected to a Domain or Mac OSX Server, it's not possible to infect or control an OSX Server and hack the network, is it?
Seems the solution to this problem is simply to NOT have an OSX Server anywhere on your network, isn't it? It's not rocket science.
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.
Which is to say, to increase security, do the following:
Apple logo -> System preferences -> Sharing
By default, uncheck all but "Remote login".
ALWAYS, uncheck "File Sharing" and "Screen sharing".
Do I have that right?
That's a good plan.........................................
Yes.
Make sure to set up an authorized_keys file and disable password authentication in the SSH configuration.
Understood
Then we are thinking along the same lines, Mr. Stamos.
And to the offer, I retract my statement in the thinking that you could be a "Microsoft Shill". I'm quite satisfied based on our e-mail conversation, that you are not a "Microsoft Shill". My statement was not meant to be a personal attack of any kind, however we often find articles for or against both Microsoft and Apple technologies that may give the appearance that a Shill is at work. In your case, I stand corrected and since I made a public statement that has been proven inaccurate, I retract that statement (You're not a Microsoft Shill).
I trust said retraction meets with your approve, mate?
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?
BEWARE OF BAD HEADLINES, SECURITY CONSULTANTS SAY
Kind of sad that said consultants had to correct the article headline, and content.
Does not compute.
I am disgusted to find that this thread has descended into a sensible and grown-up discussion. This is not the behaviour I expect on El Reg and demand something be done or I shall be written to the Daily Mail!
I'm not surprised
Not too surprising. Mac is an incredibly unpopular enterprise computer so they haven't had to deal with it too much. I'm sure if they become a popular enterprise machine they'll do something about it.
propriewhaaaaa
"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"
I believe Server Admin uses HTTP, Apple Remote Desktop uses SSH and VNC, and Bonjour/mDNS is an open standard that anyone can use. The protocol draft will have a very familiar name in it if you go to the IETF.
Zeroconf/mDNS isn't remotely proprietary. Even Ubuntu uses it for service discovery. If you don't want it, you don't have to use it in any event. It's optional.
This topic is closed for new posts.
