[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect Benjamin Fabian
Benjamin Fabian
protozeus at web.de
Sat Jul 17 21:38:59 GMT 2004
Hi all,
this is the sketch of my GIAC detect from http://isc.sans.org/logs/Raw/.
Comments and feedback highly appreciated; be kind ;-)
Best regards,
Ben
-----------------------------------------------------------------------
Detect 1: "Get the Balance Right"
1. Source of the Trace
a) The trace:
[**] [1:628:3] SCAN nmap TCP [**]
[Classification: Attempted Information Leak] [Priority: 2]
06/10-08:51:10.544488 193.144.127.9:80 -> 46.5.227.141:137
TCP TTL:46 TOS:0x0 ID:998 IpLen:20 DgmLen:40
***A**** Seq: 0x37 Ack: 0x0 Win: 0x578 TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS28]
[**] [1:628:3] SCAN nmap TCP [**]
[Classification: Attempted Information Leak] [Priority: 2]
06/10-08:51:15.514488 193.144.127.9:80 -> 46.5.227.141:137
TCP TTL:46 TOS:0x0 ID:1329 IpLen:20 DgmLen:40
***A**** Seq: 0xA5 Ack: 0x0 Win: 0x578 TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS28]
[**] [1:628:3] SCAN nmap TCP [**]
[Classification: Attempted Information Leak] [Priority: 2]
06/10-08:51:20.504488 195.77.24.2:80 -> 46.5.227.141:137
TCP TTL:46 TOS:0x0 ID:1621 IpLen:20 DgmLen:40
***A**** Seq: 0xFE Ack: 0x0 Win: 0x578 TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS28]
[**] [1:628:3] SCAN nmap TCP [**]
[Classification: Attempted Information Leak] [Priority: 2]
06/10-08:51:25.504488 195.77.24.2:80 -> 46.5.227.141:137
TCP TTL:46 TOS:0x0 ID:1931 IpLen:20 DgmLen:40
***A**** Seq: 0x161 Ack: 0x0 Win: 0x578 TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS28]
Source IPs 193.144.127.9 and 195.77.24.2 are sending TCP-packets, which just have the ACK-bit set, from source port 80 to port 137. Here is the corresponding trace captured by tcpdump:
08:51:10.544488 193.144.127.9.80 > 46.5.227.141.137: . [bad tcp cksum f9f9!] 55:55(0) ack 0 win 1400 (ttl 46, id 998, len 40, bad cksum 3cc4!)
0x0000 4500 0028 03e6 0000 2e06 3cc4 c190 7f09 E..(......<.....
0x0010 2e05 e38d 0050 0089 0000 0037 0000 0000 .....P.....7....
0x0020 5010 0578 5d26 0000 0000 0000 0000 P..x]&........
08:51:15.514488 193.144.127.9.80 > 46.5.227.141.137: . [bad tcp cksum f9f9!] 110:110(0) ack 1 win 1400 (ttl 46, id 1329, len 40, bad cksum 3b79!)
0x0000 4500 0028 0531 0000 2e06 3b79 c190 7f09 E..(.1....;y....
0x0010 2e05 e38d 0050 0089 0000 00a5 0000 0000 .....P..........
0x0020 5010 0578 5cb8 0000 0000 0000 0000 P..x\.........
08:51:20.504488 195.77.24.2.80 > 46.5.227.141.137: . [bad tcp cksum f9f9!] 254:254(0) ack 0 win 1400 (ttl 46, id 1621, len 40, bad cksum 9f9f!)
0x0000 4500 0028 0655 0000 2e06 9f9f c34d 1802 E..(.U.......M..
0x0010 2e05 e38d 0050 0089 0000 00fe 0000 0000 .....P..........
0x0020 5010 0578 c1a9 0000 0000 0000 0000 P..x..........
08:51:25.504488 195.77.24.2.80 > 46.5.227.141.137: . [bad tcp cksum f9f9!] 99:99(0) ack 1 win 1400 (ttl 46, id 1931, len 40, bad cksum 9e69!)
0x0000 4500 0028 078b 0000 2e06 9e69 c34d 1802 E..(.......i.M..
0x0010 2e05 e38d 0050 0089 0000 0161 0000 0000 .....P.....a....
0x0020 5010 0578 c146 0000 0000 0000 0000 P..x.F........
b) The source of the trace:
The logs of this detect have been taken from the "raw" logs section of www.incidents.org. [1] A first look with tcpdump gives us information about the network the logs have been taken from:
tcpdump -vvenr 2002.5.10 | more
-vv : use just a medium level of verbosity; feel free to experiment for deeper inspection.
-e : show the ethernet (MAC) addresses.
-n : do not resolve IP addresses to DNS names.
-r : traffic not taken from a network interface card (NIC), but from a given file.
The traffic thus inspected hints at a "home net" being part of 46.5.0.0/16 (IANA reserved IP addresses, therefore probably obfuscated as stated in the README to the log files), as this network is source or destination of every packet we see. Given this, we can look at the Ethernet layer:
MAC external device, NIC looking inside: 0:0:c:4:b2:33
MAC internal device, NIC looking outside: 0:3:e3:d9:26:c0
The first three bytes identify the vendor of the NIC (according to RFC 1700, obsoleted by RFC 3232, which just states that RFC 1700 has been replaced by an online database [2]). Especially for MAC addresses we refer to the IANA homepage. [3] There is a nice searchable version that is useful for reference. [4] We use it to look up the vendors by the MAC-address prefixes:
00000C Cisco Systems, Inc
0003E3 Cisco Systems, Inc
We can conclude that the IDS sensor is somehow placed between two Cisco devices, probably routers or a PIX firewall. The network might look somehow like the following pictorial attempt:
Internet
|
External Cisco Device (int. MAC: 0:0:c:4:b2:33)
|
Switch (SPAN port) -- Snort (stealth interface)
|
Internal Cisco Device (ext. MAC: 0:3:e3:d9:26:c0)
|
Internal Networks (46.5.0.0/16)
We look deeper for interesting traffic by using Snort as a display tool:
snort -c /etc/snort/giac.conf -k none -h 46.5.0.0/16 -l T2002.5.10 -r 2002.5.10
-c : use the given configuration file; note that my giac.conf uses all available standard rules as included with version 2.1.1 (Build 24).
-k none : ignore checksum errors (which resulted from obfuscating the IP addresses); as the TCP/UDP checksums use a pseudo-header including the IP addresses, just ignoring the IP checksum is not enough to prevent Snort from ignoring these modified packets).
-h : state the point-of-view for snort, this is our guessed home net, deducted from first look above.
-l : states the directory where Snort saves the output.
-r : as in tcpdump, states Snort should read his input in binary format from a file.
With the help of Snortalog [5] we try to identify the top alarms (option -attack) from the alert file generated by snort during the previous step - this is located in the directory T2002.5.10: snortalog.pl -attack -file alert . Skimming through the messages we have the unusual freedom of choice where to look closer. As traffic concerning port 137/tcp (!) looks very interesting, this is what we will focus on.
2. Detect was generated by ...
The detect above was generated by Snort 2.1.2 with a full rule set applied to the binary capture file - which was itself created by an older Snort of unknown exact version and rule set. It is probable that the original alert was generated by the same rule as mine, perhaps having an older version as 3:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap TCP"; stateless; flags:A,12; ack:0; reference:arachnids,28; classtype:attempted-recon; sid:628; rev:3;)
This rule looks for inbound TCP-packets (even packets not part of regular and already initiated sessions, as "stateless" implies) with just the ACK-bit (possibly together with the reserved or ECN bits) set and an acknowledgement number of 0, which would only be possible after cycling the whole range and even then highly improbable. So an ACK-scan like with nmap -sA would be a likely diagnosis, and this is what the alert messages state. Note, however, that the Nmap 3.5 man page [6] states that the acknowledgement numbers used in this kind of scan would be random looking. Later I found reference and lab testing regarding this issue in Antony Gummery's GIAC practical posting [7], where he gave a link to proof that earlier Nmap versions indeed used 0 as acknowledgement number [8] - a fact which seemed to be the motivation for writing this Snort rule.
The second set of traces was generated by applying tcpdump to the downloaded file. By variations of filters (tcpdump -nvvXr 2002.5.10 host 46.5.227.141 / host 195.77.24.2 / host 193.144.127.9) we made sure that the only captured packets from these two sources were directed at the destination IP 46.5.227.141.
3. Probability the source address was spoofed
We see no signs of an attempted Denial-of -Service here, because we have only a few packets from two source IP addresses, nor does the detect look like a one-packet exploit, as this would most likely require a completed three-way-handshake which most probably did not occur. So it would be reasonable that the source wants something in return - either a RESET or an ICMP unreachable message - or by a lack thereof be able to draw conclusions about filtering devices in the path. So spoofing seems not probable here.
4. Description of the attack
The source IPs above are sending TCP-packets with only the ACK-bit set from source port 80 to port 137 on IP 46.5.227.141 which resides in our "home" net. The acknowledgement number is 0, which is highly improbable (if not impossible) in normal traffic. This could only occur if during long and intensive data transfers the sequence numbers had to be recycled, and even then the last packet before this would have to have included as last byte that with the maximum number of 232.
To describe what is really going on we have to look at the larger picture of observed traffic from, see 9. Correlations below. The whole picture presents itself as follows. Both IP addresses seem to belong to traffic shaping or load-balancing devices, which try to determine an optimal route to our "home" net. This is with all probability a response to some client on our side connecting to a service in the load balancers' realm, not a stimulus. All the correlation detects below indicate that this is a normal and mostly harmless procedure, which generates an awful lot of strange packets and general network noise.
5. Attack mechanism
What would be the reason to send such packets as seen in the traces above? The nmap man page [9] states:
ACK scan: This advanced method is usually used to map out firewall rulesets. In particular, it can help determine whether a firewall is stateful or just a simple packet filter that blocks incoming SYN packets.
This scan type sends an ACK packet (with random looking acknowledgment/sequence numbers) to the ports specified. If a RST comes back, the ports is classified as "unfiltered". If nothing comes back (or if an ICMP unreachable is returned), the port is classified as "filtered". Note that nmap usually doesn't print "unfiltered" ports, so getting no ports shown in the output is usually a sign that all the probes got through (and returned RSTs). This scan will obviously never show ports in the "open" state.
So the normal purpose for an ACK-scan would be to probe firewalls - reconnaissance versus the network defenses. Or it might try to pass through to find a host alive - first reconnaissance versus a single host. But if a reset returns, it cannot be determined if the targeted port was open or closed, in both cases an unsolicited ACK should return a RESET (RFC 793, headline "Reset Generation", page 36): [10]
1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset.
(...)
2. If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent.
But some more information about the target host may be gathered by passive fingerprinting the returning packet, e.g. by the use of p0f. [11]
If we have a look at the huge history of strange traffic originating from these IPs in: 6. Correlations a), b), c), this is still ongoing activity even after two years. Especially a) is ringing a bell: Load balancer traffic.
In our case the source seems to be more interested in the returning packet itself than in reconnaissance of target networks or hosts. It carries a TTL that helps to calculate the distance in hop counts between each load balancer and the client network. The roundtrip time between sending the ACK and receiving the RESET also can be used to optimize the choice which server should respond.
Interesting it the destination port of 137/tcp, which we do not see in younger examples of traffic from these sources - but this could be due to limited visibility and not enough samples. Is this just a choice of a port assumed closed on almost every existing machine (as Windows Netbios name service uses 137/udp)? Or was this port chosen by design - perhaps assuming that port 137/(any protocol) at that time was open in some very simple packet filtering devices instead of narrowing to 137/udp? It is hard to say - but with all caveats this port seems to be replaced by 123/tcp nowadays, perhaps in the same hope of slipping through loose filters that were build to allow NTP (123/udp) in.
Just two examples of load balancing products are:
i) 3-DNS [12]
ii) LinkProof [13] - there is also white paper giving an overview of its operation. [14]
An example of just one kind of strange traffic from this kind of devices is given in 6. Correlations, d).
We use whois to examine the source IPs:
whois -h whois.ripe.net 195.77.24.2 ...
inetnum: 195.77.24.0 - 195.77.24.255
netname: GVANET
descr: Generalitat Valenciana
descr: Internet access for Valencia State (NCC#1998103531)
country: ES
...
whois -h whois.ripe.net 193.144.127.9 ...
inetnum: 193.144.104.0 - 193.144.127.255
netname: GVA
descr: Red GVA De La Generalitat Valenciana
descr: Valencia
country: ES
...
Both addresses are registered with an official sounding "Generalitat Valenciana" in Spain. This Generalitat has a very flashy and fancy web portal that I found by using Google: www.gva.es
And what do we find if we do a reverse lookup on this hostname?
www.gva.es canonical name = aesgard.gva.es.
Name: aesgard.gva.es
Address: 193.144.127.85
Name: aesgard.gva.es
Address: 195.77.24.70
Strike. This name has two possible IP addresses - one in each of the same subnets that are seen as source in our traces: 193.144.127.0/24 and 195.77.24.0/24. And now we know how much noise they generate just to spare us some milliseconds waiting time, see 6. Correlations e).
Very caring.
6. Correlations
a) First we look at the DShield database. [15] At the time of writing IP 195.77.24.2 appears 1,512 (!) times in the database, whereas IP 193.144.127.9 does not appear a single time. Some of the TCP-ports IP 195.77.24.2 seems to have "scanned" for are: 53, 80, 123, 1915, 4671, 4672, 36296, 54367. Many of these destination ports have also been used as source ports; in addition we see for example 20 and 3128. Concerning flags there is plain SYN, lonely ACK and sometimes no flags. Some records might indicate ICMP echo requests (source "port" 8) that seem not have been normalized correctly.
A direct correlation for destination port 137/tcp is not listed, but lots of packets have been sent with source port 80. One similarity occurs: destination 123/tcp whereas normal usage of this port only occurs with NTP (123/udp), though some databases list Trojans using this TCP port. [16] As most of the other scans are not Trojan-related, I would dismiss this possibility in the whole context. All these patterns indicate probing for normally open and normally closed ports with source ports and flags used to bypass simple packet filtering devices.
b) A correlation for IP 193.144.127.9 which shows more common signs of load-balancer traffic, note that the IP is still active in 2004. [17] No explanation is given there.
[**] SCAN nmap TCP [**]
03/12-04:09:22.980000 0:6:53:3:7E:20 -> 0:10:DB:8:9C:C1 type:0x800
len:0x3C
193.144.127.9:80 -> xxx.xxx.xxx.33:53 TCP TTL:40 TOS:0x0 ID:23818
IpLen:20 DgmLen:40
***A**** Seq: 0x2A4 Ack: 0x0 Win: 0x578 TcpLen: 20
c) Antony Gummery investigated parallel traffic while preparing his GIAC practical. His detects come from raw logs 4 months later. [18] They have the same source port 80/tcp and destination port 137/tcp. He is doing extensive and very well arguing analysis on these traces with similar results but a little different conclusion about the severity. [19]
[**] SCAN nmap TCP [**]
10/17-17:25:45.266507 193.144.127.9:80 -> 32.245.136.215:137 TCP TTL:44
TOS:0x0 ID:54253 IpLen:20 DgmLen:40
***A**** Seq: 0x282 Ack: 0x0 Win: 0x578 TcpLen: 20
17:25:45.266507 193.144.127.9.http > 32.245.136.215.netbios-ns: .
[bad tcp cksum 1815!] 642:642(0) ack 0 win 1400
(ttl 44, id 54253, len 40, bad cksum bb64!)
0x0000 4500 0028 d3ed 0000 2c06 bb64 c190 7f09 E..(....,..d....
0x0010 20f5 88d7 0050 0089 0000 0282 0000 0000 .....P..........
0x0020 5010 0578 a783 0000 0000 0000 0000 P..x.........
d) An example of LinkProof traffic by Chris Brenton. [20]
e) The final test. I just visited www.gva.es [21] from IP MY.COMPANY.NET.99 - and what do our Snort and Raptor firewall report (in an abstract, normalized log-format)?
195.77.24.2 80 MY.COMPANY.NET.51 53 TCP
193.144.127.9 80 MY.COMPANY.NET.51 53 TCP
193.144.127.9 53 MY.COMPANY.NET.51 53 TCP
193.144.127.9 - MY.COMPANY.NET.51 - (pingd)
For the record, MY.COMPANY.NET.51 is not a DNS server.
7. Evidence of active targeting
Yes, these packets seem to be actively targeted, there are no horizontal scan patterns. The destination server might be a DNS server. But what we see is no stimulus - it is most probably a reply to not recorded outgoing connections attempts to web servers. A group of load-balancing devices tries to deliver an optimized path for the request.
8. Severity
We estimate the severity of the attack according to the formula recommended by SANS:
Severity =
(Criticality + Lethality) - (System Countermeasures + Network Countermeasures)
Each value is ranked on a scale from 1 (lowest) to 5 (highest).
a) Criticality: What is the function of 46.5.227.141? The above trace is the only occurrence of that IP. Most load balancer traffic seems to target DNS servers, but that would be arguing a posteriori. Thus spoke sagacious Salomon: 3.
b) Lethality: The probable function of the observed traffic is route optimization, so no much danger here. But the methods are indeed scans that gather information about the home network. Who knows what happens with that information? So I would give it Lethality: 2.
c) System Countermeasures: Frankly speaking - we do not know. We do not know if the fact that we do not see return packets is due to the fact that there were none, even if a possible positive response from 137/tcp would be somehow remarkable. So we have to be neutral here: 3.
d) Network Countermeasures: We do not know much. But they have a network IDS in place which indicates a sharpened sense for security. Let's rate it with 4.
Severity = (3+2) - (3+4) = -2
9. Defense recommendation
The port 137 (UDP and TCP) should definitely be blocked from entering any network, perhaps already at the border router if performance allows. Stateful inspection should be installed which keeps track of inbound and outbound sessions, so a lonely unsolicited ACK-scan would be blocked. The same applies to all not internally presented services. If possible, a general "Deny all" strategy should be implemented, with just the necessary openings. Inbound ICMP messages should be very handled restrictive but with care, as some error messages (e.g. fragmentation related) are necessary for normal traffic. The deployment of an IDS is a very good move, though we recommend in general fine-tuning of signatures to reduce the number of false positives. In our case the signature was triggering correctly, just the motivation for the observed scan is non-aggressive - but how should Snort know? We cannot exclude all possible load-balancers from investigation.
10. Multiple Choice Question
Given the trace below, which answer is true?
[**] [1:628:3] SCAN nmap TCP [**]
[Classification: Attempted Information Leak] [Priority: 2]
06/10-08:51:10.544488 193.144.127.9:80 -> 46.5.227.141:137
TCP TTL:46 TOS:0x0 ID:998 IpLen:20 DgmLen:40
***A**** Seq: 0x37 Ack: 0x0 Win: 0x578 TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS28]
(a) This is a false positive; we see return traffic from a web server.
(b) This is part of a normal Netbios name resolution process between a Windows XP client and a WINS server.
(c) An acknowledge-number field of zero after Three-way-handshake is a security feature of Open BSD 3.4 or later.
(d) Such and similar packets are indicating the presence of load-balancers.
Correct answer: (d)
11. References:
[1] Raw Logs on Incidents.org: http://www.incidents.org/logs/raw/2002.5.10
[2] IANA Protocol Numbers and Assignment Services: http://www.iana.org/numbers.html
[3] IANA Ethernet Numbers: http://www.iana.org/assignments/ethernet-numbers
[4] Vendor/Ethernet MAC Address Lookup and Search: http://www.coffer.com/mac_find/
[5] SnortAlog Homepage: http://jeremy.chartier.free.fr/snortalog/
[6] Nmap network security scanner man page: http://www.insecure.org/nmap/data/nmap_manpage.html
[7] Firewall incidents at the FinchHaven datacenter: http://www.finchhaven.com/pages/incidents/031202_tcp_123.html
[8] Fyodor on Snort-users mailing list, Aug 11, 2000: http://archives.neohapsis.com/archives/snort/2000-08/0152.html
[9] Nmap network security scanner man page: http://www.insecure.org/nmap/data/nmap_manpage.html
[10] RFC 793, Transmission Control Protocol, Sep 1981: ftp://ftp.rfc-editor.org/in-notes/rfc793.txt
[11] p0f Homepage: http://lcamtuf.coredump.cx/p0f.shtml
[12] F5 3-DNS Controller: http://www.f5.com/f5products/3dns/
[13] Radware LinkProof: http://www.radware.com/content/products/lp/default.asp
[14] LinkProof - White Paper: http://www.radware.com/content/products/lp/whtpaper/default.asp?_v=about&document=1316
[15] DShield Homepage: http://www.dshield.org/
[16] Firewall incidents at the FinchHaven datacenter: http://www.finchhaven.com/pages/incidents/031202_tcp_123.html
[17] Pedro Bueno on Intrusions list, Apr 8, 2002: http://cert.uni-stuttgart.de/archive/intrusions/2002/04/msg00110.html
[18] Raw Logs on Incidents.org: http://www.incidents.org/logs/RAW/2002.9.17
[19] Antony Gummery on Intrusions list, Mar 22, 2003: http://www.dshield.org/pipermail/intrusions/2003-March/007239.php
[20] Chris Brenton on Intrusions list, Apr 26, 2002: http://cert.uni-stuttgart.de/archive/intrusions/2002/04/msg00318.html
[21] Generalitat Valenciana portal site: http://www.gva.es
-----------------------------------------------------------------------
(End of Detect)
-----------------------------------------------------------------------
____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200
More information about the Intrusions
mailing list