Subject: Re: [midcom] STUN security showstopper

From: [email-masked]
Date: Fri, 10 May 2002 12:12:15 -0400

How would the atttacker guarantee that it could prevent the server from
receiving the original message?

"Christian Huitema" <[email-masked]>@ietf.org on 05/10/2002
11:59:53 AM

Sent by:  [email-masked]

To:   "Melinda Shore" <[email-masked]>, <[email-masked]>
cc:   <[email-masked]>
Subject:  [midcom] STUN security showstopper

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

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

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 10 May 2002 09:25:06 -0700

A classic way is to mount a short duration DOS attack against the
server.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 10, 2002 9:12 AM
> To: Christian Huitema
> Cc: [email-masked]
> Subject: Re: [midcom] STUN security showstopper
> 
> 
>

---

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

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

If we make the hypothesis that the attacker can see the client's
traffic, then it is easy to predict the time at which the client will
start using STUN -- for example, just after receiving a SIP INVITE. That
offers interesting possibilities.

-- Christian Huitema

---

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

> From: Melinda Shore [mailto:[email-masked]]
> 
> At 12:12 PM 5/10/02 -0500, Andrew Molitor wrote:
> >        Doesn't the server signature cover the address and
> >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.

Problem is, the client cannot sign its own IP address and port either,
since the NAT is going to change them. As I said in the original
message, the root cause is that there is no functional difference
between a NAT and an attacker that does address spoofing.

-- Christian Huitema

---

From: Mark Taylor <[email-masked]>
Date: Fri, 10 May 2002 11:03:01 -0700 (PDT)

Christian Huitema wrote:

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

If it is a shared LAN, why wouldn't the attacker just
use some sort of packet sniffer applicaion to
eqavesdrop and be done with it

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com

---

From: "Sanjoy Sen"<[email-masked]>
Date: Fri, 10 May 2002 14:26:57 -0500

I'm wondering whether its possible to build a profile at the STUN server
based on the received (mapped) addresses over a sufficient period of time
and compare any new arrival against the profile. Similar ideas are used in
Intrusion Detection software.

In a very limiting deployment scenario, the STUN service may be configured
with the possible (expected) IP addresses of all NATs in the serving domain.

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Friday, May 10, 2002 2:09 PM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: RE: [midcom] STUN security showstopper
> 
> 
> I wonder where we go from here. I believe that the attack scenario
> demonstrates that the "protected" version of STUN is not much better
> than the nonce-protected version. The attack the nonce protection
> requires that the attacker be able to listen to the client's traffic;
> the attack against the protected version is enabled if the attacker is
> able to listen to the client's traffic. The client will detect the
> attack against the nonce because it will receive two responses; the
> client will also receive two responses in the attack against the
> protected version; in both cases, the attack will only go 
> undetected if
> the attacker succeeds in blocking either the direct request, or its
> response.
> 
> A first possibility is to re-assess the domain of 
> applicability of STUN.
> For example, if I use STUN on my home network which is directly
> connected to reputable ISP, I may not be too concerned by the attack
> scenario. If we follow this logic, we should keep STUN simple by just
> removing the cryptographic part, but restrict its application to
> "physically secure" attachment networks, such as home 
> networks directly
> connected to an ISP, or even shared access networks that use a
> "per-client" encryption key, i.e. in which the clients cannot look at
> each other traffic. Unprotected open networks, such as for example the
> IETF WIFI network, would be left out of the domain of application.
> 
> The problem with this "domain of applicability" option is that it is a
> bit of a cope-out, since it is very hard for the software in a mobile
> device to determine whether the local network is or is not physically
> secure -- the safe assumption being that it is never secure. In that
> case, the better security is probably to complement STUN with other
> solutions, which may or may not use cryptography. We have 
> heard of many
> partial solutions, such as:
> 
> 1) Wait for some time after the first response is received, 
> in order to
> detect duplicate responses, possibly contradictory responses.
> 
> 2) Renew the mapping requests at random, unpredictable intervals, in
> order to make interception difficult.
> 
> 3) Ask mappings from several different servers.
> 
> 4) Ask for a mapping response over a TLS channel.
> 
> Neither of these responses is perfect. The first solution raises an
> alarm when a weird event happens, but does not tell which of the
> responses is to be believed. The second an third responses make the
> attack harder by using time diversity and/or special diversity: the
> attacker must catch all the attempts, to diverse servers; OTOH, a
> dedicated attacker near the client could do just that. The TLS channel
> will provide a reference mapping to a TLS connection, not the UDP
> connection that the will be use for VoIP; it can only be used for some
> plausibility control, and is a poor defense against an attacker on the
> same subnet; in any case, a dedicated attacker could also 
> insert itself
> in the middle of a TLS connection. In short, none of that is terribly
> appealing.
> 
> We may want to consider another line of defense that defends 
> against the
> attacks that a false mapping enables, instead of trying to make sure
> that the mapping is genuine. For example, we could say that if you use
> STUN to set up an RTP connection, you should consider that the network
> connection is unsafe, and you should encrypt the RTC traffic, thus
> effectively thwarting the man in the middle attack. Or, if we have
> received several candidate mappings, we could conduct a 
> continuity test
> to check the mapping that are usable, thus thwarting the denial of
> service attack.
> 
> -- Christian Huitema
>

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 10 May 2002 12:30:45 -0700

> 	Hey, I know. Maybe we could go to work to develop a system
> by which the signaling infrastructure could securely communicate
> directly with the NAT device, and via that secure authenticated
> channel, establish and discover NAT bindings?

