E.T. Can’t Phone Home Security Issues with VoIP

1. E.T. Can’t Phone HomeSecurity Issues with VoIP Ofir Arkin Managing Security Architect

2. VoIP Overview The VoIP Threat Module The Session Initiation Protocol The Session Initiation Protocol Threat Module The RTP Protocol The RTP Threat Module Agenda

3. Overview IP Telephony, VoIP and VON

4. Overview • IP Telephony is defined as the use of IP networks to transmit both voice and data packets • VON (or Internet Telephony) is used to describe the usage of the Internet to transmit both voice and data packets • VoIP is used to describe the usage of managed IP networks to transmit both voice and data packets (usually associated with Carrier-Class networks) • In the course of History VON was the predecessor of VoIP, and its success led to the interest and development of IP Telephony and VoIP • Do you remember VocalTEC’s Internet Phone?

5. Overview • The IETF has defined many standard track IP Telephony protocols • Many IP Telephony protocols are still under a development / draft stage at the IETF • The IP Telephony protocols defined by the IETF can be used with different IP Telephony architectures: • Internet Telephony • Internet Telephony Service Providers (ITSPs) • Corporate LANs • Converged Network Architecture

6. Overview • The protocols combining any IP Telephony architecture are divided into the following roles: • Signaling Protocols • Media Transport Protocols • Supporting Protocols

7. Overview – Signaling Protocols • The VoIP Signaling Protocols perform the following services: • Locate a User – The ability to locate another user which whom a user wish to communicate with • Session Establishment – The ability of the called party to accept a call, reject a call, or redirect the call to another location or service • Session Setup Negotiation – The ability of the communicating parties to negotiate the set of parameters to use during the session, this includes, but not limited to, Audio encoding • Modify a Session – The ability to change a session’s parameters such as using a different Audio encoding, adding/removing a session participant, etc. • Teardowna Sessions – The ability to end a session

8. Overview – Media Transport Protocols • The Media Transport Protocols are used to carry voice samples (such as the Real Time Transport Protocol – RTP) • The media transport protocols are able to use a codec to digitize voice and to compress it into small samples that will be encapsulated within an IP transport protocol (usually UDP) and transported using an IP network

9. Overview – Supporting Protocols • These are the protocols which supports the various IP Telephony architectures: • For example: • Quality of Service (QoS) protocols (DiffServ, IntServ, RSVP, MPLS, 802.1q) • DNS (with or without extensions) • Routing – TRIP (Telephony Routing over IP) • Etc.

10. OverviewIETF’s VoIP Architecture • The IETF’s VoIP architecture is based on a number of protocols, each of which is only a small part of the complete solution • Therefore the IETF’s VoIP architecture is a very flexible one • A Telephony Architecture which connects the PSTN with VoIP–based Network(s) has to have elements which will translate signalingand voice samples between the PSTN and the VoIP IP Network and vice versa. Therefore some gateways are introduced with the infrastructure

11. Overview – VoIP Signaling Protocols, Definitions IETF’s VoIP Architecture • Media Gateway (MG) – A network element which converts audio signals carried on telephone circuits into data packets carried in packet switched networks, and vice versa • Media Gateway Controller (MGC) – Used to control a Media Gateway • Signaling Gateway (SG) – A network element which converts SS7 signaling information from the PSTN into formats understood by the network elements in the IP network, and presents an accurate view of the elements of the IP network to the SS7 network (and vice versa)

12. Overview – VoIP Signaling ProtocolsIETF’s VoIP Architecture • The VoIP signaling protocols with the IETF’s VoIP Architecture can be divided into the following categories: • Protocols used between the Media Gateway and the Media Gateways Controllers (such as MGCP and the Megaco protocols), known as Gateway Control Protocols (GCP) • Protocols used between the Media Gateway and the Signaling Gateway (such as SCTP, M2UA, M3UA) • Protocols used between Media Gateway Controllers (MGCs) to initiate a session between users (such as SIP) • Protocols used within the IP Network (SIP…)

