honeynet reverse challenge | ||
Prev | Next |
Our first tactic in analyzing the binary was to run ldd in search of any shared library dependencies. This yielded nothing, which told us the binary was statically linked. This creates a larger file, but increases portability.
Next we searched for any tell-tale strings in the binary using strings. Some of the strings we found most interesting were...
[mingetty]
/tmp/.hj237349
/bin/csh -f -c "%s" 1> %s 2>&1
TfOjG
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin/:.
PATH
HISTFILE
linux
TERM
/bin/sh
/bin/csh -f -c "%s"
gethostby*.getanswer: asked for "%s", got "%s"
RESOLV_HOST_CONF
/etc/host.conf
order
bind
hosts
resolv+: "%s" is an invalid keyword
resolv+: valid keywords are: %s, %s and %s
resolv+: search order not specified or unrecognized keyword, host resolution will fail.
multi
nospoof
alert
reorder
trim
RESOLV_SERV_ORDER
RESOLV_SPOOF_CHECK
Given the assumption that the binary was designed with malicious intent, the strings above suggested two potential areas of inquiry:
Next, we began the reverse-engineering in earnest using tools like gdb and objdump. We sank more than a few hours into this phase of the analysis and didn't get too far for a number of reasons, not the least of which is that none of us are especially good with decompilers and assembly language. We were discouraged to learn that no only was the binary statically linked (which denied us shared library intelligence), but it lacked debugging symbols or function names.
We began getting frustrated at this point, so we took the inevitable step of running the binary to see if we could learn more about the genie once he was outside the bottle. Nothing exciting (or even noticeable) happened at the command line, so we ran ps -aux. By looking at the process start times, we were able to deduce (and then confirm) that the binary launched what appeared to be a mingetty process.
Next we ran netstat -alp and were able to see that our mingetty process was in fact a daemon listening for raw network voice protocol (NVP) traffic on no particular port (which is not a very mingetty-like thing to do). We now presumed the mingetty process name was camouflage only.
We began running strace to watch the bogus mingetty process interact with the system. This proved disappointing. We could watch the process launch and detach itself as a listening daemon (which we already knew), but after that the process just sat there waiting for some sort of stimulus. We bogged down here for a while then decided it was time to bring in the heavy artillery: Google.
We sifted through our accumulated knowledge of the binary looking for those bits which were most distinctive. After a couple tries we honed in on "NVP" and "mingetty" and asked Google to search on that query. Google returned one hit: http://www.incidents.org/archives/intrusions/msg00774.html
We contacted Ryan, who posted the message. This turned out to be a phenomenal piece of good luck. It turned out that Ryan was in possession of a binary which was ancestral to the binary we were analyzing. Better still, the ancestral binary contained debugging symbols which allowed us to see function names - function names like the following:
send_to_all
DNSFlood
encryptData
decryptData
Even knuckleheads like us could see what was going now.
Ryan's binary lacked the range of functions contained in our binary, but after mapping the commonalities, we were left with a few holes in a jigsaw puzzle which was mostly complete. We mapped the commonalities using REC (our decompiler of choice by this time) and a Perl script. The Perl script mapped function names into the decompiled output from our binary, using decompiled output from Ryan's binary as a Rosetta stone.
We drew some packet templates on paper and carefully stepped through the flood functions to see how it was constructing the packets. We made a reasonable (hopefully correct?) guess on the SYNFlood function. We were also was able to get an idea of how the NVP packets it was expecting were structured. Making a 'sendpacket'tool was reasonably easy, especially once we copy-and-pasted the encrypt/decrypt functions from the REC output (and tweaked it to compile and work right). With the sendpacket tool, we could send data to the binary and have to start calling some of those DoS functions.
Prev | Next | |
advisory | answers |