If the brutal sport of boxing can call itself “the sweet science,” then eWEEK Labs OpenHack studies are the equally brutal branch of computer science.
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 record of the bout will show when 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 prospective e-business builders: These are the punches that will be coming their way, and every one of them can be blocked—but only with relentless attention to detail.
Round 1: Hack PC Week
Our first worldwide challenge pitted Microsoft Corp. Windows NT/Internet Information Services against Linux/Apache servers, 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. ET.
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 CGI 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: Right on the Chin
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 each other 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] 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 it had not been changed. The lessons, for both IT providers and their customers, hardly need to be spelled out: Security should be present by default and easy to maintain, rather than being optional and difficult to configure.
Round 3: Still Standing
OpenHack 3, in January 2001, went beyond typical site configurations by employing a “trusted system” foundation—the 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 end game of an attack, was not enough to win the challenge.
Controversy arose two months after this OpenHack 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. When modprobe is next execd in order to load a module, the malicious code will be executed in the security context of the process which requested the module.”
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 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 (also known, in a pun on “private key” encryption, as a “purchased key” 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.
As technical security measures, exemplified by these OpenHack challenges, approach almost theoretical levels of protection, enterprise IT should remember that their systems live in the real world—where its always in someones interest to break the rules.
Coming Oct. 14: OpenHack 4!
Technology Editor Peter Coffee can be reached at [email protected].