Odd formatting in SQL Injection exploits?

Question

I am trying to learn more about SQL Injection attacks. I understand the principle, but when I really look at some of these attacks, I don’t know how they do what they do.

Odd quotes and a lot of obfuscation through HEX characters often appear.

I do not get HEX characters ... of course they are translated to ASCII by the browser, so what's the point?

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

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

What is an expression?

Answer 1

I do not get HEX characters ... of course they are translated to ASCII by the browser

Nope.

However, I am mostly confused by the odd quote. I have problems finding an example right now, however it usually seems that the quotation will end at some point until the end of the expression, when I thought it would be at the end?

Imagine that you are building embedded SQL instead of replacing the parameters as you need. We will use a clear language that is very similar to PHP for no particular reason.

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

So now imagine that $param installed by the browser as such ...

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

(We pretend that -- is a sequence of SQL comments here. If it also has no ways)

So what is your SQL after string substitution?

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

which will delete every entry in foo .

It was purposeful, but it should give you an idea of ​​what the uneven quotes are.

Answer 2

Let's say that we have a form in which we pass a form with a name field. the name was used in the variable, $ Name. Then you 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 separator. After that, everything will be ignored. "Used to delimit string literals.

There are several reasons for using hexadecimal characters in an attack. One of them is obfuscation, and the other is a circumvention of some naive security measures.

Answer 3

There are cases where quotation marks are prohibited using SQL injection. In this case, the attacker must use an encoding method such as hexadecimal encoding for his strings. For example, '/etc/passwd' can be written as 0x2f6574632f706173737764 , which does not require quotation marks. Here is an example of a vulnerable query where quotation marks are not allowed.

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

If you want to use mysql function like load_file() , you need to use hexadecimal encoding.

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

In this case, / etc / passwd is read and will be the second line.

Here is a variant of the hex encoding 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 am using this exact method for using HLStats 1.35 . I also used this function in php nuke exploit to bypass xss filters for writing <?php?> To disk using into outfile . It is important to note that into outfile is a request statement that does not accept function output or a hexadecimal encoded string, it will only accept a quoted string as a path, therefore, it cannot be used by an attacker in the vulnerable request above into outfile . Where as load_file() is a function call, and hexadecimal encoding can be used.

Answer 4

Regarding the odd quotation; SQL injection occurs where the encoder does not sanitize user input for dangerous characters such as single quotes — consider the following statement

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

if I know that the valid user is an “administrator” and inserts 'or 1=1 , I will follow

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

This will always return the request, because the left side of the expression will always be true, regardless of the password value.

This is the simplest example of SQL injection, and you will find that the attacker will not need to use a quote at all, or perhaps comment on the rest of the query with a comment, for example -- or /* if there are more parameters after the input point.

Regarding HEX encoding, there may be several reasons that exclude filtering, it is easier to use hexadecimal encoded values, because you do not need to worry about quoting all your values ​​in the query. This is useful if you want to use concat to jointly designate two fields as follows:

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

To make the third line visible, go back to isntance admin::admin . If I had not used hexadecimal encoding, I would have to do this:

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

This may be a problem with the aforementioned addslashes function, but also with poorly written regex processing functions, or if you have a very complex query.

Sql injection is a very broad topic, and what I covered is hardly even an introduction.