[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect Mark Stingley

[Mark Stingley]

Here's my first one brethren.  Rip away.  :)

===============================================

Detect One “What is ! Q?”

Source of Trace

The source of this trace is from
http://isc.sans.org/logs/Raw/2002.10.14

	2002.10.14	987,764	Mon Apr 5 11:06:49 2004

The actual date of the capture as reported by Ethereal
is 2002-11-14.

The first thing I like to do in analysis of foreign
capture data is to build a set of text files with host
data.  Working with output manually keeps command
level skills fresher than continually relying on
prebuilt scripts or gui based applications.

For example:

ttcpdump -ennr 2002.10.14 | awk '{print
$2"\t"$4"\t"$11"\t"$13}' | tr -d "," | sed s/":$"//g 
> mac2ip.txt

Results in a base MAC address/ip address/port list to
work with:

Source MAC	Destination MAC	Source IP	Destination IP
00:00:0c:04:b2:33	00:03:e3:d9:26:c0
170.129.50.120.62872	64.154.80.45.80
00:00:0c:04:b2:33	00:03:e3:d9:26:c0
170.129.50.120.62872	64.154.80.45.80
00:00:0c:04:b2:33	00:03:e3:d9:26:c0
170.129.50.120.62873  	64.154.80.45.80

In this capture file, a total of 338 separate ip
addresses could be identified, but there are only two
MAC addresses, both associated with Cisco gear.  Since
we see only two MAC addresses for all traffic, it is
likely that this connection is a span port on a Cisco
switch, or a tap between the switch and router.

00:03:e3:d9:26:c0 is the MAC that can be associated
with Internet traffic, while the MAC 00:00:0c:04:b2:33
associates with a 170.129.xxx.xxx LAN.  My guess would
be that the former very well could be a 7xxx series
router, while the later is most likely a series 29xx
switch.

Detect Generation Method

Snort 2.1.2 (Build 25), backdoor.rules v1.34.2.6

>From the “alert_fast” output, we see a total of 18
alerts for “BACKDOOR Q”, which look like these:

11/14-10:29:14.826507  [**] [1:184:6] BACKDOOR Q
access [**] [Classification: Misc activity] [Priority:
3] {TCP} 255.255.255.255:31337 -> 170.129.172.186:515
11/14-10:32:53.016507  [**] [1:184:6] BACKDOOR Q
access [**] [Classification: Misc activity] [Priority:
3] {TCP} 255.255.255.255:31337 -> 170.129.132.79:515
11/14-10:49:26.156507  [**] [1:184:6] BACKDOOR Q
access [**] [Classification: Misc activity] [Priority:
3] {TCP} 255.255.255.255:31337 -> 170.129.129.188:515

All of the detects come from 255.255.255.255 port
31337 and target different 170.129.xxx.xxx hosts on
port 515.

Address Spoofing Probability

Going from the alert log to closer examination with
tcpdump, here is an excerpt of the traffic:

tcpdump -s 1514 -nnvvr 2002.10.14 src host
255.255.255.255

10:29:14.826507 IP (tos 0x0, ttl  15, id 0, offset 0,
flags [none], proto 6, length: 43)
255.255.255.255.31337 > 170.129.172.186.515: R [tcp
sum ok] 0:3(3) ack 0 win 0 [RST cko]
10:32:53.016507 IP (tos 0x0, ttl  15, id 0, offset 0,
flags [none], proto 6, length: 43)
255.255.255.255.31337 > 170.129.132.79.515: R [tcp sum
ok] 0:3(3) ack 0 win 0 [RST cko]

The source IP is spoofed as 255.255.255.255, and the
Reset flag is set (RST) which should quench any
response from the target host.

Attack Description

Excerpted from the Snort.org rules search:

   GEN:SID 1:184
   Message BACKDOOR Q access

   Summary: Q is a Trojan Horse offering the attacker
remote access to the
   victim host. This event is generated when raw TCP
packets are sent to the
   victim server.

   Impact:  Possible theft of data and control of the
targeted machine leading to
   a compromise of all resources the machine is
connected to.
 
Following the Snort rules reference to
whitehats.com/info/IDS202, I decided to Google for
"TROJAN-ACTIVE-Q" and discovered the excellent paper
by by Les Gordon "What is the Q Trojan?":

