My next class:

Teredo "stray packet" analysis

Published: 2010-02-16. Last Updated: 2010-02-16 21:15:10 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

This investigation started with Rick observing some odd UDP traffic hitting his firewall. In this case, the traffic came from 66.55.158.116 port 3544. The destination port was a "random" high port. If you would like to provide your packet captures, see the end of this article for the right filter.

Port 3544 is assigned to Teredo. However, Teredo itself uses this port to establish connections, not necessarily for the actual Teredo tunnel traffic itself. As a host establishes a Teredo connection, it will connect to a Teredo server on port 3544 and negotiated the details of the connection. During this negotiation, a IPv6 address is established for the host.

The IPv6 address used by Teredo will always start with "2001:0000:". This /32 prefix is reserved for Teredo. It is followed by the IPv4 address of the Teredo server, 16 bits worth of "Flags" defining the type of NAT used by the client's network, the UDP port used to connect back to the client and finally the clients public IPv4 address. To illustrated this, here a more "graphical" representation of a Teredo address:

2001:0000:SSSS:SSSS:FFFF:UUUU:CCCC:CCCC  S = Server IP address, F = Flags, U = obfuscated UDP port, C = public client IP address 

in short: Everything needed to connect back to the client is encoded in the IPv6 address. (also see our IPv6 tool )

The Teredo packet itself is rather simple. The IPv6 packet is embeded in a IPv4 UDP packet. We got an IPv4 header, a UDP header followed by the IPv6 header. Wireshark for example does a nice job in analyzing Teredo traffic.

Now lets go back to Rick's packet trace. If all this is true, then the last 4 bytes of the embeded IPv6 destination address should match the public IPv4 address the packet was sent to. In Rick's case, this wasn't the case. The two addresses didn't match at all.

The only packets Rick saw where "Bubble Packets". Bubble packets are used by Teredo to keep the firewall open. Typically every 30 seconds, the Teredo client will send an empty IPv6 packet to the server. This will extend the connection timeout in most firewalls. For UDP, there is no state like for TCP. In order to preserve the resemblance of state, firewalls assume that if a host sent a packet out, there may be a reply coming back. Teredo takes advantage of this "statefull UDP" feature in modern firewalls.

This is why we would like to connect more of these packets to see if Rick's experience was just a "one off" oddity or if others are seeing the same traffic. Rick did not use Teredo or IPv6 for that matter. We are interested in your packet in particular if you are NOT using IPv6

You can use tcpdump or windump to collect the traffic. You probably have to collect the traffic outside of your firewall. The tcpdump line is not perfect, and may capture some other UDP traffic (e.g. DNS). Before you send it to us, take a quick look at it to make sure you are not sending us any confidential data.

As a reminder, the tcpdump command line to collect the traffic: tcpdump -c100 -s0 -i any -w /tmp/teredo udp port 3544

------
Johannes B. Ullrich, Ph.D. IPv6 Security Essentials Training
SANS Technology Institute
Twitter

Keywords: ipv6 packets teredo
4 comment(s)
My next class:

Comments

The UDP client port is not the only obfuscated part in the teredo address. The same method is used for the client IPv4 address (exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF, see also section 4 of RFC4380). This might explain why your address did not match.

Cheers
I collected some packets today. They were the first/only I've seen to match the description. There were 448 packets over a span of about 40 minutes (i.e., much more than 1 every 30 sec or so).

FWIW when I decode the embedded client public address, it maps to Verizon Wireless.

It seems reasonable to assume that the Microsoft source address is spoofed, of course, making MS deal with any ICMP errors sent "back."

I suspect the embedded public address of the client is the real address of the scanner, seeing who actually forwards the packets to it. At this point it's just an identification scan to see who's running a Teredo relay (which isn't me, so no further enlightenment here).
I wrote:
>FWIW when I decode the embedded client public
>address, it maps to Verizon Wireless.

Scratch that. I did the decode incorrectly. The embedded client public address is *my* public address. Hmm....
Is there a Vista/Win7 machine behind your public IP or did you recently get a new DHCP lease? Could this be similar to the P2P afterglow we often see after a lease change?

Diary Archives