Odd formatting in SQL Injection exploits?

I have been trying to learn more about SQL Injection attacks. I understand the principle, but when I actually look at some of these attacks I don't know how they are doing what they are doing.

There often seem to be uneven quotes, and a lot of obfuscation via HEX characters.

I don't get the HEX characters..., surely they are translated back to ASCII by the browser, so what is the point?

However, I am mainly confused by the odd quoting. I am having trouble finding an example right now, however it usually seems that开发者_Go百科 the quoting will end at some point before the end of the statement, when I would have thought it would be at the end?

Perhaps an example is the common use of '1 or 1=1

What is such a statement doing?

I don't get the HEX characters..., surely they are translated back to ASCII by the browser

Nope.

However, I am mainly confused by the odd quoting. I am having trouble finding an example right now, however it usually seems that the quoting will end at some point before the end of the statement, when I would have thought it would be at the end?

Imagine you're building inline SQL instead of using parameter substitution as you should. We'll use a make-believe language that looks a lot like PHP for no particular reason.

$sql = "delete from foo where bar = '" + $param + "'";

So, now, imagine that $param gets set by the browser as such...

$param = "' or 1=1 --"

(We're pretending like -- is the SQL comment sequence here. If it's not there's ways around that too)

So, now, what is your SQL after the string substitution is done?

delete from foo where bar = '' or 1=1 --'

Which will delete every record in foo.

This has been purposefully simple, but it should give you a good idea of what the uneven quotes are for.

Let's say that we have a form where we submit a form with a name field. name was used in a variable, $Name. You then run this query:

INSERT INTO Students VALUES ( '$Name' )

It will be translated into:

INSERT INTO Students VALUES ( 'Robert' );  DROP TABLE STUDENTS; --')

The -- is a comment delimiter. After that everything will be ignored. The ' is used to delimit string literals.

To use hex chars in an attack has some reasons. One of the is the obfuscation, other one to bypass some naive security measures.

There are cases where quote marks are prohibited with sql injection. In this case an attacker has to use an encoding method, such as hex encoding for his strings. For instance '/etc/passwd' can be written as0x2f6574632f706173737764 which doesn't require quote marks. Here is an example of a vulnerable query where quote marks are prohibited. :

mysql_query("select name from users where id=".addslashes($_GET[id]));

If you want to use a mysql function like load_file(), then you have to use hex encoding.

PoC:/vuln.php?id=1 union select load_file(0x2f6574632f706173737764)

In this case /etc/passwd is being read and will be the 2nd row.

Here is a variation on the hex encode function that I use in my MySQL SQL Injection exploits:

function charEncode($string){
    $char="char(";
    $size=strlen($string);
    for($x=0;$x<$size;$x++){
        $char.=ord($string[$x]).",";
    }
    $char[strlen($char)-1]=")%00";
    return $char;
}

I use this exact method for exploiting HLStats 1.35. I have also used this function in my php nuke exploit to bypass xss filters for writing <?php?> to the disk using into outfile. Its important to note that into outfile is a query operator that does not accept the output to a function or a hex encoded string, it will only accept a quoted string as a path, thus in the vulnerable query above into outfile cannot be used by an attacker. Where as load_file() is a function call and a hex encoding can be used.

As for the uneven quoting; sql injection occurs where the coder didn't sanitize user input for dangerous characters such as single quotes - consider following statement

SELECT * FROM admin WHERE username='$_GET["user"]' and password='$_GET["pass"]'

if I know that valid user is 'admin' and insert the 'or 1=1 I will get following

SELECT * FROM admin WHERE username='admin' and password='something' or 1=1

This will result in returning the query alway true, because the left side of the expression will always be true, regardless of the value of the password.

This is the most simple example of sql injection, and ofter you will find that the attacker won't need to use the quote at all, or maybe comment the rest of the query out with comment delimiter such as -- or /*, if there are more parameters passed after the injection point.

As for the HEX encoding, there may be several reasons, avoiding filtering, it is simply easier to use hex encoded values, because you don't need to worry about quoting all your values in a query. This is for instance useful if you want to use concat to co-notate two fields together like so:

inject.php?id=1 and 1=0 union select 1,2,concat(username,0x3a3a,password) from admin 

Which would providing 3rd row is visible one, return for isntance admin::admin. If I didn't use hex encoding, I would have to do this:

 inject.php?id=1 and 1=0 union select 1,2,concat(username,'::',password) from admin 

This could be problem with aforementioned addslashes function, but also with poorly written regex sanitization functions or if you have very complicated query.

Sql injection is very wide topic, and what I've covered is hardly even an introduction through.