13. The IETF’s VoIP Architecture

14. Internet Telephony Architecture Using SIP

15. Overview – Security “...It is no longer necessary to have a separate network for voice...” • With VoIP the Internet Protocol (IP) is the vessel for voice transmission, therefore we inherit the security problems associated with the IP protocol • The security issues are more complex because of the nature of speech (voice quality), and other conditions VoIP needs to meet in order to fulfill its promise as the next generation in Telecommunication • Other security issues arise from the VoIP protocols themselves and from the different architectures in which IP Telephony can be deployed

16. Mr. Zerga and the IP PhoneOcean’s Eleven (The Coca-Cola vs. Pepsi wars of the 80’s is back with VoIP Phones?)

17. The VoIP Threat Module

18. The VoIP Threat ModuleOverview [1] • The VoIP (and IP Telephony) threat module is combined from different number of issues: • The Usage of IP: The IP protocol’s security weaknesses are inherited (sniffing, spoofing, reply attacks and all the rest of the family) • There is no separation of networks: The signaling and media share the same network (they are not separated as with the PSTN). It lowers the bar regarding potentially misuse of IP Telephony • The nature of speech: Issues such as Delay, Latency, Jitter, Packet Loss, Speech Coding Techniques, Network Availability, Managing Access & Priority, etc. There is a burden on maintaining adequate speech quality

19. The VoIP Threat ModuleOverview [2] • Continued… • The VoIP Protocols themselves • Supporting Protocols (DNS…) • VoIP Infrastructure (Phones, Servers, Special Servers…) • Supporting Infrastructure (Switches, Routers…) • Different IP Telephony Architectures (leads to different security risks) • Physical Security • …and Supporting Technologies

20. VoIP-based Protocols • We wish to maintain: • Integrity • Confidentiality • Authentication • Non–Repudiation • We face issues like: • Call Tracking • Call Hijacking • Eavesdropping • Active modifications • Denial of Service

21. VoIP-based Protocols (& Architecture) • The placement of the intelligence • With the PSTN today the signaling intelligence is with the Switches • The phones are just “dumb devices” • In the future everything we know today will be changed (we see the signs today with the VoIP technology) • With some of the VoIP signaling protocols (like SIP) the intelligence is placed at the edges – the IP phones themselves • This opens up a wider window opportunity for problems initiated by an end user • As we know, not all clients are born equal – a.k.a. some will be malicious

22. VoIP-based Protocols • Authentication • An IBM Executive Quote from the early days of the PCs: “Our goal is to make the computer as easy to use as the telephone” • Authentication…of what exactly? – Importance of Device authentication vs. the failure of user authentication • Or Who the hack wants to authenticate each time he needs to use the IP phone? • Especially not good if you wish to call 911 services… • When you have a heart attack you do not wish to authenticate to call the Ambulance services… • Re-Authentication at predetermined intervals

23. VoIP-based Infrastructure • The devices • Phones (usually are not that powerful devices) • Servers (SIP Proxy, SIP Registrar, SIP Redirect, Gatekeepers, Media GWs, Media GW Controllers, Signaling GWs, etc) • Gaining Unauthorized Access • Remote Access (not on the same local LAN) • Management interfaces • Abusing Authentication issues • Manipulation of settings • Perform Call tracking • Etc.

24. VoIP-based Infrastructure • Physical Access • To the Phone • Hard resets (using a button) • Soft resets (using the phone’s software) • Device configuration and manipulation of settings • Call tracking • Uploading firmware, adding changing functionality and/or adding a permanent backdoor… • etc.

25. VoIP-based Infrastructure • Physical Access (continued) • To the Network (more later…) • Free Phone Calls • Eavesdropping • Bypassing Filtering • Bypassing QoS restrictions • Etc. • To other VoIP-based devices (you get the picture…)

