Technolution

In today’s post, we’re going to be looking at Level 6 of the Natas wargame hosted by Over The Wire.

What’s Going On?

Upon logging in, we are presented with a text input, a button and a link entitled View sourcecode.  Clicking on the view source code link we get presented with what looks like a php file.  It seems to be the index code, php code included.  This gives us a chance to reverse what is happening and perhaps figure out what to put in the text box.

Looking at the php file we can see an include statement on a .inc file, perhaps a file which we could read (since .inc files aren’t run through the PHP interpreter by default).  Additionally we see a check for the existence of a variable called “submit” passed through POST.  If submit exists, then POST’s secret variable is checked against the php page’s secret variable, I wonder where that was defined.  If the secrets match, the password for the next level will be printed to the screen.

Looking at the HTML we can see the form is standard and will set these values if we simply know what we want to supply as the secret.  So, let’s go and look at that include file and see if the secret variable is defined there.  Pointing our browsers at the file, we get returned a php line of code which instantiates the secret variable.  Let’s copy that value and submit it through the form!

The results for submitting the correct secret speak for themselves.  We get an “Access Granted” message as well as the password for the next level!

So What?

I guess there are a couple things to take home from this level.  When writing in PHP or any other server-side scripting language, building security around obscurity is not a good idea (well, it never is).  Don’t attempt to claim your code is safe just because it’s complicated to reverse without seeing the code, but simple otherwise.  Also, know how your code might be revealed, and what the consequences are.  Know what file types get interpreted and which file types don’t.  Know what will happen if your PHP process goes down and page requests are still made to the server.

In today’s post, we’re going to be looking at Level 5 of the Natas wargame hosted by Over The Wire.  This is a web-based wargame and requires the password obtained through level 4.  Without further adieu, let’s point our browsers at the level5 page and log in!

What’s The Haps?

Upon logging in we get quite an interesting message.  This time it says that we are not currently logged in!  However, we can see the page loaded, which means we entered the correct username/password for Apache to let us into the directory.  Then, what do they mean, we aren’t logged in?  Well, let’s look at the source to double check on anything obvious.  Nothing much there.  Ok, so we haven’t submitted much of anything.  So I don’t believe they’re expecting POST/GET data for a form log in (and I wouldn’t know where to start on name/pass).  So what could they mean, we aren’t logged in?  What could be communicating that, leading to that state?

Well, like we said in level 4, HTTP is a stateless protocol.  As such, the fact that we’re not logged in needs to be stored somewhere.  Since I haven’t seen us provide info (such as through a web-form), lets look at the next spot that could be checked.  Websites often make use of cookies to store bits of data on a user’s computer.  This can often be used to track shopping carts, or if a user has logged in to a web application.  So, let’s check our cookies.

To view cookies in Chrome, let’s go to Menu -> Settings -> Show Advanced Settings… -> Content Settings -> All Cookies and Site Data -> Type Natas5 into the search box.  Firefox users, there is a similar process.  Here we can see that there is one cookie used by the natas5 site and that it goes by the name “loggedin”!  Looking at it further we can see that it has the value zero (perhaps logic false).  So now we know the website uses the cookie, perhaps telling us we aren’t logged in because of the value of the cookie to track state.  What will happen if we change the value of the cookie?

Exploit

To exploit this vulnerability, let’s make use of a simple Chrome add-on called “Edit This Cookie.”  Perform a quick Google search to download and install the add-on.  Then, load the level 5 page.  From here, click on the cookie icon in the upper right hand corner of the address bar to open the add-on.  It should already be looking at the “loggedin” cookie, with the default value 0.  Let’s change that 0 to a 1, then click submit cookie changes.  Finally let’s reload the page.  We should now see an “Access Granted” message, a long with the password for the next level!

So What?

This level yet again emphasizes the statelessness of the HTTP protocol and the various ways in which state can be added on through cookies.  However, it stresses the importance of using a good system for verification of state, since cookie values come from users and thus can be crafted by malicious users.

Let’s look at Natas Level 4 in this post.  To get started, point your browser over to the level 4 website, http://natas4.natas.labs.overthewire.org/, and log in with the password from the previous level.

What’s Going On?

Upon logging in we get a message that access is disallowed and that it will only be granted to people coming from http://natas5.natas.labs.overthewire.org/.  Well that’s interesting, how are we supposed to come from level 5?  Well, for this we’re going to look into how HTTP requests work.

First, it should be clear enough to say that HTTP requests are generated by a client and sent to an HTTP server.  This server processes the request and sends a response back to the client.  In browsing the web, this happens through our web-browser and we are usually unaware of it.  That is, until we get messages back from the server saying things like HTTP Error 404, File Not Found.

So, how does a website know things like where a person is coming from when they are requesting a page?  Well, since HTTP is a stateless protocol, it’s supplied in the clients HTTP request.  This attribute of the HTTP request is called the “referer”, and is usually set by your browser when you follow a link.  Thus, since it’s supplied by the user, it is something the user can fake!  Let’s attempt to do that for this level.

Exploit

In this level we’re going to switch from using the browser now, to using the command line!  We’re going to make simple use of the cURL program.  This is standard on many Linux distributions and is also available for Windows.  cURL lets us request a curl via the command line, as well as supply changes to the HTTP request based on command line arguments.  Today we’ll be making use of the –user and –referer arguments.  The user argument lets us specify the username and password to log in to the natas level4 web page.  The referer argument lets us specify our own URL to act as the referer of our HTTP request.  Putting it all together we should get:

curl –user natas4:PasswordForNatas4GoesHere –referer http://natas5.natas.labs.overthewire.org/ http://natas4.natas.labs.overthewire.org/

In response we should see a print out of the HTML from the request, and if done correctly this code includes the password for natas level 5!

So What?

This level is a reminder about the statelessness of HTTP and as such the unverified nature of HTTP request attributes.  HTTP requests are under the full control of the user/crafter, and as such should be best treated as being from a malicious request creator, not an average user.

Welcome back.  In this post we’re going to continue on in the Natas wargame, provided by Over The Wire.  This is a web-based wargame highlighting web security issues.  Let’s get started.

Level 2

Upon logging into the level2 page with the password we acquired during the previous level, we see a message saying that there is nothing on this page.  That’s great, but lets see if there is anything of use.  View source!  Upon viewing source we can see two links to directory structures.  One is to the css file for Natas, and looking at the URL we might remember that’s the main URL of natas.  This means that when we go there, there must exist some sort of index.html file, the default file which is loaded when a directory is accessed.  Thus, we won’t be able to get a listing of the directory.  However, if we look at the other link, “files/pixel.png”, we see that the local files directory is a directory we haven’t looked in yet.  So, let’s go there and see if we can get a directory listing to find anything interesting.  Hitting http://natas2.natas.labs.overthewire.org/files/ we get a directory listing of two files, pixel.png and users.txt.  Looking in users.txt we see the password for the next level!

Moral of the story?  Watch which directories are in a www view-able folder.  Throw in an index.html if you don’t want a directory listing in a directory, or use something like .htaccess to limit access in specific directories, or turn off directory listing in general!

Level 3

Upon logging into the level3 web page, we see a message saying nothing is there, again.  So let’s view source (this should be second nature by now).  A comment says there are no information leaks, not even to Google.  What could that mean?

Well, if you know how Google works (at least in the big picture), you might know that they “crawl” through the internet looking for pages so that they can index them and search through them.  They also know that certain web owners may not want google searching through certain things.  As such, Google and many other search engines will look for specific files for them which describe what they can search through and what they shouldn’t, on a given webpage.  This might be what level3’s comment is talking about.  If this file exists telling Google not to look in certain places, it will give us an idea of the directory structure of this level!  This file is called robots.txt.  Let’s look for this file ourselves!

Pointing our browser at robots.txt we see it specifies a directory which shouldn’t be searched.  However, since this is just a request for search engines to not search it, it still allows for us users to load it up!  Looking in this directory we see a single users.txt file with the password for the next level.  Done!

Lesson?  Robots.txt requests for search engines to not search through directories, it doesn’t disallow them to, nor does it disallow directory listings.  Robots.txt is a polite request for someone not to do something, it isn’t a security measure!

Today we’re going to start looking at a new wargame.  This game is hosted on OverTheWire.org and is called Natas.  It is a web-based game and will be different than the shell based games we’ve looked at so far.  So, without further adieu, let’s get started.

Level 0

To start, let’s follow the instructions on the Natas webpage, and point our browser to the level0 URL, http://natas0.natas.labs.overthewire.org, and login with the username/password natas0/natas0.  Upon logging in we get a message saying the password for the next level is on this page!  Well, since we know that the web browser formats what the web server sent us, let’s simply view source so we can see most of what was sent, without formatting.  Upon viewing the source we see an HTML comment with the password of the next level in it.  Tada!

Level 1

Let’s login to the level1 page, http://natas1.natas.labs.overthewire.org/, with the password we got from level0.  Once there we see a message saying the password is on the page, but we can’t right click!  That doesn’t make the source safe!  There are many options to view the source without right clicking.  In Chrome you can go to Menu -> Tools -> View Source (shortcut Ctrl+u), Firefox is similar.  One could also make a telnet/netcat connection to the server and request the HTML files themselves, and skip the browser!  Any approach works, and once we are viewing the source, we again see the password to the next level.

So What?

These levels are a reminder that anything in an HTML file will be sent to the user that requested the file from the server.  Thus, don’t put anything secretive within an HTML file, even if it’s a comment!  HTML is formatted by the user’s browser, not the webserver, so all comments will also be sent to users.