Pwnat – Autonomous Nat Traversal (2010) | Hacker News Reader

Pwnat – Autonomous Nat Traversal (2010)

samy.pl

97 pointsjgeralnik40 comments

The really cool part about this is that the server does not need to know the client's ip address. Instead a new original form of ICMP hole punching is used to allow any client to punch the NAT so that the server can dynamically learn the client ip, and then regular UDP hole punching is used.

I'm sad that P2P never took off in the messaging world and now we are stuck with servers storing data even if it's E2E encrypted.

I use NAT traversal for Firestr (http://firestr.com) back in 2013 though this is still cool because of the ICMP hole punching. I'll have to see if I can incorporate that.

There's some progress. See https://libp2p.io eg.

P2P messaging is a hard sell, in my opinion for a couple of reasons:

P2P requires knowledge of the peer's IP, which can be unwelcome depending on the messaging partner (and it's hard to make a config for do you trust this person enough to see your IP: yes, no, only if I'm on network X, not if I'm on network Y, etc)

P2P requires both nodes to be online simultaneously, so it's difficult to make work well for asynchronous messaging with smart phones or mobile laptops or desktops that are regularly turned off. Maybe you remember how Skype used to be?

So, I think you definitely want a server based store and forward messaging path to ensure delivery and for (optional) privacy from peers, and adding an optional P2P path is additional work, without a lot of gain; at least if it's text. When you start sending media, the bandwidth/storage savings from going P2P make it worth exploring.

> This will work behind many NATs and firewalls, but not all.

While this is an interesting concept, the hard part in NAT traversal is getting it to work on all the possible NAT types. In particular, I believe that this method doesn't work for symmetric NAT devices[1], which are widespread in corporate environments. It's not a surprise that this idea from 2010 didn't take off, ICE/TURN are still kings.

[1] These devices assign a different port for each destination address, and this ICMP method doesn't help predict the port that will be assigned.

As long as only one side of the connection is behind a corporate NAT you could simply try all 65535 ports until you find the one that works. The side behind the NAT would receive the packet and then be able to respond.

And then you're blacklisted by the corporate firewall for doing what looks like port scanning.

All 3 corporate firewalls I have been behind have been HTTP only. No actual internet connection. (Except for DNS, which worked.)

DNS working in a corporate IT environment is a surprise. Often, clients are issued an internal DNS server via DHCP, and outbound DNS to arbitrary servers is blocked. This helps mitigate DNS hijacking and also allows some additional outbound domain filtering and logging.

Oh, yes, DNS is an internal DNS. You can't change it. I meant, it's the only way to "trickle leak" data without it going through the filtering proxy. But who knows, maybe the DNS requests are logged too, but they don't seem to be filtered.

Edit: they are filtered. Suspicious names go to 127.0.0.1

You can leak names can't you? Wouldn't kinda-short-secret-message.foo.example.com make its way eventually to the authoritative server for example.com, as long as it's not too sketchy a domain?

Yep, that works.

And of course, with the advent of DNS over HTTPS, this is no longer as effective. I can still access blocked sites and get around logging, I just have to set up a tunnel to cloudflare.

Which, from a security point of view, would be grounds for immediate termination and quite some companies I worked for would try to sue you to pay for impact assessment.

(connecting a usb-modem is much safer, I'd have to actually spot the device which would require getting out of my chair... ;)

The point is not really for me to circumvent restrictions, it's more that a bad actor could. This can largely defeat the purpose; though malware using this is not common, it's started to crop up.

2010? Samy (author of pwnat) is the person jailed for hacking MySpace using this Code. He write this code in 2005 or 2007 something, He upload to his site in 2010, but this code is very old, and I was the first one to compile it on windows back than. It works, but for limited devices back then. It is very respectable code in itself.

He didn't "[hack] MySpace using this code". He just used XSS.

He's still my hero though!

This is old technique from early 2000 and flawed as others have described. Outgoing ICMP is blocked in every corporate environment I have ever been to and never makes it to the Internet facing gateway.

I'm on a large corporate network right now and I get responses back from `ping www.google.com`.

But also this technique doesn't depend on ICMP that is just what the example happens to use. Pwnat itself uses only UDP for outgoing requests.

ICMP is used by the server in order to find out the IP of the client. Then they switch to UDP. This method does not work without ICMP. Now, of course you can use outgoing UDP in probe fashion instead of ICMP, but that's again most probably blocked.

I had a quick test, not working for me many previous comments about this script https://hn.algolia.com/?q=pwnat

ah, I've got it, it's a pretty old code :)

