|
|
--Boundary-00=_A+yHEtdwcr/Qm/F
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
Here is a text about pitbull, a tool based on SELF.
Enjoy.
pluf
--Boundary-00=_A+yHEtdwcr/Qm/F
Content-Type: text/plain;
charset="us-ascii";
name="7a69-PUP.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="7a69-PUP.txt"
Perverting Unix Processes
by Pluf
pluf@7a69ezine.org
1. Introduction
2. MXEcution
3. Pitbull
4. Conclusion
5. References
1. Introduction
The address space of a UNIX process can be used by an attacker to do as many
evil actions as possible. One of the most powerful techniques is the execution
of a new binary by using a userland execve() implementation [1]. The purpose
of this text is to present a tool based on SELF [2] and to explain which
elements are involved in its operation.
2. MXEcution
As we describe on [2]:
"If we want to execute that binary an undefined number of times (to parse
more arguments, test new features, etc) it will be needed to build and send
a new lxobject for each try. Although it obviously has some disadvantages,
it's enough for most situations. But what happens if what we really wish is
to execute our binary a lot of times but from the other side, that is, from
the remote machine, without building the lxobject?
To face this issue we have developed another technique called "multi-execution".
The multi-execution is a much more advanced derived implementation. Its main
feature is that the process of building a lxobject is always done in the remote
machine, one binary allowing infinite executions. Something like working with
a remote shell."
3. Pitbull
Pitbull is an example of a system that takes advantage of a process address
space in order to execute ELF binaries. It is primarily useful for building
post-exploitation frameworks and rootkits. It has been developed for Linux
but should not be a problem to port it to other UNIX platforms.
The pitbull's execution logic can be summarized in the following steps:
+ have a remote process which lend us its address space (jumper)
+ build a pitpack and sent it to the remote host
+ prepare the binary payload and start the interactive loader
As can be seen, pitbull comprises three objects: pitpacks, the pitpack builder
and the interactive loader.
Pitpacks:
A pitpack is a special data structure that is sent to the remote machine to be
placed somewhere into the process address space by the jumper. Each pitpack is
build by the pitpack builder and comprises two objects: the interactive loader
or IL (always present) and the binary payload (optional):
PitPack
|------------------------------------------------------------|
ILoader ELF Binary Payload
|-------------| |--------------------------------------------|
.------------------------------------------------------------,
| BIN0(SHELL) | HDR:BIN1(app1) | HDR:BIN2(app2) | .... |
'------------------------------------------------------------'
The binary payload is a group of statically linked ELF binaries and headers
which describe them (memory location and size). This is an optional element,
, it is possible to build a pitpack with an iloader only and retrieve the
binaries later.
Pitpack size: to send a statically linked binary from one host to another one
is sometimes difficult due to its size and the problem increases if more than
one of these binaries must be transmitted. To solve this issue we can send a
pitpack without binary payload and retrieve each binary later, these binballs
can be compressed as well.
Pitpack situation: to avoid problems the pitpacks are placed in mapped memory
areas reserved by mmap(), all of this is done automatically by the jumper.
Obviously, it is advisable not to use memory zones that can be overwritten or
take place during loading process, such as "heap" or "stack", see [2] (4.3).
Pitpack obscurity: a memory dumping of the process where a pitpack is placed
could be fatal, this is because a future analysis could detect and reconstruct
all the binaries which comprised the binary payload. We can't really avoid that
but is possible to make this work much more harder by obscuring the pitpack.
It has advantages and disadvantages, pitbull does not use this feature.
Interactive Loader:
The IL is a statically linked binary, contains its own stack context and
shellcode elf loader, this is we called "lxobject". When the jumper catches
the pitpack it starts the loading of the IL. Once the IL is loaded and running
correctly it tests for the presence of a binary payload. Then the binaries
founded are added into an internal "armoury". After this startup sequence the
IL is ready to execute binballs. The execution of a binary comprises the
following steps to be completed:
(first phase: shell process)
+ locate the requested binary in the binary payload (IL)
+ spawn a child process to be replaced by the binary (IL)
(second phase: child process)
+ get arguments and environment variables to build the stack context (IL)
+ patch the binary with shellcode elf loader and stack context (IL)
+ load and execute (SLOADER)
The original process (iloader) is responsible of doing the first two steps:
locates the binary to be executed (search) and creates a new child process
where it will be placed later (fork). Note that the location of a binary will
be more complicated and takes more time if the pitpack has been obscured. The
new child process must do the remaining steps, this is the most critical part,
if any of this steps are not executed successfully the child will crash. Also,
the building of the stack context raises one problem, the stack top address is
required: on kernels < 2.6.11 it is a well-known virtual address, 0xc0000000,
but the latest versions >= 2.6.11 have added virtual address space randomization
which makes difficult our task of locate it. One way to solve this is with the
following chunk of code:
detect_stack_top:
jmp get_exit_addr
call_signal:
popl %ecx
movl $0xb,%ebx
movl $__NR_signal,%eax
int $0x80
movl %esp,%edi
next:
inc %edi
movb (%edi),%al
jmp next
get_exit_addr:
call call_signal
exit:
movl $0xa,%ebx
movl $__NR_exit,%eax
int $0x80
4. Conclusion
Some of current attack frameworks add support for both [3] and [4] post-exploitation
techniques, and userland execve() is not an exception. Under certain circumstances
it could give to the attacker more functionalities and fun. Pitbull is just an
example so it lacks of some pretty important features: multi-os & multi-platform
support, pseudo-terminal support, secure transaction channel, pitpack obscurity,
and so on. I leave this part for you.
5. References
[1] The Design and Implementation of ul_exec. by the grugq
http://securityfocus.com/archive/1/348638/2003-12-29/2004-01-04/0
[2] Advanced Antiforensics: SELF. by Pluf & Ripe
http://www.phrack.org/phrack/63/p63-0x0b_Advanced_Antiforensics_and_SELF.txt
[3] Metasploit's Meterpreter. by Skape
http://www.nologin.org/Downloads/Papers/meterpreter.pdf
[4] Syscall Proxying - Simulating remote execution. by Maximiliano Caceres
http://www1.corest.com/files/files/11/SyscallProxying.pdf
begin 644 pitbull.tgz
M'XL(`(4&'D0``^P[:7/;.);Y.OP56/<1NUNB2.JT:J9GG*,[KG'
'-$[G17EV;D>=N2*R?H]NL)ZH^D\E''$FFI8)I