Hackers first crack the exposed host. Then they see if it has multiple interfaces. The local ARP cache will tell them the RFC1918 addresses if it is a NAT. The "NAT" just clusters several machines together in one machine. Whether there are multiple machines behind a NAT is of little consequence. Those machines that have exploitable ports available are still exploitable. A good example is HTTP buffer overflows. A number of NATs will happily forward the overflow attacks right through to the web server, which is still exploited. SIP phones are similarly exploitable. And how many NATs will forward external packets addressed to RFC1918 space between both interfaces? A lot used to. The limited access depended on the assertion that RFC1918 packets couldn't be transmitted beyond the external interface due to routing configuration. This assertion cannot be guaranteed. Change that routing, and there is frequently complete transparancy. But the fact that it doesn't usually work has caused many people to make the false assumption that it can't ever work, and wrongly conclude that NAT is an access control device when it isn't. --Dean On Fri, 20 Jun 2003 Valdis.Kletnieks@vt.edu wrote: > On Thu, 19 Jun 2003 03:57:40 EDT, Daniel Senie <dts@senie.com> said: > > > Maybe YOU should read it, and explain how this is useful for attacking the > > hosts behind a NAPT box. The technique described in this paper uses > > variations in the IPid field as evidence of more than one host generating > > packets. Fine. So you plunk a box just upstream of the NAT box, and now you > > can determine how many ACTIVE hosts are talking to sites outside the NAPT box > > *sigh*. OK. You're correct. *BY ITSELF*, there's not much of an attack > vector here. On the other hand, every hacker who has graduated from the > ranks of the ankle-biting script kiddies knows that target recon is something > that you want to do if feasible. > > Information leakage makes it a lot easier.... > > Let's pretend you're a hacker. You've found a box that you suspect is a NAT. > What's the FIRST thing you want to know? Yep - verify that it IS a NAT. And lo > and behold, if you can enumerate more than one host behind it, it's probably a > NAT. > > What's the second thing you probably want to know? What techniques are likely > to work, of course. And your choice of attack tools will quite likely be > swayed dramatically if you suspect there's only 3-4 boxes behind the NAT > because the NAT is a front end for a SOHO or similar, or if there's only 3-4 > boxes because there's a DMZ behind it, or if you suspect there's hundreds back > there. > > And all sorts of info leaks out in the oddest ways. For instance, I save the > rfc822 headers from my mail. So far in June, I've caught 38,836 Received: > lines from off-campus hosts, with 12,211 unique sources. Of these, 2,597, from > 409 different sources, contain an IP address literal from 1918 space. Those > often give (a) a target IP inside the 1918 space and (b) the clue (dependent on > the MTA) that perhaps the site doesn't have care/clue enough to get PTR records > set up.... > > >