6 ms·

NAT-to-NAT direct connections with no proxy/STUN needed

162 points by metabrew 17y ago

rubyrescue 17y ago
very 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?
- xal 17y ago
  Very but as with the example he is giving, this is very useful technology for video games where hosts and clients are regularly behind NAT. UPNP has made this somewhat better but it's still no where near perfect. If i'm not mistaken, much of the UDP punch-through technology was invented by Skype. However, skype still relies on a proxy server that every client connects to. It needs that so that the client can prepare the router to let data through from a certain client IP. These guys here found a ridiculously clever way of skipping this step which makes true P2P with both end points behind NAT possible and even easy to implement.
- thorax 17y ago
  All of these techniques could be prevented if you knew about them. Yet I wouldn't be surprised if the specific IP address wasn't customizable eventually when you control both sides.
- d4rt 17y ago
  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 protocols. I'm not aware of any perfect prevention or detection technique, but detection could in the case of a moderate amount of data transit could possibly be done via analysis of netflow records.
  - tophercyll 17y ago
    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.
- tptacek 17y ago
  Better just to block all ICMP TTL exceeded packets, breaking traceroute entirely. Normal users don't use it that much. Traceroute sucks; it's clunky, slow, and unreliable. Network people need it (and they can carve exceptions for themselves), but end-users don't.
tptacek 17y ago
Cheat 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 NATs, but most corporate networks are doing more than NAT'ing; they're dropping everything but DNS and HTTP from a proxy.
- alecco 17y ago
  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_serverless_nat_to_nat_udp_hole_punching_for/c0n2kpp?context=3 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://<server external ip>/pubkey_hash:<pub key hash> The hash could be base64 encoded in just 24 chars. Of course this is thinking out loud. There are protocols for this already. Thats of course drafty and not really checked, but you can get the idea and improve on it. It looks very doable. 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).
  - tptacek 17y ago
    You're right. It's a big deal. It's just not a big deal for corporate networks.
    - alecco 17y ago
      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.
jbeda 17y ago
This looks to be two things: a way of discovering ips and communicating them without STUN and a simple nat traversal using UDP. Th first is a little clever but not super interesting as signalling channels are a dime a dozen. The second is essentially a small subset of ICE and will fail if anyone remaps ports.
- jbeda 17y ago
  For something similar check out scottlu's FWD — http://www.scottlu.com/2008/05/fwd-tool-for-peer-to-peer-port.html http://www.scottlu.com/2008/05/fwd-tool-for-peer-to-peer-por.... It uses xmpp as the signalling channel and the ICE implementation from libjingle. This is the P2P stack we built for Google Talk several years ago. If you get this stuff right you can establish a direct connection when both parties aren't behind a full cone NAT — 90+% of the time.
00joe 17y ago
Ok, 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.
- rphlx 17y ago
  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.
- tptacek 17y ago
  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.
alecco 17y ago
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_serverless_nat_to_nat_udp_hole_punching_for/ http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser...
tophercyll 17y ago
We'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.
- dotBen 17y ago
  This sounds like an interesting project, do let us know!
- huhtenberg 17y ago
  You should make a test version of your p2p client and ask here (and, say, on Reddit and p2p-hackers list) to help test it. You will get a few hundred sample points in a matter of hours.
- gritzko 17y ago
  Sorry for being lazy. Does it need root rights to forge ICMP?
