RE: Re: NAT router inbound network traffic subversion

[<fd () ben iagu net>]

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
protocol.

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
outside.

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).

Cheers,

ben

> -----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
> OVER )"
>
> 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