The battle has begun, and the first salvo was a fierce one, as a cascade of denial-of-service attacks swept over the Openhack III site in its first four days of operation.
As of midday Thursday, no one had succeeded in any of the four hacking goals, although eWeek Labs saw creative DoS attacks directed against the Champaign, Ill., site, along with heavy usage.
There are consistently 50 to 100 users logged in to the shell server, trying to break that systems security. (eWeek Labs Openhack I and II tests didnt allow users to log in locally.) Openhack IIIs widespread coverage by news media nationwide might have added to this glut of would-be hackers.
Argus Systems Inc. staff discovered a bug in the companys code that caused two of the Open Hack systems (the shell and Web servers) to crash under a heavy network load. They analyzed core dumps from these crashes on Tuesday and developed a patch, which was installed on the affected servers on Wednesday.
The systems that allow user log-ins—the shell and Web servers—are a swamp of general nastiness as users attack both the system theyre on and one another. One common attack weve found is where users modify each public accounts .profile script (which is run automatically when new users log in) to immediately log them out again either through an “exit” or “kill-9 $$” command.
We also saw several resource utilization attacks where users run so many processes that the systems process table is filled up or the server runs out of swap space. At this point, no new log-ins can happen, and those who are already logged in cant run any commands. Argus is working on ways to stop these kinds of attacks, but resource utilization attacks (as a class) are hard to prevent.
There have also been countless DoS attacks, both locally and remotely. On Wednesday morning, less than 48 hours into the test, our intrusion detection log had grown to 1.3GB in size and contained logs for 7.46 million events; we stopped logging the most common DoS attacks at that point simply to save disk space.
One user discovered a way Tuesday to remotely shut down or crash IBMs WebSphere application server; were still trying to figure out how this was accomplished.
WebSpheres log files contain a large number of Java null pointer and illegal argument exceptions in code that parses user input, showing that many people are submitting bad data to the store, hoping to manipulate server-side code into retrieving the secret database data.
