eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Like the boxer trying to stay on his feet after a blow that comes from nowhere, the site that dares the world to attack it will stand or fall in full view of both its fans and its detractors. The frame-by-frame study of the bout will show when the sites guard was dropped or when a brilliant combination of blows broke through and will serve as the only kind of lesson that really matters to those who dont want to finish the next contest flat on their backs.
The detailed records of attackers gambits accumulated by eWeek Labs, in three security challenge events since the fall of 1999, are the scouting films that must be reviewed by enterprise IT. These are the punches that will be coming their way as they build out business on the Web, and every one of them can be blocked—but only with relentless attention to detail.
Round 1
Our first worldwide challenge pitted the combination of Microsoft Corp.s Windows NT and Internet Information Services against Linux and the Apache Web server, with each platform running a classified-advertising application. The first attacks triggered our monitoring tools 7 minutes after a press release announcing the contest hit the wires at 8:30 a.m. EST.
A 20-hour attack by Gibraltar-based security consultant Lluis Mora, working under the nom de guerre of JFS, was slowed by circuit-level firewalls that minimized his knowledge of site configuration.
However, once Mora identified the commerce application on the site as PhotoAds, whose source code comes with the product, he quickly gained the advantage. Mora found a pathway into the system through what was supposed to be a Common Gateway Interface script variable holding an uploaded file name but which he manipulated into a means of general file system access.
Perversely, Mora was able to defeat an automatic file renaming operation (which would have blocked this attack) by sending what appeared to be an invalid file name. The script ignored renaming errors and thus left the input untouched.
This is an excellent example of the success-oriented design, so to speak, that characterizes insecure code. Once the code does what its supposed to do, the developer goes away happy, failing to consider whether the code has also been prevented from doing undesirable things.
Moras attack was complete when he discovered a known system vulnerability for which the remedy patch had not been applied. That loophole in the task-scheduling cron utility gave him the ability to execute the code that he had deviously uploaded, completing the one-two punch that laid us low.
Round 2
OpenHack 2, conducted in the summer of 2000, fell for a similar combination punch.
The sites MiniVend storefront application served as an entry point by accepting arbitrary commands through a pathway that was supposed to process only file names. That application then became the route for attack on the database of which that application was a trusted user.
This crack is especially notable as developers begin to move toward distributed application designs, based on XML Web services, in which key application components may be maintained by outside service providers. System modules need to regard one another with friendly suspicion, rather than the unguarded trust that an in-house development team may have unwisely come to take for granted.
Amazingly, consultant Mora once again scored the knockout blow, this time with a true sucker punch. From his own transcript of the database crack: “Reading in the [Oracle Corp.] documentation, I found a reference to a procedure that has to be followed whenever you change MDSYS password, which looks really complex to me, so chances are the people at eWeek havent changed it because it involved too much work. I have no idea what the default password for it is, so I gave it a try with the first that comes to my mind: mdsys.”
Embarrassingly enough for both Oracle and eWeek, the default password was the same as the name of this default account, and Mora was right—it had not been changed. The lesson, for both IT providers and their customers, hardly needs to be spelled out: Security should be present by default and easy to maintain, rather than being optional and difficult to configure.
Round 3
OpenHack 3, in January 2001, went beyond typical configurations by employing a “trusted system” foundation—Argus Systems Group Inc.s PitBull LX. PitBull is a Linux-based platform (also available with other Unix underpinnings) augmented by internal partitions that strictly limit system components privileges. Even root-level access, normally the endgame of an attack, wasnt enough to win the challenge.
Controversy arose two months after this test, when another Argus challenge site was defeated by a tactic that might have succeeded against the OpenHack 3 site. “By modifying kernel variables,” wrote the attacker known as Bladez, “[the variable] ModProbePath can be altered to point to malicious code.”
This flaw was patched the following month by Argus, but it highlights the ease with which facilities designed to provide flexibility and efficiency can turn into devastating loopholes.
Finally, we have to give some sort of not-so-honorable mention to the attacker who failed to defeat OpenHack 3 by technical means and who then turned to the tried-and-true cash attack. His proposition was simple: An eWeek insider should assist the attack and share the cash prize. Needless to say, that hack failed as well.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.