SQL injection attacks – part 3
In the previous lesson, we performed a successful brute force attack on a login form. Now, let’s go to the SQL Injection tab (not the Blind one), where we can type the example SQL injection in the UserID field:
Note: try to understand, on your own, how this SQL injection works and why it was successful. If you need help figuring it out, here’s the answer.
This will return a list of usernames and passwords. Notice that the passwords are hashed with an md5 hash which is incredibly easy to crack.
We can go to a website like md5hashing.net/hash, type in the hash string and set it to md5, and we will get the password within seconds.
There are, of course, tools on Kali that let us do this as well.
Why is it so easy to crack and figure out the password? Because of a few reasons such as the password being weak in the first place, and because MD5 is “fast.” An attacker can try billions of potential passwords per second on a single GPU. Using a slow hash like bcrypt is preferred for passwords for that very reason.
As a side note for the curious, there is a difference between Hashing and Encryption although the two terms are often used incorrectly (and I must admit I’ve been using it incorrectly).
Now that we know that this form is vulnerable to SQL injections, we can poke around. Let’s do one more example before moving on to a different type of attack.
Exploiting the Database with SQLMap
Kali has a tool called SQLMap which automates the detection and exploitation of SQL injection flaws.
If we type in user ID of 1 in the input and submit, we can see what the URL looks like for this request.
Let’s grab that and use it in SQLMAP.
Then, we’ll add in the cookies that we need (the security cookie and PHPSESSID – again, yours will be different so don’t just copy/paste without editing; and if you forgot how to get it, inspect the Network traffic while submitting the ID of 1 in the input field), and we’ll pass in a flag that tells SQLMAP to show us what databases are being used by this application.
Here’s what the command looks like:
We can run a similar command but change out the -dbs option for —tables (with 2 dashes) in order to list out all of the tables in the databases we found.
At this point, we’re already getting a ton of information about how this database is structured, and we can use this information to build our attack.
But, let’s go ahead and mark this lesson as complete to move on to the next attack: XSS (Cross-site scripting).
Of course, feel free to poke around some more before moving on!