Another SIP vulnerability documented
draft-state-sip-relay-attack-00 documents yet another vulnerability in SIP, this time allowing an attacker to use a victims credentials to send authenticated requests as the victim. This could be used, for example, to charge calls to the victim.
Any scalable solutions i've been able to come up with so far have been blown away by the fact the attacker can cause the target URI (as the victim sees it) to be whatever we want, as I just commented on sip@ietf.org:
Thanks for documenting this!
page 10:
It is worth noting that the protection
provided on the request URI is purely theoretical, as [RFC3261]
introduces an exception to the request URI checking required by
[RFC2617] in section 22.4:Another important consideration to keep in mind while thinking about solutions is that the Contact header in the dialog creating request can be pretty much anything bob likes if he also adds a Record-Route header in, leading to the dialog target URI at alice's UA being whatever bob wants, and thus the Authentication header can be manipulated to contain whatever the attacker wants in the uri parameter. To explain - consider Figure 1 in the draft.
F1 could be sent by bob@rouge.com as:
INVITE sip:alice@proxy.com SIP/2.0
Contact: <sip:+1-900-xxx@proxy.com>
Record-Route: <sip:bob@rouge.com;lr>thus, when alice creates the dialog, the remote URI will indeed be +1-900-xxx@proxy.com, and your in-dialog F10 message will be:
F10 INVITE Alice -> Bob
INVITE sip:+1-900-xxx@proxy.com SIP/2.0
Route: <sip:bob@rouge.com;lr>
Proxy-Authorization: Digest username="alice", realm="proxy.com", uri="sip:+1-900-xxx@proxy.com", nonce="f84f1cec41e6cbe5aea9c8e88d359543", response="3bea678acef9875433487f23a567d876", opaque="", algorithm=MD5
Content-Type: application/sdp
Content-Length:...presto - the authentication header now even contains the URI you want to call. note that a re-INVITE could also be done to change the target URI a few times to get different Authentication headers with different URIs in, all legitimate.
As to the potential solutions: both only accepting from registered contact or any attempt at avoiding sending re-INVITE [1] are in my opinion unfeasible and broken - i'll have some thought on others, though :-)
~ Theo
1 - REFER is another in-dialog method that could be abused - an OOD REFER may be accepted with authentication by - for example - a PSTN gateway. Social engineering of alice could result in alice's UA sending a REFER that could then be used.
I've just been for a long run and thought about this, and not come up with even a half sane solution: blurgh.
bed.
