Upload
kelly-maxwell
View
228
Download
1
Tags:
Embed Size (px)
Citation preview
Ofir ArkinManaging Security Architect
VoIP The Next Generation of Phreaking
orE.T. Can’t Phone Home
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
2
Agenda
Overview
VoIP Overview
Who’s In Charge? – The Politics Behind the Engineering of the Standards
The VoIP Threat Module
The Session Initiation Protocol
The SIP Threat Module
Security Mechanisms within SIP (and why some of them will fail)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
3
It is a hype – You can see IP Phones in high profile TV series and Movies like 24, and
Ocean’s Eleven
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
4
Overview
“...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 an emerging technology for carrying voice
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
5
VoIP Overview
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
6
VoIP Definition
We can define VoIP simply as “the transport of voice traffic using the Internet Protocol”. Stating “using the Internet Protocol” associates the usage of the Internet in the mind of many people. But the matter of fact is that Internet Telephony is only a portion of VoIP, and VoIP has a broader definition.
To remove any shreds of a debut we define VoIP as “the transport of voice traffic using the Internet Protocol utilizing any network”.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
7
What Protocols Do We Need?
Signaling Protocols, Protocols in which Establish, Locate, Setup, Modify and Teardown sessions
Media Transport Protocols, Protocols which transmit the voice samples
Supporting Protocols, DNS, Location Servers, QoS, Routing Protocols, AAA…
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
8
What Protocols Do We Have?
Signaling
– SIP
– H.323
Media Transport
– RTP & RTCP
– SCTP
Supporting Protocols
– Routing - TRIP (Telephony Routing over IP)
– Quality of Service – RSVP, 802.1q
– DNS, etc
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
9
Protocols Combining a VoIP Solution
SIP IP Phone
SIP IP Phone
Location Service
SIP Proxy
SIP Proxy
DNS Server
Media Transport
1. A request is sent (SIP INVITE) to ESTABLISH a
session
2. DNS Query for the IP Address of the SIP Proxy of the Destination
Domain 3. The INVITE is forwarded
4. The Location Service is being queries to check that the destination IP address
represents a valid registered device, and for its IP
Address
5. The request is forwarded to the End-Device
6. Destination device returns its IP Address to the
originating device and a media connection is opened
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
10
Where Do We Find VoIP-Based Architectures?
Telecoms
ITSPs
Corporate LANs
Internet Telephony
Consumer/The Average Joe
We will not discuss why using IP to carry Voice with this presentation
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
11
Who’s In charge?
The Politics Behind the Engineering of the Standards
Opinions within this section represent my own opinions not @stake’s!
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
12
Decision Making in the IETF Telephony WGs
The IETF (Internet Engineering Task Force) is leading the standards with VoIP
More than the ITU (H.323 for example)
The problem is the forces within the working groups that “take decision” without any voting mechanism
Within a working group everybody has own their agenda, usually representing their company’s
Sometimes, there are conflicts with the working group’s own agenda
In one of the working groups the agenda stated that Security is a must and should be an integral part of the protocol being developed… So?
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
13
Decision Making in the IETF Telephony WGs
Several working groups are related
There are cases were changes in one working group affects another working group
Sometimes there is no correlation
The amount of information is huge. If this is not your day job there is no chance that you will be able to read the whole related information (and analyze it)
Sometimes, before non-industry people can take a look or say something, the battle is already decided (if you are not from the Telecom industry)
Being loud sometimes is the key…
Important issues are being ignored
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
14
Decision Making in the IETF Telephony WGs – Example I
“One final note. One of the most valuable things I learned from executive at my former employer is this pearl of wisdom, "Finished is a feature, and arguably the most important one". I am certain that, even with these changes, there are still questions and issues with the sips mechanism (and indeed, everything else). However, we need to finish bis, and we have customers anxiously waiting its arrival. Indeed, the ramifications of not finishing are quite severe. Like everything else, it is a tradeoff. I believe we are at the point where we have achieved a very good tradeoff between just finishing it, and getting it perfect. That tradeoff is not something the sip group has been very good at, so it is sometimes a bit of a hard pill to swallow. Do not take that to mean that I don't feel bis is ready; the confidence that I have that bis is very solid is extremely high. Indeed, the increase in length of the spec is almost entirely attributed to a very well specified, very complete protocol. Being intimately familiar with this document at a level of detail which is often frightening, I personally believe that
WE ARE FINISHED.
Thanks,xxxx xxxx”
21 February 2002 [Bis-07.9 Goes to be Bis-08]
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
15
Decision Making in the IETF Telephony WGs– Example II
“…Working Group Summary The SIP Working Group conducted an extensive discussion of all changes developed from RFC 2543 to this document set. The MMUSIC and SIP Working Groups both did extensive review of an Offer-Answer Model with SDP, which was developed as a needed feature for SIP use of Session Description Protocol (SDP) bodies, but which the MMUSIC validated as an SDP semantic.
There was largely very strong consensus for the documents, throughout exhaustive review managed by the editors, despite the large amount of material encompassed.
Consensus was strong to add an Internet threat analysis for SIP use to the document. However, a vocal group of participants preferred to minimize security features in SIP in favor of design of configurations with trust ("walled garden" style). Eventually consensus was achieved on non-walled garden security, including mandatory-to implement TLS support in proxies and servers, and elimination of Basic (plaintext passwords) from the long-standing SIP User Agent Client (UAC) HTTP Authentication design. A rougher consensus formed around the requirement for end-to-end security support. The specification defines optional-to-implement S/MIME providing end-to-end integrity and confidentiality for both SIP headers and bodies. After more opportunities for implementation, the IESG expects that the requirement level of the S/MIME support will be upgraded in a future update.”
The IESG Secretary, March 7th, 2002.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
16
Decision Making in the IETF Telephony WGs
Although, the quality produced is usually good and not everything is bad…
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
17
Some of the Related IETF Working Groups
SIP, Session Initiation Protocol
SIPPING
SIMPLE, SIP for Instant Messaging & Presence Leveraging
MIDCOM, Firewall & NAT Traversal
IPTEL, Internet Telephony
AVT, Audio Video Transport
MMUSIC, Multiparty Multimedia Session Control
QoS Related, DiffServ, IntServ, RSVP
PSTN Legacy, SigTran, Megaco
Interaction of PSTN and IP Services, PINT, SPIRITS
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
18
The VoIP Threat Module
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
19
The VoIP Threat Module
Some challenges facing VoIP technology can be abused to introduce security and availability issues
– Delay/Latency
– Jitter
– Packet Loss
– Speech Coding techniques
– Network Availability
– Managing Access and Prioritizing Traffic: whenever a subscriber wishes to place a call he needs to be able to do so, where the appropriate bandwidth will need to be assigned to its call
The IP protocol’s security weaknesses are inherited (sniffing, spoofing, reply attacks and all the rest of the family)
Unique security issues raise from the protocols combining a VoIP solution
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
20
The VoIP Threat Module
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
21
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”
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
22
The VoIP Threat Module – Physical Security
Bypassing simple packet shaping mechanisms
Getting into the VoIP VLAN – An end-of-game
Alice’s PCAlice's IP Phone
Voice
Data
Alice's IP Phone
Voice
Data
Mikasa Sukasa
Packet Shaping for QoS(DiffServ)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
23
The VoIP Threat Module – Physical Security
IP PhoneIP Phone
PCPC
IP PhoneIP Phone
PCPC
100BaseT Hub
100BaseT Switch
100BaseT Switch
100BaseT Switch
100BaseT
100BaseT
100BaseT
100BaseT
100BaseT
100BaseT
Eavesdropping can be done 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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
24
The VoIP Threat Module – Physical SecurityFree 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 by using Call-ID to differentiate between calls destined to the phreaker to the calls destined to the owner of the line
Alice's IP Phone
Voice
Data
Mikasa Sukasa
I am representing thephysical address of the IP
Phone
I am representing thephysical address of the
Switch
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
25
The VoIP Threat Module – Authentication
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
26
The VoIP Threat Module – Availability
Shared infrastructure is bad for your health
– Do you really wish to put the tag of critical infrastructure on a shared infrastructure?
– Knock the Switches Off and you knocked them all
No Electricity No Service
– “G, here goes our Carrier Grade 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)
Last – Mile Availability problems
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
27
Other Rents
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
Call Tracking
and more…
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
28
The Session Initiation Protocol
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
29
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)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
30
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
31
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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
32
Overview of Operation
INVITE F1
INVITE F2
INVITE F4100 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
BYE F13
200 OK F14
Alice’s PC Bob’s SIP Phone
atlanta.comProxy Server
biloxy.comProxy Server
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.
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
33
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:[email protected], 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:[email protected]. 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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
34
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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
35
Overview of Operation – INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)
The Method name
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 nameContains a SIP or SIPS
URI that represents a direct route to Alice
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
36
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
37
Overview of Operation
INVITE F1
INVITE F2
INVITE F4100 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
BYE F13
200 OK F14
Alice’s PC Bob’s SIP Phone
atlanta.comProxy Server
biloxy.comProxy Server
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.
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 theIP 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).
F5: The biloxi.com proxy serverreceives 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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
38
Overview of Operation
INVITE F1
INVITE F2
INVITE F4100 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
BYE F13
200 OK F14
Alice’s PC Bob’s SIP Phone
atlanta.comProxy Server
biloxy.comProxy Server
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.
Each proxy usesthe 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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
39
Overview of Operation
INVITE F1
INVITE F2
INVITE F4100 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
BYE F13
200 OK F14
Alice’s PC Bob’s SIP Phone
atlanta.comProxy Server
biloxy.comProxy Server
F9: Bob decides to answer the call. When he picks up the handset, his SIP phone sends a200 (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. 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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
40
Overview of Operation
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:[email protected]>;tag=a6c85cf 465
From: Alice <sip:[email protected]>;tag=1928301774 466
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 131 471
(Bob’s SDP not shown)
The first line of the response contains the response code (200) and the reason phrase (OK)
Added by Alice’s softphone
Added by atlanta.com SIP Proxy
Added by biloxy.com SIP Proxy
Contains a URI at which Bob can be directly reached at his SIP phone.
What method this 200 OK is sent for?
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
41
Overview of Operation
INVITE F1
INVITE F2
INVITE F4100 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
BYE F13
200 OK F14
Alice’s PC Bob’s SIP Phone
atlanta.comProxy Server
biloxy.comProxy Server
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.
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 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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
42
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
43
Overview of Operation
INVITE F1
INVITE F2
INVITE F4100 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
BYE F13
200 OK F14
Alice’s PC Bob’s SIP Phone
atlanta.comProxy Server
biloxy.comProxy Server
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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
44
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 Record-Route 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.
INVITE F1
INVITE F2
INVITE F4100 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
BYE F14
200 OK F16
Alice’s PC Bob’s SIP Phone
atlanta.comProxy Server
biloxy.comProxy Server
ACK F13
BYE F15
200 OK F17
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
45
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:[email protected]) 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 RegistrationServer
SIP LocationServer
Bob’s SIP Phone
1. REGISTER
2. Write in DB
biloxy.comProxy Server
3. Query for Bob’sLocation
4. Zero (0) or moreURIs
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 request.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
46
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=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0
Bob’s SIP PhoneSIP RegistrationServer
REGISTER F1
200 OK F2
Associating Bob’s URI <sip:[email protected]> with the machine he is currently logged (the Contact information) <sip:[email protected]>
The information expires after 2 hours
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
47
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:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0
All Current Binding of <sip:[email protected]>
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
48
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).
INVITE F1
100 Trying F2
180 Ringing F3
Alice’s PC Bob’s SIP Phone
CANCEL F4
487 (Request Terminated) F5
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
49
Overview of Operation – CANCEL
INVITE F1
100 Trying F2
180 Ringing F3
Alice’s PC Bob’s SIP Phone
CANCEL F4'
200 OK F4
BYE F6
200 OK F7
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.
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).
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
50
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.
OPTIONS F1
200 OK F2
Alice’s PC Carol’s SIP Phone
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
51
Overview of Operation – OPTIONS
OPTIONS sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:[email protected]>
Accept: application/sdp
Content-Length: 0
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
52
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:[email protected]>;tag=93810874
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:[email protected]>
Contact: <mailto:[email protected]>
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)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
53
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
54
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”
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
55
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
56
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
57
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
58
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
59
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
– 423 Interval Too Brief
– 480 Temporarily Unavailable
– 481 Call/Transaction Does Not Exist
– 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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
60
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
61
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
62
SIP Architecture (I – Proxy)
SIP UA [A]
SIP Proxy
DNS Server
SIP UA [B]
Location Service
SIP Proxy
SIP Registrar1. Register
2. Store
sip.london.atstake.com
sip.sf.atstake.com
3. INVITE
5+6. DNS Query 7. FW: INVITE 9+10. Query & Respond
11. FW: INVITE
4. 100 Trying
8. 100 Trying
12. 180 Ringing
13. 180 Ringing
14. 180 Ringing
15. 200 OK
16. 200 OK
17. 200 OK 18. ACK
19. Media Transport is opened
20. BYE
21. 200 OK
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
63
SIP Architecture (II – Proxy & Redirect)
SIP UA [A]
SIP Proxy
DNS Server
SIP UA [B]
Location Service
SIP Proxy
SIP Registrar1. Register
2. Store
sip.london.atstake.com
sip.boston.atstake.com
3. INVITE
5+6. DNS Query 9. FW: INVITE 11+12. Query & Respond
13. FW: INVITE
4. 100 Trying
10. 100 Trying
14. 180 Ringing
15. 180 Ringing
16. 180 Ringing
17. 200 OK
18. 200 OK
19. 200 OK 20. ACK
21. Media Transport is opened
22. BYE
23. 200 OK
SIP Redirect Server
sip.NY.atstake.com
7. FW
: INVIT
E
8. Redire
ct:
sip.b
oston.ats
take.com
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
64
SIP Architecture (III – The Principle of Mobility)
SIP UA [A]
SIP Proxy
DNS Server
SIP UA [B]
Location Service
SIP Proxy
SIP Registrar1. Register
2. Store
sip.london.atstake.com
sip.sf.atstake.com
3. INVITE
5+6. DNS Query 7. FW: INVITE 9+10. Query & Respond
11. FW: INVITE
4. 100 Trying
8. 100 Trying
12. 3xx Redirect
13. FW: Redirect
SIP UA [B]
14. FW: INVITE
15. 180 Ringing
16. 180 Ringing
17. 200 OK
18. 200 OK 19. ACK
20. Media Transport is Open
21. Bye
22. 200 OK
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
65
SIP Message Structure
Some Other Time
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
66
The Change of Tides
…but than one day someone said: “Buckle up Dorothy, because Kansas is going bye-bye…”
UDP is hard to secure so let us now recommend using TCP because we can claim we can secure it…
So now TCP is the main transport protocol for sending SIP messages.
All the claims why UDP is better were thrown like they never existed…
So confused Dorothy had to continue her journey…
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
67
The SIP Threat Module
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
68
SIP Threat Module
Assumption:
An Attacker Is On the Wire
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
69
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 messages
– Mid-Session tricks
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
70
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
71
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
72
Denial of Service – CANCEL
SIP UA [A]
SIP Proxy
DNS Server
SIP UA [B]
Location Service
SIP Proxy
SIP Registrar1. Register
2. Store
sip.atlanta.com
sip.biloxy.com
3. INVITE
5+6. DNS Query7. FW: INVITE 9+10. Query & Respond
11. FW: INVITE
4. 100 Trying
8. 100 Trying
12. 180 Ringing
13. 180 Ringing
SIP UA [C]
15. CANCEL
14. 180 Ringing
The CANCEL needs to “hit” Bob’s SIP Phone before it sends the 200 OK. This is a Denial-of-Service on Bob
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
73
Denial of Service – CANCEL
SIP UA [A]
SIP Proxy
DNS Server
SIP UA [B]
Location Service
SIP Proxy
SIP Registrar1. Register
2. Store
sip.atlanta.com
sip.biloxy.com
3. INVITE
5+6. DNS Query 7. FW: INVITE 9+10. Query & Respond
11. FW: INVITE
4. 100 Trying
8. 100 Trying
12. 180 Ringing
13. 180 RingingSIP UA [C]
15. CANCEL14. 180 Ringing
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.
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
74
Denial of Service – BYE
Location Service
SIP Registrar
SIP UA [B]
SIP UA [C]
SIP Proxy
SIP UA [A]
SIP Proxy 1. Register
2. Store
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 both
3. INVITE
4. 100 Trying
5. FW: INVITE
6. 100 Trying
8. Reply
9. FW: INVITE
7. Query
10. 100 Trying
11. FW: 100 Trying
12. FW: 100 Trying
13. 200 OK14. FW: 200 OK
16. BYE
15. FW: 200 OK
sip.atlanta.com
sip.biloxy.com
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
75
Denial of Service – BYE (to Alice)
Location Service
SIP Registrar
SIP UA [B]
SIP UA [C]
SIP Proxy
SIP UA [A]
SIP Proxy
The 200OK is sent to acknowledge the BYE request
16. BYE
17. FW: BYE
18. FW: BYE
19. 200 OK
20. FW: 200 OK21. FW: 200 OK
200 OK received (The transaction is non-existent on Alice’s SIP Phone ONLY)
22. Any SIP Message
The “session” does not exist on the SIP Proxy anymore, but it will pass the message
23. FW: Any SIP Message
24. FW: Any SIP Message25. 481 Call/Transaction Does Not Exist
26. 481 Call/Transaction Does Not Exist
27. 481 Call/Transaction Does Not Exist
We got a mismatch
sip.atlanta.com
sip.biloxy.com
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
76
Denial of Service – BYE (to Bob)
Location Service
SIP Registrar
SIP UA [B]
SIP UA [C]
SIP Proxy
SIP UA [A]
SIP Proxy
17. 200 OK18. FW: 200 OK
16. BYE
19. FW: 200 OK
The “session” does not exist any more on Bob’s SIP Phone
sip.atlanta.com
sip.biloxy.com
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
77
Denial of Service – BYE (to Both)
Location Service
SIP Registrar
SIP UA [B]
SIP UA [C]
SIP Proxy
SIP UA [A]
SIP Proxy
16. BYE (B->A)
17. 200 OK
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 participants, and the 200 OK responses, although generated for a different message will not be suspected (Sequence of both BYE will be the same)
18. FW: 200 OK17’. 200 OK
16. BYE (A->B)
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 request.
19. FW: 200 OK
18’. FW: 200 OK 19’. FW: 200 OK
sip.atlanta.com
sip.biloxy.com
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
78
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.”
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
79
Call HijackUsing Manipulation of the Registration Records
Location Service
SIP Registrar
SIP UA [B]
SIP UA [C]
SIP Proxy
SIP UA [A]
SIP Proxy1. Register
2. Store3. Register
4. Store
Associating Bob’s URI <sip:[email protected]> with the machine he is currently logged (the Contact information) <sip:[email protected]>
Associating Bob’s URI <sip:[email protected]> with the attacker’s machine <sip:[email protected]>
4. INVITE
5. 100 Trying
6. FW: INVITE
7. 100 Trying
8. Query
9. Reply
10. FW: INVITE
sip.atlanta.com
sip.biloxy.com
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
80
Call Hijack Using Manipulation of the Registration Records
You can query the 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
You can give your registration higher priority than the other record (not deleting other records)
You can just register without priority and “knock off” the target so the SIP Proxy will try your entry…
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…
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
81
Call Hijack Using 301 Moved Permanently Response Code
SIP UA [A]
SIP Proxy
1. INVITE
2. 100 Trying
sip.atlanta.com
SIP Proxy
sip.biloxy.com
SIP UA [B]
SIP UA [C]
SIP:carol@IP_ADDRESS
3. FW: INVITE
4. 301 Moved Permanently
“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 value and redirect future requests to the address(es) listed.”
5. INVITE
The INVITE that was originally sent to [email protected], 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
6. FW: INVITE
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
82
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.”
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
83
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
Can evolve to introducing other participants to the session
“Eavesdropping made easy”
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
84
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
85
MITM Attacks – 302 Moved Temporarily
SIP UA [A]
SIP Proxy
1. INVITE
2. 302 Moved Temporarily sip.atlanta.com
SIP Proxy
sip.biloxy.com
SIP UA [B]
“Carol’s Proxy”
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.”
3. INVITE’
4. FW: INVITE’
5. 100 Trying
6. FW: INVITE
Carol is now acting as a SIP Proxy
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
86
MITM Attacks – vs. Registrar
Location Service
SIP Registrar
SIP UA [B]
SIP UA [C]
1. Register
Bob’s SIP Phone performs a registration request
Carol is spoofing a 301 Moved Permanently response message allegedly coming from the REGISTRAR
2. 301 Moved Permanently
3. Register’4. 401 Unauthorized
5. Register’’ request with appropriate credentials
6. Confirm Registration
7. Register request for bob’s credentials8. Store
Carol has bob’s credentials – Game Over
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
87
MITM Attacks – 305 Use Proxy
SIP UA [A]
SIP Proxy
1. INVITE
2. 305 Use Proxysip.atlanta.com
SIP Proxy
sip.biloxy.com
SIP UA [B]
“Carol’s Proxy”
“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 (Use Proxy) responses MUST only be generated by UASs. “
3. INVITE’
4. FW: INVITE
5. 100 Trying
6. FW: INVITE
Carol is now acting as a SIP Proxy
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
88
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 will be changed or the Media stream will be cut, the signaling protocol is simply blind
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 voice)
No Provisioning what so ever on the Media stream
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
89
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)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
90
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!
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
91
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
92
Call Tracking
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
93
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…
It also 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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
94
Clients are Malicious
Location Service
SIP Registrar
SIP UA [B]
SIP Proxy
SIP UA [A]
SIP Proxy
A “conspirator” will have all the route taken (at least the entities that needs to be passed through) in the VIA headers
sip.atlanta.comsip.biloxy.com
Encrypted
SIP Proxy
sip.somewhere.com
Encrypted
Might be
Encrypted
Might be
Encrypted
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
95
More Issues
Firewalls & NAT
A great need to understand who was first – The chicken or the egg (with signaling)
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
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
96
Security Mechanisms with the SIP Protocol
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
97
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…
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
98
Security Mechanisms with the SIP Protocol
S/MIME for message bodies (key distribution)
Digest Authentication (Not again!)
With encryption firewalls will be useless when they have the ability to really understand the protocol (remember Max-Forwards for example?)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
99
Multimedia Communication (RTP & RTCP)
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
100
Multimedia Communication (RTP & RTCP)
Maybe Some Other Time
© 2 0 0 1 - 2 0 0 2 O F I R A R K I N & @ S T A K E , I N C .
101
Future/Current Research
Bypassing the use of Encryption (no, not breaking the code)
Analyzing Instant Messaging using SIP
Ofir ArkinManaging Security Architect
VoIP The Next Generation of Phreaking
orE.T. Can’t Phone Home Questions?