Home page logo

fulldisclosure logo Full Disclosure mailing list archives

RE: Re: NAT router inbound network traffic subversion
From: <fd () ben iagu net>
Date: Fri, 4 Feb 2005 11:50:54 +0100

This topic is debated once every 12 months on the firewall-wizards list -
you could check the archives there.

You cannot get a packet in from the outside on PAT (port translated NAT, NAT
overload, etc) to a client that is idle. Actually, that may be a lie given
that there used to be a bunch of crappy NAT equipment that would accept
packets addressed to the correct internal IP, but that mostly doesn't happen
anymore, and it's an implementation thing. 

This is the part that could be considered a security feature, since it is
the only real incremental security compared to connecting directly. 

You talk about this being 'intractable' rather than 'impossible'. This isn't
correct. It is genuinely impossible in a reference implementation, since
there is no state entry to allow the traffic, and traffic not allowed is
denied. In real life that gets blurry. NAT entries that don't get torn down,
dumb implementations that remember too much of their routing roots, overload
behaviour etc could mean that you might find a way to do it on a certain
box, but the basic behaviour is axiomatic.

You can attack existing connections - DNS spoofing, blind TCP MitM (or not
blind if you're close enough), UDP packet injection in general. These are
all a class of attack exploiting the simplicity of NAT states
(internalIP:internalPort->onesingleIP:Port), but they require a spoofable

Basically, those attacks are not all that much harder or easier than if the
connection did not use NAT, and rely on most of the same conditions,
including the ability to sniff the connection to have any real chance of
blind TCP MitM. NAT adds an additional barrier if you actually care which
machine you are attacking, and some of the previous people have sent links
to the various ipid and other techniques to work out who is who from the

morning_wood's scenario is neither more nor less difficult / likely,
irrespective of the presence of NAT; it works but is orthogonal to the NAT
security issue. Mostly the same for Mark Senior's excellent DNS response
injection example (although if that attack is carried out blind there is an
extra complication because the client source port will often be changed by a
PAT router).



-----Original Message-----
From: full-disclosure-bounces () lists netsys com 
[mailto:full-disclosure-bounces () lists netsys com] On Behalf 
Of Kristian Hermansen
Sent: Friday, January 28, 2005 4:37 PM
To: full-disclosure () lists netsys com
Subject: [Full-disclosure] Re: NAT router inbound network 
traffic subversion

I think the answers that I received in response to my query 
are somewhat
obvious -- yes -- but neither answered my question!  Morning Wood's
analysis was brilliant as ever, like always ;-P

"atacker now can do a he wishes to the rest of your network ( GAME

Ummm...okay.  The problem with you was this statement:

"NAT client browses web..."

HOW IS THIS NOT USER INTERACTION?!?!?  I asked if there is a 
computer on
the internal network that doesn't do anything -- that means SENDING NO
PACKETS to the router -- if an attacker can get EVEN ONE 
PACKET inside:
then they will prove everyone wrong, right?  If one packet can get
through, it can be considered a rogue packet that should not have
entered the internal network destined for a particular host 
-- or better
yet -- an internal broadcast address going to all hosts.

Some say getting these rogue packets into the network is "impossible".
That is the reason for my question.  I like to think that 
most problems
are "intractable", but not "impossible".  Can anyone prove me wrong?
Can someone push a rogue packet behind a router with no client
interaction???  This is my chautauqua...
Kristian Hermansen <khermansen () ht-technology com>

Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

  By Date           By Thread  

Current thread:
  • RE: Re: NAT router inbound network traffic subversion fd (Feb 04)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]