The testing environment was redhat linux 7. 2 running on a pentium 100
with 64 megs of ram.
Started off with strings of the-binary.
Tried to search on the internet for *nazgul*, couldn't find anything.
Searching for "The Linux C library 5.3.12" + "yplib.c,v 2.6 1994/05/27 14:34:43
swen Exp" on google gave 1 result. The binary for a program called
safeload.
The strings from safeload are here
. The source is here
, Try http://www-miaif.lip6.fr/willy/pub/safeload/v0.2/untared/
The strings from "inetd" in the lrk4
rootkit also showed up in a google search search on "yplib.c,v 2.6 1994/05/27
14:34:43 swen Exp"
The with the strings output was from a honeynet report, http://project.honeynet.org/challenge/results/submissions/addam/strings/inetd.strings
Used the "REC portable decompiler engine and the MIPS R3000 disassembler"
to try and generate source code
.
See http://www.backerstreet.com/rec/rec.htm for the tool.
Generated assembly with objectdump -D, didn't
help much
.
Executing the program resulted in the "[mingetty]" process listening for
a raw nvp socket on port 11.
A remote nessus scan on the machine didn't provide any new information.
Used the HT editor to place nop's over the close system calls in the second
fork. Still no output.
I used fenris and modified the socket
to be bound as udp to port 5555. After struggling to do this I was unable
to figure out what bytes to send to it.
I created a udp client and was able to send data blocks to the-binary. I
tried an array of 0-499 but not much further, my assembly needs work. Saw
some conditionls to check the received data. Used fenris and aiger to step
through but was not able to get much past the data being received. After
the snort test data was released I tried sending the same packets to my fenris-port-5555-bound-binary
from a remote machine. Still ended up in endless conditional loop.
I restored the symbol tables using dress and saved it as "new-binary." I
still was not able to deduce much of anything from the assembly or the recovred
REC code.
Release of the snort test data helped. I constructed
a packet
and sent it via raw nvp on port 11 to the new-binary. I
modified my previous udp client
to send raw data over nvp. I used the string from
the forth packet
of the snort.log (one just before the hacked machine sent off outgoing connections).
Viola, Ptrace followed [mingetty]
as it forked, opened files and spawned new sockets. The information
here is difficult to interpret. Probably should have saved each fork in
a separate file.
I also used the Linux Trace Toolkit, http://www.opersys.com/LTT. This gives
a complete picture of the machine while the code was running. The output
was more clearly organized for me. The kerel trace daemon output for each
of the processes below was captured.
985 the-binary
-986
-987
-988
-989
-990
-991
-992
Some brief notes about what each process was doing, click on each of the
above for the actual trace output. Also the newtork calls
from the kernel here
. Socket call summary here
. Filesystem calls here.
985 - execs new-binary,
986 - setsid, sigaction, fork and exit
987 - chdir, close fd's 0,1,2, open the SOCKET, recv on socket, after receive
fork, repeat.
988 - fork
989 - read from .hj237349, sends 473 bytes over SOCKET, read from .hj237349
again, send message 498 bytes over SOCKET.
990 execve bash, opens and reads or maps the following (then forks):
ld.so.cache
libtermcap.so.2.0.8
libdl-2.2.4.so
libc-2.2.4.so
locale.alias
LC_IDENTIFICATION
LC_MEASUREMENT
LC_TELEPHONE
LC_ADDRESS
LC_NAME
LC_PAPER
LC_MESSAGES
SYS_LC_MESSAGES
LC_MONETARY
LC_COLLATE
LC_TIME
LC_NUMERIC
LC_CTYPE
mtab
meminfo
991 reads from .hj237349, execcve tcsh, opens files similar to above
lots of closes, then new socket, opens nsswitch.conf
ld.so.cache
libnss_files-2.2.4.so
group
socket call 7 fpm fd:16
utmp
ioctl
fork
992
ioctl
execve 8x
write
exit
Used tracker to detect changes to the filesystem. Hopefully computes md5
sums for all files and compares. http://hexadecimal.uoregon.edu/tracker/
Results here. Fresh install, took a snapshot, logged in to a second terminal
and ran a debug session. The altered devices,
crontab and log files
could be expected. Where is the file that was written by the last process.
Used snort to record network traffic but never saw any packets come out of
the test box. LTT showed out and in packets during the test. Perhaps they
were sent to 0.0.0.0.
Thanks for donating your time to read this. Spent a ton of time reading
and flailing all month. Ran out of time, learned a ton.
Some feferences
http://www.incidents.org/papers/ssh_exploit.pdf
http://jeff.wwti.com/papers/Mixter/trojans.txt
http://www.acm.uiuc.edu/sigmil/RevEng/t1.htm
http://www.phrack.com/phrack/58/p58-0x05
http://khdp.org/docs/project/b4b0/3/b4b0-3-7.txt