"LOGS: GIAC GCIA Version 3.4 Practical Detect Tuong Dam".

Hi all,

Below is the network detect for my GCIA prctical assignment Part 2
Network Detects.

All comments are welcome.

Thanks for your time.

Tuong Dam.

Network Detect 1: SCAN NULL

Snort SCAN NULL alert output from raw log 2003.12.15.2 (first record)

[**] [1:623:2] SCAN NULL [**]
[Classification: Attempted Information Leak] [Priority: 2]
11/19/03-04:59:38.188892 0:A:95:7C:24:0 -> 0:50:56:40:0:6D type:0x800
len:0x3C
10.10.10.113:59194 -> 192.168.17.68:5001 TCP TTL:38 TOS:0x0 ID:43084
IpLen:20 DgmLen:40
******** Seq: 0x0  Ack: 0x0  Win: 0xC00  TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS4]

Matching packet in tcpdump format that triggered the snort SCAN NULL
alert:
 
04:59:38.188892 0:a:95:7c:24:0 0:50:56:40:0:6d ip 60: 10.10.10.113.59194
> 192.168.17.68.5001: . win 3072
0x0000   4500 0028 a84c 0000 2606 061d 0a0a 0a71        E..(.L..&......q
0x0010   c0a8 1144 e73a 1389 0000 0000 0000 0000        ...D.:..........
0x0020   5000 0c00 c2b9 0000 5555 5555 5555             P.......UUUUUU

1. Source of trace:

http://incidents.org/logs/raw/2003.12.15.tgz
Tar ball down loaded and extracted into 14 separate files
2003.12.15.1-14.
Raw log file 2003.12.15.2 was used for this detect.

Browse through the raw log file initially using Ethereal 0.10.0a running
on Linux 2.4.22-1.2188.nptl kernel, I've noticed that the raw log
capture time appears to be from 2003/11/19 04:59:37 till 05:01:51 same
day.

To get a closer look into this raw log 2003.12.15.2 for SCAN NULL, an
event of interest which I've decided to analysis further, it's about 9%
of the total alerts generated.

Ethereal filter "tcp.flags == 0 and tcp.seq == 0" was used to match TCP
packets with its flags (SYN, ACK, FIN, RST, PSH and URG) all set to zero
plus the sequence number also set to zero, the result found was 3250
packets matching this condition out of a total of 36935 packets. Further
more, the source IP address was a single host 10.10.10.113 to 2
destination hosts sharing the same MAC address 00:50:56:40:00:6d with IP
address 192.168.17.68 and 192.168.17.129 respectively.

Interestingly, a combination of the above mentioned filter and tcp.ack
== 0, which means also matching for packet with it's tcp acknowledgment
number set to zero, the result found was empty set.

More on this point, Snort only generated 3248 instances of SCAN NULL
alert instead of Ethereal filter 3250 instances.  

# grep "\[\*\*\]" alert | sed "s/\[\*\*\]//g" | cut -f 2 -d ']' | sort |
uniq -c | sort -rn | grep "SCAN NULL"

   3248  SCAN NULL

Based on the information I have discovered so far, the network diagram
may hypothesis look like the following: 

                        10.10.10.113 
                      00:0a:95:7c:24:00 
                     (AppleCom_7c:24:00)
                              |
                        IDS collector
                              |
                  |++++++++++++++++++++++++|
                  |                        |
            192.168.17.68           192.168.17.129
                     00:50:56:40:00:6d      
                      (Vmware_40:00:6d)

2. Detect was generated by:

Hardware:               Pentium 3 733 MHz - 384 MB Ram.
Operating system:       Fedora Core release 1 (Yarrow).
Software:               Snort Version 2.1.3RC1 (Build 26).
                        Snort rules set (2004/04/30).
Snort command:          snort -c /etc/snort/snort.conf -r
/var/log/incidents.org/2003.12.15.2 -l
/home/working/1_detect/2003.12.15.2 -k none -dye

Snort command option explanation:
-c uses specified snort config file RULE_PATH variable for rules set
location.  -r read tcpdump-formatted  file
/var/log/incidents.org/2003.12.15.2
-l logging to /home/working/1_detect/2003.12.15.2 instead of snort
default one /var/log/snort. 
-k none turn off checksum verification subsystem, this is to do with raw
log file checksums modification by incidents.org site to hide protected
network information.
-d dump the application layer data to output log.
-y include year to output log.
-e dump the link layer headers to output log.

SCAN NULL alert was triggered by Snort rule ID 623 below (1):

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN NULL";
stateless; flags:0; seq:0; ack:0; reference:arachnids,4;
classtype:attempted-recon; sid:623; rev:2;)

