U of Wisconsin's Mac OS X Security Challenge

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

Comments

Prove it!

[Bromskloss]

Can you prove ZDNet wrong, or can you show that Mac OS X can really be hacked in less then 30 minutes?

So guys, what do you say? Should we all mabye prove ZDNet wrong by not breaking into that computer?

Re:Prove it!

[CheeseburgerBlue]

The poster then promptly disappeared in a puff of logic.

Re:Prove it!

[Ford Prefect]

I was appalled that someone might have hacked into this machine and thus given the impression that MacOS X was somehow ... insecure, so I hacked into it myself and patched it up with some new security features.

So to anyone wanting to compete in this challenge: sorry. :-(

A Different Test

[Paradise Pete]

While I appreciate this test, and expect it to not be breached, it is simply not the same test. The original test was to see if a regular local user could elevate its privileges to admin. The fact that the "proof" was to be done by changing a web page is a red herring. The real story was that someone was (apparently) able to do that.

This test is of the web server, and of remote cracking without local access. Also, the explanation page says that the original article did not mention that local access was given. Well, perhaps they've updated the article, but it certainly says so now:

"Participants were given local client access to the target computer and invited to try their luck."

As I said, I appreciate this test, but I am also concerned about the apparent ability of an ordinary local user to gain admin status.

Re:A Different Test

[mekkab]

I think you can't "see the forest for the trees."

The original test was equivalent to saying "I'll let a thief into my house. Let's see if he can steal anything!" Most houses don't have everything bolted down to the floor.

But how often do you allow someone into your machine? For A desktop, not often, perhaps never.

The biggest risk to most computers is a network based attack; this is the real meat and potatoes and a better test of the security of a machine.

Re:A Different Test

[daveschroeder]

Yes, they updated the article.

And the whole point isn't that the test "isn't the same". This is how most Mac OS X machines will appear to outside entities on the internet. The original article - and definitely before it was updated - left people with the impression that a Mac OS X machine could be owned in 30 minutes just by being connected to the internet, without the user "doing" anything, and the subsequent coverage of this in most press proves it. None speak to the fact that a local account was given, or even explore the implications. What could have been a useful article was useless, vague sensationalism. I updated the bottom of the page this morning:

Update

The ZDnet article has been updated to include the sentence, "Participants were given local client access to the target computer and invited to try their luck." But might it not have been interesting to explore:

- What are the implications of local account access, and under what conditions might a computer be used in that way?

- How can such access normally be obtained? Do home users behind firewalls and with no ports open need to worry?
How can a vendor fix the claimed local privilege escalation vulnerabilities when they are not informed of the issue?

- What are the moral and ethical implications of knowing about allegedly severe vulnerabilities in products, like the "hacker" they interviewed, and actively choosing to NOT give the vendor an opportunity to fix the problem(s)?

- How might a Linux or BSD distribution, other commercial UNIXes, or Windows stand up to a similar challenge, where anyone who wishes is given local account access?

- A discussion about how since much of OS X is closed, this might make it more difficult for the community to discover - and report and fix - potential vulnerabilities in the closed pieces

...and things of that nature, instead of leaving people with the impression that any Mac OS X machine connected to the Internet can be taken over in 30 minutes?

Re:A Different Test

[Paradise Pete]

The original test was equivalent to saying "I'll let a thief into my house. Let's see if he can steal anything!"

I don't think that analogy is quite apt. It's more like locking someone in your basement and they figure out how to gain access to your whole house.

When I run a third party program I am essentially letting them inside, but as a non-priviledged user I'm confining them to a specific area. But if this ability to elevate privileges turn out to be a fact, then any program I run can have full access.

Right now we have only this one supposed demonstration of it. What I'd really appreciate seeing is that *original* test repeated. If we can look at this as if it were an experiment, then when someone publishes a result others try to repeat it under the same conditions. They don't conduct a different test with different conditions in order to disprove the original.

Re:A Different Test

[Stalyn]

If we can look at this as if it were an experiment, then when someone publishes a result others try to repeat it under the same conditions. They don't conduct a different test with different conditions in order to disprove the original.

Science never enters the picture here, this is a religious debate.

Logs

[Bromskloss]

Mabye logs could be published (in real-time) so that we all can see some of what possible challengers are up to. That would be interesting.

Possible Danger

[zaguar]

Email das@doit.wisc.edu if you feel you have met the requirements, along with the mechanism used. The mechanism will then be reported to Apple and/or the entities responsible for the component(s).

With virus/spyware becoming a multimillion dollar business, do you really think that the real hackers (sorry for the use of the term) will stay away from this, due to the this very condition. Do you think that the dangerous exploits and cracks that are, for the moment, unknown by Apple, and are hence, very valuable. They will not be willingly sent to Apple for some minor publicity and no material, no, they will be auctioned off in some sleazy IRC channel in Russia.

Generic smear campaign

[catwh0re]

I've noticed a significant rise in anti-macosx articles recently. To the point where I'm beginning to believe that it is staged. Each article usually has 3 points to make: Mac OSX is not *nix, Max OSX is insecure and "easy" to hack (and not a target due to small install base.) and that Apple are slow with patches to security faults.

So far each article has been based on unique situations that lack credibility to begin with, give little detail, and take focus away from the fact that it's basically a machine running a collective of industry proven software (such as apache and openssh.)

Also of note is that Mac OSX currently has an a user base of over 10 million machines. So the argument that it's too small a target is ridiculous. In fact it's a bigger target as it's untouched territory with a bonus of headline making news.

Re:* yawn *

[plate_o_shrimp]

[quote]I'd rather have a nice manual ... on how to improve/lock down an OS X machine.[/quote] There's this..... http://www.nsa.gov/snac/downloads_macX.cfm

Your wish has been granted:

[daveschroeder]

Corsaire - Securing Mac OS X Tiger

NSA - Mac OS X Security Configuration Guide (not yet updated for Mac OS X 10.4)

Apple - Common Criteria configuration guide

And for the "average joe"?

- Keep your machine patched
- Don't randomly open ports for services you don't use
- Have a personal firewall/router
- Don't run software you don't trust

And this doesn't "prove" anything, except that the initial ZDnet article was totally vague and sensationalistic, making it seem to an average person reading that article that a Mac OS X box could just be "hacked" by being on the internet. That is wrong, and I'm showing that. Simple. It's all explained on http://test.doit.wisc.edu/

Easy, To Do

[LifesABeach]

The process is pretty simple, "It's too expensive to compromise the Hardware, but the Humanware; That's cheap, and easy. First your dog/pet/loved is shoot, dead, in front of you. The next comes easier. The gun is pointed at you, and you are given 2 minutes to change the web page to some off topic theme. If you are given an extra 5 minutes, you'll learn Photoshop so that you can put an image of you doing it to a male Shetland pony in front of the members of the supreme court, all looking down on you and smiling in that knowing fashion." The D.O.D. Security Instructor that said this to me didn't even bat an eye; That's the chilling part.

Re:Easy, To Do

[SEWilco]

"...dog/pet/loved is shoot, dead"

• We're talking about a nerd. In Wisconsin.
• You can't hack your own web page in 2 minutes after your computer has been shot dead.

No, you're still wrong about the REAL problem

[xiphoris]

The real problem is that tests like this are garbage in the first place.

In fact, Bruce Schneier (a respected cryptographer, responsible for Blowfish) addressed the topic thoroughly almost 8 years ago in his column Crypto-Gram. Here's a relevant snippet:

You see them all the time: "Company X offers $1,000,000 to anyone who can break through their firewall/crack their algorithm/make a fraudulent transaction using their protocol/do whatever." These are cracking contests, and they're supposed to show how strong and secure the target of the contests are. The logic goes something like this: We offered a prize to break the target, and no one did. This means that the target is secure.

It doesn't.

Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so.

You can read the original here.