Thursday, 23 May 2013

[EN] Blind SQL Injection – WebGoat Lesson



0. Blind SQL injection – what is it?

Blind SQL Injection, it’s kind of SQL Injection attack when we can’t see any error message.
Full description you can find at Wikipedia’s page, here.


______________________________________
1. What we will need?
______________________________________

In a situation when we have some restrictions and we can't install 'other' programs (for example, when we're working in a corporation), we can use few tools that don't need to be installed.
In our case we will use:
and browser (in my case it will be Firefox (www.mozilla.org)).


______________________________________
2. How the lesson looks like
______________________________________
 

In a situation when we have no error displaying we must think about 'other situation when page will provide us usable information' about if there is a vulnerability or not.


______________________________________
3. How can we do it?
______________________________________

Our example is a excercise based on Windows system. We should start webgoat.bat now.

After visit at http://localhost/WebGoat/attack server will ask us about credentials to log in. 
Type ‘webgoat’ twice and click to „Start WebGoat”. 

At the left side we can choose lesson to do. Today we will do one from 'Injection Flaws', choose "Blind Numeric SQL Injection".


„The form below allows a user to enter an account number and determine if it is valid or not. Use this form to develop a true / false test check other entries in the database.”



Consequently, ID with value 101 seems to be good. (“True” condition has been met.)

  
 

Let’s check what will change (if any) in situation when we will send to the aplication a wrong or non-existent ID (Let’s try with ID = 777).
 



We can observe that the page will not change, but we can see other information – “invalid account number”. So now we know how this webapp will work in case when ID is not available (wrong/false). Excellent.


In a condition when we can download and/or install other tools, we can use this one listed in ‘Solution Videos’ (link: http://yehg.net/lab/pr0js/training/webgoat.php ). In our case (protected environment) we can’t do it, so we must think about other way to do the same action.
 


Our scope to do now is: „Put the discovered pin value in the form to pass the lesson.”
So (if the ‘condition’ must be fulfilled) we can chech if we can inject SQL code, using form available at this page. Thinking about other WebGoat’s lessons – we can suppose that condition to do it should looks like this:
101 AND 1=(SELECT userid FROM users WHERE ID=101)

Based on the data presented in the task, now we’ll construct a SQL-query to check (send) ‘conditions’ to our vulnerable form. It should be done like this:
101 AND 1=((SELECT pin FROM pins WHERE cc_number = '1111222233334444')=[pinWeReLooking4])

Now we should knew if value 1 (‘true’) is equal to value2 (condition)builded as a query:
 ((SELECT pin FROM… where cc_number = …) = (goodpin?))’ – if this is good, condition is ‘true’ too (1=1) and we can exploit this vulnerability.  

If we will think about ‘how many PIN’s could be there, from 0000 to 9999, there is a lot of manually checking… (By the way: in a ‘real life’ there should be some anti-bruteforce'ing mechanizm, to block „more than 3” probes, right? ;) )


In a solution presented by the author of video tutorial (http://yehg.net), he is using a tool that we will change to Burp.
To prepare of bruteforcing value of PIN by Burp Intruder, we will use a PowerShell (available in Windows by default). Choose 'Menu Start -> Run' and type: powershell (enter).

Below is a simple command to generate a list of PIN's (we will use it as a payloads): 


 
Generated values (PIN’s) we must paste to txt file, let’s call it ‘pins.txt’. This file will be used as a payload-file in a next stage of attack. Now we can change proxy in our browser to Burp (127.0.0.1:8080):



Now (with ‘Intercept on’) in Burp, go to your browser (WebGoat page) and click „GO!” in our vulnerable form. Request catched by Burp we will send to Intruder.




Change 'account_number' value to our 'if 1=1' condition-test:



To start testing, we need our payload file (pins.txt), add it now.




In „Options” tab, set both values – one for ‘true’ value, and one for a ‘false’ (wrong one).
 





In case of testing part of webapps available only for logged-in users, remember to set other two values in ‘Options’ cart:
 


Now we can start Intruder:





In a ‘results’ window we can now easily wait (and see) the correct PIN value we were looking for!





If all steps of attack was prepared correctly, WebGoat should now get our value (and in a ‘real-life’ situation, we will have access to bank account ;) )
 




______________________________________
Congrats! :D

And remember use this technique only in legal tests! ;)

Good luck! 
o/







4 comments:

  1. this article is a good booster to my hacking skills. i really liked you artice
    Born 2 hack

    ReplyDelete
  2. born2hack: thanks. Enjoy! ;)

    If you have any questions, feel free to mail me.
    I will answer as soon as possible.

    Cheers
    o/

    ReplyDelete
  3. "SQL Injection" is subset of the an unverified/unsanitized user input vulnerability ("buffer overflows" are a different subset), and the idea is to convince the application to run SQL code that was not intended. If the application is creating SQL strings naively on the fly and then running them, it's straightforward to create some real surprises. http://born2hack.hpage.com/sql-injection-attack_58594237.html

    ReplyDelete
  4. Yes, that's true Paul. ;)

    btw: I saw that you have a nice art about it at your blog ;) good job.

    Thanks for watching;)

    Cheers,
    o/

    ReplyDelete

What do You think...?