26. VoIP-based InfrastructureAvailability • Shared infrastructure is bad! • Do you really wish to put the tag of critical infrastructure on a shared infrastructure? • Knock the Switches Off (from the regular data network) and you knocked the Voice network as well… • Do you trust VLANs? • No Electricity No Service • No ability to call emergency services (Violates E911 regulations) • “G, here goes our Carrier Grade availability…” • Connectivity to different offices in a corporate scenario

27. VoIP-based InfrastructureAvailability • Costs of redundancy, and UPSs for every switch and router at the last mile (for a carrier) or in a corporate… • Denial of Service Even more easy with VoIP, since you really do not need to be “that smart” and use too much traffic, but still you can cause outage in the whole network, a neighborhood, or a building, or on a single end-user (depends on your point of presence in the network) a corporate, etc. • Last – Mile Availability problems (in a carrier-grade network)

28. The VoIP Threat ModulePhysical Security • Who said Physical Security? • The Last – Mile is our main concern: • Access to the Physical Wire (and to equipment) – If achieved all is downhill from there (this holds true for any architecture using VoIP as well) • Equipment is likely to be stolen – Routers and switches are nice decorations for a room • Physical Tempering – “Cut the cord Luke”

29. The VoIP Threat ModulePhysical Security • Bypassing simple packet shaping mechanisms • Getting into the VoIP VLAN – An end-of-game

30. The VoIP Threat ModulePhysical Security • Eavesdropping can be achieved easily if there is access to the wire, with no specialized equipment other than a hub, a knife, and a clipper. • Between the IP Phone (or Customer Premises Gateway) and the Switch • Between two switches • With both scenarios we bypassed any QoS mechanism used.

31. The VoIP Threat ModulePhysical Security – Free Phone Calls • An “Advantage” Over Phreaking of this sort because the eavesdropper can also have free calls without the knowledge of the subscriber… • For example, using a different Call-ID to differentiate between calls destined to the phreaker to the calls destined to the owner of the line

32. The VoIP Threat ModuleAccess Technologies • The Security issues are not limited to “traditional” technologies only • Various Access Technologies with a Converged Network Architecture are susceptible to attacks • One notable example is Broadband Wireless Access Networks using LMDS (Local Multipoint Distribution Service). When encryption is used between the Base Station to a residential transceiver cripples the connection so badly some manufactures of LMDS equipment admit it is useless… • All you need to have is the right equipment…

33. The VoIP Threat ModuleAccess Technologies

34. The VoIP Threat ModuleExample • Cisco Call Manager Servers where affected by the Nimda worm since they where install on a Windows 2000 Servers with IIS5 (default install)

35. The VoIP Threat ModuleExample • @stake advisory – Multiple Vulnerabilities with Pingtel xpressa SIP Phones (July 12th, 2002), http://www.atstake.com/research/advisories/2002/a071202.txt • Pingtel xpressa SIP VoIP phones model PX-1 • The Pingtel xpressa SIP-based phone contains multiple vulnerabilities affecting all aspects of the phone’s operation. These vulnerabilities include: remote access to the phone; remote administrative access to the phone; manipulation of SIP signaling; multiple denials of service; remote telnet access (complete control of the VxWorks operating system); local physical administrative access, and more. • Using the vulnerabilities enumerated within this advisory it is possible to jeopardize critical telephony infrastructure based on Pingtel’s xpressa SIP phones. Additionally, certain vulnerabilities present a severe risk to an organization’s entire network infrastructure.

36. Other Rants • Regulations – It is the IETF policy not to worry about the hooks for wiretapping, but without this ability no service provider will be able to deploy VoIP (at least in the USA, UK and other countries) • Fraud • and more…

37. The Session Initiation Protocol

