RE: LOGS: GIAC GCIA Version 3.5 Practical Detect CoenBakkers

Nice work,

How might an attacker DOS this location by discovering that they have an
open proxy? 

Also, you mention in Lethality section that misusing a server can affect
other individuals and companies.  In what ways could this affect them?

Scott Renna CISSP/GCIA
Security Analyst

-----Original Message-----
From: intrusions-bounces@xxxxxxxxxxxxxx
[mailto:intrusions-bounces@xxxxxxxxxxxxxx] On Behalf Of
coen.bakkers@xxxxxxxxxxxxxxxxxxxxxxx
Sent: Tuesday, May 25, 2004 5:22 AM
To: intrusions@xxxxxxxxxxxxxx
Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect
CoenBakkers



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 <mss 1460,sackOK,timestamp 77366309 
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 <mss 1460,sackOK,timestamp 77366609 
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 <mss 1460,sackOK,timestamp 77367209 
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 <mss 1460,sackOK,timestamp 77367320 
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 <mss 1460,sackOK,timestamp 77367620 
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 <mss 1460,sackOK,timestamp 77368220 
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 <mss 1460,sackOK,timestamp 77368331 
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 <mss 1460,sackOK,timestamp 77368631 
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 <mss 1460,sackOK,timestamp 77369231 
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 <mss 1460,sackOK,timestamp 77369342 
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 <mss 1460,sackOK,timestamp 77369642 
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 <mss 1460,sackOK,timestamp 77370242 
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 <mss 1460,sackOK,timestamp 79850643 
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 <mss 1460,sackOK,timestamp 79850943 
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 <mss 1460,sackOK,timestamp 79851543 
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 <mss 1460,sackOK,timestamp 79851686 
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 <mss 1460,sackOK,timestamp 79851986 
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 <mss 1460,sackOK,timestamp 79852586 
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 <mss 1460,sackOK,timestamp 79852635 
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 <mss 1460,sackOK,timestamp 79852935 
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 <mss 1460,sackOK,timestamp 79853535 
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 <mss 1460,sackOK,timestamp 79853676 
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 <mss 1460,sackOK,timestamp 79853976 
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 <mss 1460,sackOK,timestamp 79854576 
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.htm
l. (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

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