This was dead-ed to allow this re-submission (thanks metabrew).
There is a great discussion @reddit http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser...
NAT-to-NAT direct connections with no proxy/STUN needed
11–20 of 37 posts
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#12Cheat sheet version: one side sends packets to a bogus IP, the other side sends ICMP TTL Exceeded packets back. Some NATs will pass the TTL Exceeded packets because that's how traceroute works; the ICMP packets are indistinguishable from "real" traceroute responses. Once both sides know each other's IP addresses, they open a tunnel by simultaneously talking outbound UDP to each other. This is a clever trick for home…
The forest, dude, the forest.
Think about the masses behind home NAT routers and P2P. From my comments on reddit http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser...
Server publishes it's NAT external IP and a hash of its (RSA) public key.
[ICMP] Client MAC(client public key + server public key hash) -> Server
(Server checks the key hash the client got is valid)
[UDP] Server MAC(server public key + hash of client public key) -> Client
(Client checks the public key hash matches the server's public key) ...
The publishing first step could be just an URI like:
pwnat:///pubkey_hash:
The hash could be base64 encoded in just 24 chars. Of course this
is thinking out loud. There are protocols for this already.
Also think about P2P and privacy, so far the middle men (e.g. Skype) would know who is talking to who. This is a major step.
And there's plenty of space on the spoofed ICMP reply to put anything relevant to start a conversation (randomized ports, hashes, keys, nonce).
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#13We're experimenting with this technique in our peer-to-peer software. Unfortunately we probably won't have data on what percentage of the time it works for a few weeks.
Provided everything goes okay, I'll try to post our data as a follow up.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#14Cheat sheet version: one side sends packets to a bogus IP, the other side sends ICMP TTL Exceeded packets back. Some NATs will pass the TTL Exceeded packets because that's how traceroute works; the ICMP packets are indistinguishable from "real" traceroute responses. Once both sides know each other's IP addresses, they open a tunnel by simultaneously talking outbound UDP to each other. This is a clever trick for home…
The forest, dude, the forest. Think about the masses behind home NAT routers and P2P. From my comments on reddit http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser... Server publishes it's NAT external IP and a hash of its (RSA) public key. [ICMP] Client MAC(client public key + server public key hash) -> Server (Server checks the key hash the client got is valid) [UDP] Server MAC(server public key + hash of…
You're right. It's a big deal. It's just not a big deal for corporate networks.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#15very clever. how hard is it for the paranoid IT guy to block ICMP time exceeded packets inbound for 3.3.3.3 but not for other hosts, to stop servers from discovering clients?
On most firewalls this should be trivial. On an Cisco ASA: access-list BLOCK_TIMEEXCEEDED deny icmp any any time-exceeded (iirc) and then apply the acl. You should block all hosts as any could be chosen by the person. They could change 3.3.3.3 to any other IP. NAT is not a security mechanism and does not ensure your hosts are protected. Denying tunneling of any kind is difficult as there are tunnels over most protoco…
And in fact they almost certainly will choose a different host. Our plan is to just buy an extra IP for one of our VPS machines and leave it unused.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#16Ok, so ICMP is easy to turn off. But why couldn't this technique be done over UDP or TCP? The server could send a UDP packet to a known "fake" address and the client could spoof its source address to penetrate the nat.
Because many/most ISPs block simple outbound src addr spoofing.
pwnat works b/c ISPs don't (currently) inspect deep enough to notice spoofed addresses in the error packet contained inside ICMP.
This is an arms race b/t clever hackers and the ISP's increasingly deep packet inspection gear.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#17Ok, so ICMP is easy to turn off. But why couldn't this technique be done over UDP or TCP? The server could send a UDP packet to a known "fake" address and the client could spoof its source address to penetrate the nat.
Because the ICMP message is a case where NATs are already programmed to allow arbitrarily-sourced traffic to pass. The point is that the trick discovers the client's address, so they can establish direct 2-way comms.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#18Earlier quoted context omitted.
The forest, dude, the forest. Think about the masses behind home NAT routers and P2P. From my comments on reddit http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser... Server publishes it's NAT external IP and a hash of its (RSA) public key. [ICMP] Client MAC(client public key + server public key hash) -> Server (Server checks the key hash the client got is valid) [UDP] Server MAC(server public key + hash of…
You're right. It's a big deal. It's just not a big deal for corporate networks.
Yeah, it's not for corporate networks.
But, for example, corporate network (and security) could benefit from this, too. Virtual P2P meetings could be done this way without a third party central server or the need to install a special server software. The meeting initiator can send an email with an URI and everyone else just clicks on it running the relevant client software. Much better security-wise than most scenarios nowadays.
Cross-continent meetings are a major pain when it's over VPN or centralized.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#19Cheat sheet version: one side sends packets to a bogus IP, the other side sends ICMP TTL Exceeded packets back. Some NATs will pass the TTL Exceeded packets because that's how traceroute works; the ICMP packets are indistinguishable from "real" traceroute responses. Once both sides know each other's IP addresses, they open a tunnel by simultaneously talking outbound UDP to each other. This is a clever trick for home…
they're dropping everything but DNS and HTTP from a proxy
That won't help them either anymore:
Weaponizing dnscat with shellcode and Metasploit http://news.ycombinator.com/item?id=1204931
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#20Cheat sheet version: one side sends packets to a bogus IP, the other side sends ICMP TTL Exceeded packets back. Some NATs will pass the TTL Exceeded packets because that's how traceroute works; the ICMP packets are indistinguishable from "real" traceroute responses. Once both sides know each other's IP addresses, they open a tunnel by simultaneously talking outbound UDP to each other. This is a clever trick for home…
they're dropping everything but DNS and HTTP from a proxy That won't help them either anymore: Weaponizing dnscat with shellcode and Metasploit http://news.ycombinator.com/item?id=1204931
(a) My point isn't that enterprises can solve the (fundamentally intractable) covert channel problem. It's that this NAT tunnelling code won't work on corporate networks.
(b) DNS tunneling is also clever, but it's loud, easily detected, easily defeated, and extremely likely to get you fired.