Revision

Disclaimer

First things first

ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

[mingetty]
/tmp/.hj237349
/bin/csh -f -c "%s" 1> %s 2>&1
TfOjG
/bin/csh -f -c "%s"

Next group of strings are "standard" strings contained in binaries statically compiled with libc and libresolv, e.g.:

@(#) The Linux C library 5.3.12
yplib.c,v 2.6 1994/05/27 14:34:43 swen Exp

The first command I ran on the-binary was 'file'. It tells you that the-binary is stripped. Maybe we can "dress" it homehow? ;-) A new tool was developed by lcamtuf as a part of fenris package which does just that: dress an unknown binary in symbols. It tries to recognize functions contained in an unknown executable and stores the known ones in ELF symbol table. Let's try 'dress' on the-binary:

$ dress -F fnprints.dat -F support/fn-libc5.dat -F support/fn-2.0.7.dat the-binary the-binary-dressed

[snip]
[+] All set. Detected fingerprints for 214 of 371 functions.

Actual disassembly

You can see many local variables, initial assigments and a call to geteuid. If euid is not 0 the-binary exits. Otherwise it proceeds. So the first thing you can learn it has to run as root, otherwise it exits without doing any harm. But is it really true? dress had fingerprinted standard functions but do you really know what's going inside those functions? Maybe the main we're looking at is just a fake and the real functionality lies inside functions we've just skipped? To check this possibility I've setup a UML (User Mode Linux) ) jail and ran the-binary as an unprivileged user under strace. Here's the output:

execve("./the-binary", ["./the-binary"], [/* 38 vars */]) = 0
personality(PER_LINUX)                  = 0
geteuid()                               = 1000
_exit(-1)                               = ?

After the binary knows it's running with euid=0 it tries to disguise in the system - first it sets argv[0] to all zeros and then copies the "[mingetty]" string onto its argv[0]. Simple ps would be fooled by this trick and unexperienced sysadmin could overlook this process.

Then it ignores SIGCHLD, forks, exits from parent process, calls setsid() and ignores SIGCHLD in the first child, forks again, exits from the first child. The second child is now the "main" process which will exist through the whole life of the-binary in the system. These 2 forks, ignoring SIGCHLD and calling setsid() is a typical "daemonization" sequence. However, as lcamtuf noted, those two fast consecutive forks could fool ptrace-based tools, as strace or fenris. The reason is flawed ptrace interface which does not provide a reliable way to follow forks or vforks in traced process.

After those 2 forks process closes stdin, stdout, stderr and changes current dir to "/". Then time is called and the result is passed on to next function, which unfortunately wasn't fingerprinted by dress. The function seems complicated and pretty cryptic. That's the point where experience comes in ;-) time is very often used as a seed to random number generator in C programs. The function called uses 12345 constant in several places. Could it be srand()? A quick check (compiling a simple program that does srand(time(NULL)) using gcc 2.7.2 and statically linked libc5) gives positive result :-)

Next called function also isn't fingerprinted however passed arguments look a little bit familiar - 2,3,11. Looking at the body of that function I've found out it's a wrapper for socket syscall (don't believe IDA, int 0x80 is _not_ reserved for BASIC ;-) EDX == 1 is socket() call (see /usr/src/linux/include/linux/net.h). The arguments passed are socket(PF_INET(2), SOCK_RAW(3), 11). So this call creates a raw socket which will receive any packets which have protocol field in IP header set to 11. Probably this is the mechanism used to control the-binary from the outer world.

After creating raw socket SIGHUP, SIGTERM and SIGCHLD are ignored. SIGCHLD is ignored 2 times for unknown reasons. Maybe the author wanted to ignore both SIGCLD and SIGCHLD ;-)

Below another non-fingerprinted function is called. A quick look at this function, consulting net.h and a name can be given: recv(). Using this knowledge we can name var_800 to something more meaningful, e.g. packet. This is the buffer which will hold received packet. A nice thing to have is also IP header structure which will give a better "feeling" of the code that will operate on the packet.

After receiving the packet there is a rather redundant check if the received packet has really protocol field set to 11. The first byte of the payload has to be 2 and the total packet length has to be grater than 200 - otherwise the-binary will reject the packet. If those checks are passed a function is called with a pointer to the 3rd byte of payload, length subtracted by 22 and an unknown pointer. I've deducted from that that the first two bytes of the payload are used as a marker. Actually only the first byte is checked (it has to contain 2).

Looking at the function called we see it only calls sprintf and does some magic on the both pointers passed as arguments. I won't go in detail here how to reverse this function: it's short and after half an hour it doesn't as cryptic as it seem. I've constructed C code, which compiled using gcc 2.7.2 looks astonishigly similar to our unknown function:

void decode(uchar *decoded, uchar *data, int len)
{
        int i = len-1, j, k;
        uchar tmp[len];
        uchar c;

        decoded[0] = zero;
        while (i >= 0) {
                j = i-1;
                if (i) c = data[i]-data[j]; else c = data[0];
                k = c - 0x17;
                while (k < 0) k += 0x100;
                j = 0;
                while (j < len) { tmp[j] = decoded[j]; j++; } // **
                decoded[0] = k;
                j = 1;
                while (j < len) { decoded[j] = tmp[j-1]; j++; }
                sprintf(decoded, "%c%s", k, tmp);
                i--;
        }
}

After the decryption the second byte of decrypted data is taken as an argument to switch statement. It looks like our target has 12 commands (numbered 1-13) and they're recognized right here.

Command no 1

void encode(uchar *encoded, uchar *data, int len)
{
        int i;

        encoded[0] = zero;
        sprintf(encoded, "%c", data[0]+0x17);
        for (i = 1; i < len; i++)
                encoded[i] = data[i]+encoded[i-1]+0x17;
}

First it creates a raw socket then allocates arg_C+23 bytes of data. Then some memory is moved back and forth and almost at the end a function is called which was fingerprinted as recfrom__sendto (it's a shame dress couldn't recognize between those two ;-). After checking socketcall number you can rename it to sendto :-) Quick check in man page allows to rename var_10 to to sockaddr (and making appropriate sockaddr_in structure) and arg_C to len. After some polishing (telling IDA to rename anonymous number offsets into symbolic names pointing into ipheader or sockaddr_in) the code is now self-commenting :-) To achieve the same effect as in sample IDB base use XREF function exetensively until you name all of the local variables and arguments and change magic numbers into symbols constants and offsets.

I won't explore sub_0_8049138 here as it's very simple and dress has done 90% of the hard work here :-) I will just allow myself to comment on poor skills of the author who uses sprintf(buf, "%d.%d.%d.%d", ip[0], ip[1], ip[2], ip[3]) and then gethostbyname(buf) to convert char ip[4] into int ;-) Summing up sub_0_8048f94: it creates socket, calls malloc, sets up IP header, copies payload passed as argument (to be exact pointer to payload is passed as an argument) into the packet's payload but at offset 2, reserving first two bytes supposedly for packet signature (only the first byte is set to 3, second is left unmodified after malloc) and finally it sends it. Source and destination address (again pointers to addresses) are passed as arguments. I've named this function send_raw_packet.

(Short digression here: it takes some effort to track all the parameters from already known functions in order to understand the "outer" routines. Full versions of IDA do this automatically for you :-) Such feature speeds up reverse-engineering a lot, as most functions which actually do anything useful have to call system function once and a while. Identyfying used structures and naming variables some sane names gives a much better understanding of the code).

XREFs to send_raw_packet show that it's called only in sub_0_8048ecc. Armed with knowledge about send_raw_packet we can analyse sub_0_8048ecc. If dword_0_807e784 is 0 it only sends only one packet from address stored in byte_0_807e780 to address pointed by arg_0. Pointer to payload is passed as arg_4 and payload's length is stored in arg_8. If dword_0_807e784 is not 0 send_raw_packet is called 10 times, each time dstaddrptr is incremented by 4, so the packet is sent to 10 addresses.

