Subject: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01)

From: Theo Zourzouvillys <[email-masked]>
Date: Sun, 22 Feb 2009 07:32:49 +0000

Hi,

i've just submitted a -01 based on the feedback i've received.

While we've all known about the issue forever, i've never sat down to
work out how bad it really is.

The results are pretty scary: "best" case scenario is a 1:10
amplification, and "worst" i can easily get a 1:350 amplification by
writing a quick script.

Additionally, out of every single vendor's implementation i looked at,
i've not yet found 1 that isn't vulnerable to being used in an attack:
phones, proxies, and SBCs can all be made to participate.

i'm surprised we've not seen this in the wild yet.  I've been recently
scanning for publicly accessible SIP servers, and out of a /8 (16
million hosts) that i've got through so far, there have been 72,725
SIP servers that are responding on port 5060 UDP.  that's a lot of
amplifiers that can be used in this attack: and that's only 1/100th of
the currently allocated RIR IPv4 address space.

 ~ Theo

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 22 Feb 2009 11:19:37 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Theo
> Zourzouvillys
> Sent: Sunday, February 22, 2009 2:33 AM
>

I'm not debating your draft's premise, but that last statement is highly dependent on the system and deployment's configuration.  For the remainder of this I'll use the term "SBC", but as far as I know proxies can do this too.

SBCs can be and almost always are configured to only accept requests from registered UA's.  So let's say you guessed one or many of them correctly; both their AoR's and guessed their full contact URI's (including username) and Via/Layer-3 IP:ports as well.  In typical deployments the request will be challenged, so the amplification is the 100 and 401/407 challenges, not a full call's worth of 18x/200 and RTP.  (And in practice there are some tricks the SBC can do to reduce actual amplification to 1:1, but it's rare to enable it - if amplification attacks are actually encountered, then this may change)

So the next issue is attack volume, and again it depends.  SBCs can and often do throttle the number of requests they'll accept in any time period from any given UA.  So they won't flood the target UA with bogus responses, because they won't accept that many spoofed requests from it to begin with - for some vendors they have hardware that will silently drop the excess.

What will sometimes happen is the SBC will dynamically black-list a flooding UA, so that if you successfully spoof one you can knock it out of service anyway, for a period of time.  Of course this triggers traps to notify the admins to look into it, but at least temporarily the damage is done. But that's by design - if you're successfully spoofing another UA, then the best an SBC can do is limit the impact of that to affect only the spoofed UA and not impact other users.

The harder problem is SIP trunks, a la IP-PBX's.  If they aren't a registering type of PBX, then their addresses are usually provisioned in the SBC's in terms of ACLs; both layer-3 ACLs and layer-7, such that you'd still have to spoof more than just IP:port.  But it's a harder problem because it's easier to guess that stuff for an Enterprise than from a subscriber, and because they often aren't challenge-able.  They're still usually throttled; and in theory potentially blacklisted, though that's less common to enable for PBX connections.  The only good side of it is the bigger the Enterprise, the more likely the SIP trunk is over a VPN of some type, where the spoofed requests would have to come in on that VPN to be processed.

BTW, we do recommend to providers that they employ uRPF on their edge routers, and some can and do.  Others don't have that ability or don't own the whole network, or don't want to take the performance impact of doing it on their routers. (because many routers take a hit for uRPF)

-hadriel

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sun, 22 Feb 2009 20:32:35 +0000

On Sun, Feb 22, 2009 at 4:19 PM, Hadriel Kaplan <[email-masked]> wrote:

> SBCs can be and almost always are configured to only accept requests from registered UA's.

What about an SBC that is configured at the edge of a network, for
example the thing that is the target of the URIs placed into ENUM?  Or
service providers who want to accept calls from "the internet" through
an SBC? These are vulnerable, are they not?

... i'm not worried about an amplification risk with a user that can
be authenticaticated: the 401/407 can be sent statelessly, meaning
only a very small amplification ratio and only 1:1 packets. (although
note that most UAs and proxies i tested did not currently send them
statelessly and instead created a IST for them along with them and
fire timer G!) - i imagine a well designed SBC would perform
differently, although i didn't happen to have a well designed SBC from
a certain vendor available for testing, so couldn't say :-)

