[ISN] Crack in OpenHack

From: InfoSec News (isnat_private)
Date: Sat Oct 26 2002 - 04:32:21 PDT

  • Next message: InfoSec News: "RE: [ISN] INFOSEC: Certifiably Certified"

    Forwarded from: William Knowles <wkat_private>
    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
    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
    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
    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
    "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 majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Sat Oct 26 2002 - 07:24:16 PDT