How Skype Punches Holes in Firewalls

An anonymous reader writes "Ever wondered, how P2P software like Skype directly exchanges data — despite the fact, that both machines are sitting behind a firewall that only permits outgoing traffic? Read about the hole punching techniques, that make a firewall admin's nightmares come true."

Oh come on.

[SatanicPuppy]

This isn't an exploit. If the admin's didn't want the firewall to forward ESTABLISHED/RESPONSE packets, they can take that capability out...One of the things I've always had issues with, with regards to commercial firewall software (e.g Zone Alarm/Windows Firewall) is that that capability usually ISN'T enabled, so I'm forever getting "APPLICATION IS TRYING TO CONNECT TO THE INTERNET" pop-ups.

If you're using a NAT with IPTables, it's trivial to tell it to drop packets on any port regardless of whether they're established or UDP or whatever. The article represents this like it's some kind of l33t hacker tool to break down a firewall from the outside, rather than the same problem you'd have if you downloaded a trojan, or some internet-connecting spyware.

Very misleading.

A Good Paper

[Al Mutasim]

Here is another good discussion (PDF): http://www.rootsecure.net/content/downloads/pdf/sk ype_protocol.pdf [rootsecure.net].

Re:punching holes...

[AndrewNeo]

They're not 'starting to charge', their free period is ending at the end of the year just like they said when they started it.

Re:Nothing new here

[Rycross]

The OpenTNL library (a game networking library pulled from the Torque engine) does this too. I remember thinking it was pretty clever at the time.

Re:DS

[GweeDo]

Um, if they worked at McDonalds they would already have free WiFi for DS gameplay.
See here [kotaku.com]

The answer...

[chill]

...is deep packet inspection. Instead of just letting packets thru based on "I'm just returning so-and-so's request", look to see what their payload contains and what type of stream it is. Yes, encryption can hide the payload. But, you can still prohibit non-SSH/HTTPS/SFTP streams from originating. If it isn't an approved protocol, make it go away.

Want to REALLY torque off the Skype guys? Let it thru, just add random packet delays to each UDP packet that goes out and comes in. A few ms each should do it. Their call quality will go to hell. Things like mail, web surfing, and other non-realtime protocols won't even notice the difference.

  Charles

Re:you have no clue

[grasshoppa]

Generally, it's wise not to open your mouth unless you know what you are talking about;

The kernel firewall knows how to MASQ udp packets; There's a timeout associated with them. So if you get a random UDP packet that it doesn't have a matching connection for, it'll drop it.

The real problem is being an administrator for a network which doesn't block outgoing traffic.

Re:Great article

[autocracy]

It is true that UDP is connectionless, but stateful firewalls do track UDP conversations as "connections." This is why, for example, DNS requests going out can be answered without unrequested inbound UDP traffic sent anywhere.

Re:udp huh?

[dotgain]

It's voice, not file transfer.

We can only send packets as fast as they come out of the codec. After you've just transmitted a packet, there's maybe a 100mS wait until the next packet even exists. As long as Skype (or any VOIP stack) is working properly, the senders do all the 'flow control' necessary, simply by having a constant, regular stream to transmit. You don't want TCP flow control at all, you've either got enough bandwidth or you haven't.

Re:Ever wondered

[Peyna]

Not to mention how to properly use an em dash.

Re:Steps, too many.

[brunascle]

both alice and bob are doing the same thing: sending a UDP packet to the other. for both, once they send out a UDP packet, that allows a UDP packet from the other side to come in.

so whoever sends the first packet wont make it to the other side, but the other side's packet will make it across, because both holes would then be open.

Otherwise known as STUN

[chhamilton]

As other have already pointed out, this a very common technique. It is slowly being adopted as a standard in the VoIP and P2P world (Google Voice uses it, for one). RFC 3489 [ietf.org] discusses this very technique, and defines a protocol to be spoken to the central server that is brokering the connection. For a good overview, you could check out the Wikipedia article [wikipedia.org]. There is also a simple, cross-platform and open-source library [sourceforge.net] available that implements the server and client side techniques, making it very easy to integrate this technique into other projects. Nonetheless, the article makes for a nice and simple description of the technique.

Re:Nothing new here

[jfengel]

