Series: Net Security
The Mac OS has long had been a very secure Internet platform... but is that still true?
Article 1 of 6 in series
Like many Mac users, I've been busy this last week installing Apple's Open Transport Tuner 1.0. This patch blocks a potential denial of service attack that can be launched from Macintosh systems running Mac OS 9 and certain CPU configurations running Mac OS 8.6 - see Geoff Duncan's piece in this issue for details on the vulnerability and Apple's fix. John Copeland, a professor at the Georgia Institute of Technology, identified this potential attack after detecting a port scan on his home networkShow full article
Like many Mac users, I've been busy this last week installing Apple's Open Transport Tuner 1.0. This patch blocks a potential denial of service attack that can be launched from Macintosh systems running Mac OS 9 and certain CPU configurations running Mac OS 8.6 - see Geoff Duncan's piece in this issue for details on the vulnerability and Apple's fix.
John Copeland, a professor at the Georgia Institute of Technology, identified this potential attack after detecting a port scan on his home network. Credit should go to Mr. Copeland for discovering this vulnerability, but how this information was disseminated and the Macintosh community's response to it have left something to be desired.
Heads in the Sand -- Many of us in the Macintosh community have become smug about network security, and with good reason. For years, Macs have been the most secure platform for deployment of Internet servers, and have proven repeatedly they are almost invulnerable to network attacks or cracking. Although the Macintosh is still the most secure platform for Internet use, we can neither blithely ignore security issues nor overreact when security issues are identified. In this instance, the confusion was spread by Macintosh news and information services and mixed with a good helping of paranoia regarding Y2K cyber-terrorism. This incident highlights that we as a community don't know how to deal with network security issues, simply because we've rarely had to deal with them before.
Looking to other communities can be instructive for us, and show us how the rest of the computing world has been dealing with their network security issues for years.
Stay Informed & Prepared -- The CERT Coordination Center at Carnegie Mellon University is the global clearinghouse for network security alerts, advisories, and guidance. The CERT team updates their Web site each time a vulnerability is identified, and they rank the level of vulnerability along with providing links to patches. They also run an announcement mailing list so you don't have to check their Web site every day.
There are also hundreds of books available that discuss network security. Books published by O'Reilly and Associates are generally of a high caliber. Nearly all of these titles are concerned with the Unix and Windows worlds, but many principles are generally applicable to any platform.
The BugTraq mailing list is also helpful if you're interested in detailed technical analysis of current computer security issues for any platform.
Another good information resource is the System Administration, Networking, and Security (SANS) Institute. This group runs regular security workshops nationwide and has a Web site full of useful information. Much of their information is geared towards Unix administrators, but that leads me to my next point.
Mac OS X Server and the forthcoming Mac OS X have BSD Unix at their cores. This means once Mac OS X ships and is installed on our Macs, we will be running Unix workstations on our desktops - and we will potentially be just as vulnerable as any other Unix workstation. Although this doesn't mean you will need to become a Unix system administrator to operate your Macintosh, it does mean you should keep yourself informed of network security topics and respond to issues and alerts in a timely fashion.
Handle Problems Responsibly -- For years the Unix community has been dealing with these issues by following some simple steps:
- As issues are identified by end users, programmers, or security professionals, they are reported to CERT and appropriate software vendors
- CERT issues an advisory or alert, and the vendor releases a patch
- Affected users apply the patch, and life goes on
Note that nowhere in this list appear the words panic, fret, worry, or hide. If you're one of the "lucky" people to identify a network security issue, you should:
- Contact CERT
- Contact the vendor(s) of the vulnerable product(s) involved
- Help them to identify and develop a patch
Also note that this list doesn't include tasks like alerting the media, publicly speculating on possible ways of exploiting the problem, or suggesting what end users should do. Advising end users and providing accurate information is the job of CERT and the vendors, and they've been doing it for years.
Evaluate Reports Critically -- Not everyone is a networking expert, and the level of detail available from resources like CERT can be overwhelming. It's not necessary for everyday computer users to follow the technical minutia of network security problems, but folks should know these resources exist so they're better able to evaluate problem reports as they arise. When a new network security problem is reported, consider whether the problem report seems responsible and credible to you, whether the problem has been reproduced by trusted third parties, and whether CERT and software vendors have been informed or issued statements. The Internet can spread misinformation and unfounded speculation as rapidly as it can disseminate critical news and software updates - it's always better to make an informed decision than let haste and trepidation get the better of you. In the immortal words of Douglas Adams (a diehard Mac user), Don't Panic!
[Chris Kilbourn is President of digital.forest, Inc., a Mac-focused
network service provider specializing in FileMaker Pro database web
hosting, server colocation, QuickTime Streaming, and other Internet
Article 2 of 6 in series
It's about time someone realized what we in the Mac Internet community have been saying for years. Even better, that someone is the U.S. Army. Here's the storyShow full article
It's about time someone realized what we in the Mac Internet community have been saying for years. Even better, that someone is the U.S. Army. Here's the story. It seems that on 28-Jun-99, an intruder gained illegal access to the home page of the U.S. Army and modified its contents. Organizations like the Army hate that, and on 30-Aug-99, FBI agents arrested a 19-year-old Wisconsin man for "malicious altering to a U.S. Army Web page" in connection with the incident.
The compelling aspect of this story is that as a result of the break-in, the U.S. Army has switched the machines that serve the Army's home page from Windows NT-based PCs to Power Macintosh G3s running WebSTAR from StarNine Technologies. Christopher Unger, Web site administrator for the Army Home Page, didn't reveal the specifics of what was done to the page, how it was done, or what the Army planned to do to prevent further intrusions, but he did say that the Army had "moved its Web sites to a more secure platform," basing the choice of the Mac OS over Windows NT on information from the W3C (World Wide Web Consortium). Using Netcraft's "What's that site running?" utility, I was able to verify that the Army's main Web server is now running WebSTAR 4.0 on the Mac OS. However, other less-obvious Army Web servers linked from the main Army home page generally run either Netscape Enterprise on Solaris or Microsoft IIS on Windows NT.
There's no telling if the Army will move its secondary servers to the Mac OS to prevent them from being cracked as well, but the W3C does compliment the security of the Mac OS in its WWW Security FAQ, saying "The safest Web site is a bare-bones Macintosh running a bare-bones Web server." In information specific to WebSTAR, the W3C notes:
"As far as the security of the WebSTAR server itself goes, there is reason to think that WebSTAR is more secure than its Unix and Windows counterparts. Because the Macintosh does not have a command shell, and because it does not allow remote logins, it is reasonable to expect that the Mac is inherently more secure than the other platforms. In fact this expectation has been borne out so far: no specific security problems are known in either WebSTAR or its shareware ancestor MacHTTP."
This logic also applies to other Web servers for the Mac OS, such as Quid Pro Quo, AppleShare IP's built-in Web server, NetPresenz, and even Personal Web Sharing.
Old News -- Of course, this information isn't news to the Macintosh Internet community, where the security of the Mac OS and Macintosh Web servers has long been known. In "Macintosh Web Security Challenge Results" in TidBITS-317, Chris Kilbourn outlined the approaches used by would-be-crackers looking to take home a $10,000 prize. Then, in "The Crack A Mac Story" in TidBITS-378, Joakim Jardenberg and Christine Pamp talked about the success of the first Crack A Mac challenge. Geoff Duncan look at the motivations behind a glut of subsequent Mac OS security challenges in "The Mac Security Challenge Fad" in TidBITS-385. And finally, we reported briefly on the successful cracking of the second Crack A Mac challenge, a far more complex setup that was compromised via a long-since patched security hole (See "Cracked!" in TidBITS-393).
What's also old news is Apple's lack of support for the Mac OS as an operating system suitable for use with Internet servers. Since the Apple Internet Server Solution bundles disappeared years ago, Apple has barely acknowledged the reality of running Internet servers on the Mac OS, despite the many happy Mac users relying on Mac OS-based Internet servers. Even now, servers from Apple run Mac OS X Server, which is essentially Unix. There's nothing wrong with Unix-based Internet servers, and for very high-volume sites, they're essential. Even the performance arguments brought up against Macintosh Web servers are essentially moot now, with WebSTAR and Tenon Intersystems' WebTen providing far more performance than most Web sites require. For the vast majority of Web sites, email servers, and FTP servers, the Mac OS and commonly available Mac OS software provide a familiar, easy-to-use solution without the fuss or security issues of Unix or Windows NT.
Looking forward, it's almost inconceivable that Apple would once again put forth the Mac OS as a serious Internet server platform. Companies seldom recant a technical stance, and more important, with Mac OS X in the works, Apple doesn't want to do anything that will reduce Mac OS X's impact. But it remains to be seen how secure Mac OS X will be when exposed to the Internet's crackers. With the power and flexibility of Unix at its base, Mac OS X will certainly be attractive to many classes of users - let's hope that crackers aren't among them.
Article 3 of 6 in series
by Geoff Duncan
Cracked! To the surprise of the Macintosh Internet community, the second-generation Crack-A-Mac Web server security challenge noted in TidBITS-387 was successfully defeated last weekShow full article
Cracked! To the surprise of the Macintosh Internet community, the second-generation Crack-A-Mac Web server security challenge noted in TidBITS-387 was successfully defeated last week. Unlike the first Crack-A-Mac challenge (which featured an out-of-the-box Mac Web server; see TidBITS-378), the second contest was built around a sophisticated server setup featuring third-party software for remote administration, database access, and other functions. Apparently, the successful break-in exploited a security hole in Lasso, a CGI from Blue World Communications that ties together WebSTAR and FileMaker Pro. Blue World has issued a security patch for Lasso; in addition, Pacific Coast has updated its SiteEdit products to address similar potential problems. The Crack-A-Mac challenge is up and running again, and still offering 100,000 Swedish crowns (about $12,500 U.S.) to anyone else who can break in by 15-Oct-97. [GD]
Article 4 of 6 in series
by Geoff Duncan
Computer security - or, rather, computer data security - is not a new idea. For as long as sensitive information has been stored on punch cards, tapes, and disks, money has been changing hands to make sure that information cannot be accessed without permissionShow full article
Computer security - or, rather, computer data security - is not a new idea. For as long as sensitive information has been stored on punch cards, tapes, and disks, money has been changing hands to make sure that information cannot be accessed without permission. Until recently, security tests were often expensive, contracted, protracted affairs conducted by professionals and consulting firms; however, the breakneck growth of the Internet has given rise to something new: public data security challenges. These events usually offer substantial cash prizes and are open to anyone with a machine and a net connection.
Public challenges usually have goals like demonstrating a technology, promoting products or services, and generating media coverage. TidBITS has covered two Mac-specific security challenges (see TidBITS-317 and TidBITS-378); these challenges helped establish the Mac OS as a secure and robust Web server platform, and gave Apple, the Mac, software developers, and the contest sponsors some good press when no one claimed the contests' prizes. However, current public Macintosh security challenges seem more concerned with marketing than security, which does little to further test the limits of Macintosh security.
Apple Europe -- The two previous Macintosh security challenges were conducted by private organizations; now, Apple Europe has thrown its hat in the ring, offering a brand-new 240 MHz PowerBook 3400 to anyone who alters the contents of a specific Web page hosted on a standard Apple Workgroup Server 9650 running Mac OS 7.6 and WebSTAR 2.0.
It's nice to see Apple using new methods to promote the Mac OS as an Internet server platform, but this contest is only about promotion. On a technical level, this challenge imitates the Crack-A-Mac challenge conducted by Infinit Information AB in Sweden this spring - and its public face is a little rougher around the edges. For instance, the contest runs from 04-Jun-97 to 31-Jul-97, but you won't find that information on the challenge server or in the challenge rules: you need a press release or article to uncover the contest dates and a few other pertinent details. Of course, you must read around mellifluous statements about Apple's "complete confidence" in the server - small wonder, given that the prize money in Infinit's contest went unclaimed just a few weeks earlier. There has also been some criticism of the contest prize: prices for 240 MHz PowerBook 3400s start around $5500, so it could be argued there's less financial incentive to break into this server than there was in previous Mac security challenges. That might be true, but perhaps it's more important that winning a PowerBook 3400 appeals to a smaller set of the server-cracking population than cold, hard cash. After all, few Windows or Unix loyalists will spend time trying to win a Macintosh.
VanHacking -- Cash is not a problem for the VanHacking Challenge being hosted by VirTech Communications in Vancouver, British Columbia from 01-Jun-97 to 15-Jul-97. They're offering $10,000 Canadian (about $7,200 U.S.) to anyone who can do two things:
Break into a protected Web page to find encrypted credit card information and a special phrase.
Decrypt the credit card information and alter the wording of the special phrase on the protected Web page.
The VanHacking server is a Power Mac 7200/120 running System 7.5.3, Timbuktu Pro 3.0.2, WebSTAR 1.3.2, and the challenge page is protected with WebSTAR's Realms capability (so you'll be prompted for a password if you try to access it with a Web browser).
On the face of it, the VanHacking Challenge is a new variation on the "alter a Web page" contest, and - by including an encrypted credit card number - the contest confronts the issue of secure electronic commerce on the Internet. VirTech's press release (and Apple's recent promotion of the contest on its corporate home page) plays up this factor: VirTech says it wants to refute the idea "plaguing the media today" that Internet commerce is unsafe and insecure.
Unfortunately, the VanHacking Challenge is aimed squarely at mainstream media and has little to do with electronic commerce. First, although earlier Macintosh Web server challenges have not directly tested WebSTAR's Realms capability, it certainly played a factor in protecting Infinit's server from attacks on WebSTAR 2.0's remote administration features. And even if the Web page were unprotected, that cracker still has to figure out how to alter the contents of the contest page, which Infinit's and ComVista's contests essentially proved can't be done for $10,000.
Then there's the matter of the encrypted credit card information. According to the VanHacking contest rules, the credit card information is encrypted using PGP (Pretty Good Privacy), a strong public key encryption program developed by Phil Zimmerman and available for a variety of platforms.
There are essentially three ways to access encrypted data: decrypt the data computationally, find a copy of the unencrypted data, or somehow obtain the appropriate key or pass phrase to decrypt the information.
Despite (occasionally paranoid) speculation that PGP may have been cracked by the U.S. government, it's highly improbable that someone will win the VanHacking contest by computationally decrypting the PGP data. Obtaining PGP keys by brute force is currently impractical, and to date there is no public evidence of weakness in PGP algorithms that would assist would-be decrypters. To put it bluntly, finding a method to quickly and reliably crack PGP-encrypted data is potentially worth tens of millions of dollars; it proves nothing if the VanHacking prize money goes unclaimed because PGP wasn't broken.
It might be possible to find an unencrypted copy of the VanHacking credit card number: there have been instances where pass phrases or unencrypted copies of encrypted information have been found in RAM, unused disk sectors, virtual memory, or temporary files. However, since it's been repeatedly demonstrated that the Mac OS is secure from most Internet attacks, it's unlikely someone on the Internet will be able to examine these areas of the contest server or other VirTech machines.
Logistically, it's easier for me to walk into the offices of VirTech Communications in Vancouver (or set up decent surveillance) than it is for me to break into its Web server. If I'm clever, I could pretend I'm a journalist and perhaps get someone to tell me what I want to know. If I'm willing to snoop, there's probably a copy of the credit card number (or a clue as to where I could find it), a PGP pass phrase, a Timbuktu Pro password, or a sensitive email message or memo to be found. If I'm willing to break some laws - which isn't an obstacle for parties interested in credit card fraud - I'm sure I could be more persuasive. VirTech has thought of this angle ("breaking into VirTech's office building will also disqualify the participant"), and while they don't mention fraud, extortion, or impersonating a law enforcement officer, the spirit of the rules is clear. Sure, these tactics sound like the stuff of corporate espionage and spy thrillers - and frankly a $10,000 prize doesn't merit this sort of effort - but when millions of dollars hang in the balance, these things can happen.
The Agony of Self-Defeat -- Are public security challenges pointless? Of course not! These contests demonstrate the integrity and value of the Mac OS and some of the excellent products available for the platform. I think that's significant.
Nevertheless, it's important to look at the objectives behind each event to separate technical merit from mouse-thumping partisanship. Challenges that merely repeat previous efforts speak more to the motivations of the contest organizers than the validity of the challenge. Similarly, contests that require circumventing technologies like PGP or Java security don't necessarily say anything more about the Macintosh than a book says about its shelf.
Article 5 of 6 in series
[Back in TidBITS-375, we noted the success of the "Crack A Mac" challenge held in Sweden for two months last February to April. The contest offered prize money - eventually more than $13,000 U.SShow full article
[Back in TidBITS-375, we noted the success of the "Crack A Mac" challenge held in Sweden for two months last February to April. The contest offered prize money - eventually more than $13,000 U.S. - to anybody who could alter the contents of a Web page served by a standard Macintosh-based Web server. Here's the story of the contest and the server setup, plus some of the break-in attempts and hoaxes the contest team encountered. -Geoff]
What We Did and Why -- To prepare for the Crack A Mac contest, we simply unpacked a standard Power Macintosh 8500/150 from its box. Then we installed WebSTAR 2.0 (the popular Macintosh Web server from StarNine), upgraded to Open Transport 1.1.2, connected the machine to the Internet, and put some Web pages on it. We didn't do anything special with the server - it wasn't behind a firewall, and we didn't make any other security arrangements. The entire setup took less than 30 minutes.
We publicized the challenge and Hacke (the name of our server) via the Web and email, and information about the contest was carried by many diverse venues, including Ric Ford's MacInTouch, MacWEEK, Wired, TidBITS (of course), along with several Swedish publications, the Wall Street Journal, and the New York Times. The contest reward was initially 10,000 Swedish kronor (about $1,350 U.S.), but during the challenge we were able to increase the amount of prize money a couple of times, thanks to nine Swedish Apple resellers. In the end, the contest reward was 100,000 kronor, or approximately $13,500 U.S.
Why did we do it? We wanted to prove there is an alternative to large and expensive Unix- and Windows NT-based solutions for secure World Wide Web services - a solution that doesn't require hundreds of hours to set up or need a separate firewall. We were not trying to prove a Mac OS-based solution is right for everyone, but we are saying it is exactly the right solution for many of us. We wanted to prove the Macintosh is an off-the-shelf system that allows safe, secure, and reliable presence on the Internet within 30 minutes. Since no one was able to claim the prize money, I think we proved our point.
For more detailed information on the contest, rules, and frequent questions and answers that came up during the contest, check out Hacke itself.
The Best Attempts -- In the early stages of the challenge, visitors were trying to exploit more or less known security issues under Unix. We also tracked news coverage on Windows NT security flaws by increased attempts to hack into our server using those flaws; each time a new article appeared about a security problem with Windows NT or NT-based server software, it was followed by a new set of attacks on our server. Many crackers seem to believe Windows NT and Mac OS have something in common. Needless to say, Hacke didn't respond at all to these attacks.
Would-be crackers also spent a lot of effort on trying to guess the password to pi_admin, an administration identity under WebSTAR 2.0 that enables webmasters to handle some core functions remotely. There were more than 220,000 attempts to guess the username and the password, but to the best of our knowledge, none were successful. However, even if someone had guessed the password, they would not have been able to change the content of the server; it simply wasn't possible through pi_admin using the set of WebSTAR plug-ins we had installed.
When guessing at the pi_admin password grew stale, crackers tried to break in to the machine providing our DNS service, with the goal of moving Hacke to another IP number, and then changing the content of the server. [DNS, or Domain Name Service, translates between IP numbers and the more-friendly names of Internet machines. -Geoff] But since our DNS service (provided via Men&Mice's QuickDNS Pro) is also running on a Mac, these attempts were destined to fail. The success rate was not any better for contestants that tried to get into Hacke via our mail server; it was running under Mac OS as well, so there was no Unix sendmail program to try to exploit.
Tired of all the Mac servers, would-be crackers tried to find something in our network that was not Mac-based. The only thing they found were the routers. Fortunately, the routers were secured, but breaking into them could have been a problem, since it could have taken part or all of our network off the Internet entirely. The question is, would that have counted as a hack that was eligible for the prize money? Successfully attacking a router would have merely revealed a security hole in our ISP's connection, and the idea of the challenge was to alter the contents of a Web page. In the end, I suppose it would have depended on the results of a successful router attack, but none were successful.
The most interesting attempts occurred near the end of the competition when people realized they needed a different solution. The best attack was pure social-engineering.
It started when <firstname.lastname@example.org> received an email message apparently sent by <email@example.com>. The message requested Christine put new text on the front page of Hacke because "I don't have the time to do it myself." We would probably have seen through this ruse anyhow, but it was even more apparent because the letter was written in English, and we normally communicate with each other in Swedish.
The next perpetrator was a Norwegian who claimed he had broken Hacke but he had been thrown out before he was done. He couldn't prove that he had been there but he threatened us with lawyers if he didn't receive the prize money. He even called us and told us that he had 3,000 witnesses because he'd accomplished the feat on a big screen during a conference in Norway. However, no evidence or witnesses have materialized.
On the last day of the contest, we received email from two people that seemed to be very polite and helpful. They told us that they had found some information that could be very useful for us. Their enclosures looked like documents but they were, in fact, small AppleScripts that could have changed Hacke's front page had they been launched on the server. They were easy to spot, but it was a good try! The people who wrote the scripts probably realized they would not be successful, since in the middle of the code we found "Rats! No $13,000 for me today."
Performance & Reliability -- It is well known that the Mac OS is currently sensitive to Ping of Death attacks, and that Open Transport and WebSTAR do not have functions to handle SYN attacks. We were largely spared the latter, and while Ping of Death attempts did not seem to knock out the server every time, Hacke was crashed three times by Ping of Death attacks. Since our idea was to conduct the challenge on an easy-to-set-up server, we did not try to defend against these attacks. Instead, we installed the widely-used shareware programs Keep It Up and AutoBoot to restart the server automatically if it crashed.
[For background, Ping of Death attacks involve sending large data packets (usually over 64K) that get re-assembled by the receiving machine into a block of data larger than the original, often causing an overflow and hence a crash. The attack is usually carried out via ping, but in theory the technique can be applied to any IP datagram. A SYN attack is a denial of service attack that involves sending a flood of SYN packets (which are always used to start a TCP transaction) that contain faked source addresses. The receiving machine then spends a lot of its time and resources trying to send and receive acknowledgments to and from machines that don't exist. SYN attacks can be used to block individual TCP ports (or entire machines) from real users. Macs aren't the only machines susceptible to these attacks, but most other platforms have patched vulnerabilities to the Ping of Death, and Apple plans to do so in a future update to Open Transport. -Geoff]
Our philosophy was that crashing a Web server only to have it reboot a minute later was not as severe a problem as an attack which alters the content of a Web page. For example, it is far more serious for a firm like Telia (the Swedish telecommunications company) if their home page is altered to read "Felia" (which, in Swedish, could mean "something that is consistently done wrong") than it is for their Web site to be down temporarily.
Additionally, the Macintosh server was incredibly dependable. As noted above, it went down just three times, and in each case we were able to trace the cause to oversized ping packets. We had expected that. This reliability was also demonstrated by our other Mac servers - Web, Mail, and DNS - that were exposed to attacks and inquiries during the contest. Further, the performance of the server was never a problem. Although Hacke was often very busy (with over 50 simultaneous connections), it sent out a single "busy" message. Some challengers may have had problems connecting to the server, however, since we're located in the southern Swedish countryside and our connection to the world is only 64 Kbps. Also, users from overseas undoubtedly experienced some connectivity problems getting through to us at all.
Some Statistics -- During the competition's two months, Hacke's English and Swedish entry pages logged more than 650,000 hits, and over 100,000 unique IP addresses were logged. The server sent out over 8,000 MB of data. Approximately 75 percent of Hacke's visitors came from the United States, 20 percent from Sweden, and the remainder were spread throughout the world. Many companies and organizations expressed interest - we logged several visitors from IBM, Hewlett-Packard, Cray, Digital, SGI, Novell, Boeing, AT&T, and Netscape. In addition, NASA and the U.S. military were frequent guests.
The Next Step -- Hacke will not disappear. We plan to announce future contests using more sophisticated setups, to address common criticisms of the Macintosh as a Web server platform (including handling several domains, remote administration, high levels of interactivity, access to databases, and so forth). We need to contact sponsors, define a stable and interesting concept, and ensure all criticisms about inadequate features or capabilities are addressed. We also need to do our real jobs: we haven't earned a single krona for the time we spent on the Crack A Mac competition. It should also be noted the Crack A Mac challenge was in no way affiliated with Apple Computer. We just feel we have a vision that should make it possible for more organizations to take the leap toward the Internet.
Article 6 of 6 in series
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)Show 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.
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.
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, <firstname.lastname@example.org>, is President, System Administrator, and Network Janitor for digital.forest, an Internet service provider in Redmond, Washington. Jon Wiederspan, <email@example.com>, of ComVista Internet Solutions assisted in preparing this article.]