latitude 17y ago
The trick with priming NAT for receiving bogus inbound TTL-Exceeded ICMP packets is really clever. However keep in mind that this method assumes that: (a) the client knows server's external ("Internet") IP (b) there is exactly one server behind the NAT device Latter is obviously quite limiting unless the "3.3.3.3" changes for every server and the client learns it together with server's external IP. This in turn means that the client still needs to communicate with some 3rd party, so this method only partly alleviates the need for the 3rd party during the tunnel setup process, but it does not completely eliminate it.
billpg 17y ago
Isn't 3.3.3.3 an IP inside the General Electric Company? What happens if they ever decide to use it?
deutronium 17y ago
Anyone mind posting the arguments for the server and client you're using. The server side segfaults for me. Mine are: Server: ./pwnat -s 2221 Client: ./pwnat -c ClientIP 3333 RemoteIP 2221
vijayshankar 17y ago
Is there a possible segfault at line 108 in udpclient.c? pport is a junk pointer at this line: sprintf(pport, "2222");
- wingo 17y ago
  In v0.2-beta, the line reads `sprintf(pport_s, "2222");'.
malbs 17y ago
I might be showing my ignorance here, I'm not a network guy, but a vast majority of internal networks use 192.168.1.0/24 192.168.1.1/24 and so on. What happens when the source and destination networks both use the same class C addresses?
- huhtenberg 17y ago
  Source is talking to the external IP of destination's NAT device and vice versa. They are not talking using their internal IPs.
davidu 17y ago
I know Samy well. Probably more than 10 years. He's one of the best of the best. I'd hire him in a second if he'd let me.
defenestrator 17y ago
how exactly is this different than netcat -u ?

162 points by metabrew 17y ago

very 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?

xal 17y ago
Very but as with the example he is giving, this is very useful technology for video games where hosts and clients are regularly behind NAT. UPNP has made this somewhat better but it's still no where near perfect. If i'm not mistaken, much of the UDP punch-through technology was invented by Skype. However, skype still relies on a proxy server that every client connects to. It needs that so that the client can prepare the router to let data through from a certain client IP. These guys here found a ridiculously clever way of skipping this step which makes true P2P with both end points behind NAT possible and even easy to implement.
thorax 17y ago
All of these techniques could be prevented if you knew about them. Yet I wouldn't be surprised if the specific IP address wasn't customizable eventually when you control both sides.
d4rt 17y ago
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 protocols. I'm not aware of any perfect prevention or detection technique, but detection could in the case of a moderate amount of data transit could possibly be done via analysis of netflow records.
- tophercyll 17y ago
  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.
tptacek 17y ago
Better just to block all ICMP TTL exceeded packets, breaking traceroute entirely. Normal users don't use it that much. Traceroute sucks; it's clunky, slow, and unreliable. Network people need it (and they can carve exceptions for themselves), but end-users don't.

tptacek 17y ago

Cheat 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 NATs, but most corporate networks are doing more than NAT'ing; they're dropping everything but DNS and HTTP from a proxy.

alecco 17y ago
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_serverless_nat_to_nat_udp_hole_punching_for/c0n2kpp?context=3 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://<server external ip>/pubkey_hash:<pub key hash> The hash could be base64 encoded in just 24 chars. Of course this is thinking out loud. There are protocols for this already. Thats of course drafty and not really checked, but you can get the idea and improve on it. It looks very doable. 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).
- tptacek 17y ago
  You're right. It's a big deal. It's just not a big deal for corporate networks.
  - alecco 17y ago
    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.

jbeda 17y ago

This looks to be two things: a way of discovering ips and communicating them without STUN and a simple nat traversal using UDP. Th first is a little clever but not super interesting as signalling channels are a dime a dozen. The second is essentially a small subset of ICE and will fail if anyone remaps ports.

jbeda 17y ago
For something similar check out scottlu's FWD — http://www.scottlu.com/2008/05/fwd-tool-for-peer-to-peer-port.html http://www.scottlu.com/2008/05/fwd-tool-for-peer-to-peer-por.... It uses xmpp as the signalling channel and the ICE implementation from libjingle. This is the P2P stack we built for Google Talk several years ago. If you get this stuff right you can establish a direct connection when both parties aren't behind a full cone NAT — 90+% of the time.

00joe 17y ago

Ok, 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.

rphlx 17y ago
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.
tptacek 17y ago
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.

alecco 17y ago

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_serverless_nat_to_nat_udp_hole_punching_for/ http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser...

tophercyll 17y ago

We'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.

dotBen 17y ago
This sounds like an interesting project, do let us know!
huhtenberg 17y ago
You should make a test version of your p2p client and ask here (and, say, on Reddit and p2p-hackers list) to help test it. You will get a few hundred sample points in a matter of hours.
gritzko 17y ago
Sorry for being lazy. Does it need root rights to forge ICMP?

latitude 17y ago

The trick with priming NAT for receiving bogus inbound TTL-Exceeded ICMP packets is really clever. However keep in mind that this method assumes that: (a) the client knows server's external ("Internet") IP (b) there is exactly one server behind the NAT device Latter is obviously quite limiting unless the "3.3.3.3" changes for every server and the client learns it together with server's external IP. This in turn means that the client still needs to communicate with some 3rd party, so this method only partly alleviates the need for the 3rd party during the tunnel setup process, but it does not completely eliminate it.

billpg 17y ago

Isn't 3.3.3.3 an IP inside the General Electric Company? What happens if they ever decide to use it?

deutronium 17y ago

Anyone mind posting the arguments for the server and client you're using. The server side segfaults for me. Mine are: Server: ./pwnat -s 2221 Client: ./pwnat -c ClientIP 3333 RemoteIP 2221

vijayshankar 17y ago

Is there a possible segfault at line 108 in udpclient.c? pport is a junk pointer at this line: sprintf(pport, "2222");

wingo 17y ago
In v0.2-beta, the line reads `sprintf(pport_s, "2222");'.

malbs 17y ago

I might be showing my ignorance here, I'm not a network guy, but a vast majority of internal networks use 192.168.1.0/24 192.168.1.1/24 and so on. What happens when the source and destination networks both use the same class C addresses?

huhtenberg 17y ago
Source is talking to the external IP of destination's NAT device and vice versa. They are not talking using their internal IPs.

davidu 17y ago

I know Samy well. Probably more than 10 years. He's one of the best of the best. I'd hire him in a second if he'd let me.

defenestrator 17y ago

how exactly is this different than netcat -u ?