Slashdot Log In
Mac OS X Security Competition Ends in 30 Minutes
Posted by
Hemos
on Mon Mar 06, 2006 11:54 AM
from the how-secure-is-secure dept.
from the how-secure-is-secure dept.
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.
Related Stories
[+]
U of Wisconsin's Mac OS X Security Challenge 401 comments
digitalsurgeon writes "The University of Wisconsin [ed: Go Badgers] has launched a Mac OS X Security challenge, in response to a 'woefully misleading ZDnet article'. From the site: 'The challenge is as follows: simply alter the web page on this machine, test.doit.wisc.edu. The machine is a Mac mini (PowerPC) running Mac OS X 10.4.5 with Security Update 2006-001, has two local accounts, and has ssh and http open - a lot more than most Mac OS X machines will ever have open.' Are you up to the task? Can you prove ZDNet wrong, or can you show that Mac OS X can really be hacked in less then 30 minutes? More information about the challenge is at http://test.doit.wisc.edu/ The challenge ends Fri 10 March 2006 10:00 AM CST." Update: 03/07 14:32 GMT by Z : Commentary on the contest and original claim is available at VNUNet
[+]
Slashback: OSX Security, DoD Filtering, Anonymous Posting 211 comments
Slashdot tonight brings some corrections, clarifications, and updates to previous Slashdot stories, including some favorable results from the University of Wisconsin's Mac OS X Challenge, skeptics investigate cold fusion claims, more on DoD web filtering, AT&T cuts 10,000 jobs after BellSouth merger, more child-proofing efforts for MySpace, Why Windows Vista Will Suck: a rebuttal, Harvard Professor punished for reporting bugs, Assemblyman Biondi backpedals on NJ anonymous posting bill, and a followup on Chinese TLDs -- Read on for details.
[+]
IT: Call for Apple Security 'Czar' 254 comments
conq writes "The second security non-incident to hit the Mac platform in as many weeks has been debunked. People are talking a lot about security on the Mac these days, and the result is that a great deal of FUD is being spread around. BusinessWeek's latest Byte of The Apple column suggests that its time for Apple to appoint a security Czar to get out ahead of the FUD before it spreads much more." From the article: "Creating a CSO position may be viewed by some as an admission of weakness. Still, I say it would be a good way for Apple to inoculate itself against the perception -- warranted or not -- that Mac security may be eroding, and get ahead of the curve for any troubles that may be inevitable. That may not be the case, but in matters related to product marketing, it's the public perception, not the reality that really matters. And once you've lost a user's confidence, it's hard to get it back. Just ask Microsoft."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
gwerdna? (Score:5, Interesting)
What kind of hacker do you suppose he is? gwerdna is a pretty poor anagram of Andrew G.
If that's not his name, it's fairly random.
He's been using it since the end of 2004 at least. http://p212.ezboard.com/bnendowingsmirai.showUser
Mac OS X Security Challenge (Score:5, Interesting)
In response to the woefully misleading ZDnet article, Mac OS X hacked under 30 minutes, I have decided to launch a Mac OS X Security Challenge.
The ZDnet article, and almost all of the coverage of it, failed to mention a very critical point: anyone who wished it was given a local account on the machine (which could be accessed via ssh). Yes, there are local privilege escalation vulnerabilities; likely some that are "unpublished". But this machine was not hacked from the outside just by being on the Internet. It was hacked from within, by someone who was allowed to have a local account on the box. That is a huge distinction.
Almost all consumer Mac OS X machines will:
- Not give any external entities access
- Not even have any ports open
The challenge is as follows: simply alter the web page on this machine, test.doit.wisc.edu (128.104.16.150). The machine is a Mac Mini (PowerPC) running Mac OS X 10.4.5 with Security Update 2006-001, has two local accounts, and has ssh and http open - a lot more than most Mac OS X machines will ever have open. Email das@doit.wisc.edu if you feel you have met the reqiurements.
Re:Mac OS X Security Challenge (Score:5, Funny)
Parent
Re:Mac OS X Security Challenge (Score:5, Informative)
Dave works and is a rather high profile Mac admin at UWisc.
Parent
Re:Mac OS X Security Challenge (Score:5, Insightful)
Whilst I agree that this is not the same as a remote exploit, do not underestimate the seriousness of local privilege escalation.
For instance, an unpatched local privilege escalation, used in conjuction with the vulnerability discussed in this article [slashdot.org] could result in a rooted machine - simply from visiting a hostile website (or even a website you visit regularly, that runs IIS and has been hacked itself)
I don't believe (as some pundits seem to) that Mac OS is a Microsoft style security disaster only awaiting the attention of hackers to happen - but I do believe that Mac owners are going to have to start paying a little more attention to security matters then they currently are.
Parent
Re:Mac OS X Security Challenge (Score:5, Informative)
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.
Parent
local account = assumed root access (Score:5, Interesting)
It like giving physical access to a machine. If you give physical access to any linux machine, its not hard to log onto it. (this is why you lock up the machines!)
Doors unlocked, windows open (Score:5, Funny)
So SSH was on and accessible? Dumb move. Like saying "I dare you to steal my jewelry from my bedroom -- oh, and my house is unlocked with the windows open."
But maybe people WANT something to be stolen. Many years ago, the garbagemen (sanitation workers) in NYC went on strike, and garbage was piling up in the streets. A relative of mine in Brooklyn still managed to get rid of his: he put it in big boxes, wrapped the boxes in gift paper with bows, and left them in his car with the doors unlocked. They always got stolen.
How this applies to the story, I dunno, but I still think it's funny.
Astroturfing? (Score:5, Interesting)
The whole article seemed to culminate in the following information: some guy said if Macs were more popular they would have a worse record than "other operating systems." It seems to be comparing OS X to Linux, but it isn't entirely clear what the baseline is for their eval of Mac OS.X and it also doesn't clarify what exactly makes these OSs different. Also, the web site defacement isn't proof that the person with an unprivileged account acquired superuser privileges to do anything other than deface the web page. I don't doubt it could have happened, but maybe it did and maybe it didn't...
Also, giving people LDAP accounts on the machine is really cheating. Maybe some noobs get a boner when someone fuzzes the hell out of a box from a local account until they get some fuzz escalated **BORING**. If they really wanted to throw down the gauntlet, then we would see Mandatory Access Control [freebsd.org] implemented on OS X . The big difference is that the MAC policies would be enforceable at the Mach [stepwise.com] MK level (on Mach ports, tasks, processes...), and OS X would be the ONLY OS with a security policy interface that could come close to usable for average people.
Re:Why keep SSH on? (Score:5, Informative)
Parent
Re:Perhaps with a desktop Mac (Score:5, Informative)
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.
Parent
Re:Perhaps with a desktop Mac (Score:5, Insightful)
I think there are probably some also remote-administration services running by default on Server, but don't quote me on that. I know for sure that ssh is not running on regular, consumer MacOS, however. (I just set up a new G5 a few days ago and I had to turn it on manually.)
I think it's also worth pointing out that based on my understanding of the article in question here (the second link in the summary doesn't point to what I think it originally did), ssh wasn't just running on the machine, attackers were allowed to log-in as a non-root user. So really what happened wasn't a cracking in the strict sense, but privilege escalation. Still bad -- and I'm rather annoyed that "gwerdna" or whatever his name was didn't tell us what this great "unpublished and unreported vulnerability" was that he used, but I don't think that it means that any box is compromisable simply by virtue of running sshd.
Parent
Re:Why keep SSH on? (Score:5, Informative)
Somewhere inside of Apple, engineers are shaking their heads at this guy and the damage he's done to the Mac's reputation.
Parent
Re:Why keep SSH on? (Score:5, Insightful)
Parent
Re:Why keep SSH on? (Score:5, Insightful)
Parent
Re:Why keep SSH on? (Score:5, Informative)
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 [nyud.net].
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 [nyud.net] SSH accounts. There was no need to penetrate this layer of security, because he left the door wide open.
Parent
RDF defeats all (Score:5, Funny)
I have a feeling that the Reality Distortion Field has already cancelled whatever negative effect this has had
Parent
Re:Why keep SSH on? (Score:5, Insightful)
Considering that the picture of the machine posted on the web site (which now seems to be unavailable) showed it sitting on a shelf next to Windows programming books, I'm guessing that his "blind faith" is in something other than Apple, and his motiviation was to generate the misleading buzz that ZDNet and Cnet are facilitating.
Parent
Re:Why keep SSH on? (Score:5, Informative)
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.
Parent
Re:Why keep SSH on? (Score:5, Insightful)
SSH is off by default, the admin had to turn it on.
Hackers don't generally have shell accounts -the admin had to set them up.
So if you take steps to make the Mac Mini less secure, then advertise you've done so, it gets hacked. Expect all major tech outlets to cover this new and amazing Mac vulnerability (you think I'm joking?).
Parent
Re:Why keep SSH on? (Score:5, Informative)
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.
Parent
Local access IS important! (Score:5, Insightful)
Parent
Re:Lord, save us from morons (Score:5, Insightful)
This configuration absolutely sucks for a home user.
A home user can't install new software without providing a root (or sudo) password everytime they want to try a software package, they can't update the system configuration from the GUI, they can't start and stop their personal webserver, they can't look at the drive space remaining without having to decode a complex partitioning scheme, they can't do a lot of things that Mac OS X lets them do without interfereing. If Mac OS X *did* restrict these activities, users would balk at the user-unfriendliness and go back to Windows.
So it comes back to a matter of design. It's easy to say, "that should have been secure!", but the costs of making that secure would have been too high for the average home user. Mac OS X's security has been proven to date to be sufficient for what it was designed to do, and has been shown to be at least as secure (perhaps moreso) than your average FreeBSD or Linux desktop. Show me the beef of the problem (i.e. everyday machines being compromised on a scale similar to Windows) and I'll agree with you that Mac OS X is insecure for its intended purpose. Until then, however, I'm going to go with the fact that this guy wasn't thinking straight.
Plenty of people use them for servers as well
Which is why Apple produces OS X Sever Edition.
and apparently OS X isn't secure by default for them.
You show me a server situation that involves hundreds of anonymous, remote logins to a system without any lockdown of the services to move it from a home server to a full-blown webserver, and I'll agree with you. I, personally, can't think of such a situation. Some webhosts provide SSH access, but they certainly don't run a default Linux or FreeBSD installation unless that distribution has been preconfigured for the security they need.
Parent
Re:Lord, save us from morons (Score:5, Informative)
Indeed. And every once in a while, Sourceforge gets hacked [sourceforge.net]. 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?
Parent
Kodos is not yours to give... (Score:5, Funny)
Kang [wanadoo.fr] might have something to say about that.
Parent