Scan Of The Month 28

Summary Report

 

 

Written by Petros Papadopoulos (peterpap2@yahoo.gr)

 

Question 1

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

  

Answer to Question 1: 

The first command the attacker send to the system after the successful compromise was (see packet 595 from day1.log)

 

                        uname –a

 

And the system responded (see packet 598 from day1.log)

 

SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10

 

So it is a Solaris 8 Machine.

 

 

 

 

 


Question 2

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

  

Answer to Question 2: 

The attacker exploited a known buffer overflow Vulnerability in CDE Subprocess Control Service dtspcd which leads

to a remote compromise of a system. This is described in full detail in

http://www.cert.org/advisories/CA-2001-31.html

http://www.kb.cert.org/vuls/id/172583

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

http://xforce.iss.net/alerts/advise101.php

 

 

This vulnerability gives the attacker root privileges on the target system. The buffer overflow happens at port 6112 

dtspcd (see packet 580 from day1.log). The attacker creates a shell on port 1524 (ingreslock) by

 

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 is probably made from an automated tool (see Scan Of The Month 20 - Scan 20 - Solaris dtspcd attack.). The tool

before the buffer overflow checked both ports 6112 and 1524 to verify their status and possible ip filtering (see packets 561 & 564 from day1.log).

 

 

And then the attacker starts sending commands to the honeypot system using port 1524 (see packet 595 from day1.log). 

 

 

 

 

 

 


Question 3

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

  

Answer to Question 3: 

The Systems used in the attack were

1.    Honeypot – IP Address: 192.168.100.28. This is the compromised system.

 

2.    Attacker – IP Address: 61.219.90.180. From this address the attacker started the attack. All the commands to port 1524 from the attacker were given from this address.

 

3.    FTP Server Controlled by Attacker - IP Address: 62.211.66.16. This Server was used from the attacker to download the files  wget, dlp, solbnc, iupv6sun to the honeypot.

 

4.    HTTP Server  Controlled by Attacker – IP Address: 62.211.66.53. This server was used from the attacker to download the rootkit sol.tar.gz to the honeypot.

 

5.    SUN FTP Server (ftp://sunsolve.sun.com). This FTP server was accessed from the rootkit to download the patches 108949-07.zip,  111085-02.zip. The rootkit is patching the system!

 

6.    Other hosts owned by attacker. The hosts 217.116.38.10  and 61.134.3.11 are owned by attacker and the honeypot sends “heartbeat” (I’m alive) messages to them. Host 80.117.14.44 connects to

     honeypot through the rootkit created port TCP 7000.

 

7.    IRC Server. Host 206.252.192.195 was contacted from Honeypot to TCP port 5555 and tunnel IRC traffic.

 

 

 

 


Question 4

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

  

Answer to Question 4: 

The diagram follows. The numbers in the comments demonstrate the sequence of the events.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Question 5

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

  

Answer to Question 5: 

The  ICMP packets are only of type Echo Reply. There is no “echo” in order to respond with an “echo reply”. This is fake ICMP trying to fool those firewalls and access list routers which don’t understand what STATEFUL ICMP is. Stateful ICMP was considered “alien technology” from big firewall vendors only a couple of years ago.

 

These ICMP are used for “heartbeat” information. The compromised system is saying “I’m alive” to the “master” who controls it.

More on the “skillz” (found in day 1 & 3) and “ficken” (found in day 3) echo replies can be found on the DDOS analysis given by

 
1.    ISS Security Alert, February 9, 2000. “Denial of Service Attack using the TFN2K and Stacheldraht programs”
 
2.    David Dittrich, December 31, 1999.  ”The "stacheldraht" distributed denial of service attack tool”
 
 

 

 

 

 

 


Question 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)  

  

Answer to Question 6: 

The protocol used is the IP V6. It was used to tunnel IRC traffic. By using IP V6 IDS systems can’t detect the potential attack since they can’t decode IP V6 traffic. The V6 IP addresses were

 

Honeypot IP V6 =  2001:6b8:0:400::5d0e  

Attackers IRC Server IP V6 =  2001:750:2:0:202:a5ff:fef0:aac7  

 

The communication between these two starts at packet 117614 (day3.log) and it is an IRC Session.

 

 

 

 

 


Question 7

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

 

Answer to Question 7: 

Yes, he is Italian. This is from the decoded IP V6 IRC session in their own(z) words …

 

:irc6.edisontel.it PONG irc6.edisontel.it :`OwnZ``

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :a giorni io cambio scheda madre

PRIVMSG `OwnZ`` :away

NICK `OwnZ``

:irc6.edisontel.it 301 `OwnZ`` `OwnZ`` :-OwnZ-

:`OwnZ``!~ahaa@bacardi.orange.org.ru PRIVMSG `OwnZ`` :away

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :quindi cambio memorie

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :metto le ddr

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :se vuoi te regalo un modulo da 256

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz ::P

:irc6.edisontel.it PONG irc6.edisontel.it :`OwnZ``

 

And more ….

 

:irc6.edisontel.it PONG irc6.edisontel.it :`OwnZ``

:RiValD|nO!~TrUe_LoVe@ppp-62-11-131-241.dialup.tiscali.it PRIVMSG #bobz :la durA=?

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :ehehhehe

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :dura come il mio cazzo

:RiValD|nO!~TrUe_LoVe@ppp-62-11-131-241.dialup.tiscali.it PRIVMSG #bobz :mhauHAUHauHAUhuahUH

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :visto che è 1 mese che nn scopo

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :ahuhuahuahuhuahuuhahuuha

:RiValD|nO!~TrUe_LoVe@ppp-62-11-131-241.dialup.tiscali.it PRIVMSG #bobz :=°|

:RiValD|nO!~TrUe_LoVe@ppp-62-11-131-241.dialup.tiscali.it PRIVMSG #bobz :beh.. buona scopata=P

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :si cion federika?

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :ahuhuahuhuahuua

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :a domani segaioli

:_-PaKi-_!~ChMoD@TaRgEtS.SuCcEsSfuLl.SeRvEr.LeIm.exploits.la PRIVMSG #bobz :ahuahuhuauhhuauhuauhhuhuahua

:RiValD|nO!~TrUe_LoVe@ppp-62-11-131-241.dialup.tiscali.it PRIVMSG #bobz :maHUHUahUHAUhauHHH

PING :irc6.edisontel.it

 

 

 

 

 

 


Bonus Question 1

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

  

Answer to Bonus Question 1: 

The IDS vendors must update their products to include IP V6 support. Otherwise bad things might happen and the IDS will give zero information. In other words (Lance’s words actually from the focus-ids list). http://lists.insecure.org/lists/focus-ids/2002/Dec/0065.html

 

IDS: IPv6

From: Lance Spitzner (lance_at_honeynet.org)
Date: Dec 19 2002

 

Recently one of the Honeynet Project's Solaris Honeynets was compromised.
What made this attack unique was IPv6 tunneling was enabled on the system,
with communications being forwarded to another country. The attack and
communications were captured using Snort, however the data could not be
decoded due to the IPv6 encapsulation.

This made me consider, this activity could be used as a means of
"covert" communications or activity. Many IDS systems, and potentially
many sniffers, have difficulty decoding IPv6 activity. Was wondering if
others had seen this activity, and the implications it may have to the IDS
community?

lance

 

 

 

And don’t forget Marty’s words from the focus-ids list http://lists.insecure.org/lists/focus-ids/2002/Dec/0069.html

 

IDS: EXPERIMENTAL IPv6 decoder available in Snort

From: Martin Roesch (roesch_at_sourcefire.com)
Date: Dec 20 2002

 

Hi everyone,
     Following up Lance's message regarding the usage of IPv6 tunneling on a
honeynet, I'd like to announce the availability of an *experimental* version
of Snort with an IPv6 decoder. This decoder is implemented to test Snort's
capability to analyze IPv6 and IPv6 tunneled over IPv4. Currently it
consists of a decoder and printing module only, so if you want to test it
and see the v6 output, just run 'snort -dv'.

If people would like to test the code out and see if it's working properly,
it can be downloaded and tested at:

http://www.snort.org/~roesch/snort-2.0.0beta-ipv6.tar.gz

This code currently doesn't have any components integrated into the
detection engine, so you can't tell Snort to look at IPv6 addresses or
header fields using the rules language yet. It is capable of looking for
standard embedded protocol headers and payloads in IPv6 tunneled over IPv4.

If people would like to test this code out, I'm primarily interested in
seeing if the code is stable and capable of decoding all v6 traffic without
any memory leaks or crashes. Unfortunately, my ability to generate v6
traffic for testing purposes is extremely limited right now, so I'm
depending on people with access to the right kind of networks to help out!

Once I'm happy with the decoder, I'll integrate IPv6 support into the
detection engine!

    -Marty

 

 

 

 

 

 

 


Bonus Question 2

What tools exist that can decode this protocol?

  

Answer to Bonus Question 2: 

My favorite is Ethereal. But from  http://www.ip6.com/us/analyzer.htm

We have

1.    Ethereal

2.    Analyzer

3.    WinDump

4.    WinPcap