http://www.sans.org/resources/idfaq/qtrojan.php?printer=Y

But, after carefully reading Mr. Gordon's detailed
explanation of the inner workings of “Q” and the lack
of similarity to the traffic I had found, I decided to
search further.

I found numerous references in GCIA practicals and
security newsgroups regarding such packets.  The
overall judgment was that whatever this traffic is, it
is NOT the “Q” trojan.

But, I did find one mention on the internet that
seemed to explain the packets themselves.  A Google
query for “RST cko” pointed me to Sonicwall and
something they call “Connection Cache Clean Up”.

In this documentation, Sonicwall makes it quite clear
that there are many situations wherein their appliance
will send RST packets to both an “initiator” and a
“responder”.  Based on the observed behavior of the
packets, I would guess that this sensor detected
packets from a Sonicwall appliance generated by the
following criteria, “IPS - Intrusion Prevention
Services dropping a connection. “

Very simply, this “attack” is merely the response of a
Sonicwall appliance to packets it thinks originated
from the 170.129.xxx.xxx network.


Attack Mechanism


The attack itself likely comes from a compromised
host.  This attacker, which we will call
SpoofHost31337 generates an attempted print spooler
exploit toward Target515, which are several different
hosts on the 170.129.xxx.xxx LAN.

SpoofHost31337 has additionally told Target515 that
its IP address is that of RealHost31337, which is
behind a Sonicwall appliance.

Our LAN target sends some kind of response to the
spoofed IP address.  Since we don't have a full
capture of all traffic for the LAN, we don't know what
the traffic was.  We can only assume that it was of a
nature that elicited a response from the Sonicwall.

The Sonicwall sent an RST packet to the “initiator”
with the data payload of “cki” to inform the
misidentified source of the traffic that the
connection should be dropped.   At the same time, it
told Target515 (“responder”) to drop its connection by
sending an RST packet with the data payload of “cko”.

The other alternative is that SpoofHost31337 IS
actually behind the Sonicwall and was detected trying
to exploit Target515.

Correlations

Sonicwall RST packet use:

http://www.sonicwall.com/services/pdfs/technotes/SonicOS_TCP_RST.pdf

Source port 31337 misuse:

http://www.sans.org/resources/idfaq/oddports.php

Port 515 LPRng/lpd vulnerability:

http://www.sans.org/resources/malwarefaq/LPRng.php
http://www.snort.org/snort-db/sid.html?sid=302


Evidence of Active Targeting

It's very hard to tell what is really going on here
because we only have responses from a Sonicwall
appliance, and it clues us only to the source port and
target host/port.

It is highly likely that random hosts on the
170.129.xxx.xxx LAN were at the least scanned by
either a host behind the Sonicwall, or one spoofing a
host behind it.

It is possible that the true source of the port 515
traffic was simply attempting the LPRng/lpd exploit on
every host it could find.

To say there was active targeting would be, at best,
conjecture.

Severity

Criticality: 0	The packets in question aren't an
attack, only informative
Lethality: 0	No damage can be done by the occasional
Sonicwall packet
System Countermeasures: 0	Not needed
Network Countermeasures: 0	Not needed

Severity = 0

In essence, this is a false alarm.

Defensive Recommendation

Naturally, true attacks on port 515 should be defended
against, and no router should ever permit inbound
connections to printers from the Internet.

In addition, all systems within the defensive
perimeter should constantly be in a state of stable
upgrade.

All hosts and servers that do printing for the LAN
should have security in place to allow only authorized
access (firewall, acl, etc.).

Lastly, it might be a good idea to take a close look
at IDS rules that can be updated to identify traffic
that matches RST responses from vendors such as
Sonicwall and ISS.  At least with Sonicwall, the
published RST packet data payloads are a dead giveaway
as to the source, even if the Sonicwall does spoof as
source of 255.255.255.255 to retain anomonimity.

Multiple Choice Test Question

What steps should be taken in intrusion analysis to
ensure that traffic can be properly identified?

A.  Research IDS signatures to become familiar with
the detection.
B.  Investigate other information regarding the
addresses and ports.
C. Google for other unique characteristics of the
packets for clues. 
D. All of the above.  

Answer:  D.

=====



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com