As OpenHack Test Nears End, Vulnerability Comes to Light

As this story goes to press, just a few days remain in eWeek's OpenHack 4 security test.

As this story goes to press, just a few days remain in eWeeks OpenHack 4 security test. No one has accomplished any of the four remaining hack challenges, but a vulnerability has been spotted in site code.

The number of attacks on the site has dropped off significantly from the beginning days of the test: Only about 5,000 new attacks were recorded in the past week by the IntruVert Networks Inc. intrusion detection system monitoring the test site.

Only one OpenHack challenge—a cross-site scripting attack—has been successfully accomplished so far. The person who levied that attack—Jeremy Poteet, chief technology officer at IT consultancy Technology Partners Inc.—has since discovered on the Oracle Corp. OpenHack application a very clever, though as yet unproven, way to hijack session information in a rare combination of circumstances. (For OpenHack test methodology, go to

Using a modification of his cross-site scripting attack, Poteet was able to log in as himself and then submit a hand-crafted URL string that modified the user identification parameter to replace his user ID with a different ID string. The vulnerability gave him an idea for how a more complex attack might be carried out.

Oracle application security checks prevent this switch from happening when the replacement user ID already exists in the database. However, if the user ID doesnt exist, an attacker could set his or her user ID session variable to the new user ID.

This user ID switch is blocked from reaching the database and so is nonpersistent and affects only the current session variables. This session information automatically expires after a few minutes. To get around that, Poteet proposed writing a custom program to maintain the session by refreshing a Web page every few minutes.

All this effort is in the hope that a user will come along and create a new account on the server, using the same user ID Poteet had chosen.

With the right software, luck and timing, we think this attack could work. If so, an attacker using Poteets hack would be logged in as that subsequent user and could view that users records, including any credit card data entered.

The application vulnerability Poteet spotted was the result of a bug in the original reference application code we developed. However, the bug appears not to have survived the application rewrite Microsoft Corp. did to convert the eWeek Labs-written reference code into Active Server Pages .Net.

The OpenHack site was scheduled to go offline at midnight PST on Nov. 8. This week, well be posting at intrusion detection reports, system logs and, most important, OpenHack application source code from Microsoft and Oracle. In addition, look for a complete wrap-up of OpenHack 4—and an analysis of what the results mean for enterprise security—in the Dec. 2 issue of eWeek.

West Coast Technical Director Timothy Dyck is at