You're right that it's not new, but you're missing a crucial step. They need to exchange port numbers, not just IP addresses, via the central server (or at least one port number). Then they need to prime the firewall to pass connections through to that port by sending out a packet to the peer from that port, even though the final destination of that packet will be filtered out.

So it's not new, but it's still pretty clever.

Not hole punching.

[mindstrm]

This is not hole punching, and not a security risk.

It is a way to get two computers that are already allowed to talk to whoever they want on the internet to talk to each other despite both having firewalls that don't allow incoming connections. It does not cause violation of firewall policy or break firewall rules in any way, it just gets over an unfortunate incompatability in this world of NAT.

The issue only arises because both parties are firewalled.

The short version: Using a 3rd server that both parties can connect to cleanly, the behavior of UDP is analyzed to see if source ports are static or predictable. If they are, it's trivial to have both hosts send packets to each other causing both firewalls to permit reply traffic, at which point direct communication between hosts over udp is possible.

This is easily overcome by randomizing source UDP ports at the nat layer.

Re:you have no clue

[mindstrm]

Now we're into semantics... stateless and connectionless are the same thing.

The nat or filter tables use the concept of a connection to allow/deny udp packets, but that is only a convention; UDP in and of itself is completely connectionless and stateless. There is absolutley nothing saying that 2 packets with the same source & destination ports are part of the same conversation at all.

It's not even an attack anyway... if you allow outgoing connections, why do you care if the person is connecting to someone else in the world who is firewalled -vs- someone who is out in the open, or whether htey are using UDP or TCP? (let's leave network performance & abusive UDP out of it...)

Re:you have no clue

[SatanicPuppy]

Well, no, I suppose if you sent every packet from a UDP session to a different port, there would be no way of telling that they're all part of the same session, because you're right, UDP doesn't contain any tracking info.

The state table entry for a UDP packet, however, contains the source IP:port and the destination IP:port, and uses that information to "track" the exchange. So unless you just allow all UDP through the firewall, the state table keeps track of how often the destination ip responds, and if it doesn't respond within the timeout set in ip_conntrack_proto_udp.c at compile time, the system will terminate that connection, and require a "new" connection to be set up between those addresses. It also won't allow the destination port to be changed without a second "NEW" packet originating from the new destination port.

I agree it's not an "attack" as such. My original point was that it wasn't an exploit at all, in the sense that you are not able to break any existing rule using this method. If you allow UDP out, and UDP:Established in, then how can you complain that you end up accepting a bunch of UDP packets?

Re: Punching Holes in BT

[Crazy Man on Fire]

I know you can punch holes for bit torrent, at least if you are using Azureus, as long as you setup your router to port forward/trigger to a particular UDP/TCP port.

If you're setting up port forwarding in your router, the application isn't "punching holes" you're just opening up your firewall at the router...

Re:you have no clue

[E++99]

All these people maintaining that UDP is a "connectionless" protocol are baffling to me...How do you think NAT works? Do you think that it just forwards UDP packets everywhere, hoping that someone wants them? All connection information has to be maintained with NAT, or there is no point.

UDP is connectionless. NAT routers invent imaginary connections based upon the outgoing packets they see, and then close the imaginary connections after inactivity. It's not part of the protocol. It's a model that the router uses to block all packets except the ones that were presumably requested.

Re:Not exactly new

[dgatwood]

Let's say Bob (as in the example in the article) is behind a NAT, his local ip he got from his router via DHCP is 192.168.1.2, and the public IP of his router is 2.2.2.2. He wants to use UDP port 2828 on his computer to transmit his voice data to Alice. So he sends out the first packed to 1.1.1.1:1414, as in the example. Now because of his NAT it looks like the data is coming from 2.2.2.2 and some arbitrary port (the router can't always use the same source port as the NATed computer because some other computer on the local network might already be using that port to connect to the outside world) lets say his router uses 3939.

Now Bobs router says, "Okay, I'll let through any UDP packets sent from 1.1.1.1:1414 to 2.2.2.2:3939 and I'll pass them on to 192.168.1.2:2828". As in the example, Alice's router will just drop this packet because there is no pre-existing connection from Alice's computer using this info. Then when Alice tries to send a packet to 2.2.2.2:2828 Bob's router drops it because his router isn't expecting traffic to this port. His router is expecting packets to go to port 3939. And Bob has no way of telling Alice which port she should actually be sending packets to since he doesn't even know which port his router decided to use on the public side to send out his packets.

