Hashbang.ca

Last Monday, I presented my solutions to the Natas server-side security war games at NSLUG. Afterwards, I spent some time to clean up my code, and I’ve now published it to CPAN as Hack::Natas, which comes with modules and scripts to solve level 15 and 16 in an automated way, plus walkthroughs for all the levels up to 17 written in Markdown (those are almost the same as my blog posts, so you’re not missing out by looking at only one or the other).

Last Monday, I presented my solutions to the Natas server-side security war games at my local linux users' group.

I recorded my talk, but it didn’t turn out well. I was using Google Hangouts for the first time, and I forgot that it only records the windows you tell it to. In the video, embedded below the fold, there’s a lot of talking about windows that were being projected, but which didn’t get recorded. Still, the audio counts for something, and you can see what I’m talking about much of the time.

This is the last level. We’re challenged with an improved version of level 9 – they’ve added additional “sanitation” to keep us out.

    if(preg_match('/[;|&`\'"]/',$key)) {
        print "Input contains an illegal character!";
    } else {
        passthru("grep -i \"$key\" dictionary.txt");
    }

We’re nearly at the end! This is the 2nd-last level.

We know there is a users table, with columns “username” and “password”. This time, the code just checks that the username exists. There’s no way to print out the data we want. Instead, we’ll have to do something cleverer.

In level 14, we see a more traditional username & password form. Let’s check the source code to see if there are holes we can slip through.

This is level 13. Looks like they claim to only accept image files, in order to close the flaw we used previously. I bet we can get around that restriction just like we did when they disallowed certain characters in the search term. Let’s examine the code.

Here’s the new part of the code:

    if (! exif_imagetype($_FILES['uploadedfile']['tmp_name'])) {
        echo "File is not an image";
    }

In level 12, we’re given a file upload form. Let’s take a look at the code that processes input.

This is level 11. Your clue is that “XOR encryption” is not encryption. Let’s look in the cookies to find out they have XOR-ed, so we can mess with it.

Welcome to level 10. “For security reasons, we now filter on certain characters” – okay they’ve gotten wise to our little game. But let’s check how good their countermeasures are.

Well, they don’t allow us to use the semicolon or ampersand any longer. Well that’s not a problem, I know other ways to manhandle that command into doing what I want.

In level 9, the “Input secret” form is replaced by one that looks like it is searching for words containing the string you provide. Give it a try, and then look at the code.

Well, this is just grepping through a wordlist, using the POSTed needle as a parameter. Since we control the value of that POSTed variable, we can control the command that gets executed. Now we need to figure out how to use that to our advantage.

Level 8 shows us another “Input secret” form. Let’s examine the source again. This time, there is an “encoded” secret. Let’s try to reverse engineer this. They’re using bin2hex, strrev, and base64_encode – those are all trivially reversible.

Level 7 is a simple webpage that doesn’t seem to offer us any clues about a vulnerability. Let’s click around those links a bit to see more.

Well, each of these links passes the name of the page to a PHP script, which seems to just stuff the contents of the file into the webpage. So, we should be able to change that URL parameter to whatever we want, in order to get the contents of the file containing the next password.

On level 6, there is a curious “Input secret” form. I wonder what it does? Well, there is also a “View sourcecode” link, which will presumably show us the source code for that form. Then, we can try to anaylze whether it has any weaknesses we can take advantage of.

“You are not logged in” – I wonder what that means. Normally, websites use cookies to tell whether you’re logged in. Let’s check if that’s the case here.

If you’re using Google Chrome, press CTRL-J and switch to the “Resources” tab. Expand the “Cookies” item, and select the current domain: “natas5.natas…” and lo and behold there is a cookie there. Named loggedin. With value 0. Remember, the client controls what gets sent in the cookies. That’s our attack vector.

We got an “access disallowed” error because we were visiting from “”, while authorized users should come from “natas5.blah”. Try the “Refresh page” link. Now the page says we came from “natas4.blah”. This is the referring to the Referer[[sic(https://en.wikipedia.org/wiki/Referer#Origin_of_the_term_referer)] header. But that’s information provided by the client, and we control the client. We can put whatever we want in that header. So, let’s put the natas5 domain, as they kindly suggested.

overthewire.org has a series of “war games” – challenges that help you learn by doing. Natas is the webserver security series. Although there are walkthroughs already available, I am going to do my own series of posts. Some of the existing walkthroughs are overly complex, and none actually finished all the levels. The war games unfortunately don’t have anything explaining why the example vulnerabilities can be important in real-world scenarios. I’ll try to fill that void.

I’m going to post one every few days, beginning with levels zero and one today.