Why You Should Not Expose Your Failed SQL Query

It is the weekend and as I am wont to do I pay a visit to A site focusing on links to
illegal file distribution. They do have some legal links, but it would be a lot
like drug dealers selling candy on the side. Not really their purpose for
being. Anyways the site was down as usual. Seems their host is just generally
bad as this is a common occurrence. Today was different though. It was serving
a relatively unique error.


What are we seeing here?

This is the exact SQL query
that the server was trying to run which failed for some reason. In other words
when I tried to access the site the server tried to (via the sessions.php file)
create a user session for me within its database. This session would then track
my usage of the site. Not sure exactly what, but possibly how long I use the
site, pages I go to, posts I make, etc. That session creation failed for some
reason and it returned this error to me.

Why is this significant?

This is a significant error as it exposes information the user (client)
should not be aware of. Specifically a database table and columns in that table
that the server uses. This is important because it makes my job easier if I am
looking to exploit the system.

How could I do that?

Let us look at the error we got back. I have highlighted the important
sections here:


This gives us two pieces of important information:

  1. That the site knows my username (which I have removed).
  2. That the site is using a particular id number to identify me (the red boxes
    which represent the ‘session_user_id’).

How does the site know my username if I have not tried to login (this is the
first thing I see on accessing the site)? The site has checked for an existing
login cookie on my machine. Lucky for us we can look at that cookie and see
what information it is providing. Let us open up firebug and take a look.


See that red box. That is the same number we are using in the failed SQL
query for the ‘session_user_id’ column. Let us go ahead and use firebug to
change that number and see what happens:


Luckily for us warez-bb operates sanely in this regard and my attempt to
exploit failed. You can see it just reverts to an anonymous user. That stills
gives us some useful information on how the site operates though. It must be
using the ‘session_user_id’ contained in the cookie, and those other values to
retrieve my username which is not saved in the cookie. Another attack vector
which I did not consider is instead of just changing the ‘session_user_id’ in
the cookie is to inject
into its spot instead. The idea would be the server would execute the
SQL command I provided in the cookie. Based on the result of the first test it
is likely warez-bb defends against this attack by sanitizing whatever input it
gets back from cookies.

Though my attacks failed this is still bad practice. The user of a site
should know nothing about the underlying operation of your server. Any
information you unwittingly provide makes the attackers job easier.

Leave a Reply