Either it could mean it is not a requir mentioned to be able to send broadcast packets to the machine. Windows uses broadcast packets for lots of things, like discovering UPnP devices, media centers, other machines file/printer shares, etc.
Or it could mean no need to have the ability to send the machine IP packets directly, so one can attack even if the machine is behind NAT.
There are far fewer ways to attack a machine behind NAT with no user interaction, but things like sending back false NTP or DNS responses, spoofing windowsupdate servers, or some of the peer to peer services built into windows sound like possible ways.
NAT does not provide security on its own, it's the firewall that drops packets. Most of the time you see both together on the same device; it's very rare to see a NAT-only device, which usually will route packets to hosts on the LAN.
The statement "there are far fewer ways to attack a machine behind NAT with no user interaction" is true even though NAT on it's own is not designed to be a firewall.
I believe that's called ICE. and still needs both clients aware that theyre about to connect, and making outbound connections to each other with the goal of opening up sourceports.
This does not negate the fact that NAT(PAT) provides protection against directly connecting to a device.
If you know a bug in the DNS resolving stack of the client, you can make it send a query to your DNS server and exploit it to establish a connection. So no, it doesn't have to know it's about to connect.
A query is easily triggered by sending an email with a an external picture embedded or something like that.
But why would the client use _your_ DNS server? It will just use its local resolver, which will most likely use the router, or ISPs DNS server, and so forth.
The difference is that NAT doesn't track the counter party, so after you reached out to the DNS, any other service can use the opened port to connect to your PC.
With a stateful firewall, it tracks that the port was opened only used for the DNS server. If a connection to that port from a different IP address than the DNS server is made, the firewall will block it.
That is inside-out. It requires a client inside your network to initiate a connection to the outside.
Obviously, NAT does nothing for preventing outbound connections.
The whole point-to-point connection between 2 NATed PCs isn't so much about security either. If an attacker wants to connect to your PC behind a NAT, all the attacker needs is to be routable.
If your router is only NATing packets and routing them, your PC is routable. The router will simply translate the addresses as usual. There is a good chance most people have never seen such a setup, as the router almost always includes other features like a stateful firewall. The firewall may even take advantage of the NAT information when it decides if a packet should be routed or dropped.
All NAT does is rewrite the Source Address and/or Destination Address fields in the IP header, and possibly the Source/Destination Port fields in the UDP or TCP header. There are many rewriting methods, including some that are designed to route packets from the public network ("port forwarding", etc).
Ok, so below is how I understand NAT to make a PC effectively (with exceptions) unroutable.
As I figured it, if pc Bob is behind a NAT, there is not a public IP address that will route to Bob. The NAT box (lets call it a router) does have a public IP address. However, when a packet arrives at the router, and the destination port isn't mapped (by mapped I don't just mean manual port forwarding but also the actual NAT process) to some port on Bob, the packet will never reach Bob.
In order to figure out a destination port that will even reach Bob at all, you either need to somehow get a recognized request from Bob, and look at the 'return address'. If you already have some control over Bob (or another PC in the NAT) that seems feasible, otherwise it takes a rather large dragnet.
My point being, unless you have info on the state of the router, anything behind it is effectively unroutable.
I'd be very interested to hear where I am wrong, it's been a while since I covered this material.
You're still looking at NAT as used to masquerade the hosts on a LAN (often with RFC 1918 private addresses) so they appear as a single public internet address. That is actually one of the fancier uses of NAT, and it's almost always combined with a firewall/etc.
RFC 2663 defines[1] a "Basic NAT" as a one-to-one mapping of IP addresses. This can be useful as a way to combine two separate IP networks that share addresses. If you have two networks using the 10.1.x.y range, you could connect them with a Basic NAT so they each see the opposite network as addresses in the 10.2.x.y range.
NAT is just about the AddressTranslation. Routing is a separate feature, and dropping packets is a separate feature that can be left out, even if those are rare situations.
> but also the actual NAT process
Often you don't even need the NAT process to be involved. Send a packet to a NAT route with the internal destination address, and some routers will simply route the packet directly. Enabling the Source Routing options can also force packets to a specific host by guessing the local address, which is easy when everybody uses 192.168.1.x or other private addresses behind their NAT. Fortunately, this generally isn't possible anymore because LSRR is now usually dropped at the firewall.
If NAT sounds like a mess, it is. NAT is a shameless subversion of the "end-to-end principle, which has set network software development back decades.
LAN means "Local area network". Imagine all the computers in your house connected to your router for example.
They mentioned it because other vulnerabilities could be classified as remote but still only exploitable on the local network. This one is exploitable from anywhere on the internet apparently. So its impact could be more severe.
I'm curious what "don't need to be on the same LAN" means. If it would be exploitable over internet wouldn't you just write that oder even leave the part about LAN out?
Are you suggesting that Tavis Ormandy is making this up?
This is upvoted because of the reputations of the people reporting it and because it sounds very serious. It's nothing to do with any kind of anti-Windows agenda.
Oh I think there is a lot to discuss. How Windows has handled vulnerabilities in the past. Can talk about how disclosure works. Maybe mention recent Intel vulnerabilities as well. Connect to CIA and NSA leaks them hoarding 0-days and so on.
29 comments
[ 2.7 ms ] story [ 57.1 ms ] threadEither it could mean it is not a requir mentioned to be able to send broadcast packets to the machine. Windows uses broadcast packets for lots of things, like discovering UPnP devices, media centers, other machines file/printer shares, etc.
Or it could mean no need to have the ability to send the machine IP packets directly, so one can attack even if the machine is behind NAT.
There are far fewer ways to attack a machine behind NAT with no user interaction, but things like sending back false NTP or DNS responses, spoofing windowsupdate servers, or some of the peer to peer services built into windows sound like possible ways.
Skype does that routinely: ever wondered how it can setup a point to point connection without port forwarding?
So to agree with PP, NAT is not a firewall...
This does not negate the fact that NAT(PAT) provides protection against directly connecting to a device.
A query is easily triggered by sending an email with a an external picture embedded or something like that.
Nothing NAT/PAT can protect you against.
With a stateful firewall, it tracks that the port was opened only used for the DNS server. If a connection to that port from a different IP address than the DNS server is made, the firewall will block it.
The whole point-to-point connection between 2 NATed PCs isn't so much about security either. If an attacker wants to connect to your PC behind a NAT, all the attacker needs is to be routable.
All NAT does is rewrite the Source Address and/or Destination Address fields in the IP header, and possibly the Source/Destination Port fields in the UDP or TCP header. There are many rewriting methods, including some that are designed to route packets from the public network ("port forwarding", etc).
As I figured it, if pc Bob is behind a NAT, there is not a public IP address that will route to Bob. The NAT box (lets call it a router) does have a public IP address. However, when a packet arrives at the router, and the destination port isn't mapped (by mapped I don't just mean manual port forwarding but also the actual NAT process) to some port on Bob, the packet will never reach Bob.
In order to figure out a destination port that will even reach Bob at all, you either need to somehow get a recognized request from Bob, and look at the 'return address'. If you already have some control over Bob (or another PC in the NAT) that seems feasible, otherwise it takes a rather large dragnet. My point being, unless you have info on the state of the router, anything behind it is effectively unroutable.
I'd be very interested to hear where I am wrong, it's been a while since I covered this material.
RFC 2663 defines[1] a "Basic NAT" as a one-to-one mapping of IP addresses. This can be useful as a way to combine two separate IP networks that share addresses. If you have two networks using the 10.1.x.y range, you could connect them with a Basic NAT so they each see the opposite network as addresses in the 10.2.x.y range.
NAT is just about the Address Translation. Routing is a separate feature, and dropping packets is a separate feature that can be left out, even if those are rare situations.
> but also the actual NAT process
Often you don't even need the NAT process to be involved. Send a packet to a NAT route with the internal destination address, and some routers will simply route the packet directly. Enabling the Source Routing options can also force packets to a specific host by guessing the local address, which is easy when everybody uses 192.168.1.x or other private addresses behind their NAT. Fortunately, this generally isn't possible anymore because LSRR is now usually dropped at the firewall.
If NAT sounds like a mess, it is. NAT is a shameless subversion of the "end-to-end principle, which has set network software development back decades.
[1] https://tools.ietf.org/html/rfc2663#section-4.1.1
Learn something new every day.
They mentioned it because other vulnerabilities could be classified as remote but still only exploitable on the local network. This one is exploitable from anywhere on the internet apparently. So its impact could be more severe.
This is upvoted because of the reputations of the people reporting it and because it sounds very serious. It's nothing to do with any kind of anti-Windows agenda.
So even if he isn't making it up, there's still nothing to discuss on this, and he's ratcheted the hype up to 11.
Oh I think there is a lot to discuss. How Windows has handled vulnerabilities in the past. Can talk about how disclosure works. Maybe mention recent Intel vulnerabilities as well. Connect to CIA and NSA leaks them hoarding 0-days and so on.