Backdoors-Part3

Kernel backdoors

The kernel on Unix is the core of how Unix works.  The same method used for libraries for bypassing MD5 checksum could be used at the kernel level, except even a statically linked program could not tell the difference.  A good backdoored kernel is probably one of the hardest to find by
administrators, fortunately kernel backdoor scripts have not yet been widely made available and no one knows how wide spread they really are.

File system backdoors

An intruder may want to store their loot or data on a server somewhere without the administrator finding the files.  The intruder's files can typically contain their toolbox of exploit scripts, backdoors, sniffer logs, copied data like email messages, source code, etc.    To hide these sometimes large files from an administrator, an intruder may patch the files system commands like "ls", "du", and "fsck" to hide the existence of certain directories or files.  At a very low level, one intruder's backdoor
created a section on the hard drive to have a proprietary format that was designated as "bad" sectors on the hard drive.  Thus an intruder could access those hidden files with only special tools, but to the regular administrator, it is very difficult to determine that the marked "bad" sectors were indeed storage area for the hidden file system.

Bootblock backdoors

In the PC world, many viruses have hid themselves within the bootblock section and most antivirus software will check to see if the bootblock has been altered.  On Unix, most administrators do not have any software that checks the bootblock, therefore some intruders have hidden some backdoors
in the bootblock area.

Process hiding backdoors

An intruder many times wants to hide the programs they are running.  The programs they want to hide are commonly a password cracker or a sniffer.  There are quite a few methods and here are some of the more common:
An intruder may write the program to modify its own argv[] to make it look like another process name.
An intruder could rename the sniffer program to a legitimate service like in.syslog and run it.  Thus when an administrator does a "ps" or looks at what is running, the standard service names appear.
An intruder could modify the library routines so that "ps" does not show all the processes.

An intruder could patch a backdoor or program into an interrupt driven routine so it does not appear in the process table.  An example backdoor using this technique is amod.tar.gz available on  http://star.niimm.spb.su/~maillist/bugtraq.1/0777.html

An intruder could modify the kernel to hide certain processes as well.

Rootkit

One of the most popular packages to install backdoors is rootkit.  It can easily be located using Web search engines.  From the Rootkit README, here are the typical files that get installed:

z2 - removes entries from utmp, wtmp, and lastlog.
Es - rokstar's ethernet sniffer for sun4 based kernels.
Fix - try to fake checksums, install with same dates/perms/u/g.
Sl - become root via a magic password sent to login.
Ic - modified ifconfig to remove PROMISC flag from output.
ps: - hides the processes.
Ns - modified netstat to hide connections to certain machines.
Ls - hides certain directories and files from being listed.
du5 - hides how much space is being used on your hard drive.
ls5 -  hides certain files and directories from being listed.


Network traffic backdoors

Not only do intruders want to hide their tracks on the machine, but also they want to hide their network traffic as much as possible.  These network traffic backdoors sometimes allow an intruder to gain access through a firewall.  There are many network backdoor programs that allow an intruder
to set up on a certain port number on a machine that will allow access without ever going through the normal services.  Because the traffic is going to a non-standard network port, the administrator can overlook the intruder's traffic.  These network traffic backdoors are typically using TCP, UDP, and ICMP, but it could be many other kinds of packets.

TCP Shell Backdoors

The intruder can set up these TCP Shell backdoors on some high port number possibly where the firewall is not blocking that TCP port.  Many times, they will be protected with a password just so that an administrator that connects to it, will not immediately see shell access.  An administrator can look for these connections with netstat to see what ports are listening and where current connections are going to and from.  Many times, these backdoors allow an intruder to get past TCP Wrapper technology.  These backdoors could be run on the SMTP port, which many firewalls allow traffic
to pass for e-mail.

UDP Shell Backdoors

Administrator many times can spot a TCP connection and notice the odd behavior, while UDP shell backdoors lack any connection so netstat would not show an intruder accessing the Unix machine.  Many firewalls have been configured to allow UDP packets for services like DNS through.  Many times, intruders will place the UDP Shell backdoor on that port and it will be
allowed to by-pass the firewall.

ICMP Shell Backdoors

Ping is one of the most common ways to find out if a machine is alive by sending and receiving ICMP packets.  Many firewalls allow outsiders to ping internal machines.  An intruder can put data in the Ping ICMP packets and tunnel a shell between the pinging machines.  An administrator may notice a flurry of Ping packets, but unless the administrator looks at the data in the packets, an intruder can be unnoticed.

Read More

Advanced Shell Coding Techniques

Introduction

This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper.  I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes.  I do not claim to have invented any of these techniques, except for the one that uses the div instruction.

The multiplicity of mul

This technique was originally developed by Sorbo of darkircop.net.  The mul instruction may, on the surface, seem mundane, and it's purpose obvious.  However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful.  First some background information on the mul instruction itself.

mul performs an unsigned multiply of two integers.  It takes only one operand, the other is implicitly specified by the %eax register.  So, a  common mul instruction might look something like this:

movl $0x0a,%eax
mul $0x0a

This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10.  The result is then implicitly stored in EDX:EAX.  The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).

So, now comes the ever-important question.  How can we use these attributes to our advantage when writing shellcode?  Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode.  It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication.  Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0?  The answer, as you may have guessed, is 0.  I think it's about time for some example code, so here it is:

xorl %ecx,%ecx
mul %ecx

What is this shellcode doing?  Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0.  Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX.  So, regardless of %eax's previous contents, %eax must now be 0.  However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax.  Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.


The div instruction

Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax.  Also like, mul it stores the result of the divide in %eax.  Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction.  But first, let's think about what is normally stored in the %eax register.  The %eax register holds the return value of functions and/or syscalls.  Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur).  So, if we know that after a syscall is performed, %eax will have a non-zero value, and that  the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax.  So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80.  It just so happens that the syscall that corresponds to the value 1 is exit().  Now for an example:

      
xorl %ebx,%ebx
mul %ebx
push %edx
pushl   $0x3268732f
pushl   $0x6e69622f
mov %esp, %ebx
push %edx
push %ebx
mov %esp,%ecx
movb $0xb, %al  #execve() syscall, doesn't return at all unless it fails, in which case it returns -1
int $0x80

divl %eax  # -1 / -1 = 1
int $0x80

Now, we have a 3 byte exit function, where as before it was 5 bytes.  However, there is a catch, what if a syscall does return 0?  Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero.  Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly.  They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping.  However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system.  So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.



Unlocking the power of leal

The leal instruction is an often neglected instruction in shellcode, even though it is quite useful.  Consider this short piece of shellcode.

xorl %ecx,%ecx
leal 0x10(%ecx),%eax

This will load the value 17 into eax, and clear all of the extraneous bits of eax.  This occurs because the leal instruction loads a variable of the type long into it's desitination operand.  In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts.  However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address.  In a normal shellcode we would do something like this, to accomplish the same thing:

xorl %eax,%eax
movb $0x10,%eax

I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right.  However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted.  Here's an example:

xorl    %eax,%eax
xorl    %ebx,%ebx
movb    $0x17,%al
int    $0x80
      
xorl %ebx,%ebx
leal 0x17(%ebx),%al
int $0x80

Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8.  Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.

Read More