RE: LOGS:GIAC GCIA Version 3.5 Pratical Detect DanteWinslow

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 


[email protected] GCIA
Defense In Depth is like ogres^h^h^h^hnions. It has layers.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: Tuesday, November 30, 2004 6:33 AM
> To: [email protected]
> 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
> [email protected]
> http://www.dshield.org/mailman/listinfo/intrusions
> 
> 
_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions