[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect Michael Meacle

[Mohan Chirumamilla]

Mike, 

Thanks for the extra information that you have provided.  It's very informative.  Regarding our discussions,  I have breifly glanced through your traffic logs and I think 32.245.166.236 is a HTTP proxy server for the internal network and the other IP address 32.245.166.119 is that of a web server (possibly).  Check out the ports in the headers. The traffic streams going to the other 134 internal addresses from the external router (0:3:e3:d9:26:c0), I guess, are either SYN or FIN scans targeted to specific ports (8080,3128,515 etc)...I just want to bring this to your notice...ignore my comments if you think they don't make any sense.
 
Thanks
Mohan
 
mtvpm <mtvpm at bigpond.com> wrote:
Mohan,

Thanks for the questions.

1.Sorry for being a little too terse thus your need
to highlight a gap in my reasoning, not to mention a
error in my document which I found while trying to
check my logic.

First my error, In my numbering of the fields I
didn't count the '>', this would confuse you if you
were looking back at its field references. See below
the amended field numbering.

Field 8: Destination IP Port
Field 9: Flags
Field 10: Seq Numbers

Now as for how I concluded that only two host were
'effectively' talking to the internet is based on
analysing the flows. Least just consider the
32.245.x range.

- We have 2 (Source IP Addresses) with a destination
mac of 0:3:e3:d9:26:c0. (remember we only had two
mac's so we can infer that the destination mac
address is the above because it can't be
0:0:c:4:b2:33 - a review at the raw data confirms this)
- We also have 134 (Destination IP Addresses) with a
source mac of 0:3:e3:d9:26:c0.

So by focusing only on the one mac address we can
see only 2 addresses going to, yet 134 coming from it.
The primary reason why we see 134 incoming address I
believe is we own all 65535 (based on the fact that
134 addresses were randomly spaced across the
B'class range) address and over the capture period
134 were scanned from the internet. In addition the
reason we only see 2 addresses flowing in both
directions (in this capture) is they (at present)
are the only valid (active) i/c and o/g real addresses.


2. While trying to analyse the raw records around
the records of interest I noticed the variation. The
primary reason I noticed the variation was that I
was trying to verify the OS (against the 304 error
messages) so that I could compare it against well
known values as outlined in the Sans training
material "Network Traffic Analysis - Using Tcpdump
parts 1 & 2 p4-24&25. If you don't have access to
the material have a look at
http://project.honeynet.org/papers/finger/traces.txt . 

When I noticed the variation I had to explain it.
The only two ideas I could come up with were NAT or
crafted packets. As I believed it unlikely the file
would have been full of crafted packets, the fact
that I could see so much traffic from the one host
and the fact that NAT'ng is commonly done by
enterprises to hide their real internal addresses. I
played the odds. 

I wasn't sure what should happen at a nat'ng device,
or in fact whether they all act the same (unlikely),
e.g.
- do they set the ttl to some predefined value e.g.
to values as outlined in the honeynet paper 
- do they decrement by 1 
- do they leave it alone
I didn't know but I went with the second one as I
believed it to be the safest against asymmetrical
routing loops. As such it was the only way I could
explain the 4 grouped ttl values.

As a result of your question I consulted google
..... again. I have found a very interesting article
by Peter Phaal (http://www.sflow.org/detectNAT/)
which outlines his concept of detecting unauthorised
NAT devices. His article (thankfully) confirms that
what I observed is probably nat'ng. In his article
he refers to another article by Steven Bellovin
(http://www.research.att.com/~smb/papers/fnat.pdf)
it outlines a further (some what more complex) way
of doing it based on ip-id. Due to the fact I'm
running very late on my assignment I have only
skimmed both articles but both appear to confirm
that nat'ng was taking place. 

I'm glad you challenged so now we both know two new
ways.

Out of interest while doing my other detect's I
refined the way of counting each TTL's as on my 3rd
detect (due to some strange packets) I was getting
erratic results. For you convenience here is the
better command.
tcpdump -nner 2002.9.27 -v "ether src 0:0:c:4:b2:33
and src host 32.245.166.236" | perl -ne 'print
"$1\n" if { $_ =~ /.*\((ttl\s\d.*?)\D/ };' | sort |
uniq -c 
8 ttl 122 
64 ttl 124 
8 ttl 125 
112 ttl 240 

Hope that helps
Mick 


Mohan Chirumamilla wrote:

Michael,

May be it is obvious, but I am missing something
here and would appreciate if you could help me out
with the following two questions.

1. Your analysis shows that there are possibly two
hosts 32.245.166.119 and 32.245.166.236 talking to
the Internet. 

Unique Source IP addresses from MAC 0:0:c:4:b2:33 
[root at snort captures]# tcpdump -nner 2002.9.27
"ether src 0:0:c:4:b2:33" | awk '{print $6}' | awk
-F\. '{print $1 "." $2 "." $3 "." $4}' | sort -n | uniq
32.245.166.119
32.245.166.236
[root at snort captures]#

And here, the numbers show that there are more than
two hosts participating from within the 32.245.0.0
address range. 

Unique Destination IP addresses from MAC 0:3:e3:d9:26:c0
[root at snort captures]# tcpdump -nner 2002.9.27
"ether src 0:3:e3:d9:26:c0" | awk '{print $8}' | awk
-F\. '{print $1 "." $2 "." $3 "." $4}' | sort -n | uniq
32.245.10.231
32.245.135.248
32.245.141.246

32.245.87.215
[root at snort captures]#

In a normal TCP session, traffic flows in either
direction almost symmetrically. What I meant by
symmetric is that, for every data packet received
the receipent sends an ack back to the sender
(assuming that there's no loss of packets at all). 
So that being said, should,'t we be seeing almost
the same hosts on each of your lists you described
above. I agree that it might not be the case if we
are talking about UDP. I did not take a look at the
dump yet. But to me that case is a bit unusual.

One possible reason could be is that all hosts in
the second list could be sitting in between the two
routers. But having 134 hosts in a "DMZ" like
set-up is again....little bit unusual.

2. You derived through your analysis that there
could be a NAT'ing device (32.245.166.236). Can you
please throw some more details on how the study of
TTL field contributed to your decission? Based on
your analysis, and assuming that my "possible
reason" that I mentioned above is ture.....I got an
impression that the source IP addresses are not
being modified during the NAT'ing process. Is this
correct?




As part of my attempt to obtain GCIA certification I
(gladly) submitt the following as my analysis for
analysis by the guru's.


Please be frank I wont be offended.

And I do appreciate your feedback.

b.t.w. you may, in places find the format a little
hard going. Them the breaks when converting from
word to flat ascii then compounded by web mail.
I'm sorry I have tried to make the format readable
.... trust me it is much easier to read in word.


1. Detect #1 .htaccess access

Extract from /tmp/alert
[**] [1:1129:4] WEB-MISC .htaccess access [**]
[Classification: Attempted Information Leak]
[Priority: 2]
10/27-10:45:29.116507 210.186.62.136:1361 ->
32.245.166.119:80
TCP TTL:108 TOS:0x0 ID:29485 IpLen:20 DgmLen:529 DF
***AP*** Seq: 0xC4BF5 Ack: 0xBA2B05FE Win: 0x2180
TcpLen: 20

1.1 Source Of Trace:
The raw log file was obtained from
http://www.incidents.org/logs/Raw/2002.9.27 . As
numerous students have previously pointed out before
the logfile timestamp and records contained within
don’t match. In fact according to tcpdump the actual
period is for 27/10/2002.

Determining range of records in the capture
[root at snort captures]# tcpdump -n -r 2002.9.27 -tttt
10/27/2002 00:05:29.746507 255.255.255.255.31337 >
32.245.78.8.printer: R 0:3(3) ack 0 win 0

10/27/2002 23:55:02.596507 32.245.166.236.65048 >
63.88.212.154.http: P 546101877:546102810(933) ack
3748866716 win 64601 [tos 0x10]

Lets determine the likely network topology. This
will allow us to set the snort HOME_NET thus
enabling snort to be more accurate. The analysis
process I have used to determine the network
topology is based on the process used by Chris
Reining[1 ]. First we need to determine how many
devices snort can see, this is achieved by
determining how many unique source and destination
MAC addresses are in the capture.

Number of unique Source MAC addresses in capture
[root at snort captures]# tcpdump -ner 2002.9.27 | awk
'{print $2}' | sort -u
0:0:c:4:b2:33
0:3:e3:d9:26:c0

Number of unique Destination MAC addresses in capture
[root at snort captures]# tcpdump -ner 2002.9.27 | awk
'{print $3}' | sort -u
0:0:c:4:b2:33
0:3:e3:d9:26:c0

In both cases we only have the same two mac’s so it
is fair to assume that snort is located between
these two network elements. For completeness lets
determine which vendor the mac’s belong too[2].

Extract from IEEE OUI and Company ID Assignments
00-00-0C (hex) CISCO SYSTEMS, INC.
00000C (base 16) CISCO SYSTEMS, INC.
170 WEST TASMAN DRIVE
SAN JOSE CA 95134-1706
00-03-E3 (hex) Cisco Systems, Inc.
0003E3 (base 16) Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA 95134
UNITED STATES

It is unlikely we will be able to determine the
actual network addresses belonging to these two
mac’s however by further analysing flows between
them we should be able to determine, with reasonable
certainly, our internal network range. To do this we
will use a number of Unix utilities to group various
fields of each tcpdump.

Below is the anatomy of the first record within the
capture. I have highlighted and numbered each import
field. This is a handy reference in future grouping
commands.

Anatomy of Tcpdump output of first record
[root at snort captures]# tcpdump -nner 2002.9.27 -c 1
10:05:29.746507 0:3:e3:d9:26:c0 0:0:c:4:b2:33 0800 60:
255.255.255.255.31337 > 32.245.78.8.515: R 0:3(3)
ack 0 win 0

If we use space as separator we get: (this is color
coded in word)
Field 1: Time
Field 2: Source MAC
Field 3: Destination MAC
Field 4: Ethernet Frame Type
Field 5: Packet Length
Field 6: Source IP Port
Field 7: Destination IP Port
Field 8: Flags
Field 9: Seq Numbers
etc 

First we will determine how many different source
addresses originate from each mac address.

Unique Source IP addresses from MAC 0:3:e3:d9:26:c0
[root at snort captures]# tcpdump -nner 2002.9.27
"ether src 0:3:e3:d9:26:c0" | awk '{print $6}' | awk
-F\. '{print $1 "." $2 "." $3 "." $4}' | sort -n | uniq
24.167.47.7

218.234.199.77
255.255.255.255
[root at snort captures]

#29 in total

Unique Source IP addresses from MAC 0:0:c:4:b2:33 
[root at snort captures]# tcpdump -nner 2002.9.27
"ether src 0:0:c:4:b2:33" | awk '{print $6}' | awk
-F\. '{print $1 "." $2 "." $3 "." $4}' | sort -n | uniq
32.245.166.119
32.245.166.236
[root at snort captures]#

2 in total

Second we will determine how many different
destination addresses originate from each mac address.

Unique Destination IP addresses from MAC 0:3:e3:d9:26:c0
[root at snort captures]# tcpdump -nner 2002.9.27
"ether src 0:3:e3:d9:26:c0" | awk '{print $8}' | awk
-F\. '{print $1 "." $2 "." $3 "." $4}' | sort -n | uniq
32.245.10.231
32.245.135.248
32.245.141.246

32.245.87.215
[root at snort captures]#

134 in total

Unique Destination IP addresses from MAC 0:0:c:4:b2:33
[root at snort captures]# tcpdump -nner 2002.9.27
"ether src 0:0:c:4:b2:33" | awk '{print $8}' | awk
-F\. '{print $1 "." $2 "." $3 "." $4}' | sort -n | uniq
61.145.114.153
61.145.114.156

216.33.240.250
[root at snort captures]#

22 in total

>From this it would appear that our internal range is
32.245.0.0/16. In addition by looking at the profile
of source ip addresses originating from within it
would appear that a nating device is being used 
(32.245.166.236). This is further confirmed when we 
observe variation in ttl’s originating from this ip 
address.

Profile of Source IP addresses
[root at snort captures]# tcpdump -nner 2002.9.27
"ether src 0:0:c:4:b2:33" | awk '{print $6}' | awk
-F\. '{print $1 "." $2 "." $3 "." $4}' | sort -n |
uniq -c
3 32.245.166.119
192 32.245.166.236

Profile of TTL of Source NAT address
[root at snort captures]# tcpdump -nner 2002.9.27 -v
"ether src 0:0:c:4:b2:33 and src host
32.245.166.236" | cut -f2 -d'>' | cut -f2 -dl | cut
-f1 -d',' | sort | uniq -c
8 122
64 124
8 125
112 240

Where for example 8 is the record count and 122 is
the actual ttl.

Below is what I believe is the likely network
topology extracted from this capture. I have used it
as the basis for the rest of the analysis.

Basic Network Layout:
** Internet **
|
*******************
* Cisco Device *
* 0:3:e3:d9:26:c0 *
*******************
|
**************** *********
* Hub / Switch * <--- * snort * 
**************** *********
|
*****************
* 0:0:c:4:b2:33 *
* Cisco Device *
*****************
|
****************** Note This could be done on the
above router
* NAT Device *
* 32.245.166.236 *
******************
|
*******************
* Rest of Network *
* 32.245.0.0/16 *
*******************

1.2 Detect was Generated by:
The detect was generated by Snort Version 2.1.2 (
Build 25), using a default rule set and a
command-line specified HOME_NET.

Snort Command Line Used:
[root at snort captures]# snort -b -l /tmp/ -c
/etc/snort/snort.conf -r 2002.9.27 -k none -h
32.245.0.0/16

The rule, which triggered the alert, is part of the
standard snort install and can be found in the file
web-misc.rules.

The Snort Rule Matched:
[root at snort snort]# grep ".htaccess" web-misc.rules
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS (msg:"WEB-MISC .htaccess access";
flow:to_server,established; content:".htaccess";
nocase; classtype:attempted-recon; sid:1129; rev:4;)

1.3 Probability the source address was spoofed:
It is very unlikely that the source address is
spoofed. First as this a reconnaissance so the
attacker needs to obtain the response. Second for
this attempt to work it has to be part of an http
connection and thus a established TCP connection. It
is very hard to spoof 3-whs to establish a TCP session.

1.4 Description of attack:
Any avid user of the Internet would have on
occasions been prompted for a username/password to
access a protected document. While there are any
number of ways to challenge for a username/password
one common way is known as “Basic”. Some web
servers, apache[3] for example, commonly store a web
username/password in a flat file routinely known as
“.htaccess”.

Extract of sample “.htaccess” file:
JDOE:rdtgHCcuBiMNU
FRED:v5.MvYkEMeNTY
MARY:dk4MhtlsoUiba
WILMA:NejKl2naRtwkM

The format of the file is line-delimited
username:encrypted-password. Where, by default, the
standard Unix crypt is used to encrypt the password.
Since the weak Unix crypt algorithm is used any
standard Unix brute force password cracker can be
run against the file. For example and effective tool
would be “John the Ripper”[4].

Once the brute force cracker has been run directly
against the file the resulting clear text
username/passwords can be used to freely access the
‘protected’ documents.

1.5 Attack Mechanism:
When an attacker wishes to obtain unfretted access
to a username/password protected site his number one
objective is to obtain any valid username/password.
One common way to do this is to obtain a copy of the
file that stores all valid usernames/passwords. Due
in part to sysadmin’s following documentation to the
letter, this file generally has a common name
“.htaccess”.

Thus a hacker will commonly try to download the said
file so he can brute force it offline. The
preference is to download the file as generally
brute force cracking tools will run much faster
offline. In addition the larger log files on the
actual web site may cause concern to an alert sysadmin.

The snort alert was triggered as a result of seeing
content “.htaccess” in a established flow to a web
server.

So in a nutshell we have:
Who: attacker at 210.186.62.136
What: wants a copy of .htaccess file which contains
username / passwords
Why: so that he can brute force crack them offline
When: 27th October 2002 at 10:45am
Where: from a internal web server 32.245.166.119
How: The file can be downloaded and saved using a
standard web browser. 

1.6 Correlations:
As of 30th May, 2004 dshield.org does not have any
reports against this address; remember the capture
was taken in 2002.

Brian Coyle a fellow GCIA student has also
previously analysed a similar trace[5].

And a reference is the snort signature database.[6]

1.7 Evidence of active targeting:
There are a total of 3 relevant records in the
capture. Snort with standard rules only detects two
of them. In fact these 3 records are the only
occurrence of the source address in all of the
capture files contained within the Raw directory.

Tcpdump of all matching source records:
[root at snort captures]# tcpdump -nner 2002.9.27 
"host 210.186.62.136"
10:45:29.116507 0:3:e3:d9:26:c0 0:0:c:4:b2:33 0800
543: 210.186.62.136.1361 > 32.245.166.119.80: P
805877:806366(489) ack 3123381758 win 8576 (DF)
10:45:29.906507 0:3:e3:d9:26:c0 0:0:c:4:b2:33 0800
590: 210.186.62.136.1361 > 32.245.166.119.80: .
489:1025(536) ack 793 win 8576 (DF)
10:55:28.146507 0:3:e3:d9:26:c0 0:0:c:4:b2:33 0800
1075: 210.186.62.136.1437 > 32.245.166.119.80: P
3774972488:3774973509(1021) ack 1430629 win 32696
[tos 0x10]

The second record is a retransmit of the first
record with an invalid basic authentication record
attached; it resulted in the following snort alert.
It was transmitted some 790mSec latter.

Snort Alert generated by second record:
[**] [1:1260:6] WEB-MISC long basic authorization
string [**]
[Classification: Attempted Denial of Service]
[Priority: 2]
10/27-10:45:29.906507 210.186.62.136:1361 ->
32.245.166.119:80
TCP TTL:108 TOS:0x0 ID:33581 IpLen:20 DgmLen:576 DF
***A**** Seq: 0xC4DDE Ack: 0xBA2B0916 Win: 0x2180
TcpLen: 20
[Xref => http://www.securityfocus.com/bid/3230]

The third record, although snort isn’t concerned is
interesting for a couple of reasons. First it has
the unusual ip.id of zero. Second is that it’s ttl
is 240 where as the two previous records were 108.
The main difference is that it is trying to download
“logos.html” instead of “.htaccess” in the same
directory structure.

I believe it is active targeting. The fact that
“.htaccess” was requested is enough in itself,
coupled with different ttl then something strange is
going on.

1.8 Severity:
Criticality: 4 It is hard to determine how important
this asset is without knowing exactly what its
business purpose of the server is, that aside it is
a internet connected web server with some form of
password-protected documents. Thus by inference it
must be reasonably important.

Lethality: 5 If this file is obtained the impact can
be disastrous. Other alerts from the capture file
indicate that this server is a Redhat Linux server
running Apache with Frontpage extensions. In
addition the second and third records have basic
authentication credentials embedded in the requests
inferring that authentication is needed to access
this server. 

System Countermeasures: 2, This is very hard to
determine without knowledge of how well the server
has been maintained. Since I can find no alerts
originating from this server except 68 “Attack-
Responses 403 Forbidden” one can assume it has been
installed and maintained correctly. That was until I
took one takes into consideration the version of
Apache. The “403 messages” indicated Apache 1.3.12
is being used. A quick google indicates Apache was
officially up to version 1.3.27 as at Oct 3 2002
[7]. I have assumed that the syadmin has not
over-ridden the http response header.

Network Countermeasures: 1, http is a permitted
protocol to this host and thus the web server has
been afforded no protection by firewall or border
routers.

(4+5) – (2+1) = 6

1.9 Defensive Recommendations:
As outlined in Snort signature database one should
first determine if the page can be successfully
downloaded. If it can then escalate the event to a
incident and manage.

One should then ensure all servers within your
organisation are configured correctly to restrict
access to any files containing username/passwords.
The snort signature database indicates how to do it
for files starting with “.ht” Use it as a basis for
blocking any relevant files.

Preventing Access to .ht* files in Apache:

Order allow,deny
Deny from all


It generally is also be more effective to offload

=== message truncated ===
		
---------------------------------
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.