Subject: RE: [midcom] STUN security showstopper

From: "Christian Huitema" <[email-masked]>
Date: Fri, 10 May 2002 10:27:15 -0700

> 	I'm a little sleepy yet, but..
> 
> > 1) Client prepares request, including signature request.
> > 2) Attacker intercepts request, and somehow manages to prevent it
from
> > reaching the server.
> > 3) Attacker replaces the source IP address and source UDP port of
the
> > request by one of its own addresses and port, and forwards the
request
> > to the server.
> > 4) Server dutifully note the address from which the packet is
received,
> > prepare a response, signs it, and send it back to the incoming
address,
> > i.e. the attacker.
> > 5) Attacker receives the response, takes note of the mapping,
replaces
> > the address and port by the original values in the intercepted
message,
> > and sends the response to the client.
> 
> 	Doesn't the server signature cover the address and
> port? Sure, they're not signed in the request, but surely the
> server signs the entire message it returns (including a length
> field and probably some other junk like a client supplied
> nonce). I confess I haven't been following STUN, but this
> seems basic it me.

The server signs the payload of the UDP message. It cannot sign the
content of the IP and UDP header, since that content will be modified by
the NAT.

> > 6) Client receives the response, note that the signature is present
and
> > is actually correct, and uses the proposed mapping.
> 
> 	Client notes that the signature is wrong and dumps the
> response, surely..

NOPE. The signature only applies to the UDP payload, and nobody touched
that.

> 	Of course, if you only get to step 2, you have implemented
> the DOS already. Preventing that sort of thing is surely outside
> the scope of MIDCOM, thankfully.

Yes. In fact, in the "shared LAN" scenario that people talk about most,
it is probably easier to mount a rogue-DHCP or a spoofed-ARP attack than
the STUN attack.

> 	Feel free to tell me why I'm stupid :)

Let's say sleepy...

-- Christian Huitema

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 10 May 2002 12:46:04 -0500 (CDT)

Oh, I see! The attacker doesn't smash the mapping itself,
he causes the server to invent a bad one -- pointing back to
the attacker -- and then forwards that on to the client. As
an added bonus, the attacker can now intercept media to the client,
if this is a phone call. I think it might be a good idea to
fix this :)

	I'm following, now, I think.

> > 	Feel free to tell me why I'm stupid :)

	You may be overly generous!