Friday, February 20, 2009
Addressing an Amplification Vulnerability in SIP Servers
I don't like elephants.
There has been a great big elephant sitting in SIP that no one has wanted to talk about, for a long time. Problem is, I don't like elephants. They scare me.
People that are not intimate with SIP seem most surprised that a publicly accessible SIP server can commonly be used as an amplifier in a reflected denial of service attack. They shouldn't be. It's been like that forever.
So after years of ignoring the elephant in the room, i've tried to start tackling it, and have submitted some discussion on the matter along with an potential solution draft-zourzouvillys-sip-via-cookie-00.
It's not a complete solution to address all of the issues, but it brings UDP in line with stream based (and DTLS) transports so we can build a solution on top of this which mitigates the issues with in-dialog initiated attacks and RTP steering.
I AM THE SCARE MONGER, AND I BRING YOU ..... SCARES!
Until the problem this draft is trying to solve is fixed, any publicly accessible SIP server listening on UDP can likely be used as a amplifier in a reflected denial of service attack. And that's bad, for all of us on the internet, not just the SIP world. It means a SIP server can be used by an attacker as to amplify an attack against non-SIP infrastructure - that could be a web server, router, DNS server, or anything else an attacker so chooses.
By amplifier, we're talking one spoofed UDP request sent by an attacker resulting in 11 UDP responses sent to the victim (combined with other attacks, the pathological case results in ~35 UDP packets being sent to the victim from a single one by the attacker, along with a significant number of RTP packets). Neither the victim nor the attacker need to have an account with the SI P server ("SIP server", for example, could be an asterisk install or just a bog standard SIP phone) - it just needs to be accessible and process requests statefully (and most do).
Ohh, and because it's UDP, it's not possible to trace the attacker, meaning we can't even find them and shut them down. woo.
Outlook
In the longer term, we've still got a few other elephants that need talking about: RTP target verification and Contact/Route validation for dialog creation are just two that can currently be abused for some potentially similarly scary attacks, and need to be solved rather than ignored.
Note that none of this is new. This kind of feels like DNS all over again :-)
ho hum.
3 Comments:
I must admit I don't know much about SIP so it's probably a stupid question, but is it worth thinking about how the port number in the cookie is generated?
James - while it can be done in any way an implementer chooses to do it, the way i've documented (and is suggested) is defined as putting the port in to the hmac hash:
HMAC(ts || ":" || src_ip || ":" || src_port, key)
so to generate a cookie using an MD5 HMAC for a request from UDP source 192.0.2.1 port 5060 at timestamp 1234567890, and a private key of "nomnomnom" would be:
HMAC("1234567890:192.0.2.1:5060", "nomnomnom")
as a cookie, this could be sent back to the client as:
cookie=1234567890-a23e025b387a5f8c4434a3292c9febe2
does this answer your question?
I think so =) I was concerned that the hash might be easily guessed if the source port was predictable, but your example with the private key clarifies that.
I guess it's possible for less well thought out implementation to generate bad cookies :-)
Post a Comment
Links to this post:
Create a Link
<< Home