Re: LOGS: GIAC GCIA Version 3.5 Practical Detect Coen Bakkers

Nice work.  Have you looked into p0f?  I think that does a passive OS 
fingerprint on SYN packets.  Not as definitive as NMAP active OS 
fingerprinting, but I'm planning to use it.  I haven't looked into it yet - it 
may not look much beyond the TTL that you mentioned.  

coen.bakkers@xxxxxxxxxxxxxxxxxxxxxxx wrote:

Hi,

This is my first posting for my GCIA practical. I would highly appreciate your 
comments and or suggestions.

Thanks

Coen Bakkers
Security Analyst


Detect 1: Proxy Scan

Source of Trace

The logs have been downloaded from: 
http://www.incidents.org/logs/Raw/2002.4.16. (April 24th 2004)

The logs are in binary format. All packets have violated the 'unknown ruleset' 
in the logs. Internal network IP addresses, Checksums have been altered.
All non-local IP addresses are existing addresses. All ICMP, DNS, SMTP and Web 
Traffic was also been removed. (Source: 1)

The logs were analyzed on a Red Hat 9 workstation. For the installation of the 
necessary software, I used Snort, Apache, PHP, MySQL, and ACID which I 
installed on basis of the Redhat 9.0 Installation Guide of Patrick Harper 
(Source: 2).

The sources I used for analyzing the log files are Ian Martins practical 
(Source: 3) which in turn used the posts of Les Gordon (Source: 4) and Andre 
Cormier(Source:5):

First let?s have a look at the source (a) destination (b) MAC addresses:
a) tcpdump -neqr 2002.4.16 | cut -d ' ' -f 2 | sort |uniq -c

2970 0:0:c:4:b2:33
426 0:3:e3:d9:26:c0
b) tcpdump -neqr 2002.4.16 | cut -d ' ' -f 3 | sort |uniq -c

426 0:0:c:4:b2:33
2970 0:3:e3:d9:26:c0

To get to know more about the MAC addresses of these devices, I then did a 
lookup on the (6) following the instructions mentioned in Ian Martin?s 
practical regarding the leading zeros. A lookup on the MAC address 0000c 
returns Cisco Systems Inc, so does 00003e3:

Cisco Device ---------------Cisco Device
I
Snort device

Now the next step is to determine the internal and the external network:

Source addresses are coming from 0:0:c:4:b2:33:

$tcpdump -neqr 2002.4.16 ether src 0:0:c:4:b2:33 |cut -d ' ' -f 5| cut -d \. -f 
1-4|cut -d -f \.1-4|sort |uniq -c |sort -rn

2961 78.37.212.28
9 78.37.212.165

Destination addresses coming from 0:0:c:4:b2:33:

$tcpdump -neqr /root/giac/2002.4.16 ether src 0:0:c:4:b2:33 |cut -d ' ' -f 
7|cut -d \. -f 1-4|sort |uniq -c|sort -rn

1292 64.154.80.51
517 64.154.80.50
383 147.208.133.112
158 24.128.12.243
57 64.4.12.204
56 64.4.12.174
37 64.12.137.56
32 216.239.33.101
24 209.10.78.199
(Rest omitted)

Source addresses coming from 0:3:e3:d9:26:c0:

$ tcpdump -neqr /root/giac/2002.4.16 ether src 0:3:e3:d9:26:c0 |cut -d ' ' -f 
5| cut -d \. -f 1-4|sort|uniq -c|sort -rn

47 255.255.255.255
36 208.177.5.232
24 193.231.96.42
24 164.164.60.11
13 203.155.237.173
(Rest Omitted)

Destination addresses coming from 0:3:e3:d9:26:c0:

$ tcpdump -neqr /root/giac/2002.4.16 ether src 0:3:e3:d9:26:c0 |cut -d ' ' -f 
7| cut -d \. -f 1-4|sort|uniq -c|sort -rn

99 78.37.212.28
94 78.37.212.165
24 78.37.180.227
(Rest omitted, hosts are all on 78.37.x.x subnet)

Cisco Cisco
External Network---- 0:3:e3:d9:26:c0 ----------- 0:0:c:4:b2:33------Internal 

Network 
78.37.x.x

Detect was generated by

I used Snort 2.1.2 (build 24) and the most current ruleset at time of the 
edition of this practical detect (April 13th, 2004). Stream4 was disabled as 
Ian Martin referenced in his practical following the advice of Daniel Wesemann 
(7)

The logfile was then run on Snort with the following command:

$snort -c /etc/snort/snort.conf -dek none -r 2002.4.16 -l detect1 -q 

Explanation of the commands used:

