Penetration Testing #5 - SQL Injection lab from INE free course
Introduction
Hello Guys!
In the fifth post of the penetration testing series, I would like to show you the solution to the SQL Injection lab from the INE free course. But as always, before going into breaking into the web app it's important to understand what the SQL Injection vulnerability really is. As the name suggests, when a web application is vulnerable to SQL Injection, the attacker can send queries to the back-end database and talk with it. That's why this vulnerability is really dangerous. Imagine that an attacker found an input field that is vulnerable to SQLi. When this happens it can for example fetch all user's credentials saved inside the database. But there are as many dangers as the number of queries that can be possibly constructed and sent to a database! Another scary example that comes to my mind is the possibility of removing the whole database! As you can see SQL Injection vulnerability is dangerous and as a pentester, you have to check if the tested web app is vulnerable to this kind of attack. Now, I will show you a really trivial web application vulnerable to SQL Injection. The index page of this app looks like this:
There is an account that is available, therefore I'm going to log in.
SELECT login, password FROM credentials WHERE login='$login' AND password='$password';
$login and $password variables are taken from the logging form. There are no security filters, so an attacker can control the content of the query, thus it's possible to talk directly with the website's database. Imagine that an attacker tries to log in with this username:
' OR 1=1; --
And the password is blank. In this situation the query sent to the database looks like this:
SELECT login, password FROM credentials WHERE login='' OR 1=1; -- ' AND password='$password';
From the knowledge about SQL, you should know what is happening here. An attacker modified the query that is controlled now and this query will result in logging in as the first user in the database. It happens because the first part of the query (login='') is false but OR 1=1 boolean statement is always true. That being said an attacker bypasses the authentication system and it's logged in (most likely) as the first user. Scary, but true. Check this out.
This is the result of the SQL Injection attack:
SQL Injection lab from INE free course
Description of the SQL Injection lab from INE free course
We have a machine at the 10.124.211.96 address that runs the target web application. Our goal is to test all injection points for the SQL Injection vulnerability. So let's see what the target application looks like.
This is a standard website that we saw in one of the previous labs. We need to check all input fields if they are vulnerable to SQL Injection. The first thing that catches my eye is the login form. Let's try the payload that I've used in the introduction to this post.
As you can see the ' OR 1=1; -- payload works fine. We don't have an account on the site but it's possible to break in. This is because of the logging in query's structure. It most likely looks like this:
SELECT email FROM credentials WHERE email='$email' AND password='$password';
The idea behind the attack is the same as in the introduction of this post. If you didn't read this section of the post I would definitely recommend it to understand what has just happened. The first injection point on the site is clearly vulnerable to SQL Injection.
And here we are inside the News section of the target web application. There is an id GET parameter that acts as an index of the news inside some table in the back-end database. Therefore the query responsible for selecting chosen news is probably something like:
SELECT news FROM news_table WHERE id='$id';
So we found another injection point that should be tested in our penetration test. This point in the application is a great way for trying to dump the database for example. But for now on we need to check if this GET parameter is really vulnerable. Let's try to inject this payload into our guessed query:
Payload: ' OR 1=1; -- -
Possible query: SELECT news FROM news_table WHERE id='' OR 1=1; -- -';
The structure of the payload is quite weird because of the last '-' sign. We have to write a character behind the SQL comment (--) since a browser removes the last blank space character. Therefore if our GET parameter payload looks like this "' OR 1=1 -- " a browser replaces it with "' OR 1=1 --" and it will not work as we want. That being said our payload should give us all posts that are available for the News section at one strike. If this will happen the injection point is vulnerable.
Ok, we don't have a list of news but we can be sure that this injection point is vulnerable. We don't really know how many columns are involved in the query and that's why we need to deal with this error. The easiest way to dump the database using this particular injection point is using the tool called Sqlmap. It scans the whole web application for injection points and tries to exploit them. We need to remember that this scanner might cause damage (for example denial of service) to the client's infrastructure. So the first thing we have to do is checking if an injection point is vulnerable manually. We know that the id GET parameter is vulnerable thus we can configure the sqlmap to exploit only this injection point.
Using this command the sqlmap will give us all the tables that exist on the MySQL server where the application's database resides. Here they are:
The most interesting table in the web application's database is accounts. Let's steal the credentials using this command: sqlmap -u "http://10.124.211.96/newsdetails.php?id=1" -p id -D awd --dump.
Now you can see how scary an SQL Injection vulnerability is. We have all user's credentials from the web application. The last thing to do is to break into the application by logging in as the administrator. ;)
This concludes the whole lab about SQL Injection. Thanks for reading and see you in the next posts on my blog!
Comments
Post a Comment