This level looks a lot like level 9 did with the dictionary lookup and it suggests there are now more input checks. Let’s see the source:
If you put the same query as level 9 $(cat /etc/natas_webpass/natas17 1>/proc/$$/fd/1) into the Search field, it doesn’t work. However, if you put it directly into the address bar after “index.php?” it still works! It’s also pretty obvious this wasn’t the intended way to solve the challenge, but those are the most fun ways, amirite?
LEVEL 17
This level is a lot like level 15, however, it gives no output at all, ever! Looking at the source code shows that the output fields are just completely commented out.
The source:
That means there’s no straightforward way to extract information about the password. Situations like this is a totally blind SQL injection. Basically, we have to use some kind of side-channel information, like the time it takes to load the page. It can be tested with a SQLi query like ” OR IF(1=1,SLEEP(5),null)# where you can see how the response takes much longer to arrive.
Rewriting the script from level 15 to measure the website’s response time as the indicator should work.
LEVEL 18
sourcecode:
This level is apparently designed to give us the password for the next level if we have a flag “admin” equal to 1. The code where “admin” is updated has been commented out, so we’re going to have to go about it another way. Notice at the top of the sourcecode is gives us a limit to the session id, 640. That suggests it’s incremental, and we can hijack an admin session by guessing the session id.
This is the code I used for the bruteforcing.
LEVEL 19
This level doesn’t supply a link to it’s sourcecode, so we have to logically deduce what is going on behind the scenes. Much of the functionality should be the same as the previous level, but the text suggests there is a change to the session id.
After attempting the login, then you can see what the session id is. Try a few logins to compare different session id’s. These are the ones I got:
Only the first half of the ID changes. Also, just from experience with binary data, it looks to me like hex encoded ascii. When decoded, they come out to:
1) 599-admin 2) 631-admin 3) 379-admin
The pattern is pretty clear, this level just adds “-admin” onto the incremental ID. Simply add that to the attack code from before to get the password to the next level.
LEVEL 20
sourcecode:
Figuring out this code and what it is doing took me a little while. What is positively super helpful is setting the “debug” flag. To do so, just add”?debug=1″ on the URL. That will help provide a lot of insight.
You’ll see that whatever you put into the form after “name”, the debug returns it as part of your name, and that works even if it’s on a new line! According to the source we have, when the code reads back data from the session file it does so line by line. So new lines mean new variables to the server side code, and the variable we’re interested in is “admin”. Therefore “admin” needs to be set after the name variable. One caveat though, variables set in forms are in the format “variable=value”, and that doesn’t work for the server side “admin” variable. That one actually needs to be in the format “variable value”.
So the way to get admin is, using Burp, add “admin 1” on a new line by itself after the “name” variable. Then you’ll have to load the page twice. Once for the code to write it into the session file on the server. And the second to read it back as an admin status.