RUCUS H. Scholz Internet-Draft freenet Intended status: Informational June 9, 2009 Expires: December 11, 2009 SIP endpoint security case study draft-scholz-endpoint-security-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 December 11, 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 Scholz Expires December 11, 2009 [Page 1] Internet-Draft SIP endpoint security case study June 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Scholz Expires December 11, 2009 [Page 2] Internet-Draft SIP endpoint security case study June 2009 Abstract SIP endpoints are subject to unwanted communication often perceived as Spam over Internet Telephony (SPIT). This document describes caveats on various layers which can be abused to send unsolicited messages. As a result users receive a degraded experience. The issues found are based on case studies of various events seen in VoIP provider networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IP layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. IP Range Guessing . . . . . . . . . . . . . . . . . . . . 5 2.2. Packet filtering . . . . . . . . . . . . . . . . . . . . . 5 3. SIP layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Perceived Identity . . . . . . . . . . . . . . . . . . . . 6 4. Implementation Shortcomings . . . . . . . . . . . . . . . . . 7 4.1. Incomplete Implementations . . . . . . . . . . . . . . . . 7 4.2. Defective Implementations . . . . . . . . . . . . . . . . 7 4.2.1. Mapping from AORs to connected phones . . . . . . . . 7 5. Case studies . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. German 5199362832664 case . . . . . . . . . . . . . . . . 8 5.2. DSL/VoIP router 0 Byte bug . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Scholz Expires December 11, 2009 [Page 3] Internet-Draft SIP endpoint security case study June 2009 1. Introduction Broadband access providers often ship access devices (IADs) which are by default VoIP enabled. Reasons for this are manifold are out of the scope of this document. The customer may or may not know about the VoIP feature set. The SIP user agents may suffer from implementation issues which are not necesarilly shortcomings of the SIP standards but rather poor implementations. In order to succesfully create a SIP dialog or make a remote phone ring the attacker needs to know the destination IP and port as well as the Contact the endpoint registered itself with. If the IP or port is wrong the message would not reach the remote SIP stack. If the requested URI does not exist the UAS should return a 404 (Not Found). Other security mechanisms (packet filter) or transport limitations (NAT bindings) may prevent communication as well. Scholz Expires December 11, 2009 [Page 4] Internet-Draft SIP endpoint security case study June 2009 2. IP layer In order to conduct a successful attack the attacker needs to know where to direct traffic to. In case of devices on the end customer premises the port density per device is rather low (i.e. one or two lines) compared to commercially used SIP trunks. To make up for this drawback the attacker has to target more devices and thus IP addresses. 2.1. IP Range Guessing SIP accounts may be tied to IP access products, i.e. part of Triple Play. In these cases an attacker only needs to identify IP ranges handed out to end customers. SIP services then may also be reachable on the same public IP address. IP access providers get assigned certain network ranges which they dynamically or statically hand out to their customers. These ranges are known to the public and can be abused. An attacker would gather list of IP ranges and attack these. Success rates are higher (80% during tests) compared to random IP addresses. 2.2. Packet filtering The SIP standard allows for direct (peer-to-peer) communication between SIP devices. In most scenarios a centralized approach with a SIP registrar is deployed, though. The SIP endpoint registers itself on a registrar server which is usually colocated in the ISPs datacenter. All signaling is inbound from that particular SIP registrar IP address or set of IP addresses. Large deployments usually rely on such a registrar as proxy and sometimes a B2BUA. In these scenarios the SIP endpoint would only receive inbound traffic from these configured IP addresses. All other traffic can be considered unsolicited. A device used in such an environment should ignore the rogue traffic and not pass it on to the SIP stack. Filtering rogue traffic on the SIP layer (i.e. by looking at Via headers) does not work as the Via header can be spoofed. In addition filtering on the SIP layer forces the device to parse potentially malicious messages. Scholz Expires December 11, 2009 [Page 5] Internet-Draft SIP endpoint security case study June 2009 3. SIP layer An attacker, just as any other SIP User-Agent, has to craft his own SIP requests and subsequent messages. He might choose to set, skip or modify header fields and values in order to confuse the victim. 3.1. Perceived Identity The calling party ID shown to the end user (i.e. in his phone display) cannot be assumed to be a strong identity as per [RFC4474]. While not compliant with recommendations UASes do pull the Caller ID based on one or more of these headers. Trust levels or priorities do differ between devices. o From displayname o From URI o Remote-Party-ID o P-Asserted-Identity Even when an ISP implements identity checks and verifies certain headers an atacker may still set false information inside SIP signaling. As an example an ITSP may compare the From URI against the credentials provided in the challenge authentication. But the ITSP may let the From displayname pass through to the remote end. The remote device then displays the unverified information carried in the displayname rather than the From URI. Scholz Expires December 11, 2009 [Page 6] Internet-Draft SIP endpoint security case study June 2009 4. Implementation Shortcomings Even with a flawless definition of SIP signaling devices are prone to mistakes. Problems arise due incomplete or defective implementations. 4.1. Incomplete Implementations SIP features various transport mechanisms for the caller identity. Mechanisms include the From header (as per [RFC3261]), the expired Remote-Party-ID draft and the P-Asserted-Identity suite ([RFC3323], [RFC3325]). A originator may choose to use an old mechnism (i.e. Remote-Party-ID) to signal a connected party. The intermediate entities are based on P-Asserted-Identityt and thus fail to check the Remote-Party-ID header. The terminating endpoint only supports Remote-Party-ID or prefers it over other headers. As a result the Remote-Party-ID can be freely set by the caller. 4.2. Defective Implementations 4.2.1. Mapping from AORs to connected phones To assure reachability for incoming sessions SIP endpoints frequently register themselves on a SIP registrar. Registration requires a username and credientials. On the SIP network these credentials map to a reachable SIP URI often perceived as phone number. During the registration process a unique but reusable Contact URI is used to identify a certain SIP account. An incoming call from the SIP network to the endpoint carries this Contact URI. SIP devices that connect more than just one account usually allow to map usernames (and thus Contacts) to handsets. If the Contact of an incoming request does match a known line the handset may ring. If the Contact does not match a 404 Not Found must be returned. Multiple devices are known to not properly check the received Contact of incomfing call setups. If the Contact is not locally known the devices fall back to ring all connected handsets. This misbehaviour allows an attacker to get around the requirement to know the current Contact of the victim. Scholz Expires December 11, 2009 [Page 7] Internet-Draft SIP endpoint security case study June 2009 5. Case studies This section describes real world attacks based on the issues described in the previous sections. 5.1. German 5199362832664 case In early September 2008 German VoIP users started to complain about their phones ringing at random times while displaying the Caller ID 5199362832664, though sometimes with a modified prefix. This case affected customers mostly based in Germany running on DSL lines. Affected devices were VoIP enabled DSL broadband routers. Analysis of the attack by various groups lead to the same conclusions. Klaus Darilion summed up the findings in [refs.ipcom]. The attacker crafted non-compliant SIP messages and sent these from one apparently unspoofed IP address (213.130.74.70 in Bulgaria) to millions of destinations. Destination IP addresses were blocks assigned to the large DSL and VoIP providers in Germany. The SIP stack on DSL routers used usually runs on the external dynamic IP address and listens on port 5060/UDP. The attacker directed the messages to this port and thus reached an huge number of devices. The signaled Contact in the Request URI was not locally known but the devices fell back to ring all connected phones instead. 5.2. DSL/VoIP router 0 Byte bug A SIP enabled DSL router tried to suppress malicous inbound SIP traffic by comparing the IP carried in the SIP Via header to the one configured in the SIP settings. This behaviour required that messages from untrusted sources had to be parsed and interpreted by the SIP stack. The attack in this case was to send an empty UDP message to the SIP device. The device pushed the message up into the SIP stack which immediately crashed. This resulted in the registered accounts being not reachable anymore. Scholz Expires December 11, 2009 [Page 8] Internet-Draft SIP endpoint security case study June 2009 6. Security Considerations This document does not introduce new risks but rather lists known problems. Scholz Expires December 11, 2009 [Page 9] Internet-Draft SIP endpoint security case study June 2009 7. Informative References [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [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. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [refs.ipcom] Darilion, K., "Analysis of a VoIP Attack", October 2008, < http://www.ipcom.at/fileadmin/public/ 2008-10-22_Analysis_of_a_VoIP_Attack.pdf>. Scholz Expires December 11, 2009 [Page 10] Internet-Draft SIP endpoint security case study June 2009 Author's Address Hendrik Scholz freenet Cityline GmbH Am Germaniahafen 1-7 Kiel 24143 Germany Phone: +49 (0) 431 9020 552 Email: hendrik.scholz@freenet.ag URI: http://freenet.ag Scholz Expires December 11, 2009 [Page 11]