Greetings! Jose Carlos Faial wrote: > > Today morning I start receiving a lot of ICMP packets from a host, > apparently in China (if the source address was not spoffed). The first > packet was: > > [2001-10-31 11:52:25] ICMP Destination Unreachable (Port Unreachable) > IPv4: 203.193.63.9 -> XXX.XXX.XXX.XXX > hlen=5 TOS=192 dlen=56 ID=37607 flags=0 offset=0 TTL=235 chksum=27228 > ICMP: type=Destination Unreachable code=Port Unreachable > checksum=39472 id= seq= > Payload: length = 32 > 000 : 00 00 00 00 45 00 00 4E F2 FE 00 00 68 11 8D DF ....E..N....h... > 010 : A3 BA 23 3C CB C1 3F 09 00 89 00 89 00 3A 61 80 ..#<..?......:a. OK, this unreachable was generated due to the following packet: Source IP: 163.186.35.60 Destination IP: 203.193.63.9 Protocol: UDP Source port: 137 Destination port: 137 TTL: 104 So based on this I would be asking myself the following questions: Is 163.186.35.60 running NetBIOS/IP (maybe a Windows machine)? Does my firewall policy permit outbound UDP/137 connection attempts? If yes, do I have a log entry showing this outbound connection? Next, try to traceroute to 203.193.63.9 What's the max hop count? Now match this TTL value against the OS at 163.186.35.60 to see if it makes sense: Windows 128 Linux/BSD 64 etc. etc. For example if 163.186.35.60 is a Windows system, and you appear to be about 24 hops (+/- 3 hops) away from 203.193.63.9, this packet could be legitimate. Answering the questions above will tell you for sure. > following thousands of packets like this: > > [2001-10-31 12:42:10] ICMP Time-To-Live Exceeded in Transit > IPv4: 203.193.63.9 -> XXX.XXX.XXX.XXX > hlen=5 TOS=192 dlen=56 ID=49325 flags=0 offset=0 TTL=235 chksum=15510 > ICMP: type=Time Exceeded code=0 > checksum=48251 id= seq= > Payload: length = 32 > 000 : 00 00 00 00 45 00 00 74 4A A4 00 00 01 11 9D 13 ....E..tJ....... > 010 : A3 BA 23 3C CB C1 3F 0A 01 03 01 03 00 60 36 1E ..#<..?......`6. Source IP: 163.186.35.60 Destination IP: 203.193.63.10 Protocol: UDP Source port: 259 Destination port: 259 TTL: 1 Obviously so of the same questions from above apply here as well (outbound policy, outbound log entries, etc.). A couple of things trouble me here. First, the TTL's don't jive with the first trace. We have 103 hops that have gone /dev/null. True this is a different target IP, but its only 1 IP off from the host your system supposedly tried to connect to. Could be some kind of weird routing loop thing but it still kind of bugs me. Then again I know I've been known to use some weird reject packets to throw off attackers as well so this could just be an advanced firewall sending you back error codes that will get you scratching your head. ;) Next, what's up with those port numbers? The Neohapsis port list has UDP/259 listed as Firewall-1, but I *thought* I remembered Firewall-1 as being _TCP_/259. Maybe Lance can double check me here. So the combination of the above two traces look suspicious but I would not jump the gun till I checked out 163.186.35.60. > I know that this can be just legitimate ICMP traffic, but I have a bad > felling about this activity. I am sure that the target machine never tried > to connect to or to send any kind of packet to the 203.193.63.9 machine, so > ICMP Time-To-Live would not be expected. They are "unsolicited" packets. Again, check the box. Windows (if that's what you are running) kicks off UDP/137 under some really weird conditions (name resolution, etc.). The UDP/259 is pretty suspect however. That one troubles me. > My question is "Can a hacker forge an ICMP packet to bypass the firewall > and use its payload (payload data is different for each packet received) to > send data to a trojan (listening for ICMP traffic on the target machine)? " The answer is, "It depends on the firewall". :p It all comes down to whether your firewall is stateful for ICMP unreachables or not. For example Netfilter decodes the unreachable (in a similar fashion to what I did above) in order to see if it can find a matching state table entry. For example those TTL exceeded packets would get dropped unless Netfilter could find a state table entry for the outbound packet I identified. If the state entry did exist, the packet is considered legitimate and would be allowed through. Unfortunately, many firewalls are not stateful for unreachables & TimeX. For example Cisco ACL's (both static and reflexive) can't deal. You might be able to do something with NBAR, but I have not tried. Firewall-1's love of passing all ICMP unlogged would also allow these packets through as well. As for "can unreachables and TimeX be used to send commands to a Trojan", absolutely. I first started seeing this in the wild around 1/2000. My guess is this is not what you are seeing however as it would not require "thousands" of packets to issue commands. Too high profile. There are some unreachable & TimeX DoS attacks, but these packets do not fit the bill. My gut feeling is that these packets are legit but I would want to see the internal host and your outbound log entries checked as mentioned above to say for sure either way. HTH, Chris -- ************************************** cbrentonat_private $ chown -R us:us yourbase ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Nov 01 2001 - 08:41:17 PST