> In typical deployments the request will be challenged, so the amplification is the 100 and 401/407 challenges

are there ever any reasons for an SBC to not send the 401/407
statelessly, and even send a 100?  A 1:2 attack is still bad, albeit a
far cry from the pathological case.

> not a full call's worth of 18x/200 and RTP.

bear in mind the via-cookie doesn't stop the in-dialog/rtp targeting,
but it does mean that it's traceable, and thus "manageable" once a
solution like via-cookie is in place. I think work needs to be done on
that issue too, but it's no where near as risky as this issue is.

> SBCs can and often do throttle the number of requests they'll accept in any time period from any given UA.  So they won't flood the target UA with bogus responses, because they won't accept that many spoofed requests from it to begin with - for some vendors they have hardware that will silently drop the excess.

Having a single SIP element doing rate limiting doesn't matter though
when there are 7.2 million SIP devices on the net [1].  If each one
will allow a 1:10 amplification, that's all a botnet needs to make it
10 times more valuable.  Hell, even a 1:2 amplification is worth it
for them, especially as it's reflected.

> What will sometimes happen is the SBC will dynamically black-list a flooding UA, so that if you successfully spoof one you can knock it out of service anyway, for a period of time.  Of course this…

... cookies solves this particular attack though, doesn't it?
(although authentication does as well in this scenario due to a
nonce?), in the same way a syncookie does for the SYN flooding
problems of decades gone by.

> BTW, we do recommend to providers that they employ uRPF on their edge routers, and some can and do.

absolutely.  over time we've got to the point where *most* UK SPs
worth their salt are doing RPF, but ....

> Others don't have that ability or don't own the whole network, or don't want to take the performance impact of doing it on their routers. (because many routers take a hit for uRPF)

It's partially loosing battle trying to get service providers to do it
(~6 years years ago i went on a rampage to try and get UK ISPs to do
it - some did, most didn't.  thankfully most have since then, though),
and while it is important (it makes bot nets lifes harder) in the
global scheme of  things, as you say many don't - and it only takes
one to have a problem.  Even if everyone did RPF at the access layer,
it doesn't stop attackers.  They just become service providers
themself (this is what spammers have done as thigns got more difficult
for them).  You don't even need to inject a prefix into global routing
tables: simply transmitting the packets is all it takes, and won't
even be traceable.

There are bunches of issues at IXs as well: there is no way ports can
be L3 filtered there currently.  The SIDR WG is trying to find
solutions to some this, but it's a long way off becoming reality imo.

 ~ Theo

1 - completely random guess from my (72k * 100).

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 22 Feb 2009 18:55:13 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Theo Zourzouvillys
> Sent: Sunday, February 22, 2009 3:33 PM
>
> example the thing that is the target of the URIs placed into ENUM?

Yup, these are essentially the same as IP-PBX trunks.  I don't know of many that allow requests in from truly unknown sources, though - they usually know the remote devices in advance, even when ENUM is used - so if they wanted to they could use IPSec or TLS if this became a problem. (some do today, but many don't - it seems many peer over private connections anyway)

> Or

Yup, but for those we strongly recommend IPsec, TLS, or even just TCP, where at least syncookies stops the trivial stuff.  Essentially what you're proposing seems to me similar in concept to syncookies, but at the next layer up.

> far cry from the pathological case.

Nope there's no reason I know of, but it's rare to do that.  Usually it's the registrar or some core device which sends the 401/407, so the SBC sends a 100 to stop the UA from retransmitting.  I have tried to convince people to let the SBC do it, but it hasn't gotten that much interest. (despite the fact it has more benefits than just this one issue)

> for them, especially as it's reflected.

