1

I am currently doing a blackbox test on a web application for training purposes. It's a personal project.

In addition to my manual testing process, I used an automated scanner for detecting obvious vulnerabilities. While this tool only found some basic issues, it also detected a potential SQLi vulnerability which I did not notice before. I am able to reproduce the error using Burp, but I am still not able to extract database data manually. Because of that, I gave sqlmap a shot.

Before I come to my actual question, let me give you some details:

The vulnerability seems to exist in a login form. When the following sequence is POSTed to the form

password=letmein&username=1%c0%00xa7%c0%a2

a mysql error is returned:

Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given

I have narrowed the sequence down to the byte %c0. This urlencoded value leads to the warning. So far, I am not sure why exactly this value leads to the warning.

The sqlmap setup looks like this:

 sqlmap -u http://thehost/include/login.php --method POST --data "password=letmein&username=1%c0%00xa7%c0%a2" -p "username" --dbms=mysql

Which generates requests/payloads in the following form:

 [PAYLOAD] 1%c0%00xa7%c0%a2)).("(,)'(
 [TRAFFIC OUT] HTTP request [#3]:
 POST /include/login.php HTTP/1.1
 Host: thehost
 Content-type: application/x-www-form-urlencoded; charset=utf-8
 Accept: */*
 Content-length: 70
 Connection: close

What I would like to do/try is change the injection point within the POST data. Is this possible? I know it is possible to specify an injection point within a GET request. Additionally, does anybody have an idea why the injected %c0 byte messes up the query?

thanks

DucatiNerd
  • 125
  • 1
  • 1
  • 4

4 Answers4

0

SQLmap works in a heuristic way, firstly it learns about difference about good and bad response from the application, then you have to introduce a real value for username parameter to get a good response, SQLmap will analyze the responses after that it will inject sql commands to detect a possible SQL Injection. Your SQLmap command must be something like this:

sqlmap -u http://thehost/include/login.php --data "password=letmein&username=this_is_a_real_username" -p "username" --dbms=mysql

The option --method POST is not neccesary, SQLmap knows it's a request POST when you use the option --data.

I hope this information helps you.

Good Luck.

hmrojas.p
  • 1,049
  • 1
  • 8
  • 16
  • Thanks for your suggestion. I have tried your approach before - the problem is that sqlmap does not detect an injectionpoint/does not detect an injection vulnerability. I am only able to trigger the mysql error using a sequence that contains *%c0* (or maybe another encoded character that generates a conflict when used with the existing database query). I am still trying to figure out why/how the warning is returned to the user. – DucatiNerd Jan 02 '17 at 15:56
  • You could use the options --risk and --level, also you can use the option --tamper and specify different injection techniques for MySQL, for example: --tamper tamper/space2mysqldash.py,tamper/space2mysqlblank.py – hmrojas.p Jan 02 '17 at 17:15
0

Referring this post: https://stackoverflow.com/questions/2973202/mysqli-fetch-array-mysqli-fetch-assoc-mysqli-fetch-row-expects-parameter-1

I believe it's not problem with the injection, rather the passed parameters might not be giving out any result and the application is trying to read the false value returned due to empty results.

Hope this helps!

0

I don't know about the injection point, but 0xc0a2 is a another way to encode the " character using the UTF-8 character encoding. What happens here is that the page script incorrectly strips "dangerous" characters before converting the encoding. You can actually insert all restricted characters this way. Just split the 7-bit binary value of the ascii code in two and encode it like this: 1100000x 10xxxxxx

0

I run into this one quite often. I am not sure if it is exploitable.

It so happens that when you use mysql_real_escape_string() in your code (AND YOU SHOULD!) before passing the input to a database query, a certain encoding is used.

I believe in this case the %c0 is not escaped, causes the execute_query() to trow an error (returning false, instead of the expected row)

%c0 in UTF-8 (which the program uses) is "À" and that breaks the query as it has no value in UTF-8 and as a result a "\x00" is injected. Everything breaks then.. I have been trying to figure out a way to make this work to my advantage but so far, I have had no luck!