Re: [FW1] Scary traffic - long

[Norman Hoy <normh () aone com au>]

Hi all,
    Chris I can understand your concern. I what I have to
say
may help explain your problem but I believe that you should
still investigate it.

Over the last few weeks I've had 4 instances of seeing
icmp's
coming in to various firewalls that I manage. This was to
the 
.255 address (firewall dropped and logged) this was followed
by and snmp request on .255 from the same address.

On each occasion I have followed this up with the
originating
organisation 2 in USA 1 in .nl and one in .au . The common
thread
with this from all organisations was that they had just
installed
castlerock's network management tool.  It appears as if this
software has a bug in it, when you first install it, the S/W
goes out and attempts to "auto discover" your network, in
reality
it was auto discovering the internet :-(.

I hope that this helps you, and proves to be the case for
you 
as well and not some hacker attempting to map your IP's.

regards
    Norman

Norman Hoy
Network Engineering
OzEmail/AccessOne
Adelaide
South Australia

61 8 8267-3356
0408 082519 24 hrs.
(coming in from international drop leading 0)

Chris Brenton wrote:
> Sorry for the cross post, but I am troubled by this traffic and I think
> it may be a serious problem.
>
> First some background:
>
> I have a client running FW-1 on NT (SP3, hotfixes & FW-1 patch 3072).
> Earlier in the week, one of the alerts where tripped on the firewall.
> After reviewing the log, I found the following traffic. Note that the
> legal IP address used on their internal network has been replaced here
> with 192.168.1.0.
>
> Time,Interface,Action,Service,Source,Destination,Protocol,Rule,Source
> Port,Info
> 15:35:11,N1001,drop,tftp,Ext_Host_1,192.168.1.255,udp,8,tftp,len 29
> 15:35:37,N1002,accept,,Cisco_1,Ext_Host_1,icmp,4,,icmp-type 0 icmp-code
> 0
> 15:35:37,N1002,accept,,Cisco_2,Ext_Host_1,icmp,4,,icmp-type 0 icmp-code
> 0
> 15:35:37,N1002,accept,,Cisco_3,Ext_Host_1,icmp,4,,icmp-type 0 icmp-code
> 0
> 15:35:37,N1002,accept,,NetWare_1,Ext_Host_1,icmp,4,,icmp-type 0
> icmp-code 0
> 15:35:37,N1002,accept,,NetWare_2,Ext_Host_1,icmp,4,,icmp-type 0
> icmp-code 0
> 15:35:37,N1002,accept,,NetWare_3,Ext_Host_1,icmp,4,,icmp-type 0
> icmp-code 0
> 15:35:37,N1002,accept,,NetWare_4,Ext_Host_1,icmp,4,,icmp-type 0
> icmp-code 0
>
> Ciscos 1&2 are switches, Cisco 3 is a router. The NetWare servers are
> all 4.11. What troubles me is the above traffic pattern. A TFTP request
> was sent to the internal network's broadcast address. Supposedly, the
> firewall dropped this traffic. Obviously, it did not as a number of
> internal systems responded. The only thing I can tell that all these
> systems have in common is that they are all running SNMP.
>
> Upon looking at the logs even closer, I found a number of sessions that
> looked similar to the following:
>
> 18:12:23,N1002,accept,,Cisco_1,Ext_Host_2,icmp,4,,icmp-type 0 icmp-code
> 0
> 18:12:23,N1002,accept,,Cisco_2,Ext_Host_2,icmp,4,,icmp-type 0 icmp-code
> 0
> 18:12:23,N1002,accept,,Cisco_3,Ext_Host_2,icmp,4,,icmp-type 0 icmp-code
> 0
> 18:12:23,N1002,accept,,NetWare_1,Ext_Host_2,icmp,4,,icmp-type 0
> icmp-code 0
> 18:12:23,N1002,accept,,NetWare_2,Ext_Host_2,icmp,4,,icmp-type 0
> icmp-code 0
> 18:12:23,N1002,accept,,NetWare_3,Ext_Host_2,icmp,4,,icmp-type 0
> icmp-code 0
> 18:12:23,N1002,accept,,NetWare_4,Ext_Host_2,icmp,4,,icmp-type 0
> icmp-code 0
>
> Note that this is the same traffic pattern as above, *except* that the
> initial TFTP entry does not appear in the log. My guess is that the same
> exploit is being used. I'm at a loss as to why one attack pattern
> created the TFTP entry while the rest did not. My guess is that the
> attacks where just slightly different enough for FW-1 to pick up on one
> of them. This implies that we may be looking at multiple individuals.
>
> I noted 5 different external host locations in all. 3 where AT&T dial-up
> lines within the US, 2 where computer clubs located in Asia. To add salt
> to the wounds, I have noted the same above traffic at yet another
> client. The one thing the two sites have in common is that AT&T is their
> ISP and they have both been given IP addresses out of the 12.0.0.0
> range.
>
> So now comes the questions part. I'm looking at the initial TFTP
> connection and the packet length of 29 troubles me. If memory serves,
> TFTP only uses 512 byte packets. Anything smaller is suppose to signal
> an end of transmission. True or no?
>
> Also, I know that the NetWare servers are not running a TFTP server (I
> think this is also true for the Ciscos, but I need to verify this). This
> means that even if the traffic did make it through, there should not
> have been any service running on these devices to respond beyond to say
> "service unavailable". This is where things get a bit weird, I know that
> UDP commonly uses "destination unreachable" messages which are generated
> by the target in order to tell the transmitting system that the service
> is not available. This means that if a savvy attacker could find an open
> UDP port (like say 53), they could effectively scan a non-NAT network
> sitting behind a firewall by looking for these messages.
>
> OK fine, except:
> 1) The port _was not_ open. Thus the drop in the first log entries.
> 2) ICMP code 0 is an "echo-reply", not a "destination unreachable". For
> that I would expect to see a Type 3 with a code of 1 or 2.
>
> So another question, is there some condition with UDP that causes an
> echo-reply to be generated? I've been through a number of RFC's but
> could not find anything. This situation also troubles me because if the
> attack pattern relies on UDP, not TFTP, this means that *any* UDP
> service could be used to elicit these responses.
>
> Of course another problem is that FW-1 does not record a length with
> logging ICMP traffic. This means that I have no idea what the payload of
> the ICMP packets may have contained. I have a sniffer running on-site
> now, but as of yet this traffic has not returned.
>
> So to recap the conditions under which I think people need to be worried
> about this exploit:
> FW-1 is the sole border protection
> Legal addresses are used internally (especially the 12.0.0.0 subnet)
> echo-reply is allowed out of the network
>
> A suggested quick patch would be to disable outbound echo-reply on the
> firewall. This will not keep the intruder out, but will at least block
> their probes on the return trip. You may also wish to block inbound TFTP
> at your router just in case this problem is limited to TFTP only and is
> not a UDP problem.
>
> Any feedback on the above would be *greatly* appreciated.
>
> Cheers,
> Chris
> --
> **************************************
> cbrenton () sover net
>
> * Multiprotocol Network Design & Troubleshooting
> http://www.amazon.com/exec/obidos/ISBN=0782120822/0740-8883012-887529
> * Mastering Network Security
> http://www.amazon.com/exec/obidos/ISBN%3D0782123430/002-0346046-8151850
>
> ================================================================================
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> ================================================================================