Slashdot Mirror
Mac OS X Security Competition Ends in 30 Minutes
ninja_assault_kitten writes "ZDnet is running an article on how a Swedish Mac OS X enthusiast held a competition to prove how good security was on his new fully patched Mac Mini was. Unfortunately, 30 minutes after the competition began, a hacker known as 'gwerdna' had broken in and defaced the website, thus winning the contest.
According to gwerdna, 'Mac OS X is easy pickings for bug finders. That said, it doesn't have the market share to really interest most serious bug finders.'." It's also worth noting a piece that says all the security news is much ado about nothing, in practical terms. The security contest also allowed people to have local access via SSH, so that had a lot to do with the crack.
It's a Mac. You don't _keep_ SSH on. It's disabled by default. You have to turn it on deliberately.
What I say does not represent the views of my employers, my friends, my cats, or myself.
The problem wasn't even that he had SSH running. It was that he was giving out accounts! I don't know what this guy was trying to prove, but his blind faith in Apple got him burned.
Somewhere inside of Apple, engineers are shaking their heads at this guy and the damage he's done to the Mac's reputation.
Javascript + Nintendo DSi = DSiCade
I've always thought OS X was more hackable than its supporters tend to say. The very fact that, until recently (like, early 2005), you could set something like this up:
1. Set up page to "redirect" to a .sit or .zip if Safari is the browser.
2. Have trojan in .zip or .sit associate itself with many common types of file, especially uncommon variants of popular files (MPEGs, for instance, seem to randomly pick whether they're Quicktime, VLC, MPlayer, or just not associated with anything, files in OS X)
3. Wait (giggling with insane glee)
Apple fixed the bug exploited in (2) above sometime in early 2005 by having the OS warn you if it was running an application for the first time. For those who are scratching their heads though: Safari, by default, opens "safe" files. This means that step one would have caused the .zip or .sit to be downloaded and extracted on the user's desktop without any user intervention. Once an application is present on a hard drive, it's already installed. In OS X (as with previous versions of Mac OS), applications include associated metadata that tells the OS "I'm an application, and I open files of types JPEG, WDOC, and CARP." If the user hasn't already associated a specific application with a specific file (because, for instance, you just downloaded it from the Internet), then opening a new file will generally cause the OS to search for applications that can open that type, pick one, and open it.
Why am I talking about an old bug? Well, this was present in Mac OS for years, and nobody did anything about it, nobody even considered it a bug until relatively recently. Despite all the crap that's leveled against Microsoft on the same subject, some justified, much not, Apple's attitude towards security is not much better.
If you can get a user to open an application, then you have some access to their machine. If root privileges are gainable from a regular account, then you have root access to their machine.
And all this time I thought you'd have to do the social engineering step of, perhaps, waiting for an application that causes the "Type in an administrator username and password" dialog to come up (perhaps Installer.app, or.. perhaps... Software Update...) and throw a dialog over it that looks identical. It's easier than I thought.
You are not alone. This is not normal. None of this is normal.
True, a Mac Mini isn't typically going to be used as a server, but if Apple decides to make some kind of Intel based server, this kind of thing is a HUGE problem.
Not necessarily. The mac mini is a desktop and has a lot of software installed on it that would be deemed a security risk in production environment. Ever hear of using a complier to shell out? That is why compilers are usually left off of servers for security reasons. Your average linux/bsd desktop box with all the goodies installed probably would not have lasted much longer.
New here, huh?
Dave works and is a rather high profile Mac admin at UWisc.
There are two types of people in the world: Those who crave closure
Not saying there's anything wrong with this, Solaris, FreeBSD, et al are the same, but while SSH may need enabling on a Mac desktop, it does not appear to on a Mac server.
Of course SSH is on by default on a Mac Server--it is designed to run, and be configured from first boot, headless. That would be pretty difficult to do if you had no services. Other default services are Apple Remote Desktop, for GUI control, and the Server Admin Suite; even the Apple Server Admin Tools can be port forwarded through SSH if you prefer.
The assumption is that servers will be managed by those with a clue, whereas desktops will not usually be. Also, no Mac desktops are expected to be configured and maintained headless from first boot, whereas you have to specify a video card for an Xserver for it to be graphical at all. I don't think those are unreasonable assumptions to make.
--
$tar -xvf
Are you telling me that they're no better than Windows when it comes to privilege separation and preventing a low-privilege user account from taking control over the system?
Yes and no. If your admin locks the machines down tight, then it's quite possible that the Mac servers are more secure than the Windows servers. Left with default settings, they're both highly vulnerable to anyone who already has access to the machine and is determined to find a hole. (Whether it be a buffer overflow in a priviledged service, or a soft link that gave elevated permissions.)
Systems are extremely hard to secure once untrustworthy individuals have access to them. That's why there's a market for products like Trusted Solaris and Trusted Linux. If you need high security against local users, you can't trust anyone. Not even root.
Javascript + Nintendo DSi = DSiCade
Funny. Sourceforge gives out SSH accounts to anyone and their dog.
Indeed. And every once in a while, Sourceforge gets hacked. And they have a trained staff of admins who attempt to very carefully lock down the systems and separate the user logins from the systems that run web services and code repositories. (Which is why you can't blow away your own code tree. You have to ask SF to do it.)
The only thing that's funny here (which isn't even funny) is that an inexperienced admin made his box 100% public without taking the standard precautions that every admin worth his salt would take. He blindly trusted that his Mac would be configured to do something it wasn't designed for, and he got burned. Well, DUH. I had a friend who's RedHat Linux box was remotely rooted several times without the attacker being given a shell account. Does that mean that Linux sucks at security?
Javascript + Nintendo DSi = DSiCade
Um, you are talking about OSX vs OSX Server. Which *Does* ship with these services enabled by default.
:-/
Which was also not what was compromised. Kind of nice for the GP to switch topics like that.
I want to know more details about this incident.
The machine was a Mac Mini "running a default install of OS X Tiger, plus fink and some decent versions of Apache, MySQL and PHP. Software Update recently updated it to Mac OS X 10.4.5 and fixed some security issues." It's colored orange for some odd reason, and sits on a bookshelf sideways. He, "set up an LDAP server and linked it to the Macs naming and authentication services, to let people add their own account to this machine."
This is all available on his webpage.
Basically, the guy is a moron. He thinks he's proving something by making a Desktop configured machine do server-class work, and then expect it not to get rooted.
Was it a local privelage escalation flaw?
Yes. The exact hole has been withheld, but it probably doesn't matter anyway. In a contest of machine vs. hacker where the owner is doing nothing to stop the hacker (and in fact, inviting him by removing barriers!), my money is on the hacker.
Was it a remote flaw in SSH or Apache? Maybe an SSH password attack?
The guy gives out SSH accounts. There was no need to penetrate this layer of security, because he left the door wide open.
Javascript + Nintendo DSi = DSiCade