LOGS: GIAC GCIA Version 3.5 Practical Detect James Affeld

This detect is going into my practical.  Comments
welcome.  

Source of Trace: a network I administer. 
 
Detect was Generated by: Snort v. 2.1.2 with a default
ruleset.  The alert was generated by the FLOW
preprocessor?s Portscan generator.  It generated the
following alert (one of many):

[**] [121:4:1] Portscan detected from foo.bar.101.51
Talker(fixed: 1 sliding: 30) Scanner(fixed: 0 sliding:
0) [**]

The source of the alert is given by the [121:4:1]
field in the alert.  The first element, whose value is
121, identifies the generator of the alert as
FLOW_PORTSCAN.  The second element gives the
particular alert for that generator, in this case
alert #4.  The third is the revision level of the
alert, this case #1 (the initial version - no
rewrites).  
(Explanation for this tag from Martin Roesch  to the
snort-users list, Thu, 28 Jun 2001 13:01:13 -0400.
http://www.mcabee.org/lists/snort-users/Jun-01/msg00668.html)

Rule # 4 is the  FLOW_TALKER_SLIDING_ALERT, which has
a variable format.  The alert gives the source IP
address and four statistics: Talker fixed, Talker
sliding, Scanner fixed, Scanner sliding.  Per the
Snort manual, 
(http://www.snort.org/docs/snort_manual/node17.html),
Talkers are ?nodes that are active on your network?. 
This does not mean that they are local hosts - they
can just be talking to local hosts.  Talkers are
involved in one host to many hosts scans.  Scanners
are ?nodes that have talked to a previously unknown
port in your server-watch-net.? Scanners are involved
in one host to many ports scans. ?Fixed? and ?sliding?
refer to timescales.  ?Fixed? means N events in M
seconds, ?Sliding? is a variable timescale whose size
is a function of the last packet received.  If there
are events over an interval, the program logic will
continue listening for an amount of time equal to that
interval times a sliding scale factor (.5 by default).
 The Snort manual gives the equation as:
        end = end + ((end - start) * sliding-scale-factor)
In more concrete terms, this means that if the sliding
scale logic is examining events 5 seconds apart, it
will continue listening for 5 + (5 * .5) = 7.5 seconds
before tallying up the final score that determines
whether the scan alert fires.  If more information
trickles in, the window can slide more until the
events are over or the threshold for an alert is met. 


The alert value for Talker(fixed: 1 sliding: 30) tells
us that the events scored the required number, 30, in
a sliding window.  This is not the number of hosts
scanned.  There are other factors involved.  For
example, you can set the flow-portscan generator to
increase the score for TCP flags associated with
scans, such as SYN-FIN and other unwholesome
combinations.   

So, to recap, the alert tells us that the source host
foo.bar.101.51 generated enough events to enough
different hosts (and/or events of such a quality),
within a sliding window of time, to warrant attention.
 

Probability the Source Address was Spoofed: 0.  This
incident presents a rare moment of certainty in the
intrusion detection field: I put my hands on the box
and saw, through the ipconfig command, that it had the
address I was looking for.  I also verified, through
the netstat command, that it was trying to connect to
a variety of remote hosts.  More generally, it is
difficult to spoof tcp connections, and the HTTP
protocol requires a correctly established tcp
connection.  So if the source were remote and the
destination local I would still be confident that the
address were not spoofed.  In this case most of the
3-way handshake is never completed because the
firewall(s) enforce a security policy prohibiting such
connections.  (See below)

Description of the Attack:
The source host was attempting to connect to external
proxy and web caching servers, in violation of the
local Security Policy.   Finding this out was a little
tricky.  The portscan alerts from the FLOW_PORTSCAN
don?t tell you in detail what the host is trying to
do.  

Fortunately, we had a tcpdump audit log machine going.
 This a suggestion made by Mike Poor who teaches the
Intrusion Detection class at SANS.  Basically, you
hook up a host with serious disk space and record 200
bytes of every packet that the host can see.  Once you
have the traffic going to the desired interface,
either via a switch span port or a network tap, the
command is: 

        tcpdump -ni em0 -w /var/log/tcpdump.log -s 200 ?<any
filters>?

I specify the -n (no DNS name lookup), -i em0 (use
interface em0), and -s 200 (capture 200 bytes of each
packet) -w /var/log/tcpdump.log (capture packets to
this file, not the screen).  The filters can reduce
the burden of logging if there is significant traffic
you don?t care about.  For example, specifying ?ip?
will lead it to ignore IPX traffic.

I won?t go into much detail about the uses of a
tcpdump audit box - suffice it to say that any time
you need more context for a Snort alert, you can go to
the audit and see.  If you have found that a host is
compromised, you can go back to the audit and see what
it was up to, and possibly how it got compromised.  

In this case, I was able to extract the information
relating to the affected host with the following
command, which reads in from the tcpdump.input.file
and outputs traffic to or from host foo.bar.101.51 to
tcpdump.output.file:

        tcpdump -r tcpdump.input.file -w tcpdump.output.file
?host foo.bar.101.51?

I could then play with a much smaller tcpdump file.  

I took a quick look at this file with the following
command:

        tcpdump -nvvvXr 101.51 | more

--vvv (very verbose output), -X (give me the asci
translation), | more (one screenful at a time)

This showed that there was a bunch of standard NetBIOS
traffic cluttering up my file.  I winnowed away the
chaff with successive commands like this:

        tcpdump -r 101.51.trim -w 101.51.trim2 'not host
x.y.96.5'

When I looked at this with the command:

        tcpdump -nvvvXr 101.51.trim2

I saw that the traffic was not a standard portscan. 
The host was establishing real http sessions, plus
some oddball things as well.  If it was a port scan,
I'd expect tons of syn packets to tons of hosts,
without much or any follow-up.  But there was
follow-up.  I also noticed that resets and icmp
destination host/port unavailable were very scarce, so
it wasn't contacting blind.  If it was a vulnerability
scan, I'd expect to see some garbage inputs sent to
the web servers contacted.  But the http sessions were
clean.  They were just more numerous than they had any
business being - 1 or two a minute all day long.

I looked a little closer and found it wasn't just port
80.  Sometimes it was port 443.  More interestingly, a
number of connections were to 3128, 6588, 8000, and
8080.  

I copied the file 101.51.trim2 to a workstation with a
graphical interface and opened it with ethereal. 
Ethereal has a great "follow tcp stream" option that
shows what transpires over a given connection.  This
is what it showed:

GET http://www.qksrv.net/image-1359099-10313584
HTTP/1.0
Accept: */*
Referer: http://www.google.com
Accept-Language: de
User-Agent: Mozilla/3.HTTP/1.1 200 OK
Date: Wed, 17 Mar 2004 22:59:45 GMT
Server: Resin/2.1.9
P3P: policyref="http://www.qksrv.net/w3c/p3p.xml";,
CP="ALL BUS LEG DSP 

Over and over, from different web servers.  

It seems very odd for a web client to submit a GET
request for a url on a different server.  As I
understand it, the browser should establish a separate
connection to the other web server to pull content
from there.  

I had a look at a connection to 8080, which is an
alternate web server port and sometimes a proxy
server.

GET http://www.qksrv.net/image-1359099-10313584
HTTP/1.0
Accept: */*
Referer: http://www.google.com
Accept-Language: de
User-Agent: Mozilla/3.HTTP/1.1 200 OK
Date: Wed, 17 Mar 2004 22:59:45 GMT
Server: Resin/2.1.9
P3P: policyref="http://www.qksrv.net/w3c/p3p.xml";,
CP="ALL BUS LEG DSP 

Aha! The web servers are being used as proxy servers. 
 

I got a text capture of the packets with 'qksr' in
them with the following command:

         tcpdump -nvvr 101.51.tcpdump 'ip[55:4] = 0x716b7372'
> www.qksrv.net.txt

ip[55:4]=0x716b7372 (give me all the packets where ip
packet bytes 55-58 =  0x716b7372, which is the hex
value for qksr, (ethereal very helpfully shows byte
position and value))

I got a count of how many times it loaded that file:

        grep -c ack www.qksrv.net.txt
        1472

So this host made this connection through various
hosts 1472 times during the period the tcpdump audit
log was collecting data.

To get the number of different hosts involved, I ran
this command:

        cat www.qksrv.net.txt | cut -f 4 -d ' ' | uniq -c |
sort | >  www.qksrv.net.count

cat www.qksrv.net.txt (print contents of
www.qksrv.net.txt to screen), | cut -f 4 -d ' '
(redirect output to cut command, get column 4, columns
are delimeted by a space),| uniq -c (redirect that
output through the uniq command - count how many of
each entry there are), | sort (sort the output).

To get a count of the hosts involved, I then ran this
command:

        grep -c : www.qksrv.net.txt.count

        1195

So this host has a list of close to 1200 working
proxies.  What's it doing with them?

http://www.qksrv.net/image-1359099-10313584 is a 1 x 1
pixel gif.  In other words, a 'web bug.'  These are
used to build profiles of users from data collected
from various sites. It is also used to track page
views.  For example, if a web page at
www.mywebsite.com contains an <img
src='http://www.qksrv.net/image-1359099-10313584'>,
when you load that page, qksrv knows you've been to
mywebsite.com.  Combine this with cookies, and all
kinds of privacy violations/user tracking is possible.
 

So why is this host loading this webbug through 1200
proxies?  Clearly the intent must be to register a
bunch of traffic.  Presumably someone is scamming an
online advertiser by inflating the number of hits
counted by the web bug. Since the requests are relayed
by proxies, it looks like distributed traffic. 
Presumably, the advertisers don't pay as much for page
views coming from one host.

Sample Server types (taken from server id in packet
captures):
webcache/2.3.STABLE
1.0 INDYNT5
1.1 proxyc4 (Netcache NetApp/5.1R2D22), 1.0
Storedeliver01
Resin/2.1.9 (fairly common - only duplicate in 10
tries) - 

Attacking Mechanism: 

The compromised host is loading a particular 1 x 1
pixel graphic file (a ?web bug?), through 1195 proxy
and caching servers.  The purpose is apparently to
make it seem as if those 1195 hosts are independently
loading the file.  That is to say, to distribute the 
apparent sources of traffic.

Unfortunately the host was re-imaged before any
forensics could be applied.  I can only speculate on
the mechanism by which the software was installed. 
The firewall was configured according to good design
principles, so initiating a connection from the
outside wouldn?t work.  That leaves compromise by
passively waiting for the host to connect.  This is
pretty common.  There are a variety of browser attacks
that a hostile web site could perform.  For just one
example, see Bugtraq #9658.
http://www.securityfocus.com/bid/9658/discussion/

Correlations: I didn?t see any in the first 100 pages
of a google search for the terms ??web bug? proxy?.  
There are a huge number of pages on defeating web bugs
by using proxies, and vice versa.  

Evidence of Active Targeting: The machine appeared to
have a list of targets to send the web bug load
requests through.  The IP addresses were not
sequential, they weren?t in order either.  Some worms
use random targeting, but the port match for this
attack was extremely high.  I saw no evidence of blind
fumbling for proxy servers; the few hosts that did
return RESET packets indicating closed ports were
consistent with the gradual drift of network
conditions.  Hosts come and go, and their
configuration evolves.  

I don?t believe the initial compromise was targeted,
as discussed above in the Attacking Mechanism section.
 I don?t have conclusive evidence for this.

Severity: Severity of the incident is given by the
formula:
severity = (criticality + lethality) - (system
countermeasures + network countermeasures)

This is a tricky question for this incident.  There is
the severity of the attack which compromised the host,
and there is the severity of the attack launched by
the host to/through/at the proxy and caching servers. 
They are separate questions, but I?ll treat them as
one anyway.

Criticality: run-of-the-mill workstation.  A 2 is as
low as I?ll go for something not on the scrap heap. 
Criticality = 2

Lethality: this box was owned.  The compromise
installed software that generated this traffic; it
could have done ANYTHING, including installing remote
access trojans and keyboard sniffers, up to and
including formatting the drive or launching a DOS
attack.  Lethality = 5

System Countermeasures: Failed.  The antivirus package
and operating system patches did not prevent the
attacks, .  Both were current, for a partial score,
but using a flawed OS loses points.  Not having a
host-based firewall and intrusion detection  reduces
its score as well.  System Countermeasures = 2

Network Countermeasures: this depends on perspective. 
The host was compromised, but after it was compromised
the network countermeasures greatly inhibited its
activities.  The network countermeasures succeeded in
spotting the pattern that revealed a compromised host.
 However, the network countermeasures did not prevent
the host from being compromised and they did permit
outbound connections to services that have no
legitimate use to the organization.  The firewall now
treats inside sources with almost as much skepticism
as external sources.  There is room for improvement,
if we employed a web proxy that could protect us from
webmail and hostile web code, that would be even
better. Network Countermeasures  = 3 

Severity = (2 + 5) ? (2 + 3) = 2

Defensive Recommendation: A proxy server for web
content would give us a chance to filter for virus
signatures.  Also:  re-image the machine.  (?Nuke the
site from orbit.  It?s the only way to be sure.?)  It
is unlikely that an outside entity could take
advantage of any back doors, but it is even less
likely after formatting the drive.   In this incident,
operations staff re-imaged the machine before I could
do any rudimentary forensics.  

Multiple Choice Question:

Which of the following could be used as a proxy server
port?

A: 8080
B: 80
C: 1080
D: 5755
E: All of the above

Answer: E.  D is not commonly used, but proxies are
often set up on non-standard port.  A, B, and C are
most common.

Epilogue:
I contacted Commission Junction to tell them about the
cheater, but they rejected my email because of a spam
blackhole list.  So their business model is to spew
web bugs all over the internet, but they don't want
spam going THEIR direction.  No, no, no.  





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