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:
- WebGoat (www.owasp.org)
- Burp Suit (www.portswigger.net)
______________________________________
2. How the lesson looks like
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?
______________________________________
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/
this article is a good booster to my hacking skills. i really liked you artice
ReplyDeleteBorn 2 hack
born2hack: thanks. Enjoy! ;)
ReplyDeleteIf you have any questions, feel free to mail me.
I will answer as soon as possible.
Cheers
o/
"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
ReplyDeleteYes, that's true Paul. ;)
ReplyDeletebtw: I saw that you have a nice art about it at your blog ;) good job.
Thanks for watching;)
Cheers,
o/