[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect MarkStingley
Smith, Donald
Donald.Smith at qwest.com
Mon Sep 20 15:50:10 GMT 2004
First catching the sonicwall reference was great.
You have done a good job. I have added a few comments/questions.
Donald.Smith at qwest.com GCIA
pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC
Mistakes are not failures. Real failure requires lack of attempt.
> -----Original Message-----
> From: intrusions-bounces at lists.sans.org
> [mailto:intrusions-bounces at lists.sans.org] On Behalf Of Mark Stingley
> Sent: Saturday, September 18, 2004 8:18 PM
> To: intrusions at lists.sans.org
> Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical
> Detect MarkStingley
>
>
> 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
You might want to include -A to show the data.
>
> 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.
Why would someone spoof 255.255.255.255?
>
> 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.
LPD exploit attacks would be tcp therefore its unlikely someone would
spoof the source addr.
So the rest of this explaination doesn't track.
The use of 31337 and 515 might imply something else since those are both
WELL KNOWN bad ports.
I have a theory think about ips (esp ones that DO resets), and
fightback/strikeback/hackback.
What would it take to get two ips (or other strikeback systems) to
attack each other?
>
> 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.
You may loose points for an all of the above type answer. Check the
notes on this practical it has been a while since I read them but at one
time it stated something like 1 correct answer.
>
> =====
>
>
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
> _______________________________________________
> Intrusions mailing list
> Intrusions at lists.sans.org
> http://www.dshield.org/mailman/listinfo/intrusions
>
>
More information about the Intrusions
mailing list