Or deploy IPv6, and be done with address translation...

> 	This sort of thing may actually be sort of moot, though.
> If I can intercept STUN messages, I can probably intercept SIP
> or MGCP messages, which are far more interesting. Directly
> hammering on signaling is easier and more powerful.

That is not correct, at least not for SIP. The client has the option to
connect to the SIP server using TLS, which effectively prevents this
kind of attacks.

> 	In fact, I don't even have to be a man in the middle.
> I can simply snoop for call setup attempts, and forge rejects
> back as fast as I can.

You can only do that if the client insists on using an insecure
communication channel with the server. On of the reason we should phase
out SIP over UDP.

> 	Fixing STUN, or creating a secure alternative, is a worthy
> goal. In the final analysis it may simply not matter.

Don't think so. Whatever new stuff we design will take several years to
deploy. In the meantime we will have to use solutions like STUN. (Or
IPv6 through Shipworm/Teredo, but the security issues are exactly the
same.)

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 10 May 2002 12:33:41 -0700

> with the possible (expected) IP addresses of all NATs in the serving 

That will certainly help against interception by 3rd parties that are on
the path between the NAT and the server. It will not help in the shared
access network scenario, since the attacker and the target are behind
the same NAT, and thus use the same set of plausible IP addresses.

-- Christian Huitema

---

From: "Sanjoy Sen"<[email-masked]>
Date: Fri, 10 May 2002 14:53:51 -0500

I thought that we're always dealing with your first scenario - attacker
between NAT and server.

In the shared network scenario, anybody who can sniff packets can do this
and the only way to prevent this is to encrypt all client packets. But this
can happen with or without the use of STUN.

> Sent: Friday, May 10, 2002 2:34 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore
> Cc: [email-masked]
> > with the possible (expected) IP addresses of all NATs in 
> the serving 
> > domain. 
>

---

From: [email-masked]
Date: Fri, 10 May 2002 15:40:53 -0400

If this is a theft attack from an internal attacker.,wouldn't the attacker
have to supply an internal address?

Attackers could mount DOS attacks by building profiles of reasonable
addresses but I do not see how a theft attack would work.

03:33:41 PM

To:   "Sanjoy Sen" <[email-masked]>, "Melinda Shore"
      <[email-masked]>
cc:   <[email-masked]>
Subject:  RE: [midcom] STUN security showstopper

-- Christian Huitema

---

From: "Sanjoy Sen"<[email-masked]>
Date: Fri, 10 May 2002 16:04:11 -0500

The difference is server vs client. Pretty much the same idea.

> Sent: Friday, May 10, 2002 2:35 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]
> Cc: 'Christian Huitema'; Melinda Shore; [email-masked]
> This is the 'reasonable address' idea that was dicussed 
> earlier and which
> was deprecated in favor of cryptogrphic methods.
> 
> 
> 
> 
> 
> 
> "Sanjoy Sen"<[email-masked]>@ietf.org on 
> 05/10/2002 03:26:57 PM
> 
> To:   "'Christian Huitema'" <[email-masked]>, 
> Melinda Shore
>        <[email-masked]>
> cc:   [email-masked]

---

From: Adina Simu <[email-masked]>
Date: Fri, 10 May 2002 15:05:33 -0700

(this might have been already proposed and rejected, if this is the case I 
apologize)

Once the client receives the STUN response containing a MAPPED ADDRESS, one 
way to verify that the address really points (belongs) to him is to ping a 
server in the Global space, using as source address the MAPPED ADDRESS. The 
ping packet should go through NATs untranslated, and it will hit the Global 
space with the same MAPPED address as source address. The reply will be 
destined to MAPPED address. If the client receives the reply, 
mapped-address is indeed his.

The server should not be the STUN server (in case somebody snoops packets 
destined to the STUN server). It could be the client's proxy... or similar.

-Adina

---

From: "Sanjoy Sen"<[email-masked]>
Date: Fri, 10 May 2002 17:12:09 -0500

Will the packet be properly routed in the private domain (behind NAT)?

> From: Adina Simu [mailto:[email-masked]]
> Sent: Friday, May 10, 2002 5:06 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 10 May 2002 16:09:43 -0700

> Once the client receives the STUN response containing a MAPPED
ADDRESS,
> one
> server in the Global space, using as source address the MAPPED
ADDRESS.
> The

That does not tell you whether there is a man in the middle. If there is
a m-i-m, the reply will go to the attacker, which will forward it.

> destined to the STUN server). It could be the client's proxy... or

That will only work if the NAT is not a symmetric NAT, but this is
indeed a generic STUN assumption.

---

From: Tom Gray <[email-masked]>
Date: Mon, 13 May 2002 05:21:12 -0700 (PDT)

At 03:34 PM 5/10/02 -0400, [email-masked] wrote:
>>This is the 'reasonable address' idea that was
discussed earlier and which
>>was deprecated in favor of cryptographic methods.

>Not really.  The "reasonable address" suggestion is
easily
>defeated, unfortunately, and that's why it hasn't
been pursued.

With the analysis that was provided at the beginning
of this thread, a surmise can be made that
cryptographic techniques can be defeated trivially.
They provide no protection at all against DOS attacks
from attacks supplying bogus addresses in requests
they hijack and pass onto the server. 

Something like the 'reasonable address', 'duplicate
reply detection'. 'server diversity' ... ideas could
be part of a system that supplements the deficiencies
in cryptographic solutions.

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com