38. SIP History • SIP was developed within the mmusic working group in the IETF • The work on SIP began in 1995 • Proposed Standard RFC 2543 in February 1999 • Authors – Handley (ACIRI), Schulzrinne (Columbia University), Schooler (Cal Tech), & Rosenberg (Bell Labs) • SIP is part of the Internet Multimedia Conferencing Suite • New SIP RFC 3261, July 2002 • Authors – Rosenberg (dynamicsoft), Schulzrinne (Columbia University), Camarillo (Ericsson), Johnston (Worldcom), Peterson (Neustar) , Sparks (dynamicsoft), Handley (ACIRI), Schooler (AT&T)

39. What is the Session Initiation Protocol? • “SIP is an application-layer control protocol that can establish, modify, and terminatemultimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility– users can maintain a single externally visible identifier regardless of their network location”. Text in this section was taken from RFC 3261

40. What is the Session Initiation Protocol? • SIP supports five facets of establishing and terminating multimedia communications: • User location:determination of the end system to be used for communication; • User availability:determination of the willingness of the called party to engage in communications; • User capabilities:determination of the media and media parameters to be used; • Session setup:“ringing”, establishmentof session parameters at both called and calling party; • Session management:including transfer and termination of sessions, modifying session parameters, and invoking services.

41. Overview of Operation • The example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parametersto establish the session, and teardown of the session once established. • This is a typical example of a SIP message exchange between two users, Alice and Bob. In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phoneover the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. This typical arrangement is often referred to as the “SIP trapezoid” as shown by the geometric shape of the dashed lines

42. Overview of Operation • Alice “calls” Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sip:bob@biloxi.com, where biloxi.com is the domain of Bob’s SIP service provider (which can be an enterprise, retail provider, etc). Alice also has a SIP URI of sip:alice@atlanta.com. Alice might have typed in Bob’s URI or perhaps clicked on a hyperlink or an entry in an address book • SIP is based on an HTTP-like request/responsetransaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response

43. Overview of Operation • In this example, the transaction begins with Alice’s softphone sending an INVITE request addressed to Bob’s SIP URI. • INVITE is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. • The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, Alice’s address, and information about the type of session that Alice wishes to establish with Bob.

44. Overview of Operation – INVITE The address which Alice is expecting to receive responses. This parameter indicates the path the return message needs to take The Method name INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice’s SDP not shown) A display name and a SIP or SIPS URI towards which the request was originally directed Contains a globally unique identifier for this call Contains an integer (traditional sequence number) and a method name Contains a SIP or SIPS URI that represents a direct route to Alice

45. Overview of Operation • The details of the session, type of media, codec, sampling rate, etc. are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327). This SDP message (not shown in the example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message

46. F2: The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice’s address in the first Via). Overview of Operation F1: Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE to the SIP server that serves Alice’s domain,atlanta.com F3: the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice’s softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. This response contains the same To, From, Call-ID,CSeq and branch parameter in the Via as the INVITE, which allows Alice’s softphone to correlate this response to the sent INVITE. F5: The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the INVITE and is processing the request.

47. Overview of Operation Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE. F4: The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob’s SIP phone. F6: Bob’s SIP phone receives the INVITE and alerts Bob – ringing. Bob’s SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction.

48. Overview of Operation If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. F9: Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange.

49. Overview of Operation The first line of the response contains the response code (200) and the reason phrase (OK) SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf 465 From: Alice <sip:alice@atlanta.com>;tag=1928301774 466 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 471 (Bob’s SDP not shown) Added by biloxy.com SIP Proxy Added by atlanta.com SIP Proxy Added by Alice’s softphone Contains a URI at which Bob can be directly reached at his SIP phone. What method this 200 OK is sent for?

50. Overview of Operation Finally, Alice’s softphone sends an acknowledgement message, ACK to Bob’s SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice’s softphone to Bob’s SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other’s address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. In addition to DNS and location service lookups shown in this example, proxy servers can make flexible“routing decisions” to decide where to send a request. For example, if Bob’s SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy server could proxy the INVITE to Bob’s voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking. In this case, the 200 (OK) is routed back through the two proxies and is received by Alice’s softphone, which then stops the ringback tone and indicates that the call has been answered.