Friday, March 6, 2009
SIP URI syntax is broken with IPv6 & Generic URIs
Well, actually, the way a bunch of commonly used URI schemes define their IPv6 syntax doesn't match what is allowed in the generic syntax defined in RFC 3986.
SIP, (as well as a number of other URI schemes) define IPv6 literal URIs to be enclosed in square brackets to differentiate them, for example:
sip:[XXXX:XXXX::XXXX]:5060
iax:[2001:db8::1]:4569/alice?friends
Presumably, this is because of the "host" ABNF rule defined in RFC 3986:
host = IP-literal / IPv4address / reg-name
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
The problem with this is that the host rule is only used when the absolute-URI contains '://':
absolute-URI = scheme ":" hier-part [ "?" query ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-emptyauthority = [ userinfo "@" ] host [ ":" port ]
so URI schemes such as sip where the URI doesn't contain a ://, then an IPv6 address would instead match path-rootless:
path-rootless = segment-nz *( "/" segment )
segment-nz = 1*pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Specifically, this means that only the following un-escaped characters are allowed:
- A-Za-z
- 0-9
- : @
- ! $ & " ( ) * + , ; =
Any other characters must be encoded using %XX format.
While this won't break SIP elements out there, one thing is will break is trying to use an IPv6 address literal somewhere where a generic URI is expected, for example:
- Generic URI parser
- XML Schema "anyURI" datatype
- HTML href attribute
... and anything else that expects a URI.
Note that implementations of above may use RFC 2396 (and RFC 2397 to add support for IPv6 literals) instead.
The following other URIs schemes are also affected:
- h323
- im
- mailto
- pres
- xmpp
It seems that most people think that RFC 3986 needs to be updated.
The original thread discussing this on sip@ietf.org.org can be found here.
Thursday, March 5, 2009
SIP relay attack summary: It's a big User Agent FAIL.
To summarise the document, it claims there are essentially 3 different attacks, all similar in the result - a 3rd party could use a victims valid credentials for authentication, resulting in - for example - the victim being charged for calls made by the attacker.
Attack 1: Direct Relay (fig 1)
bob alice +1-900-xxx
proxy.com @rogue.com @proxy.com @proxy.com
| | | |
| | INVITE F1 | |
| |---------------->| |
| | 200 OK F2 | |
| |<----------------| |
| | ACK F3 | |
| |---------------->| |
| | | |
| | media session | |
| |.................| |
| | | |
| | INVITE F4 | |
| |<----------------| |
| modify | |
| the request | |
| INVITE F5 | | |
|<----------------| | |
| 407 F6 | | |
|---------------->| | |
| ACK F7 | | |
|<----------------| | |
| reverse | |
| the changes | |
| | 407 F8 | |
| |---------------->| |
| | ACK F9 | |
| |<----------------| |
| modify | |
| the request | |
| | INVITE(auth) F10| |
| INVITE(auth) F11|<----------------| |
|<----------------| | |
| INVITE F12 | | |
|----------------------------------------------->|
| | | |
In this attack, the attacker sends an INVITE directly to the victim. The victim answers and the call starts. The attacker then forces the victim to send a re-INVITE: possible though session timers, or possibly through social engineering (e.g, getting the call put on hold).
Once the attacker receives the re-INVITE send by the victim, an INVITE is sent to the proxy of the service provider that the victim uses. The service provider will respond back to the attacker with a 407 along with a Proxy-Authenticate header containing a realm and nonce.
The attacker then copies the Proxy-Authenticate header in to it's own 407 response (to the in-dialog re-INVITE), which the victim receives. The victim then re-sends the re-INVITE with valid Proxy-Authorization header credentials.
At this point, the attacker receives the re-INVITE with credentials in, and adds into the INVITE it originally sent to the service provider.
Because these credentials are legitimate, and the information covered by the response in the authorization header is the same, the call is allowed.
Solution
The solution to this attack is really simple, and something that all UAs should be doing already: A SIP UA must limit the scope in which it will send authentication credentials.
While it seems like every UA out there should already be doing that, it would appear many don't.
Summary
This is a SIP User Agent security FAIL, not a problem with SIP.
Attack 2: Through outbound proxy (fig 2)
bob alice
p2.com @rogue.com proxy.com @proxy.com
| | | |
| | INVITE F1 | INVITE F2 |
| |--------------->|--------------->|
| | 200 OK F4 | 200 OK F3 |
| |<---------------|<---------------|
| | ACK F5 | ACK F6 |
| |--------------->|--------------->|
| | | |
| | mediasession |
| |.................................|
| | | |
| | INVITE F8 | INVITE F7 |
| |<---------------|<---------------|
| modify | |
| the request | |
| INVITE F9 | | |
|<---------------| | |
| 407 F10 | | |
|--------------->| | |
| ACK F11 | | |
|<---------------| | |
| reverse | |
| the changes | |
| | 407 F12 | 407 F13 |
| |--------------->|--------------->|
| | ACK F15 | ACK F14 |
| |<---------------|<---------------|
| | INV w/auth F17| INV w/auth F16 |
| |<---------------|<---------------|
| modify | |
| the request | |
| | | |
| INV w/auth F18 | | |
|<---------------| | |
| | | |
So presuming we've got a well configured SIP User Agent that only sends credentials to 407 responses received through the proxy it's configured with, the second attack highlighted in the draft is a method by which the attacker can perform the same operation, but through the proxy that the victim uses, by sending a call to the UA through the proxy.
Of course, any sensibly configured outbound proxy would remove credentials at the edge of the network that relate to the realms that the administrative domain the proxy is in may generate, rather than leave them in.
Assuming a well configured proxy is at play, this leaves an attack where a SIP User Agent which has credentials for 2 authentication realms - lets say proxy.atlanta.com and proxy.billoxi.com may potentially be tricked into sending credentials for proxy.atlana.com through it's proxy.billoxi.com proxy, and therefore wouldn't be protected by the network stripping out the credentials.
Solution
As in Attack #1, a User Agent should simply ensure that the scope in which it will send credentials is limited. A UA registered with two providers should only ever send proxy authentication details to the outbound proxy those credentials have been configured for.
Summary
This is a SIP User Agent security FAIL, and not a problem with SIP.
Attack 3: Directed Response (fig 3)
bob alice
proxy.com @rogue.com proxy.com @proxy.com
| | | |
| | INVITE F1 | INVITE F2 |
| |<---------------|<---------------|
| remove proxy.com | |
| from Record-Route | |
| and Via headers | |
| | 200 OK F3 |
| |-------------------------------->|
| | ACK F4 |
| |<--------------------------------|
| | | |
| | mediasession |
| |.................................|
| | | |
| | INVITE F6 | INVITE F5 |
| |<--------------------------------|
| modify | |
| the request | |
| INVITE F7 | | |
|<---------------| | |
| 407 F8 | | |
|--------------->| | |
| ACK F9 | | |
|<---------------| | |
| reverse | |
| the changes | |
| | 407 F10 |
| |-------------------------------->|
| | ACK F11 |
| |<--------------------------------|
| | INV w/auth F12 |
| |<--------------------------------|
| modify | |
| the request | |
| | | |
| INV w/auth F13 | | |
|<---------------| | |
| | | |
If the attacker can get the victim to call the attacker through it's proxy and the proxy is victim is publicly accessible, then the attacker could theoretically remove any Record-Route and Via headers from the request, and send a 200 response directly back to the victim. As the call originally went through the proxy, the UA could conceivably think this call was secured, and thus when the re-INVITE is triggered, it would send the credentials.
Solution
As with both the other attacks, a User Agent should simply ensure that the scope in which it will send credentials is limited. A UA should never send credentials to in any request that is not within the scope the credentials have been provided for.
Similarly, it's common for a device to have an option similar to send in-dialog requests through outbound proxy (i.e, draft-outbound style routing), in which case even a badly written the User Agent is not vulnerable.
Summary
This is a SIP User Agent security FAIL, and not a problem with SIP.
Summary
In summary, I don't think this document presents any security issues in SIP itself, but does highlight and document some attack vectors that UA vendors should take on board when developing SIP User Agents, and a useful reminder to SIP service providers that you really need to really think about your network deployment (or pay me to do it for you).
Most specifically, a SIP user agent that is configured with proxy credentials should only ever send them in requests being transmitted directly to the outbound proxy the credentials have been provided for, and never to a 3rd party.
Service providers should ensure they remove authorization headers that relate to any realms they are administratively responsible for at the edge.
An important point in the above attacks is that a user agent appears to need to know when a request containing authentication is actually coming from it's proxy or not. In reality this is not the case, as the answer to the question of if credentials should be sent or not lies in where those credentials are going to be send to, not where the request for them came from.
Without sending all (including in-dialog) requests via an outbound proxy, it's not always going to be possible to tell when the next hop is really the proxy wanting authentication or not, specifically due to the fact that an in-dialog next hop may be a different hostname - for example sbc-13.b.london.edge.voip.co.uk - rather than the proxy itself - for example outbound.voip.co.uk.
The answer to this lies in (mutual) TLS between a SIP user agent and it's proxy, either TLS over TCP or more recently and cutting edge, DTLS over UDP. This allows for a client to be sure of where it's sending a request to before actually doing it, and thus that it doesn't leak it's proxy credentials when it shouldn't.
Until [D] TLS is universally deployed, a temporary workaround to this is ensure that the IP address you're sending to is in the SRV or A/AAA records of the proxy. While this is far from perfect, in reality it will work for most deployed service providers today. Note that if you do implement this, please remember to refresh the list based on TTL values in RRsets as well as the fact hosts may have both A, AAAA, and SRV records! and for goodness sake make the setting optional!
End-to-End & Multi-Hop proxy authentication
The above attacks don't cover end-to-end (WWW-Auth instead of proxy authentication), or multi-hop proxy authentication.
It's far harder to limit the scope in which the authentication should be released in these scenarios, as it's not a simple case of "only if sending to the proxy the credentials are for". Identity could be considered instead in these scenarios.
Although note that Identity isn't perfect yet - it has some issues with "baiting" - a subject for another day.
Wednesday, March 4, 2009
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.
SIP bug of the day: Cisco FAIL
Vendors that don't provide me with an email address of an english speaking human point of contact that can handle protocol bugs and isn't a front desk ticket person who has no idea what i'm talking about or tries to tell me to use another protocol like h323 instead can get their bugs stuck here instead!
Call from an E1:
INVITE sip:xxxxxx@X.X.X.X SIP/2.0
To: <sip:xxxxxx@X.X.X.X>
User-Agent: Cisco-SIPGateway/IOS-12.x
Our SIP server returns a 302 with new Contact:
SIP/2.0 302 Directed
Contact: <sip:Y.Y.Y.Y;param>
Server: InUrSIPPacketzRedirectingUr/INVITES
New INVITE following the 3xx FAIL:
INVITE sip:Y.Y.Y.Y;param SIP/2.0
To: <sip:@Y.Y.Y.Y>
User-Agent: Cisco-SIPGateway/IOS-12.x
Anyone from Cisco reading (and i know you do) - please can you get someone to fix it: I gave up trying to get bugs in your stacks fixed a long time ago :-)
Cisco IOS Software, 5350 Software (C5350-JK9S-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1)
SIP Security - User Interfaces
As SIP-enabled phones capable of receiving calls from callers with SIP URIs as identifiers, much thought needs to be given to how these identifiers (assuming they are verified) are rendered to end users.
It is common for a phone to render the "Display Name" in a SIP request on the phone's UI. This value is set by the caller themselves, an in the case where a caller is an attacker, can manipulate it to make the UI display a value of it's choice, for example:
From: "manager@hsbc.co.uk" <sip:attacker@evil.example.com>;tag=xxx
Every single SIP device I tested displayed this as manager@hsbc.co.uk on the screen.
Even more thought needs to be taken when allowing Call-Info. A picture of a padlock could be sent with Call-Info to render a picture of a padlock on the screen, lulling the user into thinking the call is secure.
Some people suggest instead you render the URI of the identity, but how do UIs render this?
From: <sip:manager%40hsbc.co.uk%00@evil.example.com>;tag=xxx
You guessed it, on the phone on my desk, I get:
Ahem.
Identity in SIP is more than just technical solutions. User Interfaces need to be carefully considered.
Are you sure you *really* know what a sequence of characters is?
Just incase you weren't too sure, RFC 3987 defines it for you:
sequence of characters: A sequence of characters (one after another).
ohh, really? Well, just incase you weren't sure, lets define a sequence of octets:
sequence of octets: A sequence of octets (one after another).
Labels: ietf
Monday, March 2, 2009
P2P Architectures (and Zebras)
Gonzalo Camarillo has just submitted draft-iab-p2p-archs-00, an overview on P2P architectures:
In this document we provide a survey of P2P (Peer-to-Peer) systems.
The survey includes a definition and a taxonomy of P2P systems. This
survey also includes a description of which types of applications can
be built with P2P technologies and examples of P2P applications that
are currently in use on the Internet. Finally, we discuss
architectural tradeoffs and provide guidelines for deciding whether
or not a P2P architecture would be suitable to meet the requirements
of a given application.
The documents definition of a P2P system:
We consider a system to be P2P if the elements that form the system share their resources in order to provide the service the system has been designed to provide.
The elements in the system both provide services to other elements and request services from other elements.
and a real quote from the draft:
ZebraNet is a network used to track Zebras in the wild.
It contains zebras, so must be worth a read!