Thursday, August 30, 2007

HTTP RS and User ID & Password Mishandling

Below are a few snippets from our August 2007 WhiteHat Sentinel customer newsletter that thought people might find interesting.


HTTP Response Splitting results are in:

Many customers have asked us which Web servers are vulnerable to HTTP Response Splitting attacks. While we are still assembling aggregate totals, here is an initial list of server types we’ve observed to be vulnerable:

1. Apache/2.x

2. Apache/1.x

3. IBM_HTTP_SERVER

4. Jetty/5.1.11

5. Lotus-Domino
6. Microsoft-IIS/5.0
7. Microsoft-IIS/6.0 (commonly misconceived to be invulnerable.)
8. Netscape-Enterprise/4.1
9. Oracle-Application-Server-10g/Oracle-HTTP-Server
10. Resin/2.x
11. Websense Content Gateway (Traffic-Server/5.x)

Note that the problem of Response Splitting susceptibility is really with the application code. A common mistake is narrowly focusing on the server itself as the source of the issue, likely because a few servers have controls to strip this attack from HTTP GET requests. However, many of the HTTP RS attack vectors we’ve found use the HTTP POST verb as well.


The initial HTTP Response Splitting tests are not yet taking advantage of our more advanced testing engines that perform layered encoding attacks and malformed URI manipulations. Once this is fully incorporated, we expect to find even more variants than we do today.


Watch Out For...

User ID and Password mishandling: Using the user ID and password after logging the user in, as session or authorization identifiers, is a dangerous practice with many security implications. Not only does the presence of an XSS vulnerability indicate that you are giving up the user’s credentials very easily, but it often indicates weak session handling and leads to a variety of information-leakage issues, like passing the user ID and password off-domain via the HTTP Referer field or non-SSL encrypted parts of the website.

So, don’t use the user ID and password as identifiers.


While enhancing our authentication and automation tests, we have been observing more and more Web applications that pass the user ID and the password around in things like hidden form fields or cookies. Sometimes credentials are encoded, sometimes encrypted, and sometimes they are en claire (in plain sight).


While the actual security implications of this are contextual to the specific application, this design pattern usually indicates the presence of one or more weaknesses.


WhiteHat Website Vulnerability Management Practice Tips


Q. What do I do if I see a user ID and password being passed around one of my applications?


A. First off – you need to identify why the credentials are being passed around in the application. If there is no reason, you can simply have your developers remove it.


Barring that, a common weakness we observe is the user ID and password being used as a form of session-token to maintain state in the application. This is a really bad idea on many levels. In addition to information leakage issues with the user credentials, this will introduce:


Session Fixation Weaknesses: The “session token” is predictable, fixed, and unchanging. This makes it a trivial task for an attacker to reverse-engineer and take over a “session.”


A Vast Attack Surface
: In general, there is no notion of a “session.” You cannot log a user “in” or “out” handling sessions in this fashion, since in this case, there is only “one” session for all eternity, making the attack surface very large once an attacker figures that out. Everything from XSS to CSRF becomes far, far worse if this weakness is present - not to mention the attacker can impersonate the user directly and at will.


Multiple other issues
from the WASC Threat Classification list

Another common use is when credentials are checked before making security decisions such as verifying whether or not a transaction is really authorized by the user. Unfortunately, if the credentials are not entered by the user, but rather provided automatically via a hidden form field or cookies – the attacker can also force the user to submit these automatically.

5 comments:

Anonymous said...

Jeremiah -I know no one can have access to it (sentinal thing), but I like the idea of it and how it works, do you mean if I used a scanner like Acunetix and finished, besides Acunetix's report, does the sentinel thing automatically take what it needs to OUT of the report? and if the program doesn't generate a report, does this sentinel thing just pull it out SOMEWHERE in the program? if so, I mean is there ANYTHING else you can help me with? MS WORD is not so professional.

Anonymous said...

Session Fixation Weaknesses: The “session token” is predictable, fixed, and unchanging. This makes it a trivial task for an attacker to reverse-engineer and take over a “session.”

This is not Session Fixation.

Anonymous said...

Isn't it unfair to label a bunch of servers as vulnerable, and then go on to say that the vulnerability actually exists in the application code?

I think it would have been better to say: The servers listed below do not have any built-in protection against response splitting attacks, so make sure your application properly filters user supplied input and encodes output.

Anonymous said...

When you say the listed servers are vulnerable, are you saying that they copy user data into response headers themselves, or simply that they are not filtering application code and allow applications to make that mistake?

Anonymous said...

Sorry for late reply to thread -- I was out for a bit to deal with a family loss.

@yousif -- I have no idea what you are asking for.

@rezn -- yes you are correct. This was a hasty typo. Session Fixation is an attack targeting the weakness described. It was supposed to be read as "Weak to Session Fixation Attacks". :)

@schmoilito -- so there's been a lot of reference to "web servers" and "proxy servers" being "vulnerable" to this, when in fact, it is (to my mind) the application code's responsibility.

Since it's a protocol-layer exloit, and the attack vechile is through application inputs reflected into HTTP Headers, it could be a bit of both.

In some cases, like IIS 6, people confuse URLScan with the .NET Request Validators (installed by default) and confuse both with IIS 6 itself.

The point was to say that "almost all web servers are vulnerable" but "it's best solved in your code".

@greg -- it means that this attack will exploit successfully on those servers. Some of those servers, like IIS 6, have additional controls that can be involked (URLScan, or .NET's Request Validators, installed by default with .NET on Windows 2003).

Others do not. Point here: Don't trust your webserver. Scrub your name-value pairs of carriage return/line feed combos.