Checkout SlayerLabs.com!
Networks Engineered to Exploit.
- Windows/UNIX - Domains/Subnets - Initial/Post/Lateral - Low Cost VPN Ranges -

SQL Injection 101

Generally, the most common web application security risk is injection and has been in OWASP Top 10 since its inception. SQL injection is a category that falls into this risk. SQLi has plenty of documentation on the subject - the goal of this post is to provide real world examples using various vulnerable web apps.

Even though it may seem dated, I’d recommend downloading metasploitable 2 since it has a few built in ready-to-go vulnerable web apps. Building blocks are absolutely necessary to understand advanced SQL (and NoSQL) injections. The basics of SQLi haven’t really changed, so this is a great machine to get started with.

First, there are plenty of SQL injection tools available, but it’s always good to start the manual way to really understand what’s happening.

Manually

Usually a SQLi is accomplished by submitting some text via a text box, other times you can simply insert it into the URL. The application uses this text to query the DB for data. Your goal is to manipulate the text in order to query the DB for more information than the web application was designed to request and give out to the user. If you’re probing for potential targets or you know your target is running an app vulnerable to SQLi a few quick ways to test MySQL…

'
#
--
"
'OR 1=1 --
'OR 1=1 #

Also fuzzdb has loads of excellent wordlists – here are some detect wordlists for multiple database vendors: https://github.com/fuzzdb-project/fuzzdb/tree/master/attack/sql-injection/detect

If the app is vulnerable, it should display a type of database error on the webpage. If it throws a 404/page not found then it’s not vulnerable.

A thorough example of a manual SQLi is located in the vuln machine Kioptrix level 3 – my walkthrough is here http://liberty-shell.com/sec/2017/09/08/kioptrix3/

Fire up metasploitable 2, open DVWA – turning it on low Security then navigate to SQL Injection module. As above, try inputting the listed test strings and see what happens. Note: We’re assuming the target is running MySQL (which it is).

Not surprised, we get a successful hit using ’ OR 1=1 #

Enum DB

Next up is to enumerate and see what this database is made of. If you’re no SQL expert, having a few go-to cheat sheets are essential. Checkout http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet for some quick SQL statements you can try out.

In this case, we’ll see what directory the DB is in by using the static MySQL @@datadir variable (see pentest monkey cheat sheet).

In order to use this variable we’ll have to continue the SQL statement. Some instances may allow a ; or the UNION command. Try yourself if you’re curious.

In this example we’ll have to continue the command using a UNION operator, then selecting the built-in MySQL var @@datadir.

This now throws us an error – specifically a column error. This tells us we need to figure out how many columns we’re working with. Again, Kioptrix 3 has a great SQLi example were enumerating the full DB and table is necessary.

Order by

Anyways, we need to run a trial and error until we find a valid number of columns by using the order by statement. We’ll start with 1 column and increase by 1 until the web app spits out an error.

Column 3 doesn’t exists, so the DB gets crabby and throws us an error. Now, we verified the table has 2 columns, which will then need how many parameters?.. you guessed it: two parameters.

Datadir

Back to our datadir variable. We now know 2 params will need to be passed in order to get a valid SQL query. Simply adding 1 as the first parameter will do the trick in this case.

So, pulling it all together…

Now you can get creative and dig around a bit, referencing your favorite SQL cheat sheets. Here are a few to get you started..

' union select 1,@@hostname #
' union select user(),system_user() #
' union select load_file('/etc/passwd'),1 #