Transcript E.T. Can’t Phone Home Security Issues with VoIP Ofir Arkin Managing Security Architect.

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
M3UA, M2UA/SCTP
M3UA, M2UA/SCTP
SIP
MGC
MG
MGC
SI
P
P
SI
Megaco/H.248
PSTN
Megaco/H.248
IP Network
RTP
ISUP
TCAP,
TCAP,
ISUP
SG
RTP
MG
PSTN
13
©2001-2002
OFIR ARKIN
&
@STAKE,
INC.
Internet Telephony Architecture Using SIP
RTP
RTP
SIP
SIP
SI
P
The Internet
Network A
P
SI
SIP
UA
SIP
Proxy
P
SI
SI
P
SIP
Proxy
Network B
RTP
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
Alice's IP Phone
Data
Voice
Data
Alice’s PC
Mikasa Sukasa
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
100BaseT Switch
PC
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
Data
I am representing the
physical address of the IP
Phone
Mikasa Sukasa
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.
biloxy.com
Proxy Server
atlanta.com
Proxy Server
Bob’s SIP Phone
Alice’s PC
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
INVITE F1
INVITE F2
INVITE F4
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
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:[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
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
Overview of Operation – INVITE
The Method name
INVITE sip:[email protected] SIP/2.0
OFIR ARKIN
&
@STAKE,
INC.
The address which Alice is
expecting to receive
responses. This parameter
indicates the path the return
message needs to take
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
A display name and a SIP or
SIPS URI towards which the
request was originally
directed
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]>
Contains a SIP or SIPS
URI that represents a
direct route to Alice
Contains a globally unique
identifier for this call
Contains an integer
(traditional sequence number)
and a method name
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.
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).
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
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
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.
atlanta.com
Proxy Server
biloxy.com
Proxy Server
Alice’s PC
Bob’s SIP Phone
INVITE F1
INVITE F2
100 Trying F3
INVITE F4
100 Trying F5
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.
180 Ringing F6
180 Ringing F7
180 Ringing F8
200 OK F9
200 OK F10
200 OK F11
&
@STAKE,
INC.
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.
ACK F12
RTP Media Stream
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
INVITE F4
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
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:[email protected]>;tag=a6c85cf 465
From: Alice <sip:[email protected]>;tag=1928301774 466
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
What method this 200 OK is sent for?
Contains a URI at which
Bob can be directly
reached at his SIP phone.
Content-Type: application/sdp
Content-Length: 131 471
(Bob’s SDP not shown)
47
©2001-2002
OFIR ARKIN
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.
atlanta.com
Proxy Server
biloxy.com
Proxy Server
Alice’s PC
Bob’s SIP Phone
INVITE F1
INVITE F2
100 Trying F3
INVITE F4
100 Trying F5
180 Ringing F6
180 Ringing F7
180 Ringing F8
200 OK F9
200 OK F10
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.
200 OK F11
ACK F12
RTP Media Stream
BYE F13
200 OK F14
&
@STAKE,
INC.
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
©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
Bob’s SIP Phone
INVITE F1
INVITE F2
100 Trying F3
INVITE F4
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
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
Bob’s SIP Phone
INVITE F1
INVITE F2
100 Trying F3
INVITE F4
100 Trying F5
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:[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 Location
Server
SIP Registration
Server
2. Write in DB
3. Query for Bob’s
Location
4. Zero (0) or more
URIs
biloxy.com
Proxy Server
1. REGISTER
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
Bob’s SIP Phone
SIP Registration
Server
Max-Forwards: 70
REGISTER F1
200 OK F2
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
The information expires
after 2 hours
Associating Bob’s URI
<sip:[email protected]>
with the machine he is
currently logged (the
Contact information)
<sip:[email protected]>
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:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
All Current Binding of
<sip:[email protected]>
Expires: 7200
Content-Length: 0
54
©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).
Bob’s SIP Phone
Alice’s PC
INVITE F1
100 Trying F2
180 Ringing F3
CANCEL F4
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.
Bob’s SIP Phone
Alice’s PC
INVITE F1
100 Trying F2
180 Ringing F3
200 OK F4
CANCEL F4'
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.
Carol’s SIP Phone
Alice’s PC
OPTIONS F1
200 OK F2
57
©2001-2002
OFIR ARKIN
&
@STAKE,
INC.
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
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:[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)
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
– 482 Loop Detected
–
413 Request Entity Too Large
–
483 Too Many Hops
–
414 Request URI Too Long
–
484 Address Incomplete
–
415 Unsupported Media Type
–
485 Ambiguous
–
416 Unsupported Media Scheme
–
486 Busy Here
–
420 Bad Extension
–
487 Request Terminated
–
421 Extension Required
–
488 Not Acceptable Here
–
423 Interval Too Brief
–
491 Request Pending
–
480 Temporarily Unavailable
–
493 Undecipherable
–
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
5+6. DNS Query
7. FW: INVITE
9+10. Query & Respond
16. 200 OK
8. 100 Trying
13. 180 Ringing
3. INVITE
SIP Proxy
sip.atlanta.com
4. 100 Trying
14. 180 Ringing
17. 200 OK
18. ACK 20. BYE
SIP UA [A]
sip:[email protected]
19. Media Transport is opened
21. 200 OK
2. Store
11. FW: INVITE
15. 200 OK
12. 180 Ringing
1. Register
SIP Registrar
SIP UA [B]
sip:[email protected]
69
©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
5+6. DNS Query
9. FW: INVITE
11+12. Query & Respond
18. 200 OK
10. 100 Trying
15. 180 Ringing
3. INVITE
SIP Proxy
sip.atlanta.com
4. 100 Trying
16. 180 Ringing
19. 200 OK
20. ACK 22. BYE
SIP UA [A]
sip:[email protected]
21. Media Transport is opened
23. 200 OK
2. Store
13. FW: INVITE
17. 200 OK
14. 180 Ringing
1. Register
SIP Registrar
SIP UA [B]
sip:[email protected]
70
©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
9+10. Query & Respond
8. 100 Trying
13. FW: Redirect
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 [A]
sip:[email protected]
11. FW: INVITE
14. FW: INVITE
17.
15.200
180OK
Ringing12. 3xx Redirect
SIP UA [B]
[email protected]
2. Store
1. Register
SIP Registrar
SIP UA [B]
sip:[email protected]
71
©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:[email protected]
SIP UA [C]
DNS Server
Location
Service
sip.biloxy.com
SIP Proxy
2. Store
9+10. Query & Respond
7. FW: INVITE
5+6. DNS Query
15. CANCEL
8. 100 Trying
13. 180 Ringing
3. INVITE
SIP Proxy
sip.atlanta.com
4. 100 Trying
11. FW: INVITE
1. Register
SIP Registrar
12. 180 Ringing
14. 180 Ringing
SIP UA [A]
SIP:[email protected]
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:[email protected]
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
8. 100 Trying
13. 180 Ringing
SIP:[email protected]
SIP UA [C]
SIP Proxy
sip.atlanta.com
3. INVITE
2. Store
9+10. Query & Respond
7. FW: INVITE
5+6. DNS Query
Location
Service
11. FW: INVITE
12. 180 Ringing
1. Register
SIP Registrar
4. 100 Trying
14. 180 Ringing
15. CANCEL
SIP UA [B]
SIP:[email protected]
SIP UA [A]
SIP:[email protected]
80
©2001-2002
OFIR ARKIN
&
@STAKE,
INC.
Denial of Service – BYE
SIP:[email protected]
SIP UA [C]
5. FW: INVITE
Location Service
16. BYE
7. Query
sip.biloxy.com
SIP Proxy
2. Store
8. Reply
10. 100 Trying
13. 200 OK
SIP Proxy
sip.atlanta.com
3. INVITE
12. FW: 100 Trying
4. 100 Trying
15. FW: 200 OK
SIP UA [A]
SIP:[email protected]
6. 100 Trying
FW:
200
OK
11.14.
FW:
100
Trying
9. FW: INVITE
SIP Registrar
1. Register
SIP UA [B]
SIP:[email protected]
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
©2001-2002
OFIR ARKIN
&
@STAKE,
INC.
Denial of Service – BYE (to Alice)
SIP:[email protected]
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
22. Any SIP Message
sip.atlanta.com
25. 481 Call/Transaction Does Not Exist
SIP UA [B]
24. FW: Any SIP Message
SIP:[email protected]
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:[email protected]
Phone ONLY)
19. 200 OK
©2001-2002
OFIR ARKIN
&
@STAKE,
INC.
Denial of Service – BYE (to Bob)
SIP:[email protected]
SIP UA [C]
Location Service
sip.biloxy.com
SIP Proxy
18. FW: 200 OK
SIP Proxy
sip.atlanta.com
16. BYE
SIP Registrar
17. 200 OK
SIP UA [B]
19. FW: 200 OK
SIP UA [A]
SIP:[email protected]
SIP:[email protected]
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:[email protected]
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)
sip.biloxy.com
SIP Proxy
18’. FW: 200 OK
18. FW: 200 OK
SIP Proxy
sip.atlanta.com
17’. 200 OK
Location Service
16. BYE (A->B)
19’. FW: 200 OK
SIP Registrar
17. 200 OK
SIP UA [B]
19. FW: 200 OK
SIP UA [A]
SIP:[email protected]
SIP:[email protected]
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:[email protected]> with the
attacker’s machine
<sip:[email protected]>
SIP:[email protected]
SIP UA [C]
Location Service
10. FW: INVITE
sip.biloxy.com
SIP Proxy
6. FW: INVITE
3. Register
8. Query
2. Store
4. Store
9. Reply
7. 100 Trying
SIP Registrar
SIP Proxy
sip.atlanta.com
4. INVITE
1. Register
SIP UA [B]
5. 100 Trying
SIP UA [A]
SIP:[email protected]
SIP:[email protected]
Associating Bob’s URI
<sip:[email protected]> with the
machine he is currently logged
(the Contact information)
<sip:[email protected]>
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 [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
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
SIP UA [B]
SIP:[email protected]
2. 100 Trying
SIP UA [A]
SIP:[email protected]
“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:[email protected]
SIP UA [A]
SIP:[email protected]
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:[email protected]
SIP UA [C]
Carol has bob’s credentials – Game
4. 401 Unauthorized
Over
2. 301 Moved
Permanently
6. Confirm
Registration
Location Service
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:[email protected]
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:[email protected]
SIP UA [A]
SIP:[email protected]
“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:[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)
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
Location Service
sip.somewhere.com
SIP Proxy
Encrypted
Encrypted
Might be
Encrypted
SIP Proxy
Might be
Encrypted
SIP Proxy
sip.atlanta.com
SIP Registrar
sip.biloxy.com
SIP UA [B]
SIP:[email protected]
SIP UA [A]
SIP:[email protected]
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