; E.T. Can’t Phone Home Security Issues with VoIP
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

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

VIEWS: 77 PAGES: 110

  • pg 1
									E.T. Can‟t Phone Home
Security Issues with VoIP

Ofir Arkin
Managing Security Architect

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Agenda
 VoIP Overview  The VoIP Threat Module  The Session Initiation Protocol  The Session Initiation Protocol Threat Module  The RTP Protocol  The RTP Threat Module

2

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview IP Telephony, VoIP and VON

3

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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?
4

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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
5

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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

6

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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. – Teardown a Sessions – The ability to end a session
7

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview – Media Transport Protocols
 The Media Transport Protocols are used to carry voice samples (such as 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 and transported using an IP network

8

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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.

9

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview IETF‟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 signaling and voice samples between the PSTN and the VoIP IP Network and vice versa. Therefore some gateways are introduced with the infrastructure

10

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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)

11

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview – VoIP Signaling Protocols IETF‟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…)
12

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The IETF‟s VoIP Architecture
SS7 SS7

ISUP, Q.931

ISUP, Q.931

SG

SG

ISUP TCAP,

TCAP, ISUP

M3UA, M2UA/SCTP

M3UA, M2UA/SCTP

MGC
P SI

SIP

MGC

Megaco/H.248

SI P

Megaco/H.248

PSTN

MG

IP Network
RTP RTP

MG

PSTN

13

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Internet Telephony Architecture Using SIP

SIP Proxy
SI P
SI P
P SI

SIP Proxy
P SI

SIP

SIP UA

SIP

Network A RTP RTP

The Internet
RTP

Network B RTP

SIP UA

14

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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

15

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Mr. Zerga and the IP Phone

16

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module

17

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Overview [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
18

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Overview [2]  Continued…
– The VoIP Protocols themselves

– Supporting Protocols (DNS…)
– VoIP Infrastructure (Phones, Special Servers…) – Supporting Infrastructure (Switches, Routers…)

– Different IP Telephony Architectures (leads to different security risks)
– Physical Security – …and Supporting Technologies

19

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

VoIP-based Protocols
 Integrity  Confidentiality

 Authentication
 Non–Repudiation  Call Tracking

 Call Hijacking
 Eavesdropping  Active modifications

 Denial of Service
20

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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

21

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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?
– Re-Authentication at predetermined intervals

22

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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.
23

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

VoIP-based Infrastructure
– Physical Access
 To the Phone

– Hard resets
– Soft resets – Device configuration and manipulation of settings – Call tracking – Uploading firmware, adding changing functionality and/or adding a permanent backdoor… – etc.

24

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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…)

25

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

VoIP-based Infrastructure Availability
 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
26

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

VoIP-based Infrastructure Availability
 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)

27

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Physical 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”

28

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Physical Security
Packet Shaping for QoS (DiffServ)

Voice

Data

Alice's IP Phone

Alice‟s PC

Voice

Mikasa Sukasa

Data

Alice's IP Phone

 Bypassing simple packet shaping mechanisms  Getting into the VoIP VLAN – An end-of-game
29

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Physical Security
100BaseT 100BaseT

PC

100BaseT Switch

100BaseT Hub

100BaseT

IP Phone

100BaseT

100BaseT

PC

100BaseT Switch

100BaseT Switch

100BaseT

IP Phone

 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.

30

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Physical Security – Free Phone Calls
Voice
Mikasa Sukasa

Data
I am representing the physical address of the IP Phone

Alice's IP Phone
I am representing the physical address of the Switch

 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

31

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Access 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…

32

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The VoIP Threat Module Access Technologies

Base Station

33

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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…

34

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The Session Initiation Protocol

35

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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 (draft-ietf-sip-rfc2543bis-09) is in the IESG final approval loop (should be RFC 3261)
 Authors – Rosenberg (dynamicsoft), Schulzrinne (Columbia University), Camarillo (Ericsson), Johnston (Worldcom), Peterson (Neustar) , Sparks (dynamicsoft), Handley (ACIRI), Schooler (AT&T)
36

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

What is the Session Initiation Protocol?
 “SIP is an application-layer control protocol that can establish, modify, and terminate multimedia 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 draft-ietf-sip-rfc2543bis-09

37

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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”, establishment of session parameters at both called and calling party; – Session management: including transfer and termination of sessions, modifying session parameters, and invoking services.
38

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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 parameters to establish the session, and teardown of the session once established.
Alice‟s PC

atlanta.com Proxy Server

biloxy.com Proxy Server



Bob‟s SIP Phone INVITE F1 INVITE F2 100 Trying F3 100 Trying F5 180 Ringing F6 180 Ringing F7 180 Ringing F8 200 OK F9 200 OK F10 200 OK F11 ACK F12 RTP Media Stream INVITE F4

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 phone over 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

BYE F13 200 OK F14

39

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response
40

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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.

41

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – INVITE
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
Contains a SIP or SIPS URI that represents a direct route to Alice

The address which Alice is expecting to receive responses. This parameter indicates the path the return message needs to take 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

Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp Content-Length: 142

(Alice‟s SDP not shown)
42

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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

43

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

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, CallID,CSeq and branch parameter in the Via as the INVITE, which allows Alice‟s softphone to correlate this response to the sent INVITE.
Alice‟s PC

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 atlanta.com biloxy.com Proxy Server Proxy Server biloxi.com domain. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE Bob‟s SIP Phone request there. Before INVITE F1 forwarding the request, the INVITE F2 atlanta.com proxy server 100 Trying F3 INVITE F4 adds an additional Via 100 Trying F5 180 Ringing F6 header field value that 180 Ringing F7 contains its own address 180 Ringing F8 (the INVITE already contains Alice‟s address in 200 OK F9 200 OK F10 the first Via).
200 OK F11 ACK F12 RTP Media Stream

BYE F13 200 OK F14

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 44 request.

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation
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 to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob‟s phone rings. Bob‟s SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction.

atlanta.com Proxy Server

biloxy.com Proxy Server

Alice‟s PC INVITE F1 INVITE F2 100 Trying F3 100 Trying F5 INVITE F4

Bob‟s SIP Phone

180 Ringing F6 180 Ringing F7 180 Ringing F8 200 OK F9 200 OK F10 200 OK F11 ACK F12 RTP Media Stream

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.

BYE F13 200 OK F14

45

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation
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. Alice‟s PC As a result, there is a twophase 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. 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.

atlanta.com Proxy Server

biloxy.com Proxy Server

Bob‟s SIP Phone INVITE F1 INVITE F2 100 Trying F3 100 Trying F5 180 Ringing F6 180 Ringing F7 180 Ringing F8 200 OK F9 200 OK F10 200 OK F11 ACK F12 RTP Media Stream INVITE F4

BYE F13 200 OK F14

46

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation
The first line of the response contains the response code (200) and the reason phrase (OK)

SIP/2.0 200 OK
Added by biloxy.com SIP Proxy

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8 ;received=192.0.2.3
Added by atlanta.com SIP Proxy

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2
Added by Alice‟s softphone

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
What method this 200 OK is sent for? Contains a URI at which Bob can be directly reached at his SIP phone.

Content-Length: 131 471
(Bob‟s SDP not shown)
47

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation
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.

atlanta.com Proxy Server

biloxy.com Proxy Server

Alice‟s PC INVITE F1 INVITE F2 100 Trying F3 100 Trying F5 INVITE F4

Bob‟s SIP Phone

180 Ringing F6 180 Ringing F7 180 Ringing F8 200 OK F9 200 OK F10 200 OK F11 ACK F12 RTP Media Stream

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. 48

BYE F13 200 OK F14

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation
 Alice and Bob‟s media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages  During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re-INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 406 (Not Acceptable), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail – the session continues using the previously negotiated characteristics
49

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation
F13/F14: At the end of the call, Bob disconnects (hangs up) first and generates a BYE message. This BYE is routed directly to Alice‟s softphone, again bypassing the proxies. Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent – an ACK is only sent in response to a response to an INVITE request.

atlanta.com Proxy Server

biloxy.com Proxy Server

Alice‟s PC INVITE F1 INVITE F2 100 Trying F3 100 Trying F5 INVITE F4

Bob‟s SIP Phone

180 Ringing F6 180 Ringing F7 180 Ringing F8 200 OK F9 200 OK F10 200 OK F11 ACK F12 RTP Media Stream

BYE F13 200 OK F14

50

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – “Forced Routing”
In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob‟s SIP phone and (due to the RecordRoute header field being passed back in the 200 (OK)) Alice‟s softphone and stored for the duration of the dialog. The biloxi.com proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently decide to receive subsequent messaging, and that messaging will go through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features.
atlanta.com Proxy Server biloxy.com Proxy Server

Alice‟s PC INVITE F1 INVITE F2 100 Trying F3 100 Trying F5 INVITE F4

Bob‟s SIP Phone

180 Ringing F6 180 Ringing F7 180 Ringing F8 200 OK F9 200 OK F10 200 OK F11

ACK F12 ACK F13

RTP Media Stream

BYE F14 BYE F15 200 OK F16 200 OK F17

51

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – Registration
Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob‟s SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP Registrar. The REGISTER messages associate Bob‟s SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged. The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the proxy in the biloxi.com domain. Bob is not limited to registering from a single device. For example, both his SIP phone at home and the one in the office could send registrations. This information is stored together in the location service and allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be registered on a single device at the same time.
SIP Location Server 2. Write in DB SIP Registration Server

3. Query for Bob‟s Location

4. Zero (0) or more URIs

1. REGISTER

biloxy.com Proxy Server

Bob‟s SIP Phone

The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the 52 request.

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – Registration
F1 REGISTER Bob -> Registrar

REGISTER sip:registrar.biloxi.com SIP/2.0

Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnas hds7
Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200

SIP Registration Server REGISTER F1 200 OK F2

Bob‟s SIP Phone

The information expires after 2 hours

Content-Length: 0

Associating Bob‟s URI <sip:bob@biloxy.com> with the machine he is currently logged (the Contact information) <sip:bob@192.0.2.4> 53

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – Registration
F2 200 OK Registrar -> Bob

SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0
54 All Current Binding of <sip:bob@biloxy.com>

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – CANCEL
The CANCEL request, as the name implies, is used to cancel a previous request sent by a client (only INVITEs). Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response (200 OK). A UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would “stop ringing”, and then respond to the INVITE with a specific error response (a 487).

Alice‟s PC INVITE F1 100 Trying F2 180 Ringing F3 CANCEL F4

Bob‟s SIP Phone

487 (Request Terminated) F5

55

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – CANCEL
If the UAS has already sent a final response for the original request, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request.

Alice‟s PC INVITE F1 100 Trying F2 180 Ringing F3 200 OK F4 CANCEL F4'

Bob‟s SIP Phone

If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist).

BYE F6 200 OK F7

56

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – OPTIONS
 The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without ”ringing” the other party.

Alice‟s PC OPTIONS F1 200 OK F2

Carol‟s SIP Phone

57

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – OPTIONS
OPTIONS sip:carol@chicago.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877

Max-Forwards: 70
To: <sip:carol@chicago.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:alice@pc33.atlanta.com> Accept: application/sdp Content-Length: 0
58

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Overview of Operation – OPTIONS
SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: <sip:carol@chicago.com>;tag=93810874 From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:carol@chicago.com> Contact: <mailto:carol@chicago.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept-Encoding: gzip Accept-Language: en Supported: foo Content-Type: application/sdp Content-Length: 274

(SDP not shown)

59

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Protocol Components
 User Agent Client (UAC)
– End Systems

– Send SIP Requests

 User Agent Server (UAS)
– Listening for Incoming Requests

– Execute an “internal logic”/program to determine the appropriate response

 User Agent
– UAC + UAS
60

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Protocol Components
 Redirect Server
– Redirect “callers” (requests) to another Server

 Proxy Server
– Relay Call Signaling (“Proxy requests to another server”) – Can “fork” requests to multiple targets

– Able to maintain basic Call-State (or not)

 Registrar
– Receives registrations requests regarding current user locations

– Stores the information at a “Location Server”
61

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Methods (Core Methods)
 INVITE
– – Initiate Sessions Change a Session state via re-INVITEs

 ACK
– Confirms Session Establishment

 BYE
– Terminates Sessions

 CANCEL
– Cancels an INVITE request sent by a client not already sent a final response for

 OPTIONS
– Query another UA or a proxy server as to its capabilities

 REGISTER
– Binds permanent address to the current location
62

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Response Codes
 1xy Information or Provisional - Request in progress but not yet completed
– 100 Trying – 180 Ringing – 181 Call is Being Forwarded – 182 Queued

– 183 Session Progress

 2xy Success - the request has completed successfully
– 200 OK

63

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Response Codes
 3xy Redirection - another location should be tried for the request
– – – – 300 Multiple Options 301 Moved Permanently 302 Moved Temporarily 305 Use Proxy

–

380 Alternative Service

64

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Response Codes
 4xy Client Error – due to an error in the request, the request was not completed . The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.
– – – – – – – – 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required

–

408 Request Timeout
65

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Response Codes
– – – – – – – 410 Gone 413 Request Entity Too Large 414 Request URI Too Long 415 Unsupported Media Type 416 Unsupported Media Scheme 420 Bad Extension 421 Extension Required – 482 Loop Detected – – 483 Too Many Hops 484 Address Incomplete

–
– – – – –

485 Ambiguous
486 Busy Here 487 Request Terminated 488 Not Acceptable Here 491 Request Pending 493 Undecipherable

–
– –

423 Interval Too Brief
480 Temporarily Unavailable 481 Call/Transaction Does Not Exist

66

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Response Codes
 5xy Server Failure – the request was not completed due to error in recipient. Can be retried at another location
– – – – 500 Server Internal Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable

–
– –

504 Server Time-Out
505 Version Not Supported 513 Message Too Large

67

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Response Codes
 6xy Global Failure – request was failed and should not be retried again
– – – – 600 Busy Everywhere 603 Decline 604 Does Not Exist Anywhere 606 Not Acceptable

68

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Architecture (I – Proxy)

Location Service DNS Server sip.biloxy.com SIP Proxy 7. FW: INVITE 16. 200 OK 8. 100 Trying 13. 180 Ringing 15. 200 OK 12. 180 Ringing 9+10. Query & Respond 2. Store

5+6. DNS Query

11. FW: INVITE 1. Register SIP Registrar

3. INVITE

SIP Proxy sip.atlanta.com 4. 100 Trying 14. 180 Ringing 17. 200 OK 18. ACK 20. BYE 19. Media Transport is opened 21. 200 OK

SIP UA [B] sip:bob@biloxy.com 69

SIP UA [A] sip:alice@atlanta.com

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Architecture (II – Proxy & Redirect)
sip.new-york.com SIP Redirect Server Location Service DNS Server sip.biloxy.com SIP Proxy 9. FW: INVITE 18. 200 OK 10. 100 Trying 15. 180 Ringing 17. 200 OK 14. 180 Ringing 11+12. Query & Respond 2. Store

5+6. DNS Query

13. FW: INVITE 1. Register SIP Registrar

3. INVITE

SIP Proxy sip.atlanta.com 4. 100 Trying 16. 180 Ringing 19. 200 OK 20. ACK 22. BYE 21. Media Transport is opened 23. 200 OK

SIP UA [B] sip:bob@biloxy.com 70

SIP UA [A] sip:alice@atlanta.com

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Architecture (III – The Principle of Mobility)

Location Service DNS Server sip.biloxy.com SIP Proxy

5+6. DNS Query

7. FW: INVITE
8. 100 Trying 13. FW: Redirect 14. FW: INVITE 17. 200 OK 15. 180 Ringing 3xx Redirect 12.

9+10. Query & Respond

2. Store

11. FW: INVITE 1. Register SIP Registrar

3. INVITE

SIP Proxy sip.atlanta.com 4. 100 Trying 16. 180 Ringing 19. ACK 18. 200 OK 21. Bye 20. Media Transport is Open 22. 200 OK

SIP UA [B] bob@somewhere.else

SIP UA [B] sip:bob@biloxy.com 71

SIP UA [A] sip:alice@atlanta.com

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Message Structure

Some Other Time

72

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The Change of Tides
 With RFC 2543 UDP was used as the underlying transport protocol for SIP

 The IETF demanded that with the new version of SIP, Security will be an integral part of the protocol
 Since UDP is hard to secure (IPSec only) the authors of the new version of the protocol turned to TCP. Up until that point they argued that UDP is a better solution for transport of SIP signaling (no retransmissions, and other…)  So Dorothy had to buckle up because Kansas gone bye bye…

73

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

The SIP Threat Module

74

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

SIP Threat Module

Assumption: An Attacker Is On the Wire

75

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Threats
 Denial-of-Service
– CANCEL

– BYE
– Using response codes – ICMP Error Messages for UDP datagrams

 Call Hijacking
– Through the Registrar – Through the usage of 3xy response code messages

– Mid-Session tricks
76

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Threats
 MITM Attacks
– Through the usage of 301 & 302 Response codes

– Through the usage of 305 (Use Proxy) response code

 No intelligence/control of the Media stream during a session  Covert Channels
– Unknown Header fields

 Enumerating
– OPTIONS – Call – Leg does not exists – Max - Forwards
77

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Threats
 Wiretapping
– Who‟s in my path?

– SIP Proxies are allowed to send messages through a set of additional proxies

 Call Tracking  Clients are Malicious

 Design Issues  Predictable Values
78

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Denial of Service – CANCEL
SIP:carol@biloxy.com SIP UA [C] Location Service

DNS Server

sip.biloxy.com SIP Proxy 2. Store 9+10. Query & Respond 15. CANCEL 8. 100 Trying 13. 180 Ringing 11. FW: INVITE

5+6. DNS Query

7. FW: INVITE

3. INVITE

SIP Proxy sip.atlanta.com 4. 100 Trying 14. 180 Ringing

1. Register 12. 180 Ringing

SIP Registrar

SIP UA [A] SIP:alice@atlanta.com

The CANCEL needs to “hit” Bob‟s SIP Phone before it sends the 200 OK. This is a Denial-of-Service on Bob

SIP UA [B] SIP:bob@biloxy.com 79

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Denial of Service – CANCEL
The CANCEL needs to “hit” Bob‟s SIP Phone before it sends the 200 OK. This is a Denial-of-Service on Alice. Whenever Alice sends an INVITE, carol will CANCEL it. DNS Server sip.biloxy.com SIP Proxy 2. Store 9+10. Query & Respond Location Service

5+6. DNS Query SIP:carol@biloxy.com SIP UA [C]

7. FW: INVITE 8. 100 Trying 13. 180 Ringing SIP Proxy sip.atlanta.com 12. 180 Ringing

11. FW: INVITE

1. Register

SIP Registrar

3. INVITE

4. 100 Trying 14. 180 Ringing 15. CANCEL SIP UA [B] SIP:bob@biloxy.com

SIP UA [A] SIP:alice@atlanta.com

80

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Denial of Service – BYE
SIP:carol@biloxy.com SIP UA [C] Location Service

5. FW: INVITE

16. BYE 7. Query sip.biloxy.com SIP Proxy 8. Reply 10. 100 Trying 13. 200 OK

2. Store

3. INVITE

SIP Proxy sip.atlanta.com

6. 100 Trying 14. FW: 200 OK 11. FW: 100 Trying 9. FW: INVITE

SIP Registrar 1. Register SIP UA [B] SIP:bob@biloxy.com As soon as the 200OK will be sent from Bob‟s SIP Phone to Alice‟s SIP Phone, Carol will send a BYE request to either Bob or Alice or 81 both

12. FW: 100 Trying
4. 100 Trying 15. FW: 200 OK

SIP UA [A] SIP:alice@atlanta.com

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Denial of Service – BYE (to Alice)
SIP:carol@biloxy.com SIP UA [C] Location Service

16. BYE sip.biloxy.com 26. 481 Call/Transaction Does Not Exist SIP Proxy 27. 481 Call/Transaction Does Not Exist 20. FW: 200 OK 21. FW: 200 OK

17. FW: BYE SIP Registrar SIP Proxy 23. FW: Any SIP Message Any SIP Message 22. sip.atlanta.com 25. 481 Call/Transaction Does Not Exist SIP UA [B] 24. FW: Any SIP Message SIP:bob@biloxy.com 18. FW: BYE The “session” does not exist on The 200OK is sent to the SIP Proxy anymore, but it will acknowledge the BYE request pass the message 200 OK received (The transaction SIP UA [A] We got a mismatch is non-existent on Alice‟s SIP 82 SIP:alice@atlanta.com Phone ONLY) 19. 200 OK

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Denial of Service – BYE (to Bob)
SIP:carol@biloxy.com SIP UA [C] Location Service

sip.biloxy.com SIP Proxy 16. BYE

18. FW: 200 OK
SIP Proxy sip.atlanta.com 19. FW: 200 OK

17. 200 OK SIP UA [B] SIP:bob@biloxy.com

SIP Registrar

SIP UA [A] SIP:alice@atlanta.com

The “session” does not exist any more on Bob‟s SIP Phone

83

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Denial of Service – BYE (to Both)
When a fake BYE will be sent to one of the participants in a dialog, that participant will generate a 200 OK reply. To avoid detection the BYE will be sent simultaneously to both SIP:carol@biloxy.com participants, and the 200 OK responses, although generated for a SIP UA [C] different message will not be suspected (Sequence of both BYE will be the same) 16. BYE (B->A)

Location Service

sip.biloxy.com SIP Proxy

16. BYE (A->B)

18‟. FW: 200 OK

19‟. FW: 200 OK

18. FW: 200 OK 17‟. 200 OK
SIP Proxy sip.atlanta.com 19. FW: 200 OK

17. 200 OK SIP UA [B] SIP:bob@biloxy.com

SIP Registrar

SIP UA [A] SIP:alice@atlanta.com

The malicious party will send the BYE request not through the SIP Proxies but direct to the dialog participants. This to avoid cases in which a stateful proxy might take action for the BYE SIP 84 request.

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Denial of Service – Using Response Codes
 A malicious party can use several response codes in order to introduce a denial of service condition
– “4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.” – “5xx responses are failure responses given when a server itself has erred.”
– “6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI.”
85

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Hijack Using Manipulation of the Registration Records
Associating Bob‟s URI <sip:bob@biloxy.com> with the attacker‟s machine <sip:bob@192.168.1.10> 10. FW: INVITE sip.biloxy.com SIP Proxy 6. FW: INVITE 3. Register 8. Query 9. Reply 7. 100 Trying 4. INVITE SIP Proxy sip.atlanta.com SIP UA [B] 5. 100 Trying SIP:bob@biloxy.com Associating Bob‟s URI <sip:bob@biloxy.com> with the machine he is currently logged (the Contact information) <sip:bob@192.168.1.5> SIP Registrar 1. Register 2. Store 4. Store SIP:carol@biloxy.com SIP UA [C] Location Service

SIP UA [A] SIP:alice@atlanta.com

86

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Hijack Using Manipulation of the Registration Records
 You can query the SIP Registrar for the list of addresses of a particular SIP URI  You will be given the list of addresses associated with your SIP URI with each successful registration  But does your UA will show it up? – Probably not (we tried this… NO!)

 You can give your registration higher priority than the other record (not deleting other records)

87

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Hijack Using Manipulation of the Registration Records
 Or, you can register with a lower priority and perform a denial of service on the higher priority entry, so the SIP Proxy will not be able to „deliver-to-it‟ and will turn to the next entry with the Registrar  The Registrar can require the registering party (which can be a 3rd party as well) to authentication before receiving the registration information. But, since the characteristics of the registration with SIP requires registration each hour for the same SIP URI, by default, it is unlikely that a SIP phone user will authenticate to the Registrar each hour…  Instead, what most of the SIP-based phones does is store the username and password information with the phone (other attack venues) and perform autentication automatically for the user when required (not always works smoothly)

88

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Hijack Using 301 Moved Permanently Response Code
The INVITE that was originally sent to bob@biloxy.com, is now being sent to the address given with the 301 spoofed response code, bob@foobar_IP (carol‟s SIP Phone). Therefore the query goes to Carol‟s SIP phone rather than to Bob‟s
SIP:carol@IP_ADDRESS SIP UA [C] 4. 301 Moved Permanently sip.biloxy.com SIP Proxy

3. FW: INVITE 6. FW: INVITE 5. INVITE 1. INVITE

SIP Proxy sip.atlanta.com 2. 100 Trying

SIP UA [B] SIP:bob@biloxy.com

SIP UA [A] SIP:alice@atlanta.com

“The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field. The requestor SHOULD update any local directories, address books, and user location caches with this new 89 value and redirect future requests to the address(es) listed.”

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Hijack – Using 30y Messages
 The location of the malicious entity can be anywhere (Alice‟s network, Bob‟s network, in-between networks)  One can also use the 302 Moved Temporarily Response Code:
– “The requesting client SHOULD retry the request at the new address(es) given by the Contact header field. The Request-URI of the new request uses the value of the Contact header field in the response. The duration of the validity of the Contact URI can be indicated through an Expires header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions. If the URI cached from the Contact header field fails, the Request-URI from the redirected request MAY be tried again a single time.”
90

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Hijack – Mid Session Tricks / ”Re-INVITE me baby one more time!”
 “…this modification can involve changing addresses or ports, adding a media stream, deleting media stream, and so on…”, “this is accomplished by sending a new INVITE request within the same dialog that established the session”…”also known as Re-INVITE”  Hijack the signaling path – you are able to introduce new routing into the signaling path of a current session  Deny signaling from any side to your benefit  Can evolve to introducing other participants to the session  “Eavesdropping made easy”
91

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

MITM Attacks
 301 and 302 Response codes can be spoofed as responses coming from any SIP element:
– SIP Registrar
– SIP Proxy Server – SIP Redirect Server – SIP UA

 More creativity – 305 Use Proxy Response Code

92

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

MITM Attacks – 302 Moved Temporarily

Carol is now acting as a SIP Proxy
sip.biloxy.com SIP Proxy “Carol‟s Proxy” 4. FW: INVITE’

6. FW: INVITE

5. 100 Trying 2. 302 Moved Temporarily 3. INVITE’ 1. INVITE SIP Proxy sip.atlanta.com SIP UA [B] SIP:bob@biloxy.com

SIP UA [A] SIP:alice@atlanta.com

302 Moved Temporarily - “The requesting client SHOULD retry the request at the new address(es) given by the Contact header field. The Request-URI of the new request uses the value of the Contact header field in the response.”

93

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

MITM Attacks – vs. Registrar
Carol is spoofing a 301 Moved Permanently response message allegedly coming from the REGISTRAR SIP:carol@biloxy.com SIP UA [C] Location Service

Carol has bob‟s credentials – Game 4. 401 Unauthorized Over 2. 301 Moved Permanently 6. Confirm Registration

3. Register’ 5. Register’’ request with appropriate credentials

7. Register request for bob’s credentials 8. Store

SIP Registrar
1. Register SIP UA [B] SIP:bob@biloxy.com Bob‟s SIP Phone performs a registration request

94

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

MITM Attacks – 305 Use Proxy, or Who‟s your Daddy?

Carol is now acting as a SIP Proxy
sip.biloxy.com SIP Proxy “Carol‟s Proxy” 4. FW: INVITE

6. FW: INVITE

5. 100 Trying 2. 305 Use Proxy 3. INVITE’ 1. INVITE SIP Proxy sip.atlanta.com SIP UA [B] SIP:bob@biloxy.com

SIP UA [A] SIP:alice@atlanta.com

“The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 95 (Use Proxy) responses MUST only be generated by UASs. “

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

No intelligence/control of the Media stream during a session
 Signaling goes one way, Media goes another way  Some device needs to control the creation of Media streams – no media stream without the appropriate signaling (who came first the chicken or the egg problem)  If there is a modification to the Media stream along the “call” (through the usage of RTP or RTCP, for example) the SIP signaling protocol will not be aware of it  If the codec used will be changed using the media transport protocol SIP is simply blind.  In the case the media stream will be cut the SIP elements participating in the session (especially the SIP UAs) will not get indication that the media is cut… They will have to understand that the conversation was cut…

96

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

No intelligence/control of the Media stream during a session
 There is no control of the “pipeline” for the Media stream. Therefore a malicious party can change the codec used through the Media protocol used, and use a codec which demands more bandwidth (and therefore its usage will raise the packet loss and we will have a lower quality, or even a poor quality of speech)  No Provisioning what so ever on the Media stream

97

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Enumeration
 If the UAS did not find a matching transaction for the CANCEL according to the procedure … it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist).  OPTIONS method  The Max-Forwards header value represents the maximum number of SIP devices this request can route through. The default value is 70 (a nice rounded number)

98

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Covert Channels
 If you will introduce a fake SIP header field with a SIP message it will be allowed across all components of a SIP based solution  Future header support – It Just Rock!

99

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Tracking
 Defined as: “Logging of the source and destination of all numbers being called”

 Capturing DTMFs along with other signaling traffic will give an attacker the opportunity to capture voice mail passwords (rings a bell?), calling card information, credit card information, or any other data entered using DTMF
 With SIP all we need is to track INVITE messages  If the BYE is also recorded the duration of the call can also be tracked, and other bits of information
100

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Call Tracking
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)

101

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Clients are Malicious
 SIPs threat module according to the SIP WG does not include “malicious clients”  If I am using a malicious client (my stack instead of the manufacture‟s stack or a modified one) and I am the called party, I can, for example, strip any Record-Route headers and not bother with those. As a direct response to this, not my client, and most importantly the caller will send signals beyond the “three-way SIP handshake” through any SIP Proxy as we like…  The “official SIP threat module” does not take into consideration that when two “friends” use the network they will be able to unveil the routing path with nearly no hassle (see example at the next slide)  There is also a lot more to this one
102

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Clients are Malicious
A “conspirator” will have all the route taken (at least the entities that needs to be passed through) in the VIA headers

sip.somewhere.com

Location Service

SIP Proxy

Encrypted

Encrypted Might be

Encrypted

SIP Proxy Might be Encrypted SIP Proxy sip.atlanta.com sip.biloxy.com SIP UA [B] SIP:bob@biloxy.com

SIP Registrar

SIP UA [A] SIP:alice@atlanta.com 103

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

More Issues
 Predicted Values  Firewalls & NAT  Bypassing the SIP Proxy = Bypassing Billing (where is my CDR syndrome)  No Control on Media streams = Bypassing Billing using tunneling with the Media streams protocols  Fraud – if you are only looking at CDRs produces – Well, you are a complete idxxx… Most important is to look at the network traffic
104

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Security Mechanisms with the SIP Protocol

105

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Security Mechanisms with the SIP Protocol
 TLS support
– TLS is only good for TCP

– This means that if you wish to use UDP for the transport of your SIP messages you will not have security (accept for body encryption)
– It is only RECOMMENDED that a UA will be able to initiate a TLS based connection… – Digital Certificated Usage and the missing piece – it is only for the SIP Servers to use digital certificates. Clients are not required to have one – Without certificates at the client side we just have at the end of the process an encrypted communication channel between two parties without authenticating their identity – 12 messages to establish a session, which according to the RFC needs to be kept alive all the time…
106

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Security Mechanisms with the SIP Protocol
 S/MIME for message bodies (key distribution)  Digest Authentication  With encryption firewalls will be useless when they have the ability to really understand the protocol (remember Max-Forwards for example?)

107

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Multimedia Communication (RTP & RTCP)

108

©2001-2002

OFIR ARKIN

&

@STAKE,

INC.

Multimedia Communication (RTP & RTCP)
 The main concern is the ability to control any part of a media stream by manipulating the appropriate values…  This is done by manipulating the Sequence and Timestamp field values to higher values than they are currently. The affect is that media streams coming from the user we are attacking will not be accepted at the destination‟s end because they will be discarded as „old‟

 More? – Some other time

109

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

Questions?

Ofir Arkin
Managing Security Architect


								
To top