SQL Injection Attacks by Example

We did receive two submissions of interested regarding SQL injection. SQL injection is a problem commonly found in web based applications which use a SQL database back-end. Like so many security issues, missing user input validation is to blame. A couple of lines of pseudo code will easily illustrate the issue:

Lets assume your web site is verifying users login credentials using this code:

$valid=select count(*) from users where username='$user' and password='$pass'

if ( $valid==0 ) {

  send_user_to_login_page

}

if we do not validated '$user' or '$pass', a malicious user could supply the following as "username": ' or 1=1; select 1 from users where username='

As a result, the application would execute this statement:

$valid=select count(*) from users where username='' or 1=1; 

        select 1 from users where username='' and password='password'

As a result, the user would be considered 'logged in' regardless of the password supplied (of course, the result will vary somewhat depending on how the actual site will deal with multiple queries).

For much more on this topic, see this brief overview:

SQL Injection Attacks by Example http://www.unixwiz.net/techtips/sql-injection.html

While the paper doesn't include any particular new revelations, it does show the basic principle behind SQL Injection attacks quite clearly. However, the paper falls somewhat short when it comes to input validation mechanisms, and how an attacker may bypass them.

As a minimum precaution for all the PHP folks: make sure you enable 'magic_quotes'. It should be enabled by default.

While the problem is usually found in web sites as they are accessible to a large number of users, similar problems could be found in other applications with database back-ends.

SQL Injection Worm

To drive home the point about SQL Injection: "Zeno" from CGISecurity.com pointed out a bugtraq posting about a worm which propagates using SQL Injection. At this point, we have not yet seen the code for the worm. However, it is quite possible given that worms have taken advantage of SQL databases in the past (e.g. see "SQL Snake"). Many SQL databases have the ability to execute shell commands or read and write arbitrary files. As always, it is good to observe "defense in depth": Run your SQL database in a chrooted environment, limit the permissions of web-accessible SQL users and check your web logs.

more WINS details

We did receive a number of submissions with packet traces showing use of the recently released exploit against flaw in WINS. The exploit used is a variation of the code published at K-Otik. In order to evade IDS signatures, the exploit was sent across multiple small packets. We only had the chance to test one IDS so far, and it recognized the exploit. I will update this diary later as I get to analyze the traffic in more details.

Asking for your input

We would like to add a new feature to our diaries. If you would like to write a short piece about a current security topic of your choice, let us know. We plan to include a contributed "speakers corner" once a week, likely Mondays.

The basic rules: It has to be relevant, and 'signed' with your name. We will verify the identity of the writer. We will pick one submission each week. It is ok to ask ahead of time is a given idea is appropriate. Opinions are welcome, but should be voiced coherently and politely. We will not screen submissions based on the opinion of the writer matching our own (at least we will try to be open). We will forward feedback to the writer. The length is limited to about 500 words.

---------

Johannes Ullrich, jullrich\at'sans.org