My first PEN tests

Recently I got introduced to software security and penetration testing of web sites and api. In the next few posts I’d like to share with you what I learned and how I did it.

We will start by exploring some vulnerabilities in a java program and how to find and fix them. For that we are going to use javulna. This is an intentionally vulnerable Java application that allows us to get familiar with finding and exploiting some basic vulnerabilities in web sites. We will then see how to fix the code to remove the security vulnerability.

As I was doing this exercise I was looking for ways that could help me detect the vulnerabilities. This is how I got to learn about Kali Linux. This is a linux distribution that contains lots of tools that facilitate penetration testing. We will see some of the tools that I used to detect vulnerabilities in the javulna code.

Exercise 1: find sql injection vulnerability

In the first exercise we will try to get access to the database behind the application. To do this, let’s try to enter some query parameters in the url and see what the answer is. To make the api requests, we will use postman. The javulna code contains a postman collection with useful requests to access the different endpoints that the application exposes.

So let’s open postman and choose the “List movies” request. If we try this request we can see that the application returns us a list of movies that contains exactly one movie, where its title contains the string “Empire” and its description contains the string “Luke”:

So let’s try to pass another query parameter to the request and see what the result is. What happens if instead of giving it a valid title to search for, we give it a single quote?

In this case we get back an error. If we look at the error in detail, we can see that the database query that the application tries to execute is select description, title, genre, id from movie where title LIKE ‘%’%’. The fact that the application gives us so much detailed information about the error is another vulnerability to which we will come back in a later post. What’s important for this exercise is that we found a way to control the sql statement that the application executes when we make the http request.

Now we can try to alter the query parameters further in an attempt to extract data from the application’s underlying database. There are different ways we can approach this. For the sake of this exercise we will look at a tool that allows us to exploit an api using sql injection. This tool is called sqlmap and it comes pre-installed with kali linux. So lets open up a terminal in kali linux and equiped with the modified request that allows us to access the underlying database, we first ask sqlmap to tell us which database engine the application uses.

sqlmap -u “http://172.17.0.1:8080/rest/movie?title=Empire'” –dbs -p title

I expected this to be a no brainer, but it appears to be more complicated than expected. The above command does not manage to return us which database engine runs in the application.

We should not give up so easy; sqlmap allows us to try some more complicated queries to find out what database we try to attack. So lets add some parameters to increase the level of the attack. We also instruct sqlmap to flush the current session because sqlmap remembers the result of the previous trials and we do want it to try from scratch.

sqlmap -u “http://172.17.0.1:8080/rest/movie?title=Empire'” –dbs -p title –level=5 –risk=3 –threads=8 –flush-session

Now sqlmap manages to tell us that the application uses database engine HSQLDB and that it contains 3 databases named public, information_schema, system_lobs

So now that sqlmap found out that the database we want to access is a HSQLBD angine, we can ask to list all tables in the public database:

sqlmap -u “http://172.17.0.1:8080/rest/movie?title=Empire'” -D public –table

The next step is to get the table structure. We expect that the table appuser will contain the user info, so lets see if we can find out what this tables’ colulns are:

sqlmap -u “http://172.17.0.1:8080/rest/movie?title=Empire'” -D public -T appuser –columns

Bingo! We see columns named name and password. Looks like we hit the jackpot. Now the last thing we want to do is to see the data in the table.

sqlmap -u “http://172.17.0.1:8080/rest/movie?title=Empire'” -D public -T appuser -C id,name,password,emailaddress –dump

That’s it. We found all the application users and their passwords.

Notice that the passwords are stored in clear text, which is obviously not a very good idea. The programmers could have hashed the passwords before storing them in the database; that would have left us with a password hash and we still would not know what the actual users’ passwords were. But that’s fuel for another post since here we just wanted to find a hole in the application that allows us to see the content of the underlying database.

I hope you enjoyed this walk through and hope to see you back next year for more exercises to attack the application.