Scan 28
Submission by Leon Ward (nard)
[email protected]  
http://www.nardware.co.uk 

Contents
   
   o  Summary
      o  Questions
           1 What is the operating system of the honeypot? How did you determine that? (see day1)
           2 How did the attacker(s) break into the system? (see day1)
           3 Which systems were used in this attack, and how? (see day1)
           4 Create a diagram that demonstrates the sequences involved in the attack. (see day1)
           5 What is the purpose/reason of the ICMP packets with 'skillz' in them? (see day1)
           6 Following the attack, the attacker(s) enabled a unique protocol that one would not expect to find on a n IPv4 network. Can you identify that protocol and why it was used? 
           7 Can you identify the nationality of the attacker? (see day3)
    o Links and further reading


Summary:

On the 29th November A SunOS 8.8 honeypot was attacked.
The attacker found a known vulnerability in dtspcd (A CDE daemon), and used a widely available exploit. After a root shell was gained  (an interactive access with root privileges), he configured the machine both as an IRC proxy for himself and his friends, and as an agent in a complex DDoS network.

The attacker, presumably Italian using interbusiness.it as their ISP (part of telecom Italia) then actively used the machine both to mask his identity on IRC (a chat network) and to attack another host, javairc.tiscali.it (a chat server for the Tiscali ISP).

For more information about how the attack progressed view this series of diagrams / data captures. 


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

From the log files supplied for review, a safe deduction can be made that the honeypot is a SunOS running on a sparc box. Many things point to this OS / Architecture, including the following.

[**] SHELLCODE sparc NOOP [**]
11/29-16:36:26.503382 0:7:EC:B2:D0:A -> 8:0:20:D1:76:19 type:0x800 len:0x5EA
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
30 30 30 30 30 30 30 32 30 34 31 30 33 65 30 30 0000000204103e00
30 33 20 20 34 20 00 00 00 31 30 00 80 1C 40 11 03 4 ...10...@.
80 1C 40 11 10 80 01 01 80 1C 40 11 80 1C 40 11 ..@.......@...@.
80 1C 40 11 80 1C 40 11 80 1C 40 11 80 1C 40 11 ..@...@...@...@.
# uname -a;ls -l /core /var/dt/tmp/DTSPCD.log;PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/gnu/bin;export PATH;echo "BD PID(s): "`ps -fed|grep ' -s /tmp/x'|grep -v grep|awk '{print $2}'`
SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10
/core: No such file or directory
/var/dt/tmp/DTSPCD.log: No such file or directory
BD PID(s): 1773
<6>Dec 1 17:1 1:55 root nex: [ID 466748 kern.info] root nexus = Sun Ultra 5/10 UPA PCI (Ultra SPARC-IIi 360MHz)
echo "${WHI}*${DWHI} ${RED} Oops.. im DUMB! i tried installing SunOS Rootkit on $OS :P"

# Ok.. so if theyre not lame, and running this on SunOS like they should...


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


The attacker can be seen searching for open dtspcd daemons, and checking if a root shell is bound already to TCP ingreslock in frame 561.

No. Time         Source         Destination    Protocol               Info
561 33015.413867 61.219.90.180  192.168.100.28 TCP 56399 > 6112 [SYN] Seq=2151229461 Ack=0 Win=5840 Len=0
562 33015.413867 192.168.100.28 61.219.90.180  TCP 6112 > 56399 [SYN, ACK] Seq=3124316702 Ack=2151229462 Win=24616 Len=0
563 33015.623853 61.219.90.180  192.168.100.28 TCP 56399 > 6112 [ACK] Seq=2151229462 Ack=3124316703 Win=5840 Len=0
564 33015.633853 61.219.90.180  192.168.100.28 TCP 56709 > ingreslock [SYN] Seq=2149411790 Ack=0 Win=5840 Len=0
565 33015.633853 192.168.100.28 61.219.90.180  TCP ingreslock > 56709 [RST, ACK] Seq=0 Ack=2149411791 Win=0 Len=0

The box is then connected to again, and an exploit is sent to dtspcd.

566 33015.853838 61.219.90.180  192.168.100.28 TCP 56710 > 6112 [SYN] Seq=2140233517 Ack=0 Win=5840 Len=0
567 33015.853838 192.168.100.28 61.219.90.180  TCP 6112 > 56710 [SYN, ACK] Seq=3124564265 Ack=2140233518 Win=24616 Len=0
568 33016.063823 61.219.90.180  192.168.100.28 TCP 56710 > 6112 [ACK] Seq=2140233518 Ack=3124564266 Win=5840 Len=0

The commands used to gain a backdoor as part of the exploit can be seen in frame 580.