-c use following rule file
-dek d stands for dump application layer
e stands for display the second layer header info
k checksum mode 
(set to none)
-r read and process tcpdump file 
-l log to a directory (if none specified it goes to the default which is 
/var/log/snort)
-q quiet mode (you can choose to skip this one out if you are getting 
error messages)

(Source: Snort help file)

This command creates an alert file in the detect1 folder. The alert file 
contains for each event the signature against it triggered. Please note that I 
have also configured my snort to log in tcpdump format in parallel to the alert 
file so that I could use that for my research as well.

Next I determined which signatures triggered:

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

Browsing through the alert file I noticed interesting activity from source host 
193.231.96.42 targeting an internal host.

The alert file contains thee different snort alert types with source IP 
193.231.96.42 and destination IP 78.37.180.227 that caught my attention:

[**] [1:615:5] SCAN SOCKS Proxy attempt [**]
[**] [1:620:6] SCAN Proxy Port 8080 attempt [**]
[**] [1:618:5] SCAN Squid Proxy attempt [**]

Finally, I ran tcpdump -v -r 2002.4.16 -nn host 193.231.96.42 or host 
78.37.180.227, which gave me the following log trace. I removed manually the 
bad checksum messages as the original checksums have been altered.

06:05:47.614488 193.231.96.42.2722 > 78.37.180.227.1080: S 
1259629854:1259629854(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 59707, len 
60)
06:05:50.614488 193.231.96.42.2722 > 78.37.180.227.1080: S 
1259629854:1259629854(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 59708, len 
60)
06:05:56.614488 193.231.96.42.2722 > 78.37.180.227.1080: S 
1259629854:1259629854(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 59709, len 
60)
06:05:57.734488 193.231.96.42.2746 > 78.37.180.227.1080: S 
1263049257:1263049257(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 4657, len 60)
06:06:00.724488 193.231.96.42.2746 > 78.37.180.227.1080: S 
1263049257:1263049257(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 4658, len 
60, bad)
06:06:06.724488 193.231.96.42.2746 > 78.37.180.227.1080: S 
1263049257:1263049257(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 4659, len 60)
06:06:07.824488 193.231.96.42.2771 > 78.37.180.227.3128: S 
1273701997:1273701997(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 43622, len 
60)
06:06:10.824488 193.231.96.42.2771 > 78.37.180.227.3128: S 
1273701997:1273701997(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 43623, len 
60)
06:06:16.824488 193.231.96.42.2771 > 78.37.180.227.3128: S 
1273701997:1273701997(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 43624, len 
60)
06:06:17.944488 193.231.96.42.2795 > 78.37.180.227.8080: S 
1283991188:1283991188(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 43370, len 
60)
06:06:20.944488 193.231.96.42.2795 > 78.37.180.227.8080: S 
1283991188:1283991188(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 43371, len 
60)
06:06:26.934488 193.231.96.42.2795 > 78.37.180.227.8080: S 
1283991188:1283991188(0) win 5840 0,nop,wscale 0> (DF) (ttl 40, id 43372, len 
60)
12:59:49.254488 193.231.96.42.1819 > 78.37.180.227.1080: S 
1729688885:1729688885(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 39334, len 
60)
12:59:52.244488 193.231.96.42.1819 > 78.37.180.227.1080: S 
1729688885:1729688885(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 39335, len 
60)
12:59:58.244488 193.231.96.42.1819 > 78.37.180.227.1080: S 
1729688885:1729688885(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 39336, len 
60)
12:59:59.674488 193.231.96.42.1843 > 78.37.180.227.1080: S 
1740193953:1740193953(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 12295, len 
60)
13:00:02.664488 193.231.96.42.1843 > 78.37.180.227.1080: S 
1740193953:1740193953(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 12296, len 
60)
13:00:08.714488 193.231.96.42.1843 > 78.37.180.227.1080: S 
1740193953:1740193953(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 12297, len 
60)
13:00:09.164488 193.231.96.42.1867 > 78.37.180.227.3128: S 
1743423800:1743423800(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 64867, len 
60)
13:00:12.154488 193.231.96.42.1867 > 78.37.180.227.3128: S 
1743423800:1743423800(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 64868, len 
60)
13:00:18.154488 193.231.96.42.1867 > 78.37.180.227.3128: S 
1743423800:1743423800(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 64869, len 
60)
13:00:19.574488 193.231.96.42.1891 > 78.37.180.227.8080: S 
1749964279:1749964279(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 11675, len 
60)
13:00:22.564488 193.231.96.42.1891 > 78.37.180.227.8080: S 
1749964279:1749964279(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 11676, len 
60)
13:00:28.574488 193.231.96.42.1891 > 78.37.180.227.8080: S 
1749964279:1749964279(0) win 5840 0,nop,wscale 0> (DF) (ttl 41, id 11677, len 
60) 

