Natas Level 15
This time, we see a little login-esque box which checks if a username exists in the database or not.
Again, in the source code a query is being run
$query = "SELECT * from users where username=\"".$_REQUEST["username"]."\"";
Once the quotations are expanded it becomes:
SELECT * from users where username=”input”;
From what we can gather, it’s possible to use sql injection, and we could definitely brute force the password by checking each character and matching it to the username via a query that would look something like:
SELECT * from users where username=”input” and password like binary “%A%”;
However, we can use a tool called SQLmap which can do this for us automatically.
Like most web accessing scripts we need to give the tool some information so it knows what to do:
The complete call of the script is:
sqlmap --auth-type=basic --auth-cred=natas15:TTkaI7AWG4iDERztBcEyKV7kRXH1EZRB -u http://natas15.natas.labs.overthewire.org/index.php --data="username=something" -p username --string=doesn --level=5 --user-agent=Mozilla --dbms=MySQL --threads 4 -D natas15 -T users --dump
This takes a while to run and tries to find all the vulnerabilites of the site. It is capable of doing many things, such as time delay sql injections, regular sql injections, and many other fun pen testing operations! In this case, I've used it as I was too lazy to write a brute force algorithm and kind of wanted to try the tool out.
Once the tool is done running, it left us with these results from the sql injection attacks:
Pass for next level: TRD7iZrd5gATjj9PkPEuaOlfEjHqj32V
Natas Level 16
This level is similar to Natas 9 & 10 but with even more restrictions on the input.
In Natas 9 we exploited the use of ; to cat the password file, and in Natas 10 we exploited greps built in multi search ability, but in this case this isn’t possible. The key is double quoted, and so anything we put as the key will be used as one input - thus eliminating the grep vulnerability.
However, if you’re familiar with shell you’ll know that $() can be used for command substitution, and while it can’t give us the password directly in this case - we can use it to determine certain things.
Reading the source code, we can see that our input should return a case insensitive match of our input if it’s valid.
Using command substitution, we should be able to test all the inputs for the password and have a final valid password for level 17. The key idea here is that if we use
$(grep somecharacters thepasswordfilefornatas17)
in our input, if -somecharacters- appears in the natas17 password, then the command substitution will return it’s result. This works in our favour, as we can use a regular input, and then add the command substitution. If the command works, the input gets mangled, if it doesn’t then we get a result from the website.
As the output still shows zooms, we know that “a” is not in the password.
As the output shows nothing, we know that x is in the password.
We brute force all the possible combinations of numbers and letters and then go through all of those to try and find the password by testing strings and not just single characters. We find all the possible characters first to reduce the time complexity of the solution as testing all the characters would take a lot longer than a smaller subset.
This is the python script I wrote for this.
The result of running the script was this:
(It took around 30 minutes, I went to eat some food while the script ran)
Pass for next level: XkEuChE0SbnKBvH1RU7ksIb9uuLmI7sd
Natas Level 17
This level is similar in appearance to level 15. Level 15 was exploitable via brute forcing sql injections to figure out the password. However, in this level we don’t have the ability to check text output as all the outputs have been commented out, and so checking usernames results in an empty result.
Typically we would use a time delay sql injection attack, where we use an sql query combined with a sleep function. When the sql returns a query, we && a delay function and then we test the time taken for our queries to return.
The query returns a result before our expected time => it didn’t work
The query returns a result after our expected time => it did work
This is the philosophy of how the time delay sqli works. There are some drawbacks, like network delays and things that could cause issues, but these can be overcome by simply increasing the time delay that is used (with the obvious drawback being a slower attack).
I decided to use the sqlmap tool again in a similar way to level 15 to get myself familiar with using pen testing tools, but it is entirely possible to write a python script which does the same thing I’m doing and probably faster as well. This is because sqlmap detects the vulnerability in the website and then performs multiple attacks.
sqlmap --auth-type=basic --auth-cred=natas17:XkEuChE0SbnKBvH1RU7ksIb9uuLmI7sd -u http://natas17.natas.labs.overthewire.org/index.php --data="username=something" -p username --level=5 --user-agent=Mozilla --dbms=MySQL --threads 1 -D natas17 -T users --dump
In this query, we removed the string to check for as nothing gets returned, and we ensure that only 1 thread is used, as multiple threads can increase false positives/negatives as it’s hard to account for thread switching in the time count.
After 2 hours, we get the results for the passwords. As sqlmap goes through all the passwords/usernames it can take a long time if all the passwords are long strings like in this example.
Pass for next level: 8NEDUUxg8kFgPV84uLwvZkGn6okJQ6aq
What I learnt
These levels were quite difficult to do. However it was great fun to learn about time delay basde sql attacks and how time consuming they can be due to network interruptions. Many of these solutions involved brute force attacks, and writing up my own script for level 16 was fun as it has been a while since I used python for anything.
Top comments (0)