You will have better luck with IPv6 if needed why bother for NAT traversing . IPv6 just works without it.

Only because IPv6 doesn't need NAT theoretically. In practice, most people are stuck using it because the router doesn't hand a public-facing IP to most clients. When building an application, you still need it.

So is this a tool or an exploit? Or both? Is this something likely to get patched by the major software/hardware vendors? Would this be a tool that would be safe to use at home if I wanted to connect to a private network on AWS or GCP and did not want to poke a hole through my nat gateway at home?

NAT is an ugly hack to extend IPv4 address space that breaks the internet. There are numerous ugly hacks for NAT traversal to fix what NAT breaks, all of which kind of seem like exploits, and some of which are effectively standardized in RFCs and used heavily for things like VoIP. The whole thing is a hideous mess that IPv6 will hopefully eventually kill.

> NAT is an ugly hack to extend IPv4 address space that breaks the internet

Or to phrase it more generously, NAT is an ugly but simple hack that allowed the internet grow despite limited address space and without a gigantic investment in hardware to support an over-engineered replacement protocol.

It may have done that back when 128 bit addresses were actually expensive, but it also altered the evolution of that network from a more open peer to peer architecture to a closed silo mediated architecture. Things that should be simple and easy became complex and expensive. We are all poorer for it. You could say that instead of paying to upgrade we are paying for lost capabilities and technical debt.

I'm not sure that wouldn't have happened anyway, just with firewalls. ISPs were not above port blocking regardless.

It's much easier to deal with port opening or changing than it is to deal with a fragmented address space. NAT reminds me of the networking analog of segmented addressing on 16 bit 8086 processors, but worse as it is not systematic.

Opening a port through NAT on your own setup is pretty much the same process as doing it on any firewall. I'm not sure how the address space being fragmented changes anything in this case, the user must poke a hole somewhere somehow.

Try writing P2P software and you'll see it. NAT is like 16-bit segmented addressing. Go find some old 16-bit C programs and see what a "near" vs "far" pointer is and that whole mess. IPv6 is like the arrival of 32-bit real mode addressing with the 80386.

P2P software wouldn't work too well without fiddling with the firewall anyway, is what I'm saying. I don't think circumstances would have changed much if we'd adopted IPv6 instead of NAT. P2P largely failed to take off outside of piracy circles because centralization is more reliable and efficient, that's all.

And yeah, I've dealt with segmented memory models, in C and ASM. I don't think the situation is very comparable at all, nor are segments as bad as people say, but that's neither here nor there. I mean, FFS, all modern systems use an MMU that remaps memory addresses between processes anyway.

> without a gigantic investment in hardware to support an over-engineered replacement protocol.

Bullshit.

Almost every piece of hardware sold since 15 years is compatible IPv6. There is no need of any "expensive hardware".

The main reason that IPV6 never lift off is the lack of interest, lazyness and no will for configuration.

NAT is older than 15 years though. And

> lack of interest, lazyness and no will for configuration

Is a symptom of v6 being over-engineered.

NAT is more over-engineered than IPv6. IPv6 is literally the same as IPv4 in most aspects. People are just lazy because NAT makes things "work" (if you can call it that).

IPv6 is really just IPv4 with more address space. There are a bunch of extensions that nobody uses, sure, but nobody uses them and they can be safely ignored in most cases.

The only other significant change from V4 to V6 is the use of multicast instead of dumb broadcast for V6's equivalent of ARP on LANs. That's an improvement as it allows smart switches to more easily scale address lookup.

I think you might have a typo in your FAQ.

"Does the server have to specify the client host? No!..... The server does need to have any unique prior knowledge about the client. "

Should that read, "The server does NOT need to have any unique...." ?

Cool, I used to do this by spoofing udp packets from 3.3.3.3 from the client to the servers public up, but was unreliable due to anti spoofing filter. This way is better

Reply on news.ycombinator.com