Scary traffic - long

[Chris Brenton <cbrenton () sover net>]

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