Network Working Group T. Zourzouvillys Internet-Draft VoIP.co.uk Intended status: Informational February 20, 2009 Expires: August 24, 2009 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Servers draft-zourzouvillys-sip-via-cookie-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 24, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document addresses a vulnerability in publicly accessible SIP Zourzouvillys Expires August 24, 2009 [Page 1] Internet-Draft SIP Via Cookie February 2009 servers (servers includes both UASes and proxies) that enables them to be used as an amplifier in a reflected denial of service attack. As a proposed solution, a mechanism for stateless cookie exchange between a SIP server and client to ensure that a public SIP server that wishes to accept SIP requests from hosts over datagram can not be used as an amplifier for a denial of service attack. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Vulnerability: Using SIP servers to reflect and amplify a UDP packet . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Proposed Solution: Cookie value in Via header . . . . . . . . 6 4.1. Client Behaviour . . . . . . . . . . . . . . . . . . . . . 6 4.2. Server Behaviour . . . . . . . . . . . . . . . . . . . . . 7 4.3. Stateless Cookie Generation . . . . . . . . . . . . . . . 8 4.4. Parameter Definition . . . . . . . . . . . . . . . . . . . 8 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Deprecate UDP transports . . . . . . . . . . . . . . . . . 9 5.2. Use Digest Authentication . . . . . . . . . . . . . . . . 9 5.3. Use a new authentication scheme . . . . . . . . . . . . . 9 5.4. Re-engineer the internet . . . . . . . . . . . . . . . . . 10 5.5. Rate Limit . . . . . . . . . . . . . . . . . . . . . . . . 10 5.6. Use Identity . . . . . . . . . . . . . . . . . . . . . . . 10 5.7. Listen for hints something is wrong . . . . . . . . . . . 10 5.8. Have a UAC CANCEL any unsolicited responses . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7.1. cookie parameter . . . . . . . . . . . . . . . . . . . . . 12 7.2. 4XX Via Cookie Required . . . . . . . . . . . . . . . . . 12 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Zourzouvillys Expires August 24, 2009 [Page 2] Internet-Draft SIP Via Cookie February 2009 1. Introduction Because SIP can be used over a datagram transport (such as UDP), any SIP server that processes requests (servers includes UASes and proxies) received from sources that can not be verified (such as the general internet) can be used in an amplification attack where an attacker can send a SIP request with the source address spoofed to be that of a victim. The SIP server then sends a far larger number of responses to the victim than the attacker sent to the server due to server transaction mechanisms used in SIP requests received over unreliable transports. To aid in mitigating this amplification attack, a new SIP Via parameter, "cookie" is defined which allows a stateless cookie exchange to occur and a client demonstrate to a server it is capable of receiving responses on the apparent source address/port and can process those responses. 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Vulnerability: Using SIP servers to reflect and amplify a UDP packet This section describes setting up an attack on a victim over the public internet using a publicly accessible stateful SIP server (e.g, a proxy or User Agent) that has been configured to process requests without authentication - for example a proxy responsible for a URI listed in a public ENUM record. Consider a SIP proxy (P1) that is authoritative for atlanta.com. It is configured to process SIP requests received from the public internet over UDP and TCP, and forward those requests statefully to the users it serves. An attacker can craft an INVITE request (F1) and sent it to P1, with the source IP address of a victim. P1 will receive the request, and then send a 100 Processing response (F2) to the apparent source of the address, the victim. Assuming that the R-URI is the INVITE is valid, the call may progress, resulting in zero or more provisional responses before a 2xx class response when the call is answered. At this point, Alice's UA will start transmitting RTP to the victim, and continue to Zourzouvillys Expires August 24, 2009 [Page 3] Internet-Draft SIP Via Cookie February 2009 retransmit the SIP responses (F4). Undoubtedly after a few seconds of Alice not getting a response after she answered the call, she will hang up. This will cause the RTP to stop being transmitted, but will generate a BYE request (F5) from P1 to the Victim. F5 will be transmitted to Victim a total of 12 times using the default timers specified in RFC 3261. Adding all of these requests together, we come to a minimum of 22 messages (1 for the 100, 1 or more for a 180, and 10 for the 200 OK, and 10 BYE requests), all sent to the Victim from a single spoofed UDP request sent by the Attacker. F1 INVITE Attacker -> P1 INVITE sip:alice@atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport Call-ID: abcdef From: ;tag=x To: sip:z@f.com CSeq: 1 INVITE Content-Type: application/sdp Contact: v=0 o=- 1 1 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 1234 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 100 Trying P1 -> Victim SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg CSeq: 1 INVITE F3 180 Ringing P1 -> Victim Zourzouvillys Expires August 24, 2009 [Page 4] Internet-Draft SIP Via Cookie February 2009 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg CSeq: 1 INVITE F4 200 OK P1 -> Victim SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg CSeq: 1 INVITE Contact: Content-Type: application/sdp v=0 o=- 1 1 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 1234 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F5 BYE P1 -> Victim BYE sip:192.0.2.1:5060 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg Additionally, if F1 contained a 100rel extension and the target supported it, a flurry of re-transmits of the reliable 1xx response would also be transmitted to the victim in addition to the 2xx responses and BYE retransmits. The scenario layed out above assumes that an attacker knows a valid R-URI that can be used as the reflector. These URIs could be collected by harvesting addresses found on the World Wide Web in the Zourzouvillys Expires August 24, 2009 [Page 5] Internet-Draft SIP Via Cookie February 2009 same way as spammers do for email addresses, or perhaps more simply by walking the global e164.arpa tree or private ones. An attacker could also perform a dictionary attack to try and solicit some valid addresses. However, even in the case of a failure response in the dictionary example presented above, a single request will still generate 11 responses if any part of the processing of the request results in the request needing to be handled statelessly (for example, a proxy forwarding the response to a next-hop address establishes by performing an SRV lookup that resulted in multiple potential targets) due to timer G. This problem is not unique to INVITE requests. There are a number of attack vectors in processing non-INVITE requests too. The most notable being a SUBSCRIBE generating a response along with a NOTIFY and it's associated retransmits. An spoofed OPTIONS request without an SDP offer will also potentially result in a larger response being sent back, allowing a reflected amplification attack. 4. Proposed Solution: Cookie value in Via header The proposed solution to this problem is to enable exchange of a stateless cookie between a server and a client on a hop-by-hop basis in a via header field parameter. The solution provides a mechanism for clients to indicate support for this extension, does not require any extra state to be stored on servers, and traverses proxies that do not implement this specification. It also provides a mechanism to allow cookies to be re-used by clients to limit the round-tripping of requests for validation. 4.1. Client Behaviour The client behaviour specified here affects the transport processing defined in Section 18.1 of SIP [RFC3261]. A client, compliant to this specification (clients include UACs and proxies), MUST include a "cookie" parameter in the top Via header field value of any requests it generates that are to be sent out over a datagram transport that is not secured by DTLS (e.g, UDP). This parameter will have no value for the first request to a given remote address/port/transport tuple, and indicates that the client supports this specification. If the client has previously received a cookie Zourzouvillys Expires August 24, 2009 [Page 6] Internet-Draft SIP Via Cookie February 2009 from the remote target, that value SHOULD be included as the value of the "cookie" parameter. If the client receives a response to a request sent with a cookie parameter with a status code of 4XX, the request SHOULD be retransmitted. The retransmitted request will contain a new branch value (As it is a new request), and the cookie parameter from the 4XX response from the first request MUST be copied in to the top Via of the new request. The new request must then be transmitted to the same target ip address and port as the original request was. If the response for the second request solicits a 4XX response a second time, the transaction MUST be aborted and processing continue by trying another server as defined in [RFC3263] or return the final response to the TU. 4.2. Server Behaviour The server behaviour specified here affects the transport processing defined in Section 18.2 of SIP [RFC3261]. When a server compliant to this specification (which can be a proxy or UAS) receives a SIP request, it examines the topmost Via header field value. If this Via header field value contains a "cookie" parameter, and the value of the parameter is is equal to a cookie generated for the client previously, the cookie parameter MUST be removed and the request continues begin processed as normal. The cookie is removed to ensure that the cookie is not leaked to a upstream server, which could then maliciously use the value for attacking the client. If a request is received from an IP address that could be spoofable (i.e, any request received from the general internet), and that request is going to have a server transaction created for it, and the top via field contains a cookie parameter, then the server SHOULD generate a new cookie for this source and generates a 4XX response, and place the cookie value into the cookie parameter of the top via field before sending the response statelessly. If a request is received to a public server over a datagram transport, and the server is unable to authenticate the client, and the top via header field does not contain a "cookie" parameter, then the server SHOULD reject the request with a 4XX Stateless Cookie Required response. Note that a server that is providing services to clients that authenticate (for example, an outbound proxy) SHOULD always send the Zourzouvillys Expires August 24, 2009 [Page 7] Internet-Draft SIP Via Cookie February 2009 401/407 statelessly to avoid being used as a reflecting amplifier in a denial of service attack. 4.3. Stateless Cookie Generation A possible way to create a stateless cookie for a client is to generate a hashed MAC [RFC2104], H1 over the concatenation of a timestamp, and the normalized values of the source IP address and port of the request: H1 = HMAC(ts || ":" || src_ip || ":" || src_port, key) The resuling cookie could then the concatenation of timestamp used for generating the hash, a "-", and H1: cookie = ( ts || ":" || H1 ) To verify a cookie, extract the timestamp and ensure it is within an acceptable period of time, and then generate the hash again using the timestamp extracted from the cookie. If the two values match, then the cookie is valid. Note that stateless deployments that run multiple stack instances on the same IP address, port, and transport (e.g, using anycast) need to share the same key. 4.4. Parameter Definition cookie-param = "cookie" = 1*paramchar 4.5. Example All non essential details have been excluded for brevity. F1 INVITE bob -> P1 INVITE sip:alice@atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK-AAAA;cookie F2 4xx P1 -> bob SIP/2.0 4xx Via Cookie Required Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK-AAAA;cookie=xxxx F3 INVITE bob -> P1 Zourzouvillys Expires August 24, 2009 [Page 8] Internet-Draft SIP Via Cookie February 2009 INVITE sip:alice@atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK-BBBB;cookie=xxxx 5. Other Solutions A number of other solutions were considered. Here are a list of some of them and why they were rejected. 5.1. Deprecate UDP transports A way of mitigating this attack would be for publicly accessible SIP servers to not enable UDP support on public interfaces. Removing such a commonly deployed compontent from systems at this time seems to extreme a solution. Additionally, UDP is a useful protocol for publicly accessible servers due to it's scalability features. Anycast can be used with stateless proxies to scale horizontally, something that can not be achieved with connection oriented transports like TCP or ones that require state like DTLS when a large number of deployed SIP UAs do not yet support RFC 3263. 5.2. Use Digest Authentication A public server could require standard digest authentication (and nonces) to be used instead. There are 2 issues with this potential solution: A SIP UAC would not know if it should query the user for credentials or just send straight away with an "anonymous" username as suggested in 22.1 of [RFC3261]. Secondly, this solution does not perform well over multi-hop UDP requests, as each hop would need to send a 401/407 response all the way back to the UAC to re-issue the request again. 5.3. Use a new authentication scheme A new authentication scheme could be defined that indicates the UAC does not wish to provide any authentication, thus getting over the problem of a UAC not knowing if it should ask the user for authentication or not. The scheme could provide a nonce in the 401/ 407 response, which then would need to be copied into the new request. Zourzouvillys Expires August 24, 2009 [Page 9] Internet-Draft SIP Via Cookie February 2009 While this authentication may be useful for other functionality in SIP, it does not solve the multi-hop UDP problem mentioned in the previous section. 5.4. Re-engineer the internet Another solution could be to simply blame service providers that allow spoofing of source addresses rather than solve the problem in SIP itself. This solution was rejected as potentially being to extreme a solution. 5.5. Rate Limit Limit number of active server transactions to any given source ip/ port. This is always a good idea in almost any implementation, but does not solve the problem as an attacker could use a small number of transactions on a large number of public SIP servers to attack the victim successfully. 5.6. Use Identity While Identity initially seems like a good candidate, it would stop anonymous users being able to send requests. Additionally, without extra constraints placed on sending responses of identity header check failures to ensure they are sent statelessly, it would not actually stop the vulnerability described in this document as a valid request sent to a different server could be replayed by spoofing the request to P1 with a source of the victim, resulting in the identity within the Identity header of the original (legitimate) request being essentially joe jobbed. Of course, there is also nothing to stop a mallicious user creating their own identity and using it in the spoofed requests. These would pass identity checks for public services (as they're valid), but without a reputation system for Identity, requests will still be processed and victims attacked. 5.7. Listen for hints something is wrong Listen for ICMP type 3 requests. Not so useful if the victim is a SIP server itself, nor if the victim is so bogged down it can't send them. Additionally, most operating systems rate limit the ICMP messages number sent per second. Even if the victim was not an SIP Zourzouvillys Expires August 24, 2009 [Page 10] Internet-Draft SIP Via Cookie February 2009 server, a known open UDP port could be used - for example by crafting the request to come from port 53 of the victim, when the victim is a DNS server. 5.8. Have a UAC CANCEL any unsolicited responses Firstly, this does not work if the victim is not a SIP stack. Even if it were a SIP stack and it knew it was being spoofed (for example, due to the received parameter in the only via of a response matching it's public IP address), this does not solve non-INVITE transactions problems. Also, the UAC may be so overloaded already it is not able to send the CANCEL out. Additionally, draft-sparks-sip-invfix-02 modifes ICT handling to drop responses that do not match an existing client transaction. 6. Security Considerations This document is specifically designed to address a security issue in SIP when accepting requests over a datagram transport. The proposed solution provides a mechanism to mitigate a SIP stack being used as an amplifier. A response sent by a proxy that requires via cookie support for clients trying to send a request to it will generally generate smaller responses than the original request due to not including SDP in the response. Even in the case of no SDP offer in the original request, the response will only be marginally larger than the request. This document does not consider attacks that can be performed by creating an INVITE session with a server and setting the remote destination address for the RTP to a victim, and could be the subject of further study. A cookie value could be leaked to a 3rd party if multiple instances of a SIP stack are running on the same IP address/port (i.e, using anycast), but only one of them implements this specification. In such a case, the first request may cause a cookie to be generated and a 4XX response sent to the client, and the second request including the cookie go to the instance that does not support this specification, so the request is forwarded without removing the cookie value, and thus leaked to any party the request was forwarded to. While the potential for attack is very limited (especially if cookie lifetime is kept very short), deployments must ensure that if Zourzouvillys Expires August 24, 2009 [Page 11] Internet-Draft SIP Via Cookie February 2009 multiple servers are running on the same address, they either always implement this specification or do not. 7. IANA Considerations 7.1. cookie parameter The IANA is requested to register the 'cookie' Via header field parameter, which is defined in Section X, under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- --------- Via cookie No [RFCxxxx] 7.2. 4XX Via Cookie Required The IANA is requested to register a new SIP response code whicvh is described in section X. It is sent when a server receives a SIP request over a datagram transport that lacks a cookie field parameter value. Response Code Number: 4XX Default Reason Phrase: Via Cookie Required 8. Open Issues ISSUE 1: As transaction handling will need to be modified on the server, the only reason for generating a new branch before sending the second request with the cookie in is to traverse middleboxes that might be very broken. Using the same branch identifier in a way seems far nicer (... although arguably a violation of 3261). Thoughts? 9. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. Zourzouvillys Expires August 24, 2009 [Page 12] Internet-Draft SIP Via Cookie February 2009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Author's Address Theo Zourzouvillys VoIP.co.uk Commerce House Telford Road Bicester, Oxfordshire OX26 4LD UK Phone: +44 1908 764 181 Email: theo@voip.co.uk Zourzouvillys Expires August 24, 2009 [Page 13]