Re: Should I be concerned about? (long reply, grab a sandwich)

[Chris Brenton <cbrenton () altenet com>]

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
-- 
**************************************
cbrenton () altenet com

$ 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