Subject: (ngtrans) Using Shipworm servers as UDP DoS reflectors

From: Pekka Savola <[email-masked]>
Date: Fri, 10 Aug 2001 01:20:50 +0300 (EEST)

Hi,

As was pointed out at IETF51 ngtrans meeting, there is a reflector denial
of service attack in 6to4 relay router functionality.

Similar attacks, though even more severe, are also possible with Shipworm.

I pointed this out very briefly on the list on Jul 18.

Here is a little more verbose how-to:

Attacker on IPv6 network sends a native packet to the Shipworm relay:

src = [real ipv6 source, spoofed or whatever]
dst = 2003:1122:3344:1234::1 (2003 is assumed to be the shipworm prefix)
data = whatever

Now, the relay will send IPv4 UDP packet to:

srcv4 = [ipv4 shipworm anycast address]
dstv4 = 17.34.51.68 (victim, does not even run ipv6)
dstv4_port = (hex)1234
data -- encapsulated ipv6:
 srcv6 = src from above, easily spoofed
 dstv6 = dst from above
 ...

Issue here is that you can use shipworm not only as a reflector sending
traffic using ipip (proto 41, as with 6to4), but to send very specific
traffic to udp ports.  Protocol 41 can be filtered by sites that have
never even heard of IPv6 if someone is mounting a DoS attack, but
reflected attacks against real UDP services cannot be distinguished
(unless the victim's firewall is decapsulating the packets, see below).

(afternote: you could filter out udp with source port of "Shipworm Relay
Port")

Good candidates for dstv4_ports might be e.g. dns, portmapper, several
dynamic rpc ports or whatever.

Effectively, you can mount DoS attack apparently coming from:

srcv4 = [ipv4 shipworm anycast address]
dstv4 = host
dstv4_potr = port being DoS'ed
data -- encapsulated ipv6 packet:

 srcv6 = spoofed ipv6 address or the attacker
 dstv6 = 2003:1122:3344:1234::1

So, there's nothing of real value (..to trace) there.  ipv4 anycast
address may be very difficult to backtrace (possible asymmetry and bgp
policy), and even then, the relay would only know of the spoofed ipv6
address.

So this appears to be a "double-safe" (from attacker's point of view)
reflector.

Sure, you can spoof source and send junk to UDP ports as it is, but you
are much easier to get the blame for it.  This appears to be almost
bulletproof method of not getting caught..

How to protect against this?  Very difficult.  You could make a MUST that
the representation of 'port' would have to be non-privileged, thus
minimizing the chance of tunneling into a port where you should not ever
go. However, some NAT's _might_ use privileged ports right after
bootstrapping, but I don't think this should ever happen.  I recall that
at least some implementations use port ranges like 49000-60000 for NAT but
not sure if this is a global phenomenon.  This might be configurable.

In any case, some consideration of the problem is probably required prior
to deployment. :-)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords