"I am somehow less interested in the weight and convolutions of Einstein's brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." | |
Stephen Jay Gould |
This alone doesn't react to an incoming buffer in any visible way. Tracing through the using kdbg we witnessed memory changes taking place in response to this command. However, we were unable to determine the exact function of this command alone. We do know that upon issuing command 2 we do see some network activity going outbound with an encoded buffer. This buffer - in our setup - decodes to nothing special.
Again, as with command 1, this we had to debug into using kdbg and still found only memory rearrangements taking place. We never tried to modify the buffer in any significant way to try and determine the exact workings of this command. We would have had we the time, and probably will in the coming weeks just so we know. We do know, however, that there is something going on that sets up memory locations for command 1 to be active after this command has been issued.
When the snort capture from the attack was released on 27th May 2002 we determined from it that this was one of the commands being issued. In fact, packets 1, 2 and 3 were all command 2's. We also concluded that they were sending the same information. We determined this running the data portion of the packets through the decoder. Packet 1's data section can be found in the snortanalysis/packet1.pkt file which can be used directly by the decoder to give the output in file ./snortanalysis/packet1.txt.
We investigated command 3 in some detail and we have stated the results of this investigation above. This command formed the focus of our investigation since it was the first one we saw visible activity in the strace logs that allowed us to fine tune the encoder we had written. This command is the hacker's diagnostics command where physical interaction through direct statefull connections are not possible. The command accepts a unix shell command or system command in the decoded buffer and runs it. During the execution all output and errors are redirected to the file /tmp/.hj237349. This file is then read into memory and deleted, the buffer encoded and sent to a series of IP addresses. We don't know the source of the IP addresses, but we do know we can detect this traffic on the network using a snort rules (see advisory).
What we found from the snort dump released by the project was that the command rpcinfo -p 127.0.0.1 was being issued by the hacker remotely in packet 4. This provides information on what programs are currently registered with the portmapper on the localhost. We already said that command 3 pipes its output into a temporary file and then sends the contents of that file onto IP addresses of unknown origin. So, is there a response to this in the snort log released. Well, we found just that in packet 5 - the output in file snortanalysis/packet4.pkt was contained in that packet after the issuing of command 3 (packet 4).
We think this is an interesting one. We can't work out exactly what it is doing, without further investigation. For that we would probably have to have a much larger test network which had a target, a DNS server and a compromised host. What appears to be happening is a DNS amplification attack. The command takes a single "arg" which is the target host. The target host IP address is resolved and then a seemingly random selection of servers (using class A addressing - see strace output in wtfu4/strace/cmd4) are sent UDP packets containing DNS queries for start of zone authorities using top level domains names such as "com", "net", etc. The source address for these queries is the target server sent as part of the command. The result of this, on a properly configured network interface, would most likely be a DNS amplification attack on the target host. The random hosts are sent udp queries on port 53 and will respond to the target host with larger payloads than the original query.
At this point we thought we had found the purpose of the trojan, but we were curious as to what the other commands were for so we continued for completeness. We were glad we did. Command 5 likewise accepted a hostname as an argument in the encoded buffer. The resulting activity was intense to say the least. We captured 31,000 packets within the space of 160 seconds. This was getting serious. The packets were Fragmented IP packets using the UDP protocol and source address spoofing. The source address was 32.32.32.32 as can be seen in the ethereal trace wtfu4/snippets/cmd5_sample.pcap. Analysis of the packet revealed that it had the IP header flags set to 0, which means that fragmentation is taking place. The offset of the fragments was 65520, which itself falls below the maximum allowed packet size, but when you add on the header length of 20, you get 65540 which takes it into an oversized packet. The result of this on the target host is unpredictable, but on an unpatched system it is likely to cause problems in the TCP/IP stack resulting in either a system halt or a reboot. This is known as a ping of death DOS attack.
We were unsure now of the true capabilities of this hybrid. The binary was much more than any DDOS tool we had come across in our searches. It was a very sophisticated piece of software capable of launching at least two kinds of DDOS attack on a selected host system. Further investigation revealed yet more. Command 6 didn't appear to do anything special at first, at least according to the ethereal trace. The output from netstat, however, told a different story. We found this was confirmed from the strace output. Command 6 was spawning another instance of [mingetty] on port 23281. This process was listening on that port and awaiting input from somewhere. We tried to telnet to the port and did get a connection which confirmed to us it was listening on tcp for incoming activity. We never managed to get it to do anything though, there was network activity but all it did was freeze the telnet client. Our guess was this was another backdoor for the hacker to carry out system analysis using a tool like nc. Again, we didn't have time to investigate this fully.
We found Command 7 to be a cutdown version of command 3. The command took a single argument again and used it as a shell command. This time, instead of piping the output and errors to a file, the wtfu4 simply ignored the output. We guessed this was a command the hacker didn't care about the result of, or would use command 3 to determine the result of. It was most likely going to be a command in a rootkit or a shell command that simply killed any active DDOS agents and respawned the trojan. We can only guess at this due to not having a captured packet with this command in it.
Command 8 was another mysterious command, we didn't have time to investigate or debug into what this was doing, but it appeared to resemble the command 2 functionality. It wasn't, however, an activating command as there was only command 1 that required activation. We are unsure as to what this particular command function is.
We have seen a similar result to this command in command 4 - the DNS amplification attack. However, this one was subtly different, we also appeared to have IP fragmentation set. The result of this command was to send a series of DNS Authorative requests for top level domains again with a spoofed source address. The result of the DNS query would be returned to the target host (again specified in the command string sent in the encoded network packet). Without further investigation we couldn't immediately see the difference between command 4 and command 9. Both appeared to be DNS amplification DOS attacks.
This is where we started to get serious DDOS capabilities. The command again takes a single string as an argument, which appears to be the hostname of a target. Within the space of 2 minutes we had captured 22,700 packets. Of these, half are simply responding to the initial packets, so we have 11,500 attack packets destined for our target host. The packets themselves contain a spoofed source IP address, again of 32.32.32.32. The protocol used is TCP and the packet is a SYN packet (an initial connection packet). There appears to be no payload associated with the packets, and the only distinguishing feature is they are sourced and destined for high ports. That is they are ports above the 1023 port which places them in a standard user space (ports 1-1023 being reserved and normally only accessible by root). We can only conclude that this is a DDOS attack of the target using the SYN flood technique. The spoofed source IP masks the identity of the attacker.
We seem now to have hit the really serious stuff and we were glad we hadn't quit when we thought we had everything with command 4. Command 11 appeared to be a more ferocious SYN flood attack. Again the source IP was spoofed (32.32.32.32) and again it was using high port numbers. The protocol was still TCP, but the ferocity of the attack was much greater. This killed the analysis machine in less than 5 minutes. You only have to look at the size of the strace output to conclude this. For command 10 we collected 2.5Mb of data over a few minutes, for command 11 that was significantly larger at around 20Mb. The times were not precise, but the difference in scale was clear nonetheless. This was confirmed with the ethereal trace which took significant lengths of time just to load for analysis. The statistics were impressive. In 35 seconds we had 220,000 packets. Even after halving these for the return packets due to the network configuration, that was 10 times as many packets in a quarter of the time.
Command 12 was a late discovery due to a minor coding error in the original client. We had taken the switch statement literally and coded for 1-11 commands. In fact it was if (cmd - 1 <= 11) which meant there was a 12th command. We tried it and discovered a different DNS attack. The volume of packets was significantly higher even than Command 11. We saw 245281 DNS queries in 80 seconds. What's more, we also saw that randomly there was a [malformed frame] in the streaming packets. This was not only a high volume attack, but it was likely that the malformed frame was amplifying it as well. Similar to the other attacks, the source address for the DNS query was the target machine.