SOTM28

Honeynet Challenge
Scan of the Month 28
Bill Frische
05/08/2003
bill dot frische at comcast dot net

The Challenge:
Members of the AT&T Mexico Honeynet captured a unique attack. As common, what is interesting is not how the attackers broke in, but what they did afterwards. Your mission is to analyze the network capture of the attacker's activity and decode the attacker's actions. There are two binary log files. Day1 captured the break in, Day3 captures some unique activity following the compromise. The honeypot in question is IP 192.168.100.28.

Download the Binaries
day1.log.gz MD5 (day1.log.gz) = 79e5871791542c8f38dd9cee2b2bc317
day3.log.gz MD5 (day3.log.gz) = af8ab95f41530fe3561b506b422ed636

Verification of the Binaries

Tools used in Anaylsis
Ethereal
Snort
p0f
mimedump.pl

All work was done on a Athlon 2100+ System with Lindows OS 3.1

Questions

What is the operating system of the honeypot? How did you determine that? (see day1)

        The honeypot system was a running the Solaris 2.8 (or SunOS 5.8). This is determined by
reading through the tcpdump log of day1 with ethereal and noticing an ftp session which
       occurred between the honeynet and the attacking system. A file was downloaded which
began with "sol." This was a clue that is was a Solaris OS.

   After that, I ran snort with the custom rules of:

alert tcp any any -> any any (msg:"OS"; flags: A+; content:"sun"; nocase;)
alert tcp any any -> any any (msg:"OS"; flags: A+; content:"sol"; nocase;)

This returned many hits. After examining a couple, I found this snort log output:

          [**] OS [**]
        11/29-08:36:38.102597 192.168.100.28:1524 -> 61.219.90.180:56712
        TCP TTL:64 TOS:0x0 ID:51363 IpLen:20 DgmLen:216 DF
        ***AP*** Seq: 0xBA6D43C4 Ack: 0x805BECFE Win: 0x6028 TcpLen: 32
        TCP Options (3) => NOP NOP TS: 113868657 48511194
        53 75 6E 4F 53 20 7A 6F 62 65 72 69 75 73 20 35 SunOS zoberius 5
        2E 38 20 47 65 6E 65 72 69 63 5F 31 30 38 35 32 .8 Generic_10852
        38 2D 30 39 20 73 75 6E 34 75 20 73 70 61 72 63 8-09 sun4u sparc
        20 53 55 4E 57 2C 55 6C 74 72 61 2D 35 5F 31 30   SUNW,Ultra-5_10
        0A 2F 63 6F 72 65 3A 20 4E 6F 20 73 75 63 68 20 ./core: No such
        66 69 6C 65 20 6F 72 20 64 69 72 65 63 74 6F 72 file or director
        79 0A 2F 76 61 72 2F 64 74 2F 74 6D 70 2F 44 54 y./var/dt/tmp/DT
        53 50 43 44 2E 6C 6F 67 3A 20 4E 6F 20 73 75 63 SPCD.log: No suc
        68 20 66 69 6C 65 20 6F 72 20 64 69 72 65 63 74 h file or direct
        6F 72 79 0A 42 44 20 50 49 44 28 73 29 3A 20 31 ory.BD PID(s): 1
        37 37 33 0A                                      773.

        =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

This output shows that a packet was sent from 192.168.100.28 to 61.219.90.180
       that had the text string "SunOS zoberius 5.8" in it. It is typical for a Solaris machine
   to show version information in the output of "SunOS <computer name> <SunOS version>"
       in response to a uname -a command. This is confimed in Ethereal by locating the packet
   above and doing a "Follow TCP Stream" command.

Please display this picture

The passive os fingerprinting tool p0f generally confirms this result:

Please display this picture

2. How did the attacker(s) break into the system? (see day1)

The attacker broke into the system using a flaw in the Common Desktop Environment.
This exploit was shown to be active in the wild by the Honeynet Project:

http://web.archive.org/web/20020213234231/http://project.honeynet.org/scans/dtspcd/dtspcd.txt

        A writeup can be found at:

http://www.cert.org/advisories/CA-2002-01.html

Using snort to detect this exploit, there are several packets below this one leading up to
the buffer overflow. The most interesting of these packets, where the shell is executed is
included below:

[**] OS [**]
11/29-08:36:26.503382 61.219.90.180:56711 -> 192.168.100.28:6112
TCP TTL:44 TOS:0x0 ID:61373 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7FC1DB88 Ack: 0xBA41EB06 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 48510034 113867474
0000000204103e0003 4 ...10...@...@.......@...@...@...@...@...@.
..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
    ..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@...@.
..@...@...@...@...@...@...@...@...@...@...@...@...@...@...@. ...
     ..........4.#. .. ... ..* ..* ..#...#...#...#.... ... ./bin/ksh
      -c echo "ingreslock stream tcp nowait root /bin/sh sh -i">/
    tmp/x;/usr/sbin/inetd -s /tmp/x;sleep 10;/bin/rm -f /tmp/x AAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The string 103e is the signature for this exploit.

    The end of the packet lauches a korn shell to create a file in /tmp called x and put the