Probability that source ip address was spoofed

The probability of this scan being spoofed is very low, since this is a TCP 
connection, a 3-way handshake is required to enable communication, and if the 
source address was to be spoofed, the attacker would therefore never receive 
the SYN-ACK packet. There is a very low probability that the IP was spoofed, 
for example if the attacker is located somewhere in between the spoofed IP and 
the target, such as a router or gateway, in that case the information gathered 
could be used to do sequence number prediction, in order to establish the 3-way 
handshake, acting thus a man in the middle. But I doubt that the effort 
required for this is involved here.

Description of the attack

Based on the available data, this is probably a open proxy reconnaissance 
attack, because of the ports targeted (1080,3128 and 8080) but to be a 100% 
sure I would need access to the source host or attacker. 

Open proxies are interesting targets for spammers, hackers and crackers. They 
can be used to surf anonymously, to distribute spam, or to misuse to system to 
launch Distributed DOS attacks for example and last but not least the scan 
could also have been produced by open proxy fighters, who collect the proxy 
information to then create blocklists. (Source: 8) 
Since these devices are often just caching information and not logging, it 
makes it a perfect target for malicious activity (Sources: 9 and 10) 

An nslookup on the source ip from my laptop gives: ras-fe-a.brasov.astral.ro

The netblock belongs to CANAD Systems Network, a romanian ISP.

Inetnum: 193.231.96.0 - 193.231.96.255
netname: CANAD-NET-07
descr: CANAD Systems Network
descr: Bucharest Romania
country: RO
(Source: 11)

Attack mechanism

Looking a bit close at the packet information given by the logs, I noticed some 
characteristics about the attacker. The IP ID changes by one all the time, the 
windows size is 5840, the datagram length is 60. The TTL (40 and 41) could 
indicate that the original TTL was 64, which would mean that the packet 
traversed 24-25 hops. These are all indicators of the source being a Linux 
machine (12) although it is possible that the packets were crafted to hide the 
real identity of the attacker. 

The timestamps are interesting to look at
06:05:47.614488
06:05:50.614488
06:05:56.614488
06:05:57.734488
06:06:00.724488
06:06:06.724488
06:06:07.824488
06:06:10.824488
06:06:16.824488
06:06:17.944488
06:06:20.944488
06:06:26.934488
12:59:49.254488
12:59:52.244488
12:59:58.244488
12:59:59.674488
13:00:02.664488
13:00:08.714488
13:00:09.164488
13:00:12.154488
13:00:18.154488
13:00:19.574488
13:00:22.564488
13:00:28.574488

The milliseconds are always ending with an 4488 value. This would indicate that 
this either a batch job or some other kind of automated tool. The 7 hour 
interval between the first and second scan could be to try to evade IDS 
detection, on the other hand each attempt is too fast to remain undetected., 
this would then support the theory of seeing a automated scan here.
The scan was probably unsuccessful. According to the logs available (tcpdump, 
Snort), none of the hosts on the internal network responded to the SYN packets 
sent by the attacker. They are probably protected by some kind of client or 
hardware firewall/filtering device. It also probable that no Reset packets were 
sent leaving the attacker with empty hands. However, it could be that the 
return packets took another route over another part of the network (for example 
a dual-homed ISP connection), which the IDS cannot see, therefore I cannot be 
sure

Correlations

Dshield has no history of malicious activity from that host (Source:13)
Mynetwatchman has no history of malicious activity from that host (Source: 14)

Several postings and practicals of other GCIA students can be found on the 
subject (Sources: 15, 16 and 17).

An excellent result of open proxy abuse in a English newspaper (Source: 18) 

An example of a proxy scanner is: Open Proxy Checker (Source: 19). This is *nix 
based program which is very easy to use and entire lists op IP?s can be added.

This Proxys4all site has some very nasty tools for usage with open proxies, 
scanners, taking into account speed and availability, and preconfigured 
autoproxy files to switch on time availability among other things (Source: 20)

Evidence of Active Targeting

This attack might have been part of a broad network sweep. However I cannot be 
sure without having access to the source host. Fact is the source IP has not 
attacked any other IP?s on the network monitored by the IDS as far as the 
logfile analyzed is concerned. The attacker just scanned on the ports discussed 
which could lead to think that the attackers knew what he is looking for. On 
the other hand, there has been no other communication seen from the target 
host, so it is difficult to be sure that the target is indeed a proxy. 

Severity

Criticality:

A proxy server can be a valuable and critical asset for some companies. I am 
not sure about which services this host is providing as I have no response 
packets from the host in my logs. Also surfing the web is possible without 
using a proxy server, should they be compromised or DOS?ed, outbound Internet 
access is not necessarily affected. Therefore I will give it a 3. 