Again looking at cross-references to global variables used in this function (I've called it send_to_all) shows us that all of them are set in main, in the second case of the switch statement.

Now back to main. After this journey into send_to_all it is easy to discover that var_44e4 is pointer to address table (addrtabptr). In the very beginning of main it's initialized to point to var_11b8 and it's never changed again. So var_11b8 is the address table (addrtab). Contents of the packet sent is some magic values and if some variable is non-zero the value of another variable is stored in the packet. Those two variables are unknown now but after finishing this tutorial you'll find all of the variables named and the intention of the author will be clear :-)

Command no 2

Next it fills internal address table (you've seen it already, used in the first command, will be also used again) using contents of the packet. First a random number in range [0..9] is chosen. It is stored in EDI. EBX is current index into the internal address table and iterates from 0 to 9 inclusive. If those 2 registers are equal nothing is done - this entry is skipped. If they're different position in address table pointed by EBX is filled either with IP address from the received packet (indexed again by EBX) - if cmd2_param is 2 - or random IP address (4 calls to rand()) otherwise.

After the whole loop the first address from the packet is copied to the position indexed by EDI (the random number chosen) if cmd2_param is non-zero or to the first position if cmd2_param is 0.

This rather messy (both in implementation and my explanation ;-) was developed in my opinion to disguise real IP address controlling the-binary. Attacker can provide other fake addresses or rely on the-binary to choose some random ones. In testing environment it's also possible to register only one (cmd2_param == 0) controller to avoid generating unnecessary network traffic.

I've named this command "register_controller" because it registers controller address(es) in the-binary allowing attacker to use "status" (and maybe other?) command.

Command no 3

I've renamed dword_807e770 to child_pid and looked at crossreferences. It is used only in two commands: this one and number 7. Looking at those commands you can see they have much in common (similar structure and strings used). child_pid is used to kill some process. Remember that in some circumstances child_pid could be 0, so could we possibly trick this command to kill the-binary (kill(0) kills all the processes in the group the process issuing kill belongs to)? Unfortunately not, because before the-binary calls kill it calls setsid. Hopefully we'll find some other way later ;-)

Looking below the first fork you can see that the parent returns to the main loop and child forks again. The first forked child calls sub_0_80556CC(10) and then kills child_pid with SIGKILL.

After inspection of pretty complicated sub_0_80556CC and recalling libc sources (yes, to reverse engineer you have to read libc sources. Not a very amusing friday evening filler though ;-) you can simply name it 'sleep'. Now it's clear: the 1st child is a 'guard' for the 2nd child. If the 2nd one executes more than 10 seconds it gets killed and 1st one exits too. So what does the 2nd one do? First it gets everything what's after the command number in the decoded packet, sprintfs it into a buffer using this format string:

/bin/csh -f -c "%s" 1> %s 2>&1

/tmp/.hj237349

As you can see the-binary allows the attacker to issue a command and see it's output. However it will fail if no csh is present on the system. I don't have any statistics here handy which distros have csh as a default (my Debian/sid certainly doesn't ;-) but I would take a guess and say it's not unprobable if the csh was missing ;-)

Command no 4

Command no 6

The parent thread of execution after fork as usually goes back to receiving more packets and the childs ignores a bunch of signals (including SIGCHLD twice, anybody knows what can it be?) and creating an ordinary SOCK_STREAM socket (not RAW this time). Another thing which can draw reverser attention is a strange constant 0xf15a. Analysing setsockopt arguments you can easily reveal that the-binary is setting SO_REUSEADDR on the newly created socket.

Below you can find two unexplored subroutines which turn out to be bind and listen respectively. Now it's time to recall listen and bind arguments. Having done so it's no surprise that var_11c8 is sockaddr_in structure which describes address and port we're binding to. Now it's clear what 0xf15a is: it's the port we're binding to (it's network byte order, so in fact it's 0x05a1f). After binding a typical network server does accept() and the-binary is no exception - rename sub_0_8056A2C to accept, var_11d8 to sockaddr and var_44cc to accsockfd. After accepting a connection the-binary forks again. Parent loops and tries to accept another connection and the child processes incoming connection (so this command can easily be used as a local DoS). At most 19 bytes are read, and crypted until the first \r or \n character. Crypting here means adding 1 to every byte ;-) Encrypted input is compared with TfOjG. (Devising a plaintext from "TfOjG" ciphertext is left as an excerise to the reader ;-) If they're identical a shell is spawned (surprise, surprise) with stdin, stdout and stderr bound to incoming connection. This time /bin/sh is used instead of /bin/csh. If the password is not correct some garbage (0x1fbff) is sent to the poor h4x0r and the process ends.

Command no 7

Commands no 5, 9,10,11 & 12 are similar to command no 4. I will describe only 4th command, the rest is similiar and in my opinion even easier. They have similar structure and technique used to reverse engineer them is the same: identify all of the structures and arguments used in syscalls, give some same names to local variables and arguments and with this power in hand analyse the execution flow making educated guesses and comment thoroughly. It's worth to note that command 4 & 9 and 10 & 11 call the same subroutine. The only difference is in one parameter which is set to 0 in commands 4 & 10, and is taken from the received packet in command 9 & 11. I have no idea why there are two almost identical commands. Maybe it's an early beta version?

Command 4 (again)

Basing on previous experience var_228 becomes addr (of type sockaddr_in) and var_638 becomes packet (of type ip_packet). var_24 seems to be a table of lengths (indexed by edi). Value from this table is incremented by 28 (hmm, 20 is IP header, 8 is UDP header length, could it be a UDP packet?). In XREFs you can see that packet is pointed by esi throughout the function. So find all the places where esi is used as an index register and change the numerical offsets into symbolic ones into ip_header structure (hint for IDA developers: this could be automated ;-). Now you can easily see that the packet the-binary is constructing is indeed a UDP one :-), so var_624 is in fact a udp_header structure and var_65c becomes udpheadptr. XREFing this pointer you can see how the UDP header is constructed - destination port is set to 0x3500 which in host byte order becomes 53 decimal...

Yes, it's a DNS attack! Not sure now what exactly kind of attack but you're certainly moving in the right direction. As a side-effect of this little discovery is knowledge about two arguments: arg_14 is the LSB of source port and arg_18 is MSB. Now var_61c can be renamed to dnshead and var_660 to dnsheadptr. XREFing the latter you can see how the DNS queries are actually set up. The routine takes the length of the query from previously identified lengths table (of dwords, indexed by edi) and copies that many bytes from var_218 indexed by var_670 into DNS packet. What is var_670? To answer this question you have to go back to the very beginning of the function. 125 dwords from word_0_80676BC are copied into var_670. Looking at word_0_80676BC you can quickly realize they're actual DNS queries :-) Rename it to some sane name (like dns_queries) and take a good look at them. There is total of 9 queries. They look up SOA of com. net. de. edu. org. usc.edu. es. gr. ie. respectively. However all of the two-letter queries (i.e. for de. es. gr. and ie.) are buggy! The author has used a popular programming technology called 'cut-and-paste' but failed to properly test his masterpiece (or she didn't understand at all what this weird DNS is about). Length marker in front of strings should be definetely 2, not 3. All of DNS servers (haven't tried _that_ many, I admit) should respond with an error to such a query. Just above the copying of queries you can see that the routine is making a local copy of queries lengths.

Now almost all elements of this simple puzzle are coming together. The only thing not yet discovered are source and destination addresses of IP packets sent. Looking through the function body (or using text search if you've correctly spotted all esi occurences) you can spot 2 occurences of srcaddr.

The first one is just after gethostbyname. It is called with arg_20 as a parameter. To understand this snippet you have to look a little bit above gethostbyname: the lookup is performed only when arg_1C is 1 and var_668 is zero or less. If the lookup succeeded (returned non-NULL) var_63c (renamed to resolvedaddr) is filled with the first returned IP address. Then this address is copied to its proper place in IP header. If gethostbyname returned NULL the process sleeps for 10 minutes and tries resolve it in infinite loop.

The second one is just after setting up of UDP header. It checks if arg_1C is 0. If it is 4 local variables are used to set up source address. arg_1C seems to be a some kind of flag. Checking how those 4 local variables are set up gives the final answer: arg_1C == 0 means the source address is given as an IP number and arg_1C != 0 means there is a hostname to resolve.

Destination address is set in 2 places: in the IP header and in the sockaddr_in structure. Both are set (surprise, surprise) to the same value taken from the location pointed by var_66c. This variable points to some element inside dword_0_806D22C table. Seems like the-binary is holding a table of 11418 DNS servers which are used as reflectors in this attack.

Now all of the pieces are in their places and it's to easy to follow execution flow. First local variables are initialized and a local copy of DNS queries and their lengths is made. A raw socket is created (in case of a failure the routine ends) and the buffer which will hold a DNS packet is zeroed.

Then loc_0_8049250 is reached which is referenced from the code below (as you can see by the arrow pointing down) which probably indicated a loop. The first reference points to a small loop in which given hostname (if any) is resolved (I've already covered this snippet). The second one is way down, almost at the of the routine. As you can see the epilogue can only be reached if creation of a raw socket fails so the jump to loc_0_8049250 makes an infinite loop.

loc_0_80492C4 seems to be another loop. Looking at the condition at loc_0_8049530 it's easy to deduct that this one interates over all of the 9 DNS queries hadrcoded in the-binary. This loops starts with choosing a random number in range [0..7999] (and storing it in EDX) if var_654 is 1. It's initialized to 1 outside all loops and set to 0 after positive check. If var_654 is already 0 EDX is set 0. var_654 is not modified anywhere else so it's a flag variable which indicates if the code executes first iteration. After the first iteration flag is cleared.

EDX is then used as and index to dns_servers table which holds the IP addresses of DNS servers. If we accidentaly found a 0 on the list the query pointer is dvanced to the next query and the outer loop continues. Howver with more than 11000 positions in the table it's not possible to find a 0 in the first 8000 so this check is rather useless.

Now execution reaches loc_0_8049308 which is the most inner loop found in this routine. This one iterates over DNS servers on the list until 0 is reached. If it is the pointer is advanced and the next query is used. Inside the loop the packet is prepared: actual query copied, random DNS query id chosen, a random UDP source port (in range [0..29999]) is chosen if none given (to be exact: if 0 given), UDP destination port set to 53, length computed (based on queries' length table), source and destination address filled, UDP checksum zeroed (UDP packets are not requiered to have checksum computed, 0 means no checksum), proper value in IP version and header length set, random TTL chosen (120+random()%130), random IP ID (in range [0..254]) chosen, IP protocol set to UDP, fragmentation and flags set to 0 and finally IP checksum computed. Then the packet is sent and complex formulaes are evaluated in order to determine if it's time to sleep ;-) The code generated here was optimized with gcc so I won't try to describe how it works with natural language, I'll use C for that matter:

if (arg_10 == 0) {
  usleep(300);
  var_668--;
} else if (arg_10 == var_664) {
  usleep(300);
  var_664 = 0;
  var_668--;
} else var_664++;

After this analysis you can clearly see it's a DNS reflector attack. It uses a hard-coded list of DNS servers which serve as reflectors and a hard-coded list of 9 queries used in the attack. 4 of the queries are buggy and don't trigger the effect of bandwidth amplification but the rest are properly constructed DNS queries and the response sent to the victim is almost twice the size of request.