Scan of the month challenge #23
Introduction
This is my submission for Scan of the month challenge #23. It attempts to
provide answers to the #23 Scan of the Month Challenge proposed by the Honeynet
Project. It is my very first submission to Honeynet Project challenges, hope
that my answers will fit all requirements ;)
Answers to questions
1. What is a binary log file and how is one created ?
As it is said in the abstract, this binary log file is created by using snort
to capture each scan in tcpdump binary format. This specific one is created
using snort.conf rules in order to log all network activity, with an output
plugin (output log_tcpdump). This binary file is uded to log every network
activity. Binary log files are naturally smaller than text log files (for
example, IP address field is 4 bytes in binary log file, contrary to ascii
representation of an IP address...); and are faster to access (because smaller
so search/matching operations can be drastically speeded up). For example,
this binary log file is about 12MB, and corresponding text file about 17MB.
2. What is MD5 and what value does it provides ?
Message Digest 5 is an one-way hash algoritm (cryptographic algorithm) that
produces a 128-bit output from any input. It is used to verify data integrity.
In our case, MD5 checksum is used as an integrity check. It is possible to
verify that file was completely downloaded and that was not modified.
Let's check MD5 signature :
[laurent@azathoth sotm23]$ md5sum 0826\@19-snort.log
0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log
[laurent@azathoth sotm23]$ cat 0826\@19-snort.log.md5
0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log
MD5 signature confirms me that file was completely downloaded and that was
not modified.
3. What is the attacker's IP address ?
I will use Ethereal (www.ethereal.com) to analyse this log file. I load the
binary log file, and i disable network name resolution that could lead to
loss of performance since there is no need to match Name <-> IP (no
domain name server is available for such private addresses [RFC1918]).
By sorting by IP source address, i find 4 different addresses : 192.168.0.{1,
9, 99, 199, 254}.
By sorting by IP destination address, i find 2 different addresses : 192.168.0.{9,
99}.
By looking at packets contents, all responses are coming from 192.168.0.99
(for example, TCP RST/ACK, ICMP Echo Replies...); and requests are coming
from 192.168.0.{1, 9, 199, 254} (for example, TCP SYN/ACK, ICMP Echo Requests...).
Since there is no replies from 192.168.0.99 to 192.168.0.{1, 199, 254}; attacker's
IP address is certainly 192.168.0.9. As matter of fact, the non resolution
of Link Layer <-> Network Layer with ARP suggests that 192.168.0.{1,
199, 254} are spoofed IP addresses. It will be verified in question 5.
4. What is the destination IP address ?
As a consequence of question 3, destination IP address is 192.168.0.99.
5. We scanned the honeypot using five different methods. Can you identify
the five different scanning methods, and describe how each of five works
?
I will try to find each scan by finding different requests involved by the
attacker, and by studying every delay involved between and during each scan.
Technical details of each scan are excerpts from Nmap manpages, because there
is no need to paraphrase Fyodor !
Note :
- Lot of noise of last requests appears during every stage of a scan. In
order to reduce noise, i used ethereal filter [ip.src==192.168.0.9]to
avoid noise created by target's responses.
- IP ID sequence eveluation can be included in port scan, by simply looking
at incrementation of IP ID numbers of distant host.
From packet 1 to packet 148006 -- First scan
First at all, attacker wants to know if distant host is alive or not :
- ICMP connectivity test.
- TCP Ping connectivity test on port 80.
This test is a success because victim returns an ICMP echo reply, and a TCP
RST packet. So distant host is alive.
After, that attacker from IP 192.168.0.9 begins TCP SYN scan (Half-open)
from packet 5 to packet 148006.
Scan duration is about : 1245-10=1235 seconds ~ 20 minutes.
Technical details of TCP SYN scan (excerpt from nmap's manpages) :
-sS TCP SYN scan: This technique is often referred to
as "half-open" scanning, because you don't open a
full TCP connection. You send a SYN packet, as if
you are going to open a real connection and you
wait for a response. A SYN|ACK indicates the port
is listening. A RST is indicative of a non-lis
tener. If a SYN|ACK is received, a RST is immedi
ately sent to tear down the connection (actually
our OS kernel does this for us). The primary advan
tage to this scanning technique is that fewer sites
will log it. Unfortunately you need root privi
leges to build these custom SYN packets. This is
the default scan type for privileged users.
Summary :
Exhaustive TCP Half-open scan with TCP/ICMP connectivity tests.
From packet 148007 to packet 150752 -- Second scan
First at all, attacker wants to know if distant host is alive or not :
- ICMP connectivity test.
- TCP Ping connectivity test on port 80.
This test is a success because victim returns an ICMP echo reply, and a TCP
RST packet. So distant host is alive.
After, that attacker from IP 192.168.0.9 begins TCP Null scan (no TCP Flags)
from packet 148007 to packet 150656.
This scan is a little bit more complex, because it involves multiple parts
:
From packet 148011 to packet 150624 : TCP Null packets on a list of multiple
ports including classical ones (21,22,53,80...). So 1306 TCP probes are sent,
but multiple probes are sent to unique ports. If we count the number of probes
to unique TCP ports, it should correspond to attacker's [nmap-services]
file. We would be able to determine nmap's version used if [nmap-services]
file is frequently modified. This file is used by Nmap in order to port
scan only on most "important" TCP/UDP ports (for exemple, 22,23/TCP...).
From packet 150626 to packet 150638 : TCP Null packets to ports that didn't
send back an answer. This part is to raise correctness of the Null scan by
sending multiple TCP Null packets again to possible open ports that didn't
answer. For example, [tcp.flags==0 and tcp.dstport==80] filter with
ethereal, shows me that 6 packets where sent to 192.168.0.99:80 between packet
148007 to packet 150656.
From packet 150639 to 150655 : Multiple kinds of packets are sent (Null,
ACK, RST, ICMP, UDP...) to multiple ports (open or not). This is a fingerprinting
technique to reveal Operating System type by observing TCP/IP stacks specificities.
From packet 150656 to 150752 : Multiple SYN and RST packets to one open port
(22/tcp).
First goal : find timestamp value of target address with packets 150656,150657,150660,150663,150666,150673,150676
from which we can determine target's and attacker's uptime with their responses
: victim (14902727), attacker (1061109567). Their uptimes are respectively
: victim (about 41,39 hours) and attacker (122,81 days). But we cannot trust
attacker's uptime because packets are crafted by an attacker tool...
Second goal : Multiple SYNs to an open port, to evaluate strengtness
of TCP Sequence Number generator. If i look at at results (1082167018, 1082164233,
1076801698...); Pseudo Random Number Generator used doesn't seem to provide
a good entropy !
Technical details of Null Scan (excerpt from nmap's manpages) :
-sF -sX -sN
Stealth FIN, Xmas Tree, or Null scan modes: There
are times when even SYN scanning isn't clandestine
enough. Some firewalls and packet filters watch for
SYNs to restricted ports, and programs like Synlog
ger and Courtney are available to detect these
scans. These advanced scans, on the other hand, may
be able to pass through unmolested.
The idea is that closed ports are required to reply
to your probe packet with an RST, while open ports
must ignore the packets in question (see RFC 793 pp
64). The FIN scan uses a bare (surprise) FIN
packet as the probe, while the Xmas tree scan turns
on the FIN, URG, and PUSH flags. The Null scan
turns off all flags. Unfortunately Microsoft (like
usual) decided to completely ignore the standard
and do things their own way. Thus this scan type
will not work against systems running Windows95/NT.
On the positive side, this is a good way to distin
guish between the two platforms. If the scan finds
open ports, you know the machine is not a Windows
box. If a -sF,-sX,or -sN scan shows all ports
closed, yet a SYN (-sS) scan shows ports being
opened, you are probably looking at a Windows box.
This is less useful now that nmap has proper OS
detection built in. There are also a few other
systems that are broken in the same way Windows is.
They include Cisco, BSDI, HP/UX, MVS, and IRIX.
All of the above send resets from the open ports
when they should just drop the packet.
Summary :
Non exhaustive TCP Null scan with TCP/ICMP connectivity tests, with OS Fingerprinting,
Sequence Number evaluation and TCP uptime querying.
From packet 150753 to packet 153250 -- Third scan
First at all, attacker wants to know if distant host is alive or not :
- ICMP connectivity test.
- TCP Ping connectivity test on port 80.
This test is a success because victim returns an ICMP echo reply, and a TCP
RST packet. So distant host is alive.
From packet 150759 to 153137 : TCP FIN/PSH/URG packets on a list of muliple
ports including classical ones (21,22,53,80...). This kind of scan is called
Xmas scan.
From packet 153138 to 153148 : TCP FIN/PSH/URG packets to ports that didn't
send back an answer. This part is to raise correctness of the FIN scan by
sending multiple TCP FIN/PSH/URG packets again to possible open ports that
didn't answer.
From packet 153149 to 153165 : Multiple kinds of packets are sent (Null,
ACK, RST, ICMP, UDP...) to multiple ports (open or not). This is a fingerprinting
technique to reveal Operating System type by observing TCP/IP stacks specificities.
From packet 153166 to 153250 : Multiple SYN and RST packets to one open port
(22/tcp).
First goal : find timestamp value of target address with packets 153166,
153167, 153170, 153173, 153176, 153181, 153184 from which we can determine
target's and attacker's uptime with their responses : victim (14916022),
attacker (1061109567). The victim uptime didn't changed a lot since first
uptime querying, it is normal ! But i can check that attacker's uptime is
false because it didn't change since last querying...
Second goal : Multiple SYNs to an open port, to evaluate strengtness
of TCP Sequence Number generator. If i look at at results (1240751450, 1237124277,
1234661897...); Pseudo Random Number Generator used doesn't seem to provide
a good entropy !
Technical details of Xmas scan (excerpt from nmap's manpages)
:
Please, refer to technical details of Second scan.
Summary :
Non exhaustive TCP Xmas scan with TCP/ICMP connectivity tests, with OS Fingerprinting,
Sequence Number evaluation and TCP uptime querying.
From packet 153251 to packet 156009 -- Fourth scan
TCP connect() scan with TCP Timestamp values in SYN packets and attacker's
TCP port is increasing contrary to other scans.
From packet 155831 to 155847 : Multiple kinds of packets are sent (Null,
ACK, RST, ICMP, UDP...) to multiple ports (open or not). This is a fingerprinting
technique to reveal Operating System type by observing TCP/IP stacks specificities.
From packet 155852 to 156009 : Multiple SYN and RST packets to one open port
(22/tcp).
First goal : find timestamp value of target address with packets 155852,
155857, 155860, 155863, 155866, 155871, 155874 from which we can determine
target's and attacker's uptime with their responses : victim (14922426), attacker
(1061109567). The victim uptime didn't changed a lot since first uptime querying,
it is normal, but it has changed ! But i can check that attacker's uptime
is false because it didn't change since last querying...
Second goal : Multiple SYNs to an open port, to evaluate strengtness
of TCP Sequence Number generator. If I look at results (1240751450, 1237124277,
1234661897...); Pseudo Random Number Generator used doesn't seem to provide
a good entropy !
Technical details of TCP connect() scan (excerpt from nmap's manpages)
:
-sT TCP connect() scan: This is the most basic form of
TCP scanning. The connect() system call provided by
your operating system is used to open a connection
to every interesting port on the machine. If the
port is listening, connect() will succeed, other
wise the port isn't reachable. One strong advantage
to this technique is that you don't need any spe
cial privileges. Any user on most UNIX boxes is
free to use this call.
This sort of scan is easily detectable as target
host logs will show a bunch of connection and error
messages for the services which accept() the con
nection just to have it immediately shutdown. This
is the default scan type for unprivileged users.
Summary :
Non exhaustive TCP connect() scan with OS Fingerprinting, Sequence Number
evaluation and TCP uptime querying.
From packet 155987 to packet 163832 -- Fifth scan
Connectivity tests are only "TCP-Ping" based because only decoy addresses
are used in ICMP connectivity tests. This connectivity test shows me that
distant host is alive.
Xmas scan with FIN/PSH/URG flags with 3 decoy IP addresses 192.168.0.{1,199,254}.
This scan permits to decrease signal to noise level of scan detection. As
a matter of fact, 4 different IP addresses seem to scan target, so it is
more difficult to know which IP address is the real attacker. But in this
environment, it's easy to find attacker's IP address, because IP address
range is 192.168.0. I can note the absence of responses from target that
can lead to the conclusion that 192.168.0.{1,199,254} are spoofed; because,
if we were in a routed environment, packets would be sent to the default
gateway according to the routing table.
443,80,22,53,111 are open TCP ports detected by this scan.
Technical details of decoy scan (excerpt from nmap's manpages) :
-D <decoy1 [,decoy2][,ME],...>
Causes a decoy scan to be performed which makes it
appear to the remote host that the host(s) you
specify as decoys are scanning the target network
too. Thus their IDS might report 5-10 port scans
from unique IP addresses, but they won't know which
IP was scanning them and which were innocent
decoys. While this can be defeated through router
path tracing, response-dropping, and other "active"
mechanisms, it is generally an extremely effective
technique for hiding your IP address.
[...]
Summary :
Non exhaustive TCP Xmas scan with 3 decoy addresses, with TCP connectivity
test.
6. Which scanning tool was used to scan our honeypot ? How were you able
to determine this ?
Nmap (Network MAPper) from Fyodor is certainly used to scan the honeypot.
What suggests me to determine this tool is the OS Fingerprinting technique.
If I take a look at OS Fingerprinting technique used in nmap, from [nmap-os-fingerprints]
file included with nmap files. I can deduce tests launched by nmap to determine
target OS.
# TEST DESCRIPTION:
# Tseq is the TCP sequenceability test
# T1 is a SYN packet with a bunch of TCP options to open port
# T2 is a NULL packet w/options to open port
# T3 is a SYN|FIN|URG|PSH packet w/options to open port
# T4 is an ACK to open port w/options
# T5 is a SYN to closed port w/options
# T6 is an ACK to closed port w/options
# T7 is a FIN|PSH|URG to a closed port w/options
# PU is a UDP packet to a closed port
If I look at first OS Fingerprinting from binary log, from packet 150639
to 150655, I can correlate with nmap test description.
Note : Packets 150646 and 150647 are RST to packets 150640 and 150643.
For more convenience, I used ethereal filter [ip.src==192.168.0.99] to
avoid noise created by target's responses.
7. What is the purpose of port scanning ?
The aim of port scanning is to discover open / closed ports on a target machine.
These ports could be UDP or TCP. The discover of open ports can help the
attacker to focus its attack or to build databases of machines / open ports
associated.
Most of times, a port scanning is a preamble to a more precise attack. If
attacker launches an heavy scan, attacker is able to create a database of
correlating IP addresses and corresponding open TCP/UDP ports. This database
can be reused any time a new vulnerability appeared...
8. What ports were found open on our honeypot ?
I use the first scan (Half-open TCP) to determine open ports on target machine,
because it is the most reliable stealthy scan whatever scanned machine is.
Moreover, this scan covers all TCP ports range. With such a scan, open ports
respond with TCP SYN/ACK. So what I have to do is counting SYN/ACK responses
from 192.168.0.99 between packet 1 to packet 148006 (and from different ports).
With ethereal filter [ip.src == 192.168.0.99 and tcp.flags == 0x0012],
I can list open ports : 22, 53, 80, 111, 443, 32768.
This is partly confirmed by second scan (Null scan), from packet 150626 to
150638, I can list open ports : 22, 53, 80, 111, 443. Port 32768 does not
appear because it was not included in TCP Null probe (probably -F option
scan of nmap, that uses [nmap-services] file).
Bonus Question: What operating system was the attacker using ?
Since, attacker is able to forge every content of any probe requests, it
is very unprecise to trust any information included in TCP/UDP/ICMP Requests.
Since there is no probe requests from victim to attacker, I must use some
passive fingerprinting techniques to find the attacker's OS. For that, I look
at Passive Fingerprinting article from Know Your Enemy series; and after,
I look at p0f tool. This tool is able to perform Passive Fingerprinting
with TCP SYN Packets (looking at Window Size, TTL, Maximum Segment Size,
DF bit, Window scaling, sackok flag, nop flag, and packet size).
Moreover, since there is only forged ICMP requests from attacker, Ofir Arkin's
studies on ICMP fingerprinting will not help me a lot...
Now, I focus on 4th scan, because it involves TCP/IP kernel specificities
of attacker. As a matter of fact, TCP connect() scan is not "controlled"
by Nmap port scanning tool. All responses from attacker (RSTs) to SYN/ACK,
when an open TCP port is found on distant station, are crafted by the attacker's
kernel so contain some TCP/IP specificities that can be used to find attacker's
Operating System.
I look at p0f values, that can be found in any requests / responses from
attacker during fourth scan :
Windows Size is 5840.
TTL is 64.
MSS is 1460.
DF set.
Windows scaling is present, value 0 bytes.
SackOK flag is present.
NOP flag is present.
Packet size is 60 bytes.
I look now at [p0f.fp] file that includes lot of fingerprints.
With Windows Size = 5840, I can extract :
[Window Size | TTL | MSS | DF | WScaling | Sackok | NOP | Packet
Size | OS Guess ]
5840 128 536
1 0 1
1 48
Windows 95 (3)
5840 64 1460
1 0 1
1 60
Linux 2.4.2 - 2.4.14 (1)
5840 64 1460
1 0 1
1 52
Linux 2.4.1-14 (1)
5840 64 1460
1 0 1
1 48
Linux 2.4.1-14 (2)
5840 64 1460
1 0 0
1 60
Linux 2.4.13-ac7
5840 64 1460
0 0 1
1 60
Linux (unknown?) (2)
5840 128 1460
1 -1 1
1 48
Windows 95 or early NT4
5840 64 1460
1 223 1
1 60
Linux-2.4.13-ac7
Seems that's an Unix-like OS ! Let's continue...
With TTL 64, and MSS 1460, i can extract :
[Window Size | TTL | MSS | DF | WScaling | Sackok | NOP | Packet
Size | OS Guess ]
5840 64 1460
1 0 1
1 60
Linux 2.4.2 - 2.4.14 (1)
5840 64 1460
1 0 1
1 52
Linux 2.4.1-14 (1)
5840 64 1460
1 0 1
1 48
Linux 2.4.1-14 (2)
5840 64 1460
1 0 0
1 60
Linux 2.4.13-ac7
5840 64 1460
0 0 1
1 60
Linux (unknown?) (2)
5840 64 1460
1 223 1
1 60
Linux-2.4.13-ac7
No more Windows !
With DF bit, and Window scaling value = 0 bytes, i can extract :
[Window Size | TTL | MSS | DF | WScaling | Sackok | NOP | Packet
Size | OS Guess ]
5840 64 1460
1 0 1
1 60
Linux 2.4.2 - 2.4.14 (1)
5840 64 1460
1 0 1
1 52
Linux 2.4.1-14 (1)
5840 64 1460
1 0 1
1 48
Linux 2.4.1-14 (2)
5840 64 1460
1 0 0
1 60
Linux 2.4.13-ac7
With sackof flag present, nop flag present, i can extract :
[Window Size | TTL | MSS | DF | WScaling | Sackok | NOP | Packet
Size | OS Guess ]
5840 64 1460
1 0 1
1 60
Linux 2.4.2 - 2.4.14 (1)
5840 64 1460
1 0 1
1 52
Linux 2.4.1-14 (1)
5840 64 1460
1 0 1
1 48
Linux 2.4.1-14 (2)
With packet size = 60 bytes, i can extract :
[Window Size | TTL | MSS | DF | WScaling | Sackok | NOP | Packet
Size | OS Guess ]
5840 64 1460
1 0 1
1 60
Linux 2.4.2 - 2.4.14 (1)
Yes ! Attacker's Operating System seems to be a Linux with a kernel version
between 2.4.2 and 2.4.14. Since [p0f.fp] file is 4 months old, and
that there is no fingerprints for kernel version > 2.4.14 in [p0f.fp]
file, it is very difficult to find real kernel version of attacker, but it
can give me a good idea...
More informations :
- Attacker is on the same IP subnet space, confirmed by a TTL value of 64.
- Attacker's timestamp value is about 16917371, so attacker's uptime is ~
47 hours.
- Attacker's port scans are subject to detection with p0f tool, because nmap
fingerprints are available in [p0f.fp] file.
Conclusions
This challenge has involved the most used port scans and fingerprinting techniques.
So it forced me to check my knowledge about scanning / fingerprinting techniques,
and scanning / fingerprinting tool nmap functions and internals (especially
about all the timeouts used between scans, and OS Fingerprinting). It also
permitted me to make an effort for redaction and presentation of a security
analysis.
References
Nmap by Fyodor -- www.insecure.org/nmap
OS Fingerprinting / Port Scanning by Fyodor -- www.insecure.org/nmap
p0f passive fingerprinting -- www.stearns.org/p0f
Passive Fingerprinting -- project.honeynet.org
ICMP usage in scanning by Ofir Arkin -- www.sys-security.org
Ethereal -- www.ethereal.com
Mozilla for HTML editing -- www.mozilla.org
Google for Web searching -- www.google.com
Contact information
Laurent Butti
e-mail : laurent.butti@francetelecom.com
Last revision : September, 22nd.