Lethality:

Any information on these servers that can be used for malicious purposes can be 
critical to the business of many companies. Also the impact that such a misused 
server can have on other individuals and other companies is high. Also a 
compromised server could lead to access on the internal network: 4 

System countermeasures:

I do not know whether there is host-based firewall running on the system nor do 
I have any configuration information about the destination host: 2

Network countermeasures:

The IDS detected and logged the attack. It is not clear whether the host 
responded to the attack, there is no trace in the logs about this, possibly the 
return packets have taken another route, which is not on the IDS segment and 
can therefore possibly not be detected by the IDS. It could also be that the 
next Cisco device or firewall on dropped the packets, but I do not have enough 
information to be sure: 3

Score: (3+4)-(2+3)= 7-5 = 2

Defensive recommendations

Should the company be using proxy servers, make sure that it cannot provide 
access to the internal network due to a misconfiguration. Make sure the proxy 
servers are fully patched. Also ensure that only authorized users are able to 
use these proxy services. Block inbound packets on ports 1080, 3128, 8080 on 
the perimeter if you do not need any inbound proxy services on your network or 
DMZ. Since the IDS detected the scan, it means it came through the first border 
router. If this not an ISP owned Cisco device, I would suggest to block the 
mentioned ports at this device (if this is solely a router), in order to have 
more cpu cycles on the firewall if this is a separate device. In this network 
topology, and seen the traffic, It could be that the second Cisco device (Pix 
firewall, router, switch) performs this action. 

Multiple choice test question

What could be the reason for a proxy scan?

1. Harvesting open proxies for spam
2. A Ringzero infected host looking for possible targets
3. A open proxy blacklist company
4. All of the above
Correct Answer: 4

References

1.ISC SANS website. URL: http://isc.sans.org/logs/raw/README(April 2004)
2.Harper, Patrick. ?Snort, Apache, PHP, MY SQL and ACID Install on RH9.0?. 
Version 4. Updated: 10/06/2003. URL: 
http://www.snort.org/docs/snort_acid_rh9.pdf (April 2004)
3.Martin, Ian. GCIA practical assignment. 
URL:http://www.giac.org/practical/GCIA/Ian_Martin_GCIA.pdf (April 2004)
4. Gordon, Les. GCIA practical assignment. URL: 
http://www.giac.org/practical/GCIA/Les_Gordon_GCIA.doc (April 2004)
5. Cormier, Andre. GCIA practical assignment. URL: 
http://www.giac.org/practical/GCIA/Andre_Cormier_GCIA.pdf (April 2004)
6. IEEE OUI and Company_id Assignments page. URL: 
http://standards.ieee.org/regauth/oui/index.html (April 2004)
7. Wesemann, Daniel. Posting on incidents.org . (Jan 20th 2003). 
URL:http://cert.uni-stuttgart.de/archive/intrusions/2003/01/msg00162.html. (May 
2004)
8.Distributed Server Boycott List. URL: http://dsbl.org/main (21 May 2004)
9.O'Neil King , Rawlson. URL: http://thewhir.com/king/open-proxies.cfm. (May 
2004)
10.Spam Links. ?everything you didn't want to have to know about spam?. URL: 
http://www.cit.cornell.edu/computer/security/openweb/ (May 2004)
11.Sam Spade website. URL: http://www.samspade.org (May 2004)
12.Bueno, Pedro. ?Passive OS Fingerprinting Update?. (Updated: 10th July 2003). 
URL: http://isc.incidents.org/diary.php?date=2003-07-10 (May 2004)
13.Dshield. URL: http://www.dshield.org/ipinfo.php. (May 2004)
14.Mynetwatchman website. URL: http://www.mynetwatchman.com/ (May 2004)
15.Larosa, Vjay. URL:http://www.dshield.org/pipermail/intrusions/2002-
December/006205.php (20th May 2004)
16.Montcalm, Erik. URL:http://cert.uni-
stuttgart.de/archive/intrusions/2003/11/msg00053.html (May 2004)
17.Chuvakin, Anton. URL: 
http://www.giac.org/practical/GCIA/Anton_Chuvakin_GCIA.pdf (20th May 2004)
18.Poulsen, Kevin. ?Lamo strikes again: WorldCom?. URL: 
http://www.theregister.co.uk/2001/12/06/lamo_strikes_again_worldcom/ (20 May 
2004)
19.Tokarev, Michael. URL: http://www.corpit.ru/mjt/proxycheck.html (May 20th 
2004)
20.Proxys4all. URL: http://www.proxys4all.com/tools.shtml (may 20th 2004)


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

                
---------------------------------
Do you Yahoo!?
Friends.  Fun. Try the all-new Yahoo! Messenger
_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions