[Intrusions] LOGS:GIAC GCIA Version 3.5 Pratical Detect DanteWinslow
Smith, Donald
Donald.Smith at qwest.com
Tue Nov 30 19:04:27 GMT 2004
Its not Q. Mark Stingley did a very good writeup on this event that
would be very hard to improve on.
Short version is the packets originated from a sonicwall firewall.
I would recommend you write up a different set of packets.
http://lists.sans.org/pipermail/intrusions/2004-September/008462.html
Donald.Smith at qwest.com GCIA
Defense In Depth is like ogres^h^h^h^hnions. It has layers.
> -----Original Message-----
> From: intrusions-bounces at lists.sans.org
> [mailto:intrusions-bounces at lists.sans.org] On Behalf Of
> dwinslow at steelersfan.net
> Sent: Tuesday, November 30, 2004 6:33 AM
> To: intrusions at incidents.org
> Subject: [Intrusions] LOGS:GIAC GCIA Version 3.5 Pratical
> Detect DanteWinslow
>
>
> Possible Q Trojan Backdoor Attempt
>
> SOURCE OF TRACE
> This trace is taken from the incidents.org raw log files and
> is dated 2002.724. This file is available from the following
> URL: http://www.incidents.org/logs/Raw/ .
>
> According to the README file in the directory. All logs have
> been obfuscated to remove any references to the protected
> networks, and the checksums were altered for the truly
> clever. Since little information is truly known about the
> network topology and its hosts, I will make some assumptions
> about them based on my analysis. I have assumed that the
> source IP address in this event is external to the protected
> network. Likewise I assumed that the packets are passing
> through an outside screening router of some sort or firewall
> into a DMZ area where a Snort IDS is position. This would
> allow the IDS to see traffic destined to and from the
> protected network.
>
>
>
>
> * *
> Internet-> **Router or Firewall-> Snort IDS-> *router or
> firewall-> Protected
> *Cisco 00:03:e3:d9:26:c0 *Cisco00:00:0c:04:b2:33
>
>
>
>
> DETECT WAS GENERATED BY:
>
> The packet analyzer tool Ethereal and a Snort IDS were used
> to evaluate this detect. The file 2002.724 was run against a
> Snort IDS and its signature rule set to see if a Snort alert
> would be triggered. The following command was used to parse
> the file against the Snort rule set and display it results on
> the console.
>
> snort -c /etc/snort/rules/snort.conf -r 2002.7.24 -v -N -A console
>
> The Snort alert "Backdoor Q Access" was triggered when
> evaluating the file. The packets that set off this alert all
> came from an apparent broadcast source IP address of
> 255.255.255.255 on source port 31337 directed at hosts of the
> protected network on destination port 515/tcp. Also, the
> Ethernet headers of these packets all contained the same MAC
> addresses. Moreover, the numbers on the time to lives (ttls)
> of these packets are relatively small, hop counts ranging
> from 12 to 15. These elements suggest that the attacker is on
> a network other than the protected network, but that network
> is also not far away from the protected network.
>
> Snort Rule:
> alert tcp 255.255.255.0/24 any -> $HOME_NET any
> (msg:"BACKDOOR Q access";
> flags:A+; dsize: > 1; reference:arachnids,203; sid:184;
> classtype:misc-activity; rev:3;)
>
> Example Alert:
> [**] [1:184:3] BACKDOOR Q access [**] [Classification: Misc
> activity] [Priority: 3] {TCP} 255.255.255.255:31337 ->
> MY.NET.164.100:515
>
>
> In addition to parsing the file against Snort, this binary
> log file was also filtered through Ethereal (Version
> 0.10.12). Filtering through Ethereal revealed 27 instances of
> logs with the source IP address of 255.255.255.255 and the
> source port of 31337. Conjointly these 27 instances all were
> destined for the protected network on port 515/tcp.
>
> Example Ethereal Dump:
>
> 08/24/02-22:05:30.964488 255.255.255.255:31337 -> MY.NET.164.100:515
> TCP TTL:14 TOS:0x0 ID:0 IpLen:20 DgmLen:43
> ***A*R** Seq: 0x0 Ack: 0x0 Win: 0x0 TcpLen: 20
> 63 6B 6F cko
>
>
>
>
>
> Each computer network interface card is allocated a globally
> unique 6-byte/48-bit link address when the factory
> manufactures the card. The first 3-bytes/24 bit of the MAC
> address identify the manufacturer. A tool at
> http://www.techzoom.net/nettools-macdecode.asp was used to
> interpret the first 24 bits. The results are as follows.
>
>
> Source Mac 00:03:e3:d9:26:c0 00-03-E3-D9-26-C0 Cisco Systems, Inc.
>
>
> Destination Mac 00:00:0c:04:b2:33 00-00-0C-04-B2-33 CISCO
> SYSTEMS, INC.
>
> POSSIBILITY THE SOURCE IP ADDRESS WAS SPOOFED:
>
>
> It is highly likely that the source IP address is spoofed.
> The source IP address 255.255.255.255 is a broadcast address.
> In using the broadcast address in normal network activity,
> the broadcast address of 255.255.255.255 is always the
> destination IP not the source IP. Furthermore the ACK and RST
> flag bits are set in all packets and the sequence numbers and
> acknowledgment numbers are all set to zero. These factors
> lead me to believe that these packets were was crafted.
>
>
>
> DESCRIPTION OF THE ATTACK
>
> "Q" is a remote access program created originally as a proof
> of concept tool by Mixter. One of the prominent features of
> this program is that it can act as a redirection server. In
> addition, it features remote shell access capability, can act
> as a relay server or bouncer with strong encryption and has a
> tunneling daemon. The dynamic design of this tool allows for
> syslog spoofing, activation via raw packets, and sessions can
> be configured to run on variable ports.
>
>
>
> ATTACK MECHANISM
>
> At first observation, this activity would suggest that these
> packets are to targeting printing services on hosts within
> this network. The Source IP address appears to be sending
> packets destined for port 515/tcp, which is used by LPD (Line
> Printer Daemon). In Unix flavors this print service daemon
> listens on TCP port 515 for print service requests.
> Furthermore, there are several security vulnerabilities
> associated with LPD, as listed in CERT Advisory CA-2001-30
> this fact alone could entice an attacker to scan for this
> service. How ever, the use of the broadcast address as the
> source address does not support this theory. If a host was
> found listening on this port there would be no way for the
> attacker to receive this information back because the source
> IP is 255.255.255.255 and not a viable return address.
> Conversely, the Q Trojan is highly configurable and can
> accept incoming encrypted traffic on any port via any RAW IP
> socket it is configured for using any configurable source IP
> address. Raw IP sockets can be TCP, UDP, or ICMP protocols.
> This traffic is very likely raw IP traffic generated by a "Q"
> Trojan client, which is scanning and communicating with
> servers. The attacker used multiple methods of obfuscating
> his/her true intentions. The methodology started with
> designing crafted packets from a broadcast source address
> (255.255.255.255) on port 31337. This port is used by a
> backdoor program/remote administration tool called Back
> Orifice. Ironically the numbers "31337" is the hacker
> spelling of the word elite "eleet". These methodologies
> continue with packets seemly targeted against internal
> addresses on port 515, normally used by the LPD daemon which
> has multiple known vulnerabilities. These covert actions are
> being used to disorient and distract security analyst and
> network administrators and to false trigger poorly configured
> intrusion detection systems. Lots of IDS use port based
> signatures. These packets can cause at least 2 port based
> signature alerts to fire. To an ill trained analyst or
> engineer this can delay response time. So in this case there
> are 27 packets that could cause a minimum of 54 alerts to be
> generated on the ports used alone. Because administrators and
> analyst are pursuing these alerts this allows the attacker
> time to send encrypted commands to listening servers.
> Subsequently, the packets are crafted to attempt to bypass
> perimeter firewalls and poor policies as well. Many firewalls
> and firewall policies will allow packets containing ACK
> and/or RST through because it is believed to be part of an
> established TCP session. Moreover some firewalls' policies
> may also allow the source IP address of 255.255.255.255
> through the perimeter because that address is not blocked and
> it is unexpected on the network. These packets may not elicit
> any response from these devices because they may appear to be
> normal activity coming from an internal host. Equally
> important a stateful firewall will add any connection
> information into it's state table allowing return traffic
> through. Since the source packet is a non-standard packet, it
> should not elicit an ICMP error message either. Ultimately
> the attacker signals for listening clients via RAW IP
> traffic. Upon receiving a special encrypted message
> containing commands the listening client responds. In this
> case it is unclear what those commands are. It is very likely
> that the payload listed in these packets 'cko" could be
> execution commands compiled by the attacker. A payload like
> this could request actions, such as opening a SSL encrypted
> connection back to a particular address or opening a shell on
> a specified port. The use RAW IP sockets by the Q remote
> administration program enables the attacker to eliminate the
> establishment of a traditional tcp - handshake type session.
> The "Q" system is based on the executing command string
> embedded in the packets and a "Q" client is always listening
> for traffic destined for it. Lastly, this program is an open
> source application which could have been re-compiled and
> specifically tailored for the attacker needs or have use
> plug-ins to enhance its capabilities.
>
>
> Severity:
>
> Severity = (Criticality + Lethality) - (System Countermeasure
> + Network
> Countermeasure)
>
> Criticality - (3) The targets identified could be vital
> workstations or servers. If these machines have Q clients
> listening for commands they could be used to attack other
> hosts or mission critical information stored on them could be
> readily compromised.
>
> Lethality - (5) Though the exact make up of these machines
> and its network is unknown a compromised critical system
> could have monumental consequences. This includes seizure of
> proprietary and sensitive information, infection of other
> hosts, and use of compromised machines in a denial of service attack.
>
> System Countermeasure - (3) Without additional information on
> this version of the Trojan it would be difficult at best to
> protect any host. Installing host based IDS systems, spy ware
> detection applications, antivirus, and configuration
> monitoring and assessment tools would be the best possible
> answers at this time.
>
>
> Network Countermeasure - (3) Blocking the source address at
> the perimeter and configuring your network firewall to not
> allow this address as a source on your network would help.
> Activity monitoring of IDS alerts and logs would also assist
> with network protection. However, the unknown capabilities of
> this version of Trojan still could present a problem
> .
>
> Severity would be (3 + 5) - (3 + 3) = 2
>
> Defensive Recommendations:
>
> Configure the network perimeter to not allow broadcast
> packets from the outside. Attempt to locate and remove any
> hosts already containing the hidden Q software. This may be
> difficult and time consuming but completely necessary. If the
> targeted hosts can be removed from the internet please do so.
> A comparison of system backups or ghost images of these hosts
> could reveal configuration changes that may lead to the
> detection and location of this Trojan software and give some
> insight as to the type of activities this Trojan has been
> attempting. Furthermore, isolating a host and attempting to
> craft a similar packet could be beneficial as well. After
> eradication, test and audit your firewalls and IDS systems to
> see how they respond to similar crafted packets. Lastly, the
> installation of Host Based IDS systems, Inline Detection
> Systems, and/or asset tracking and allotment tools on
> critical hosts or in critical portions of the network is
> recommended to help detect and possible prevent this type
> activity in the future.
>
>
>
>
> _______________________________________________
> Intrusions mailing list
> Intrusions at lists.sans.org
> http://www.dshield.org/mailman/listinfo/intrusions
>
>
More information about the Intrusions
mailing list