Alice's computer should not be sending to 2828. It should be sending to the source port seen in the packets sent to the centralized server used for the rendezvous operation. Bob doesn't tell Alice anything. Bob sends a message to the central computer, which in turn, tells Alice something. The central computer DOES know what port Bob's router used because it can look at the source port on the UDP packet.

When a breakdown occurs (rare, but possible), it is not because of the difference between 2828 and 3939. It occurs because the router picked a -different- source port to use when sending packets to Alice than it did when sending packets to the central server. If the router does not consistently map port 2828 to 3939, but instead adds a secondary mapping from 2828 to 5050 when communicating with Alice's machine, the connection may fail. However, in order for a complete failure to occur (as opposed to simply requiring two or more packets to be sent and a little extra negotiation), one of the following must be true:

A. Both routers must be broken in this way. If this is the case, neither side can get a packet through to the other side.
B. One router must be broken in this way and the other router must alter the source port (reverse port masquerading) of inbound traffic.

If neither of these is true and Alice's machine is the one with the broken router, her router will use a different source port when communicating with Bob's machine that corresponds with the different destination port to which Bob's response must be sent. As long as Bob's router does not munge this, Bob's computer now knows how to send a message back to Alice, and a bidirectional communications channel should exist at that point.

I'm not saying that any of these services/protocols handle that extra bit of negotiation, of course, just that the problem isn't unsolvable unless both routers have a critical defect in their behavior.

Re:The answer...

[Zone-MR]

A few ms each should do it.

I'm pretty sure a few ms would be absorbed by the jitter buffer. Heck, 20ms jitter is often a normal occurance on long-distance WAN links.

TCP over UDP

[John Sokol]