Your point is that botnets can take advantage of the SBC's to amplify their attacks on other UA's, right?  But to do that they have to know the URI's/IP:port's of the other UA's they want to attack indirectly, and at that point why bother attacking via the SBC - just attack the UA's directly, spoofing other UA's, or spoofing the SBC's, or even not spoofing.  I mean it's a botnet, so you have enough resources to cause a resource exhaustion attack on any UA's, and who cares if they can trace it?

> problems of decades gone by.

Yup, either cookie or auth would solve it, but my guess is we'd still want to blacklist if it's more than a short-lived event.  That's what happens now: you get some leeway for a short while, but eventually you get kicked out for a longer period of time, because as far as we know you've got a broken UA or someone's learned your info, and we can't let you affect the overall network.

 -hadriel

---

From: Theo Zourzouvillys <[email-masked]>
Date: Mon, 23 Feb 2009 10:49:14 +0000

> Yup, these are essentially the same as IP-PBX trunks.  I don't know of many that allow requests in from truly unknown sources, though - they usually know the remote devices in advance, even when EN…

I believe (hope!) that these are going to get more common! ... the
driving reason behind me doing this was running through security
issues for deployment of public gateways for the 4.4.e164.arpa go-live
date  on March 11th (at *last*).  While i'd love the world to change
to TCP/TLS overnight, i just don't see it happening ... just "cause
UDP can be used for attacking 3rd parties"

Even if SBCs may not be commonly deployed in that way, there are
certainly millions of SIP devices that are.  Think all the asterisk
machines hosted on public IPs, for example.

> Essentially what you're proposing seems to me similar in concept to syncookies, but at the next layer up.

yeah, it is - in fact probably why i subconsciously called them via cookies :-)

> Your point is that botnets can take advantage of the SBC's to amplify their attacks on other UA's, right?

No!  Attacking UAs isn't really that much of a worry (as 401/407 can
"fix" that, especially as UDP scales so well).  It's that you can use
SBCs to amplify attacks on anything you like.

Botnets can take advantages of SIP elements to attack anything not
just UAs.  "anything" could be a DNS server, mail server, web server,
or anything with routable IP just due to sheer number of PPS and
throughput saturating links.

> I mean it's a botnet, so you have enough resources to cause a resource exhaustion attack on any UA's, and who cares if they can trace it?

Because it's another layer of indirection as well as amplification.
Indirection makes traceability harder, which means longer before
machines initiating attacks get discovered.  Amplification means
networks hosting the zombies are less likely to notice initially. so
it's a double fail for us :-)

> Yup, either cookie or auth would solve it, but my guess is we'd still want to blacklist if it's more than a short-lived event.  That's what happens now: you get some leeway for a short while, but e…

Lets say i have a 2mbit link at home.  Given the 1:350 example, I
could theoretically generate a 700mbit attack against anything i
wanted.

In the case of a botnet, they can use 4000 machines sending out a
single 500 byte INVITE every second, which would result in the same
thing.

 ~ Theo

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 23 Feb 2009 16:17:41 -0500

On Mon, 2009-02-23 at 10:49 +0000, Theo Zourzouvillys wrote:
> > Yup, these are essentially the same as IP-PBX trunks.  I don't know
> of many that allow requests in from truly unknown sources, though -
> they usually know the remote devices in advance, even when ENUM is
> used - so if they wanted to they could use IPSec or TLS if this became
> a problem. (some do today, but many don't - it seems many peer over
> private connections anyway)
> 
> I believe (hope!) that these are going to get more common!

Yes, Hadriel, you're thinking in a rather PSTN way.  Suppose I change a
few words in your sentence:  "I don't know of many Web servers that
allow requests in from truly unknown sources."  In the Pingtel days, our
gateway SBC would accept SIP calls from anywhere across the great
Internet.  Our current IT administration is a bit more backward.  But
we'll convince them eventually!

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Feb 2009 18:34:26 -0500

> From: Dale Worley [mailto:[email-masked]]
> Sent: Monday, February 23, 2009 4:18 PM
>
> Yes, Hadriel, you're thinking in a rather PSTN way.

No I'm not.  I'm merely indicating what I believe the common scenarios are as I see them today.  It has no relation to how my neurons interact.

-hadriel