This rule was designed to match all TCP packet with source IP (match
EXTERNAL_NET variable definition) to destination IP (match HOME_NET
variable definition) with TCP flags (SYN, ACK, FIN, RST, PSH and URG)
all set to zero and the sequence number as well as acknowledgment number
are all set to zero.

Let's have a look at one of the packet from 2003.12.15.2 log which
triggered the snort SCAN NULL alert and see how this rule apply to it.

# tcpdump -nxqr 2003.12.15.2 tcp[13]=0 and tcp[4:4]=0 and tcp[8:4]=0 -c
1

04:59:38.188892 10.10.10.113.59194 > 192.168.17.68.5001: tcp 0
                         4500 0028 a84c 0000 2606 061d 0a0a 0a71
                         c0a8 1144 e73a 1389 0000 0000 0000 0000
                         5000 0c00 c2b9 0000 5555 5555 5555

tcpdump command option explanation:
-n do not perform host addresses to names lookup.
-x print packet in hex without its link level header.
-q quiet mode, only interesting for the hex output.
-r read packet from file 2003.12.15.2.

tcpdump filter explanation:
tcp[13]=0 look for packet with TCP header 13th byte equal zero. 
tcp[4:4]=0 look for packet with TCP header 4th byte, continue for 4
bytes length equal zero.
tcp[8:4]=0 look for packet with TCP header 8th byte, continue for 4
bytes length equal zero. 
-c 1 only displays the first match packet.

tcpdump output explanation:
04:59:38.188892 time stamp of the packet.
10.10.10.113.59194 source IP and source port.
> direction of the traffic.
192.168.17.68.5001 destination IP and destination port.
tcp encapsulated protocol, TCP in this case.
0 number of bytes in the TCP data, zero byte in this case.

Next, the hex output itself, each character in hex output equal 4 bits
or 1 nibble, 2 nibbles equal 1 byte. Zero is the number we start to
count in digital world. Let's have a look at some important fields
within IP header and TCP header.

In IP header, the first nibble is the 4-bit represents IP version, we
have hex "4" in our case and it's means IP version 4.
The next 4-bit is the IP header length, because it's 32-bits word, so
hex "5" here means 5 * 32-bit (or 4 bytes) equal 20 bytes, agree? This
packet have 20 bytes IP header length.
The 9th bytes of the IP header is the packet encapsulated protocol
information, we have hex "06" which means TCP. End of the 20 bytes IP
header will be the TCP header. 

In TCP header, TCP flags information stored at the 13th byte of the TCP
header, we have here a hex value of "00", its binary equivalent is:
00              0       0    0     0      0       0     
2 reserved bit, urgent, ack, push, reset, syn and fin -> all set to
zero.
TCP sequence number stored at the 4th byte of the TCP header and
continue for 4 bytes length, we have here hex value of "0000 0000" ->
sequence number equal zero.
TCP acknowledgment number information stored at the 8th byte of the TCP
header and continues for 4 bytes length, we have here hex value of "0000
0000" -> Acknowledgment number also equal zero. 

All conditions of the Snort rule are met, an alert is raised and
recorded.

3. Probability the source address was spoofed:

Snort rule ID 623 suggested SCAN NULL class type as "attempted-recon";
information gathering is another word to describe this type of attack. 

With NULL SCAN or other type of scan, the attacker most wanted list is
the return data from its corresponding scan traffic. If the source IP
address is spoofed, return traffic will go to the spoofed IP address
instead of attacker real source IP address, which is certainly not what
the attacker want.  

More over, in our case, noticed that the single source IP address
10.10.10.113 is one of the RFC 1918 (2) private IP address spaces, this
IP address should not be visible to the Internet. Will it be the host
10.10.10.113 was compromised and being used as 3rd party tool to scan
internal network for further attack, or this is just an internal
penetration test.The former will need more information and investigation
on host 10.10.10.113 to confirm the fact. Either way, the source IP
address in unlikely to be spoofed. 

4. Description of attack:

