Post by Swamp Gas on Mar 7, 2006 12:21:42 GMT -5
In response to the recent "hacked a MacMini in 30 minutes" article.
test.doit.wisc.edu/
www.rixstep.com/1/20060306,00.shtml
Mac OS X Security Challenge
Mon 7 March 2006 8:45 AM CST
Welcome, slashdot.
Mon 6 March 2006 9:00 PM CST
This challenge will end on Fri 10 March 2006 10:00 AM CST
This machine will be moving to a new network soon; the cutover will be transparent
Mon 6 March 2006 10:00 AM CST
In response to the woefully misleading ZDnet article, Mac OS X hacked under 30 minutes, the academic Mac OS X Security Challenge has been launched.
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 local account access
Not even have any ports open
In addition to the above, most consumer machines will also be behind personal router/firewall devices, further reducing exposure
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. 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). Going after other hosts/devices on the network is out of bounds.
Mac OS X is not invulnerable. It, like any other operating system, has security deficiencies in various aspects of the software. Some are technical in nature, and others lend themselves to social engineering trickery. However, the general architecture and design philosophy of Mac OS X, in addition to usage of open source components for most network-accessible services that receive intense peer scrutiny from the community, make Mac OS X a very secure operating system. There have been serious vulnerabilities in Mac OS X that could be taken advantage of; however, most Mac OS X "vulnerabilities" to date have relied on typical trojan social engineering tactics, not genuine vulnerabilities. The recent Safari vulnerability was promptly addressed by Apple, as are any exploits reported to Apple. Apple does a fairly good job with regard to security, and has greatly improved its reporting processes after pressure from institutional Mac OS X users: Apple is responsive to security concerns with Mac OS X, which is one of the most important pieces of the security picture.
The "Mac OS X hacked under 30 minutes" story doesn't mention that local access was granted to the system. While local privilege escalation exploits can certainly be dangerous - and used in conjunction with things like the above Safari exploit - this isn't very informative with regard to the general security of a Mac OS X machine sitting on the Internet.
I have commented a bit on Mac OS X security in general.
Is there a prize?
There is no prize but recognition (if desired). This is an academic effort.
Objections to this test
Some have objected to this test as doing nothing more than testing the security of apache or ssh on a PowerPC architecture. That is correct. And that is how most of the world will see Mac OS X externally. The original article was not fair, because it did not note, or even imply, or hint in any way, that local account access was granted. The whole point of Apple using proven open source services like OpenSSH and apache on Mac OS X is exactly because of their secure nature as a result of years of scrutiny by the community. Most users of Mac OS X in a consumer or desktop setting will never even enable any of these services at all. It's unfortunate that the initial coverage was so journalistically poor and sensationalistic on what might otherwise have been an article about an interesting local vulnerability. Instead, it chose to leave people with the impression that a Mac OS X machine can be "hacked" just by doing nothing more that being on the Internet. That is patently false.
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?
What happens if someone is successful?
It will be reported on this site. It also means there is a serious, as-yet-unknown problem, likely with Mac OS X's shipping implementations and configurations of apache or OpenSSH. If so, I'd sure like to know about it!
Important note
This page may be updated by me. Any changes will be announced via this site. Last update: Tue Mar 7 09:46:26 CST 2006
Contact information/media inquiries:
Dave Schroeder
University of Wisconsin
das@doit.wisc.edu
+1 608 265-4737
test.doit.wisc.edu/
www.rixstep.com/1/20060306,00.shtml
Mac OS X Security Challenge
Mon 7 March 2006 8:45 AM CST
Welcome, slashdot.
Mon 6 March 2006 9:00 PM CST
This challenge will end on Fri 10 March 2006 10:00 AM CST
This machine will be moving to a new network soon; the cutover will be transparent
Mon 6 March 2006 10:00 AM CST
In response to the woefully misleading ZDnet article, Mac OS X hacked under 30 minutes, the academic Mac OS X Security Challenge has been launched.
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 local account access
Not even have any ports open
In addition to the above, most consumer machines will also be behind personal router/firewall devices, further reducing exposure
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. 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). Going after other hosts/devices on the network is out of bounds.
Mac OS X is not invulnerable. It, like any other operating system, has security deficiencies in various aspects of the software. Some are technical in nature, and others lend themselves to social engineering trickery. However, the general architecture and design philosophy of Mac OS X, in addition to usage of open source components for most network-accessible services that receive intense peer scrutiny from the community, make Mac OS X a very secure operating system. There have been serious vulnerabilities in Mac OS X that could be taken advantage of; however, most Mac OS X "vulnerabilities" to date have relied on typical trojan social engineering tactics, not genuine vulnerabilities. The recent Safari vulnerability was promptly addressed by Apple, as are any exploits reported to Apple. Apple does a fairly good job with regard to security, and has greatly improved its reporting processes after pressure from institutional Mac OS X users: Apple is responsive to security concerns with Mac OS X, which is one of the most important pieces of the security picture.
The "Mac OS X hacked under 30 minutes" story doesn't mention that local access was granted to the system. While local privilege escalation exploits can certainly be dangerous - and used in conjunction with things like the above Safari exploit - this isn't very informative with regard to the general security of a Mac OS X machine sitting on the Internet.
I have commented a bit on Mac OS X security in general.
Is there a prize?
There is no prize but recognition (if desired). This is an academic effort.
Objections to this test
Some have objected to this test as doing nothing more than testing the security of apache or ssh on a PowerPC architecture. That is correct. And that is how most of the world will see Mac OS X externally. The original article was not fair, because it did not note, or even imply, or hint in any way, that local account access was granted. The whole point of Apple using proven open source services like OpenSSH and apache on Mac OS X is exactly because of their secure nature as a result of years of scrutiny by the community. Most users of Mac OS X in a consumer or desktop setting will never even enable any of these services at all. It's unfortunate that the initial coverage was so journalistically poor and sensationalistic on what might otherwise have been an article about an interesting local vulnerability. Instead, it chose to leave people with the impression that a Mac OS X machine can be "hacked" just by doing nothing more that being on the Internet. That is patently false.
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?
What happens if someone is successful?
It will be reported on this site. It also means there is a serious, as-yet-unknown problem, likely with Mac OS X's shipping implementations and configurations of apache or OpenSSH. If so, I'd sure like to know about it!
Important note
This page may be updated by me. Any changes will be announced via this site. Last update: Tue Mar 7 09:46:26 CST 2006
Contact information/media inquiries:
Dave Schroeder
University of Wisconsin
das@doit.wisc.edu
+1 608 265-4737