lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: Mark.Senior at gov.ab.ca (Mark Senior)
Subject: NAT router inbound network traffic subversion

See http://www.phrack.org/show.php?p=62&a=3  "The Impact of RFC
Guidelines on DNS Spoofing Attacks" by have2Banonymous

The short version - Windows sends DNS queries from a consistent source
port - 1026 in the author's tests, and with predictable request IDs -
the first request after boot up is 1, then 2,3,4... (like an idiot's
luggage combination)

You can predict what DNS server an home ISP user will query; it's the
ISP's DNS server.  Using source port 53, and destination port 1026, you
have everything you need to get phoney DNS replies past the NAT router.

If you brute-force the lower hundred or so request IDs, you're
reasonably likely to hit a request ID the DNS client just sent, assuming
the computer was booted recently.

And, here's the kicker - Windows doesn't check if the answer matches the
question it asked - if you look up www.good.org, and an attacker manages
to sneak in a phoney reply packet telling you that www.evil.com has
address 6.6.6.6, that will be good enough.  And your browser will be
directed to the evil server, but show the good one's name in the address
bar. 

Cheers
Mark
-----Original Message-----
From: full-disclosure-bounces@...ts.netsys.com
[mailto:full-disclosure-bounces@...ts.netsys.com] On Behalf Of Kristian
Hermansen
Sent: January 27, 2005 23:12
To: full-disclosure@...ts.netsys.com
Subject: [Full-Disclosure] NAT router inbound network traffic subversion

I have Googled around and asked a highly-respected Professor at my
University whether it is possible to direct packets behind a NAT router
without the internal 192.168.x.x clients first requesting a connection
to the specific host outside.  The answer I received is "not possible".
I also asked if this can be thought of as a security feature, to which
the reply was again "yes".

Now, I wouldn't place all my bets on his answer and I am calling on
someone out there to clear up my question.  If NAT really does only
allow inbound connections with a preliminary request as he suggests, it
seems that the only way to get an "unauthorized" packet behind the
router is by some flaw in the firmware of the device.

How about if the client has requested a connection to Google.com from
behind his Linksys home NAT router: would it be possible for an outside
attacker to spoof packets from Google's IP to get packets into the
network?  Or do we need to know the sequence numbers as well?  Or is
there an even more devious way to get packets on the inside without a
client's initiative?

Has there been any research into this?  Are there statistics on worm
propagation and exploited network hosts in relation to those individuals
that did not own routers (and instead connected directly to their
modem)?  If *all* home users on the Internet had NAT routers during the
summer of 2003, would we have significantly slowed the spread of
Blaster?  I believe these all to be very important questions and the
security aspects of the ability to route packets behind NAT really
interests me...maybe some of you can elaborate :-)
--
Kristian Hermansen <khermansen@...technology.com>

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