[ISN] Hacker Log: Pathway to Successful Site Attack

From: InfoSec News (isnat_private)
Date: Tue Dec 03 2002 - 01:33:59 PST

  • Next message: InfoSec News: "[ISN] Linux Security Week - December 2nd 2002"

    By Jeremy Poteet 
    December 2, 2002 
    A few fairly simple practices would have prevented my successful
    attack on eWeek's OpenHack site. The bottom line is that application
    security can be attained, but it must be consistently applied and
    methodically checked to be effective.
    Rather than focusing on one of the five OpenHack challenges presented
    by eWeek, I decided to try to find any security problems I could.
    My attempt to hack the site began by making a quick pass through the
    Microsoft Corp. and Oracle Corp. versions of the OpenHack application,
    both to get an idea of their scope and an overview of their
    The first decision I made was to determine which application would be
    more vulnerable.
    While registering for an account, I noticed some inconsistencies in
    the Oracle version, where nonrequired items such as "title" generated
    unexpected error messages. This is not a security hole per se, but it
    did indicate a lack of consistency, which I felt was the most likely
    avenue of vulnerability in an application with the security attention
    that this one had received.
    After using the Oracle OpenHack application for a few minutes, it
    appeared that the application used a common routine for conducting
    field input validation. I began looking for fields that stood out as
    being different, in the hope that one or more of these fields might
    have been overlooked or that the standard checks might prove
    The OpenHack application is small, and the list of interesting fields
    was quite short. These included a few hidden form fields, some ID
    numbers passed as query parameters, a URL field and a set of radio
    The first field I began evaluating was a hidden form field for user
    identification that appeared when editing an account.
    The application contained a label that stated: "(User ID cannot be
    changed once an account is created)." I changed the hidden form field
    to be a new user ID and hit the submit button.
    The application processed my request and changed my user ID to the new
    ID. I logged out and tried logging in with my old ID. That ID was no
    longer known to the application. I logged in with the new ID and my
    original password. I was then logged in as that new user. I repeated
    the process and changed my log-in ID back to the original state. While
    not one of the program challenges, I reported this to eWeek as a bug
    in the intended use of the program.
    I then began thinking about the fact that the developer had not
    checked whether the ID had changed. I believe this was due to the fact
    that the same screen is used to both add and edit existing users.
    Although it can be done securely, using the same screen to conduct two
    tasks does place a higher level of responsibility on the developer to
    ensure that the logic is appropriate in both cases. It seemed as if
    the developer had not fully expected the field to be changed in the
    case of the edit scenario.
    However, when I chose a duplicate ID, it returned the duplicate ID in
    the user ID field along with an error message. When I saw the data
    returned to the screen, I tried using a script tag as the user ID.  
    This proved to be successful.
    I know the Oracle developers were aware that hidden form fields can be
    modified, but I believe this vulnerability was missed in their initial
    assessments because the screen can be used in multiple contexts.
    To ensure a secure system, each scenario must be run through the logic
    to ensure that all cases are dealt with appropriately.
    The second cross-site scripting bug I discovered was in the URL field
    on the "Product or Services" Web page. The field seemed to use the
    same field input validation routine as the rest of the application.  
    However, the context in which this field was used, constructing a URL,
    was different from any other fields in the application.
    I entered a normal URL and looked at the HTML source that was returned
    to see the specific syntax I needed to inject into. Because the same
    routine that was used for checking the large comment fields was being
    used to check the URL, characters such as ", =, (, ) and a space were
    all considered valid. Adding a JavaScript event to the anchor tag was
    a simple process and proved to be effective.
    Although the technique I used to exploit this cross-site scripting
    vulnerability was different from the one I described earlier, the
    source problem was actually the same.
    Reuse is an important concept in software development and can be very
    useful in a well-designed security model, but the developer must be
    careful not to allow reuse to expose security holes.
    The same validation routine was used in all cases, even though the
    context in which the fields were being used was not consistent. This
    variation in field usage should have resulted in a corresponding
    variation in the field validation routines.
    This reuse, combined with the fact that cross-site scripting can be
    accomplished in a variety of ways, allowed my successful attack.
    Jeremy Poteet (jpoteet@tech-partners.com) is chief technology officer
    at IT consultancy Technology Partners Inc., based in Chesterfield, Mo.  
    Company information can be found at www.tech-partners.com
    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 : Tue Dec 03 2002 - 04:26:40 PST