SCAN NULL was used to gather target information prior to launch the real
attack. By using tool available like NMAP, HPING, the attacker will be
able to send malformed packet (tcp flags, tcp sequence number and tcp
acknowledgment number all set to zero) to its target, and simply just
waiting for response and uses the data to figure out the OS platform, OS
version, open port, services information, even machine uptime, TCP
initial sequence number, etc.  

If the target was protected by stateless firewall or just packet filter
devices, which normally only looking for initial TCP packet with Syn
flag to decide whether or not to allow the packet, by sending malformed
packet like NULL SCAN, it may confuse the devices and make its way
through to get the response. 

Further more, for organization that have their security policy to not
filter out going traffic, the attacker will even have a good scan
output.

>From NMAP man page (3):
---------------------- 
"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)".

"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 distinguish between the two platforms". 

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

Snort rule 623 references point to http://www.whitehats.com/info/IDS4

However, I could not find a CVE number associated with SCAN NULL.

5. Attack mechanism:

Single source 10.10.10.113 sent 3248 NULL SCAN (tcp flags, sequence and
acknowledgment number all set to zero) packets to 2 destination hosts
192.168.17.68 and 192.168.17.129 at around 2 minutes.

Two source port 59194 and 59195 was swapping each other every 10 packets
where destination port seems randomly pick, pls note that each
destination port scan twice and destination port range from 1 - 65301. 

# tcpdump -nnq -r 2003.12.15.2 src host 10.10.10.113 and 'dst host
192.168.17.68 or dst host 192.168.17.129' and tcp[13]=0 and tcp[4:4]=0
and tcp[8:4]=0 | awk '{print $4}' | cut -f 5 -d '.' | sort -n | uniq -c

      4 1:
      4 2:
      4 5:
      4 7:
      4 10:
-------snip------
      4 44443:
      4 49400:
      4 61439:
      2 61440:
      4 65301:

Before it end the first scan, 2 more packets from another source port
59202 to destination port 1 with 2 different windows size: 4096 and
4194304.

Then host 10.10.10.113 start the second scan to 192.168.17.129 with the
same pattern without the last 2 packets.

Let's have a look at how the target hosts response. First we will look
for all reply from the scan packets.

# tcpdump -nqxr 2003.12.15.2 src host 192.168.17.68 or src host
192.168.17.129 and dst host 10.10.10.113 and dst port 59194 or dst port
59195 or dst port 59202
05:01:07.165603 192.168.17.129.https > 10.10.10.113.59194: tcp 0 (DF)
                         4500 0028 0000 4000 3e06 562c c0a8 1181
                         0a0a 0a71 01bb e73a 0000 0000 0000 0000
                         5014 0000 e036 0000 0000 0000 0000
05:01:30.711480 192.168.17.129.ftp > 10.10.10.113.59194: tcp 0 (DF)
                         4500 0028 0000 4000 3e06 562c c0a8 1181
                         0a0a 0a71 0015 e73a 0000 0000 0000 0000
                         5014 0000 e1dc 0000 0000 0000 0000

Only 2 replied from host 192.168.17.129 for TCP 443 and tcp 21. Noticed
13th byte of the TCP header, we have a hex value of "14", this is
equivalent to 0001 0100 in binary, the tcp flags are in order: 

2 reserved bit, urgent, ack, push, reset, syn and fin.
00              0       1    0     1      0       0    --> we have ack
and reset flags set.

With this result, is that the scan has been un-successful, not really,
the attacker is now known at least two things: 

a. Target OS is not the one which following RFC 793 (4), as per NMAP man
page, it may be: Windows, Cisco, BSDI, HP/UX, MVS, or IRIX.
b. Nothing reply but 2 well known TCP services HTTPS 443 and FTP 21 from
host 192.168.17.129.

6. Correlations:

Search engine from GIAC web site http://www.giac.org with key word "SCAN
NULL + 2003.12.15.2" returned only one match document:

GIAC GCIA Certified Analyst Number 700 Gregory Lalla has posted the
similar network detect from his practical paper (5), however, his detect
was based on nearly the entire 2003.12.15.tgz log, it looked at SCAN
NULL and other type of scan as well.

My detect purely based on 2003.12.15.2 and focus on SCAN NULL in-depth.

Search engine from GIAC web site http://www.giac.org with key word "SCAN
NULL" returned a number of match documents, I am listing two below:

Robert Sorensen GCIA practical paper (6) has briefly described NULL SCAN
and provided "Top 10 Sources triggering this attack signature"