line "ingreslock stream tcp nowait root /bin/sh sh -i" in the file. It then calls
inetd with the -s switch to run in standalone mode using the configuration file /tmp/x.
Then, it waits 10 seconds before beginning the cleanup. The net result is that an
interactive shell is now running on the ingreslock port, usually port 1524.


3. Which systems were used in this attack, and how?(see day1)
61.219.90.180 was used to exploit dtspcd, get the shell, install rootkit, patch the system,
install psybnc -- which is an irc proxy. A full text log of what happened after the shell
was gained can be found here. The one thing that cannot be seen in the text log is what
files were installed in the tar file downloaded by the attacker named "sol.tar.gz." However,
by using Ethereal to reassemble the http stream and then mimedump.pl to decode the mime
encoding a list of file extracted onto the system can be generated as shown below:

jerusalem89998:~/scan28/day1/mimedump-tmp# tar tvf msg-2746-1.tar > ../rootkit-files.txt
    jerusalem89998:~/scan28/day1/mimedump-tmp# cd ..
    jerusalem89998:~/scan28/day1# more rootkit-files.txt
    drwxr-xr-x train/train       0 2002-11-15 03:05:47 sol/
    -rwxr-xr-x train/train     715 2002-08-06 21:15:18 sol/dl
    -rwx------ train/train    9056 2002-04-26 10:50:41 sol/du
    -rwx------ train/train   35376 2002-04-26 10:50:41 sol/l2
     -rwx------ train/train   18120 2002-04-26 10:50:41 sol/ls
    -rwx------ train/train    8332 2002-04-26 10:50:41 sol/pg
    -rwx------ train/train    9492 2002-04-26 10:50:41 sol/ps
    -rwx------ train/train    8772 2002-04-26 10:50:41 sol/su
    -rwx------ train/train    1787 2002-04-26 10:50:41 sol/sz
    drwxr-xr-x train/train       0 2002-04-26 10:50:43 sol/etc/
    -rw------- train/train     397 2002-04-26 10:50:43 sol/etc/tconf
    -rw------- train/train     525 2002-04-26 10:50:43 sol/etc/ssh_host_key
    -rw------- train/train     512 2002-04-26 10:50:43 sol/etc/ssh_random_seed
    -rw------- train/train     329 2002-04-26 10:50:43 sol/etc/ssh_host_key.pub
    -rwx------ train/train   11668 2002-04-26 10:50:43 sol/fix
    -rwx------ train/train   13984 2002-04-26 10:50:41 sol/ls2
    -rwx------ train/train   21424 2002-04-26 10:50:41 sol/sn2
    -rwx------ train/train   10488 2002-04-26 10:50:41 sol/syn
    -rwx------ train/train    1910 2002-04-26 10:50:43 sol/szl
    -rwx------ train/train   86024 2002-04-26 10:50:42 sol/top
    -rwx------ train/train    9064 2002-04-26 10:50:41 sol/find
    -rw------- train/train     877 2002-08-25 18:56:22 sol/logo
    -rwx------ train/train   12472 2002-04-26 10:50:42 sol/lsof
    -rwx------ train/train    8780 2002-04-26 10:50:41 sol/ping
    -rwxr-xr-x train/train 259832 2002-04-26 10:50:41 sol/sshd
    -rwx------ train/train      17 2002-04-26 10:50:43 sol/sver
    -rwx------ train/train 136288 2002-04-26 10:50:43 sol/wget
    -rw-r--r-- train/train 194539 2002-04-26 10:50:41 sol/psy.tar.Z
    -rw-r--r-- train/train   37809 2002-04-26 10:50:41 sol/110646-03.zip
    -rwx------ train/train      80 2002-04-26 10:50:41 sol/sniffload
    -rwx------ train/train    8672 2002-04-26 10:50:41 sol/crypt
    -rwx------ train/train   15180 2002-04-26 10:50:42 sol/idsol
    -rwx------ train/train    9508 2002-04-26 10:50:41 sol/login
    -rwx------ train/train    8388 2002-04-26 10:50:42 sol/rpass
    -rwxr-xr-x train/train   11369 2002-11-15 03:06:26 sol/setup
    -rwx------ train/train    8024 2002-04-26 10:50:41 sol/utime
    -rw------- train/train     114 2002-04-26 10:50:41 sol/x.conf2
    -rwx--x--x train/train    7725 2002-04-26 10:50:41 sol/findkit
    -rw-r--r-- train/train 187911 2002-04-26 10:50:41 sol/103577-13.tar.Z
    -rwx------ train/train 260272 2002-04-26 10:50:43 sol/ssh-dxe
    -rw-r--r-- train/train 201027 2002-04-26 10:50:41 sol/109662-03.tar.Z
    -rwx------ train/train    8772 2002-04-26 10:50:41 sol/strings
    -rwx------ train/train    9064 2002-04-26 10:50:41 sol/netstat
    -rw-r--r-- train/train   41775 2002-04-26 10:50:41 sol/111606-02.zip
    -rwxr-xr-x train/train    2869 2002-04-26 14:01:10 sol/p-engine
    -rwx------ train/train    8780 2002-04-26 10:50:41 sol/passwd
    -rw------- train/train     446 2002-04-26 10:50:42 sol/x.conf
    -rwx------ train/train   12874 2002-08-25 18:54:09 sol/switch
    -rw------- train/train   11246 2002-08-21 11:16:21 sol/setup.save
    -rwxr-xr-x train/train     217 2002-04-26 10:50:41 sol/startbnc
    -rwx------ train/train     282 2002-04-26 10:50:43 sol/removekit
    -rwxr-xr-x train/train     732 2002-04-26 10:50:42 sol/patch.sol5
    -rwxr-xr-x train/train     862 2002-04-26 10:50:42 sol/patch.sol6
    -rwxr-xr-x train/train     840 2002-04-26 10:50:43 sol/patch.sol7
    -rwxr-xr-x train/train    1011 2002-04-26 10:50:41 sol/patch.sol8
    -rwxr-xr-x train/train     488 2002-04-26 10:50:41 sol/childkiller
    -rwx------ train/train    4032 2002-04-26 10:50:41 sol/cleaner
    -rwxr-xr-x train/train 109372 2002-10-22 12:03:05 sol/solsch

80.117.14.44 connected to the psybnc server, configured, and tested it. A
full text log of this configuration transaction can be found here. The attacker continued
connecting from this IP and the transactions can be found here, here, and here.

206.252.192.195 is the irc server which was connected to on day 1. A full text log
can be found here.

62.211.66.16 is the ftp server where the attacker downloaded files from. FTPing to it
anonymously tells you to sign up for a web page at http://www.xoom.com for access.

62.211.66.53 is another Xoom address where the attacker downloaded a file
via http. The site does free web hosting and resolves to xoom.virgilio.it.

  Both 62 addresses are reported to be owned by Telecom Italia NET by
RIPE (www.ripe.net/whois).

sunsolve.sun.com was used to download some patches to install onto the system.

    4. Create a diagram that demonstrates the sequences involved in the attack.

Please display this picture

5. What is the purpose/reason of the ICMP packets with 'skillz' in them? (see day1)

This is evidence of a Distributed Denial of Service tool called Stacheldraht. This is the client
side trying to talk to a server at 61.134.3.11 and 217.116.38.10. If it were successful,
the client would get a packet with the work 'ficken' in the payload instead of skillz.
Another clue that this is a Stacheldraht is the strange identifier in each packet of 0x1a0a
(in binary) or 6666 (in decimal). There appears to be no evidence that the client was
able to contact its server on day1.

6. Following the attack, the attacker(s) enabled a unique protocol that one would not expect to find
on an IPv4 network. Can you identify that protocol and why it was used?

IPv6. It appears the attacker wanted to connect to an IRC Server in Italy which used IPv6.

This particular application of IPv6 is encapsulated into IPv4. This is a known project
called 6bone. According to the 6bone website, the purpose of 6bone is to be an IPv6 testbed
and is a virtual network using IPv6 over IPv4 tunneling. More information about it can be
found at http://www.6bone.net/.

The traffic generated between the compromised machine and an IRC server is indeed IPv6
encapsulated in IPv4. The packet analyzer Ethereal easily show this encapsulation:

Please show this picture

The screen shot of x-chat below shows that irc6.edisontel.com and irc6.edisontel.it have
the same IPv6 address. It is the same address on which the IRC conversation takes place
on day three. The full text of that conversation can be found here.

Please show this picture

7. Can you identify the nationality of the attacker?

On the Internet you can be anyone from anywhere. However, due to the conversations recorded in the tcpdump logs
it can be assumed that the attacker was fluent in Italian. Furthermore, the some IP addresses involved in the attack
the belong to an various organizations physically located in Italy. I would conjecture that the attacker was Italian.

Bonus Question:

What are the implications of using the unusual IP protocol to the Intrusion Detection industry?

Tunneling always is a problem with IDS. For a host based IDS, it is less of an issue due
to the fact that you are, generally, looking at things from a higher view than the TCP/IP
layer -- you are looking for changed files, password changes, kernel mods, etc....

For a Network IDS, tunneling often causes issues because in a signature base NIDS you will
often be looking a certain number of bytes into the packet for the information to match the signature.
If the attack has been encapsulated, you will have your byte offset wrong.

However, the problem is no worse than having VLAN tagging. Once you know that you
are dealing with an encapsulated protocol, you change the way you look and move on.

On the other hand, an anonlmy based NIDS would ideally catch this immediately because the
IDS specialist has properly configured their network and knows that the NIDS should never see
a IPv6 packet under normal circumstances.

The real problem for the NIDS industry is the proliferation of encrypted sessions. If day3 had been
encapsulated with SSH or SSL there would be no reading or detecting the usual protocol.

What tools exist that can decode this protocol?

I used mainly Ethereal. Snort 2.0.0 has some IPv6 functionality. WildPackets' EtherPeek 5.0
includes IPv6 decode functionality. IxAnalyze also will decode them. There are a whole
slew of commercial products which can decode IPv6.