Hacker Log: Pathway to Successful Site Attack

[InfoSec News <isn () c4i org>]

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

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
architecture.


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
ineffective.

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
buttons.

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 majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.