Hide full article
In the beginning, the concept was simple: pay $10,000 to anyone who could bypass the security on a Macintosh Web server using only off-the-shelf software to protect the system (see TidBITS-303). From 15-Oct-95 to 31-Nov-95, digital.forest, ComVista Internet Solutions, Westwind Computing, Maxum Software, StarNine, and WebEdge Technologies sponsored the $10,000 Macintosh Web Security Challenge. Anyone who could break through the security on a designated server and retrieve the protected information would receive $10,000. The goal was to raise awareness of the fact Macintosh servers make the most secure platform for World Wide Web servers.
The Plan -- Our original plan was to protect a single page on the Web server so only one person would have access to it. After some consideration, we decided to make the challenge even more enticing by allowing users to see the page and only protect one line on the page. The only software used was StarNine's WebSTAR (the Web server) and NetCloak (a CGI application from Maxum Development). Security was provided in two ways. We used WebSTAR's Realms capability to require a username and password of anyone viewing the secure page, and we employed the filtering capability of NetCloak to hide the secure line on the page from anyone who did not provide both the proper password and come from the proper IP address. The server was available at challenge.comvista.com (it is no longer on the Web) and Henry Norr of MacWEEK was enrolled as the "authorized user" with access to the secure page. Henry logged in during the Challenge to verify that the page was, in fact, available to the proper user while still denying all others.
<http://www.starnine.com/>
<http://www.maxum.com/>
Challengers were given a username and password to access the page, as well as Henry's username (just to get them started), the IP address of the server, information about our AppleTalk and IP network, and a listing of the software available on the server. Occasionally, we received requests for additional information about the setup and, with the exception of the password and IP address, we answered them. The only restrictions on claiming the prize were that we had to receive notice within two days of the end of the Challenge and the winner had to explain how the feat was accomplished.
Designing the Network -- digital.forest provided the Internet connection for the server and monitored the Web site at the network layer. The network configuration consisted of a burstable T-1 connection to the Internet through a Cisco 2501 router. The network hub was an Asante 24 port non-managed hub, and the Web server itself was an Apple Workgroup Server 8150 with the Apple Internet Server bundle.
When we planned the challenge, I'd hoped to experiment with various network configurations to help isolate traffic. Our original start date was 01-Oct-95, but unfortunately delay of the installation of our T-1 (read about my struggles with GTE at the URL below) did not allow time for network configuration experiments. With the new start date approaching, I settled on the rather flat network architecture of router-hub-server. The server was on the same network segment as all other computers served by our T-1. We didn't need a firewall or packet filter on the router, since all of the CPUs on the network were Macs.
<http://www.forest.net/advanced/isp/ gtesucks1.html>
Watching and Waiting -- This network configuration made traffic analysis more of a bother than I would have liked, but it wasn't impossible. Apple Computer Northwest loaned me a Quadra 630 for a monitoring station, but I rapidly discovered NetMinder Ethernet from Neon Software would not work with the 630's communication slot Ethernet card. Disappointed, I used my trusty PowerBook 165 with an Asante SCSI Ethernet adapter. I experienced a performance loss running through the SCSI adapter, but I could still track what was going on behind the scenes.
The Results -- In the 45 days the contest ran, no one broke through the security barriers and claimed the prize.
I generally ran the network packet analyzer for three to five hours a day to check for interesting packets destined for the Challenge server. I created packet filters that captured all TCP/IP network traffic in or out of the Challenge server. (Hint to Neon: drop the limit of five packet filters - it's frustrating when you want to do advanced filtering). Some things I saw were amusing, others downright hilarious.
The Mac OS is not Unix -- One of the more amusing things was that with all the information and technical specifications posted on the server itself, most people who tried to bypass the security thought the server was a Unix box! People tried to telnet and send mail to the server, looking for a process they could exploit. These types of attacks were fairly regular during the course of the challenge. I still smile when I think about how many people saw:
% telnet challenge.comvista.com
telnet> Connection refused.
(A hint to crackers: there's no shell in the Mac OS to talk to, and even if we ran a mail server, you still wouldn't be able to mail yourself /etc/shadow. The Mac just doesn't work that way.)
People also tried to FTP to the server, looking to either put something on the server, or copy something from it. Again, this was a fruitless exercise as there was no FTP server on the Challenge server.
Things became more interesting, however. I noticed a fair amount of UDP (User Datagram Protocol) traffic coming from various computer science departments in universities. It appeared some enterprising students had written scripts that went up the UDP and TCP port numbers, looking for hidden processes that could be attacked. We did not run any TCP/IP processes other than the Web server on port 80, so all this did was waste bandwidth.
Another MacTCP Quirk -- There was also quite a bit of ICMP (Internet Control Message Protocol) redirect packet traffic on the network. As I traced them back to their source, they turned out to be from people trying to do traceroutes to the Web server. Something I was unaware of until the Challenge was that MacTCP does not respond to ICMP packets properly, making traceroutes to MacTCP hosts impossible. The packets time out at the closest gateway to the host because the Mac never responds to them. I confirmed this by running my own traceroutes to the Challenge server from a Unix host and comparing those packets with those coming from outside sources. Open Transport fixes this behavior, and it is now possible to do a traceroute to a Macintosh host that uses Open Transport.
This particular quirk of MacTCP begat an email message from a gentleman saying our challenge was unfair because he could not perform a traceroute to the server. After I pointed out that this was a failure of MacTCP and not anything I had done, he backed off. He then pointed out that it would be trivial to snoop the password to the locked page, yet for some reason he did not step forward to collect the $10,000. I wonder why?
Summary -- On the whole, I learned that network-level security on the Macintosh is really quite good. Unlike Unix, there are no TCP/IP server processes built into the Mac OS, so there is nothing to attack unless you put it there yourself. In addition, TCP/IP services on a Mac lack the low-level communications available on Unix systems, which provides additional security. If you keep mail, FTP, and Web file spaces from overlapping, there is no way to pipe data from one service to another.
One note about server design: when installing multiple TCP/IP services on a single machine, be certain there is no way to upload a file with one service and make it available to another. If a user can FTP files directly into Web server file space, that user could upload a CGI application and immediately launch it.
In sum, the Challenge did nothing to contradict our belief that if you have a Macintosh-only TCP/IP Internet-connected network, you have little to fear from outside intruders coming from the Internet. Further, if you are running a Mac Web server, there appears to be no way to compromise it from the network level. However, if you have a Unix computer within your network, you must still safeguard and protect that machine lest it become compromised and provide a close and easy platform for launching other attacks.
A Closing Warning -- Please note these results do not mean the Mac community can ignore security; on the contrary, we need to be even more on our toes for security breaches, simply because they will most likely come from an unexpected vulnerability. Most of the attacks attempted were based on known vulnerabilities in Unix systems. Once Macs become more popular as servers and make their way into larger commercial networks, crackers will have more incentive to compromise these systems.
In addition, it is not our contention that this contest proved anything about Macintosh network security, or that such a contest could replace quality testing for flaws in server software. In fact, we would not have risked our money if we had not first convinced ourselves of the security of the system.
Finally, it is possible that a cracker did bypass our security and discover the hidden phrase, but is unwilling to come forward because the information is potentially more valuable than the $10,000 reward.
[Chris Kilbourn, <kilbo@forest.net>, is President, System Administrator, and Network Janitor for digital.forest, an Internet service provider in Redmond, Washington. Jon Wiederspan, <jon@comvista.com>, of ComVista Internet Solutions assisted in preparing this article.]
