Crack in OpenHack

[InfoSec News <isn () c4i org>]

Forwarded from: William Knowles <wk () c4i org>

http://www.eweek.com/article2/0,3959,648584,00.asp

By  Timothy Dyck 
October 25, 2002

Two hours and 20 minutes after eWEEK's OpenHack 4 security test began,
a wedge was driven into its defenses. The site is bloody but unbowed,
and four hack challenges remain.

Kudos (and a $500 prize) go to Jeremy Poteet, chief technology officer
of Technology Partners Inc., an IT consultancy in Chesterfield, Mo.  
Poteet discovered two different cross-site scripting vulnerabilities
on the first day of the test.

This year's OpenHack test is focused on application-level security.  
Microsoft Corp. and Oracle Corp. each wrote, and deployed on their
applications servers, a Web-based application that was a functional
match for one used in production at eWEEK.

The applications are hosted at openhack.com, which was opened for
"business" on Oct. 22.

Poteet found the vulnerabilities in the Oracle version of the
application. It's important to note, however, that the vulnerabilities
were in the site application code itself, not in Oracle9i Application
Server. The holes that allowed the attacks to succeed could have
appeared on any platform and illustrate 'yet again' that process, not
product, is most critical to strong security.

A cross-site scripting vulnerability happens when a Web application
allows a user to submit scripting code to it, then displays this input
for the user to view, causing the script code to run.

Attackers usually exploit this type of vulnerability by embedding code
in a URL; the code runs when users click on the link. Running in the
security context of its site host, this parasitic code could access
site cookies or do anything else legitimate site scripting code can
do.

Poteet first discovered a problem in the Oracle application's user
account modification page, which allows logged-in users to edit their
user account data. When a user submits changed information, the
application checks data for validity. If there's a problem, the page
displays an error message and asks the user to correct the bad input.  
When doing so, it redisplays what is supposed to be sanitized input.  
However, one field in the Oracle-written app—the user ID itself—wasn't
checked for HTML scripting tags.

Poteet created a user account and submitted a hand-crafted URL to the
site that passed in a value for his user ID set to a very short
JavaScript program. Poteet would have known his attack was successful
when he saw a popup box containing the word "Test." In this case, the
page's input error handling itself had an error.

This vulnerability wouldn't get an attacker far, however, because the
page properly detected that this string was an invalid user ID. Even
if this check had failed, the application would have replaced angle
brackets, quotes, parentheses and semicolons with spaces before the
user input was saved in the database.

One hour after reporting the first vulnerability, Poteet reported a
second successful cross-site scripting attack. This one occurred in a
separate area of the site, where logged-in users are asked to confirm
various inputs entered on a previous page. One of these inputs is a
URL.

Poteet's second attack mode would be harder for site administrators to
detect because it doesn't use any tags that tip it off as script code.

During his OpenHack crack, Poteet subverted the HTML control
characters in the URL display code that turns the URL into a clickable
link. He submitted the string 'a"  
onclick="javascript:alert(document.cookie);' as his URL. When the code
was placed between anchor tags that the application adds
automatically, a clickable URL with an associated JavaScript block was
created.

In contrast to the first case, this input passes the application's
first line of input checks and is considered a legal URL. However,
when saved, another input sanitization routine swings into action and
makes the URL script code non-functional by removing the two
parentheses and semicolon from it. This second-layer defense restricts
the attack to one particular verify page and to the logged-on user
that submitted the bad URL in the first place.

Poteet tried his cross-site scripting attacks against the functionally
identical Microsoft test application, but both were blocked there.

Oracle fixed both problems the same day they were confirmed.

West Coast Technical Director Timothy Dyck can be reached at
timothy_dyck () ziffdavis com.


 
*==============================================================*
"Communications without intelligence is noise;  Intelligence
without communications is irrelevant." Gen Alfred. M. Gray, USMC
================================================================
C4I.org - Computer Security, & Intelligence - http://www.c4i.org
*==============================================================*



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.