Once you have a bi-directional UDP packet exchange going, (it's not a connection like TCP) but it is in some sense an unreliable connection.

You can then route TCP over it (grab packets from /dev/tap or /dev/tun) , or use a user space TCP stack connection or use something like my ECIP (http://www.ecip.com/ [ecip.com]) over it.

Re: Punching Holes in BT

[Anonymous Coward]

yes, and you can steal the crown jewels, as long as the queen willfully gives them to you!

Re:STUN?

[tjansen]

* It's the same as STUN, the article even mentions STUN at the end.
* STUN also supports "symetric" firewalls/NATs, I think that's not mentioned in the article. But no one uses them at home anyway, and I doubt that they are widespread elsewhere.
* SIP can use STUN (it's not required, but pretty common now).
* What the article does not mention: Skype can also mis-use HTTP proxys with HTTPS support to get through the firewall. That's the configuration that most companies have, and I hoped to get a bit more information about that in the article. But basically it will work similar to the common HTTPS tunnels (google for them if you don't know them), just Skype-specific instead of allowing arbitrary TCP connections.

UDP *is* Connectionless; Apps might not be

[billstewart]

UDP is a Layer 4 protocol for transmitting packets between (Layer 5,6,or 7) applications - it doesn't have any concept of connection, state, or acknowledgements, either in the packet headers or in the protocol for what to do with those packets. By contrast, TCP creates a connection between the two endpoints, using the 3-way-handshake mechanism, window size management, acknowledgements, retransmit mechanisms, etc., and the connection has state (SYN sent, SYN-ACK received, N bytes still waiting to go into a window, FIN received, etc.)

The Applications may or may not create Layer 7 connections or maintain state. Most UDP applications do one of three things

• Do a simple one-packet response to a one-packet query - DNS usually works this way, and all the protocols like Echo and Daytime that got turned off due to packet-amplification attacks like smurfing work that way. The application doesn't maintain any state - it just answers your question and waits for the next one.
• Send a stream of packets, unacknowledged, which you hope will mostly be delivered. Voice and videoconferencing applications work that way - it's better to have an occasional static or screen glitch than to slow the whole thing down waiting a few hundred milliseconds for lost packets to retransmit, watching everybody's mouth move out of sync like a bad Godzilla movie.
• Provide a full-scale connection, emulating TCP badly at Layer 7. Applications that do this are usually designed for LANs, where they usually work, and they can get higher throughput with less CPU demand on the computer because the connections usually work and are have much lower latency and loss and higher bandwidth than the environments TCP was designed for.

  Some applications that look like this are really hybrids - they've gone to a lot of work to make sure they work fine in a stateless UDP environment, where packets might get lost or duplicated, and remote partners might go on and off line, such as remote file-system apps where the Layer 7 acknowledgement that Block 12345 has been written to disk is what the application needed to know anyway. Being stateless lets the app not have to keep track of which remote sites are currently reachable, and lets a server scale to handle lots of sporadic accesses. And sometimes the client app maintains state even if the server doesn't - the client knows it has 242344 more bytes to send to the server, but the server responds to each packet idempotently when it comes in and doesn't worry about the past or future.

• Genuine one-shot unacked messages - telemetry apps are often like this, and sometimes logging apps are as well. If you lose the message "It's 43.123 degrees at 12:24:14", there'll be another one soon saying "It's 43.122 degrees at 12:24:15" that's probably just as useful as doing an ack and retransmit.

Firewalls used to be manually configured for some protocols - you'd allow a UDP connection from 1.1.1.1:1414 to 2.2.2.2:2828 - and also support protocols statelessly - you'd allow ping responses, or TCP SYN/ACKs, but didn't explicitly track which responses were really from which connections. This was usually good enough for TCP, but fairly crude for UDP, since the Layer 4 protocol doesn't tell you state. Stateful inspection techniques let the firewall keep track of each exchange between two sites - you'll accept ping responses from 2.2.2.2 to 1.1.1.1 because you know 1.1.1.1 just sent a ping to 2.2.2.2, and you'll accept TCP packets from 2.2.2.2:443 to 1.1.1.1:12345 because you know 1.1.1.1:12345 did a TCP SYN to that 2.2.2.2:443 and haven't seen a TCP FIN or timed out the connection. They're simulating state, even for protocols that don't have connections or state at Layer 4, because applications usually have one or a series of packet exchanges even if they don't have state at Layer 7 (or only have state at one end.)

Re:Great article

[woztheproblem]

From page 2 of the article:

Astonishingly, hole punching also works with TCP. After an outgoing SYN packet the firewall / NAT router will forward incoming packets with suitable IP addresses and ports to the LAN even if they fail to confirm, or confirm the wrong sequence number (ACK). Linux firewalls at least, clearly fail to evaluate this information consistently. Establishing a TCP connection in this way is, however, not quite so simple, because Alice does not have the sequence number sent in Bob's first packet. The packet containing this information was discarded by her firewall.

Re:Great article

[dotgain]

I think he means "tunnel" the TCP packets over the UDP "connection", which is exactly how OpenVPN and others work.

The UDP packets that travel between two hosts (the "connection") is now analogous to some sort of LAN cabling between them: We encapsulate whatever we want inside the UDP packet, and it's probably make it to the destination. We can therefore tunnel TCP/IP inside of UDP/IP packets and get reliability and flow control, as well encrypt the contents if we want security.

NAT behavior is not consistent

[__aadkms7016]

See: http://www.ietf.org/internet-drafts/draft-ietf-beh ave-nat-udp-08.txt [ietf.org] for a taxonomy of the ways NATs behave. The method described in the article won't work for all kinds of NATs.

Re:Great article

[Score Whore]

TCP headers and UDP headers are quite different and a valid TCP header is not a valid UDP header. Bytes 5-8 of a TCP header are the sequence number. Bytes 5-6 of the UDP header are length, and 7-8 are the checksum. It seems unlikely that a UDP stack would be able to handle parsing part of a TCP sequence number as a length value.

Could you encapsulate a stream that acts like TCP inside of a stream of UDP packets? Sure. But it's not you can switch to a TCP stream as the predecessor post claimed.

News?

[Jahz]

Use of the procedure described above is not limited to Skype and is known as "UDP hole punching".

This sentence, which occurs in the last paragraph of TFA, should be further noted. The technique described here has been around for as long as NAT routers have been around (a very long time). Its fairly common knowledge/practice in network security circles. In fact, this was taught in my network security course last year. I think it was on the final as well... except we had to defeat a NAT router using TCP packets which is a slightly more tricky task.

On a tangent:
NAT routers are not really proper firewalls, though they have the side effect of keeping most attackers out. This is beacuse NAT was designed and implemented primarily for allowing multiple computers to utilize a single global address. They technically break the OSI stack by reaching past the link layer... and provide a bit less security than using vanilla iptables without modules. A more interesting exercise would be to describe the steps to defeat a firewall with stateful packet inspection.