0530 ff ec 82 10 20 0b 91 d0 20 08 2f 62 69 6e 2f 6b .... ... ./bin/k
0540 73 68 20 20 20 20 2d 63 20 20 65 63 68 6f 20 22 sh -c echo "
0550 69 6e 67 72 65 73 6c 6f 63 6b 20 73 74 72 65 61 ingreslo ck strea
0560 6d 20 74 63 70 20 6e 6f 77 61 69 74 20 72 6f 6f m tcp no wait roo
0570 74 20 2f 62 69 6e 2f 73 68 20 73 68 20 2d 69 22 t /bin/s h sh -i"
0580 3e 2f 74 6d 70 2f 78 3b 2f 75 73 72 2f 73 62 69 >/tmp/x; /usr/sbi
0590 6e 2f 69 6e 65 74 64 20 2d 73 20 2f 74 6d 70 2f n/inetd -s /tmp/
05a0 78 3b 73 6c 65 65 70 20 31 30 3b 2f 62 69 6e 2f x;sleep 10;/bin/
05b0 72 6d 20 2d 66 20 2f 74 6d 70 2f 78 20 41 41 41 rm -f /t mp/x AAA

This code can be cleaned up to be read as...

/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

This creates a root shell backdoor on TCP port 1524.
For more information about the exploitable buffer in dtspcd, see links and further reading at the end of this document.
For a list of commands executed by the attacker refer to the series of diagrams / data captures.


3: Which systems were used in this attack, and how? (see day1) 

From the logs given, a safe assumption can be made that the attacker is sitting at a MS Windows XP professional box connected via ADSL to the Italian ISP interbusiness.it. He also has remote shells on numerous linux box's (probably stolen). On the third day the attacker connected again from his XP machine to use the psybnc daemon he installed on day 1. This connection was from another IP in ISP's pool, confirming further the idea of him having an ADSL or account with them.

There are other boxes that pay a serious role in the packet captures, mainly the two DDoS handlers that the agent constantly tried to connect to. These were 217.116.38.10 & 61.134.3.11.

4 Create a diagram that demonstrates the sequences involved in the attack. (see day1)

View the series of diagrams / data captures.

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

The attacker installed a DDoS (Distributed Denial of Service) agent on the honeypot. The "skillz" packets (example below) are used to converse with its controlling handler / clients.
The handlers it tries to communicate with are 217.116.38.10 & 61.134.3.11, and example of this can be seen in packet 620.

620 10065.488930 192.168.100.28 217.116.38.10 ICMP Echo (ping) reply   --- skillz packet

[**] [1:1855:2] DDOS Stacheldraht agent->handler (skillz) [**]
[Classification: Attempted Denial of Service] [Priority: 2]
11/29-18:49:50.110576 8:0:20:D1:76:19 -> 0:7:EC:B2:D0:A type:0x800 len:0x422
192.168.100.28 -> 217.116.38.10 ICMP TTL:255 TOS:0x0 ID:35612 IpLen:20 DgmLen:1044 DF
Type:0 Code:0 ID:6666 Seq:0 ECHO REPLY
[Xref => http://staff.washington.edu/dittrich/misc/stacheldraht.analysis]

If the "skillz" packet is received by the handler, it will reply with an ICMP echo reply containing the string "ficken", example below.

621 10075.488253 192.168.100.28 61.134.3.11   ICMP Echo (ping) reply   --- ficken packet

[**] [1:1856:2] DDOS Stacheldraht handler->agent (ficken) [**]
[Classification: Attempted Denial of Service] [Priority: 2]
12/01-20:09:32.623352 0:7:EC:B2:D0:A -> 8:0:20:D1:76:19 type:0x800 len:0x422
61.134.3.11 -> 192.168.100.28 ICMP TTL:237 TOS:0x0 ID:31099 IpLen:20 DgmLen:1044 DF
Type:0 Code:0 ID:6667 Seq:0 ECHO REPLY
[Xref => http://staff.washington.edu/dittrich/misc/stacheldraht.analysis]

If the skillz packet is not received by any of the handlers configured, the agent will keep sending them until it is forcibly killed. Once the skillz is received, the handler will add the agent to its list and have the ability to use it to launch an attack.

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

There are a few packets captured on day 3 that I would not normally expect to see on an IPv4 network, examples below.

1) IPv6 traffic. This may sound obvious, but it should not be seen on an IPv4 Network.
The attacker connected to an IPv6 IRC server.

120176 70755.592016 2001:750:2:0:202:a5ff:fef0:aac7 2001:6b8:0:400::5d0e   IRC Response
117405 60625.347106 fe80::c0a8:641c                 ff02::1:fff8:e01c      ICMPv6 Multicast listener report

These are also bizarre because, one would not expect to see AODv6 (Ad hoc On-demand Distance Vector Routing Protocol v6)  and Hop by hop options sent over IPv4.

44494  50418.226660 192.168.100.28                  195.130.233.20         AODV6
40565  50049.431616 192.168.100.28                  195.130.233.20         IP IPv6 hop-by-hop option (0x00)

2) DLSw. DLSw is a method of transporting NetBIOS traffic over IP.

45529 50520.649728 192.168.100.28 195.130.233.20 DLSw DLSw Unknown Version, Unknown message Type

 3) Banyan Vines IP

47669 50736.595120 00000000.0000 00000000.0000 Vines IP Unknown VIP protocol (00)

7 Can you identify the nationality of the attacker? (see day3)

All clues point to the fact the attacker is Italian.

Appendix, Links and further reading

Ethereal: http://www.ethereal.com
Snort: http://www.snort.org
DDoS analysis http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
nardware.co.uk http://www.nardware.co.uk
dtspcd  information http://www.securityfocus.com/bid/3517