Subject: [midcom] STUN security showstopper

From: "Christian Huitema" <[email-masked]>
Date: Fri, 10 May 2002 08:59:53 -0700

I am afraid I have found an attack that invalidates both the current CMS
approach and the proposed protected hash approach.

Let's first restate the threat we want to protect against: an attacker
observes the STUN request, provides a fake response to the STUN client,
and uses that fake response as a way to either deny service to the STUN
user, or insert itself between the STUN user and its peer. The denial of
service is achieved by providing a response that contains an entirely
bogus address; the man-in-the-middle attack is achieved by providing the
address of the attacker itself. The current proposals try to protect
against that by letting the server sign the responses.

The problem is that the server has no way to ensure that what it is
signing is genuine. Suppose that the attacker, instead of merely
responding to the request, simply forwards it to the server, giving the
following flow:

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.
6) Client receives the response, note that the signature is present and
is actually correct, and uses the proposed mapping.

The root cause of the problem is that we cannot sign the request. More
precisely, we cannot include the source IP address and UDP port of the
request in the fields covered by a signature. This pretty much by
construct: we are trying to deal with NAT traversal, and what NAT do is
precisely rewrite the source address and port to some value that the
client cannot predict. An attacker who manages to intercept the message
and change the source IP address and source port behaves in fact exactly
like a NAT; no amount of cryptography and signatures will protect us
against that.

This makes be believe that cryptographic signatures are not practical
defenses against the attack we fear most. If we look at the flow, a
critical part is that the attacker has to somehow prevent the message
from reaching the server, or prevent the genuine responses from reaching
the client. If an attacker can do that, it can by definition mount a
denial of attack against the STUN service; it can also place itself as a
man in the middle, also pretty much by definition. If the attacker
cannot do that, then the client will receive several responses to a STUN
request, and will be able to detect that something fishy is going on.
This may be the basis for a protection.

-- 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:12:34 -0500 (CDT)

On Fri, 10 May 2002, Christian Huitema wrote:

	I'm a little sleepy yet, but..

> 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.

> is actually correct, and uses the proposed mapping.

	Client notes that the signature is wrong and dumps the
response, surely..

	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.

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

		Andrew

---

From: Melinda Shore <[email-masked]>
Date: Fri, 10 May 2002 13:31:38 -0400

At 12:12 PM 5/10/02 -0500, Andrew Molitor wrote:
>port?

Right, but the client doesn't know its external address -
that's why it's using STUN - so has no way to know that
it's receiving a response to a bogus request.  It leaves
us facing the prospect of protecting the client request,
and all that implies.

Melinda

---

From: Scott Brim <[email-masked]>
Date: Fri, 10 May 2002 13:31:38 -0400

> nonce). I confess I haven't been following STUN, but this

View from a casual observer: What could the server sign that would be
different it it was intercepted?  The server is going to respond to the
interceptor with the interceptor's global address/port, and the
interceptor is going to pass that along to the client to get the desired
behavior.  The interceptor doesn't have to change anything at all in
what the client originally provided -- and all will be signed.  

..Scott

---

From: "Cullen Jennings" <[email-masked]>
Date: Sat, 11 May 2002 17:01:39 -0700

Christian's attack is great and really helps straighten this stuff out. I
think we need to discus the threat as well as solutions to the threat.

Let's look at this threat carefully and decided how important it is to
solve. It sounds to me like you have an attacker that can perform an attack
that is pretty much a man in the middle attack on the traffic between the
stun client and server. If it is successful in this attack, then it can
perform a man in the middle attack on the traffic that the STUN was
negotiating a port for. For sake of a concrete example, call this RTP.

1) Is the real solution to secure RTP against man in the middle attacks?

2) Is this attack against STUN easer than a man in the middle attack against
RTP?

3) How possible is it to stop DOS attacks against low end non symmetric NAT
devices regardless of it STUN is used or not?

Stun is used like a routing protocol. If someone sends me a bad ARP that
causes me to send traffic to the wrong place, the solution is to make sure
that traffic does not contain information the attacker can use. We don't get
to a viable solution by thinking we can control exactly who does or does not
see our packets on a IP network or thinking that we can control what the
topology of the network is.

As Christian has pointed out, this problem may be impossible to solve,
however, the questions is still open to if it needs to be solved or not.

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 14:12:04 -0400

This is definitely a difficult threat to address. I agree with Cullen on
many points. When you get down to it, the threat is very similar to the
threat of a rogue router between you and a server. A rogue router could
hijack any UDP traffic I send through it, modifying the source address
so that it gets the responses instead of me. I think you will find that
protecting against this attack in the face of NAT is exactly the problem
we are trying to solve here, and it is a much bigger problem than just
STUN.

I also think that, on the list of attacks to worry about, a rogue router
is the least likely kind of attack you'll see. DoS attacks, fraud, and
eavesdropping attacks are much easier to launch, and those are the ones
we should focus on.

Thus, I would contend that the primary threat we are dealing with is
still preventing an eavesdropper from seeing a STUN request fly by, and
then sending a faked response back directing traffic towards it. The
path we were going down previously - use of a short lived shared secret
in a digest-like exchange - appears to protect against this, and I would
propose we continue along that direction.

Now, with regards to the issue of whether the mechanism for obtaining
the shared secret should be orthogonal to STUN or not - I think it is a
separate mechanism, but it cannot be decoupled. Christian is right that
we cannot permit the usage of long-lived shared secrets because of the
threat of off-line dictionary attacks. Therefore, STUN *must* use some
kind of mechanism for the establishment of one-time passwords. This
could be documented separately, but would be a mandatory dependency of
STUN. That is, clients and servers MUST implement this other thing. We
could allow for other things down the road too, but we need a baseline
mechanism which is mandatory to implement, which provides high quality
keying.  I fear that just saying "you must use a shared secret with an
entropy greater than 64 bits" within STUN is going to be ignored, and
people will use low entropy passwords anyway. 

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com