Andy Millican GSEC pratical paper (7) described NULL SCAN and mentioned
RFC 793 "TCP packet without the RST flag set to a closed port on a
remote network should receive an RST response" and "OS that do not
adhere strictly to the RFC standard (Windows 95/NT, Cisco, BSDI, HP/UX,
MVS, and IRIX)".

Other source:
Internet Security Systems website (8) mentioned SCAN NULL briefly.

Paul Asadoorian, GCIA Internet Security Engineer posted SCAN NULL
traffic from source 209.202.29.63 (9).

7. Evidence of active targeting:

Single source IP 10.10.10.113 originate 3248 NULL SCAN packets in just
more than 2 minutes to 2 destination hosts 192.168.17.68 and
192.168.17.129 with destination port range from 1 - 65301. This
indicated to me that the hosts are well picked and directly to be the
main target.

8. Severity:

severity = (criticality + lethality) - (system countermeasures + network
countermeasures)
   2     = (    4       +    4     ) - (         4           +      2  )

Criticality = 4. Lack of the network infrastructure design information,
it's hard to assign this parameter, however, during the scan, host
192.168.17.129 replied with HTTPS and FTP, this seems the host itself is
providing some critical core services.

Lethality = 4. Attacker obtained possible open port and OS platform.

System countermeasures = 4. Host level security seems okay with the
target at this stage. Given host 192.168.17.68 did not response to the
scan, only 2 replies from host 192.168.17.129.

Network countermeasures = 2. Network security was not as good as it
should be. It should drop the malformed scan packet right at the network
entry point.

9. Defensive recommendation:

#1 Review border routing devices security, it must configured to drop
all malformed scan packet silently at the network entry point.

#2 Keep FTP and HTTPS server software and patch up to date, particularly
the base components of these severs. i.e ssl library for HTTPS.

#3 Application level security, it will be ideal to setup the following
for web service:

End user ---------HTTPS reverse proxy-------------------HTTP web server
                (Capable to rewrite incoming request, 
                rewrite rule based on Snort web signature) 

Sample Snort web signature and its corresponding apache rewrite rule:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-ATTACKS ps command attempt"; flow:to_server,established;
uricontent:"/bin/ps"; nocase; sid:1328;classtype:web-application-attack;
rev:4;) (10)

# WEB-ATTACKS ps command attempt
RewriteRule ^/.*/bin/ps.*$ http://blackhole/blackhole_worm.html [NC,P,L]

10. Multiple choice test question:
Company XYZ IDS system just raise an alert, IT security staff inspected
the associate raw packet and discovered the following tcp header values:

tcp[4:4] = 0 and tcp[8:4]= 0 and tcp[13] = 0

A This is buffer overflow attack with serial of binary 0000.......0000.
B This is valid packet, the IDS system just raised a false alert, we
need to upgrade the rule set.
C This is a port scan using NMAP with -sN option to send tcp packet with
its sequence number, acknowledgment number and tcp flags are all set to
zero.
D This is a port scan using NMAP with -sS option to send tcp packet with
its syn flag set to 1 and other flags are set to zero. 

Answer: C

NMAP with -sN option will form tcp packet with sequence number tcp[4:4],
acknowledgment number tcp[8:4] and  tcp flags tcp[13] all set to zero.

References:
----------

(1) Snort signature ID 623.
http://www.snort.org/snort-db/sid.html?sid=623
(2) RFC 1918: http://www.faqs.org/rfcs/rfc1918.html
(3) NMAP man page: http://www.insecure.org/nmap/data/nmap_manpage.html
(4) RFC 793: http://www.faqs.org/rfcs/rfc793.html
(5) GIAC GCIA Certified Analyst Number 700 Gregory Lalla practical
paper. http://www.giac.org/practical/GCIA/Gregory_Lalla_GCIA.pdf
(6) Robert Sorensen GCIA practical paper.
http://www.giac.org/practical/Robert_Sorensen_GCIA.htm#ss-15
(7) Andy Millican GSEC practical paper.
http://www.giac.org/practical/GSEC/Andy_Millican_GSEC.pdf
(8) Internet Security Systems website.
http://www.iss.net/security_center/advice/Intrusions/2000309/default.htm
(9) Paul Asadoorian GCIA Internet Security Engineer posted SCAN NULL
traffic. http://www.dshield.org/pipermail/intrusions/2001-May/000312.php
(10) Snort signature ID 1328.
http://www.snort.org/snort-db/sid.html?sid=1328





_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions