VoIP Security
German WWII Enigma
Quantum Key Exchange
Mary “Queen of Scots”
Nomenclature cipher
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
VoIP Security
• Lecture is a broad brush intro – large topic
•
•
•
•
•
– Basic ideas around security
– Catalog of threats and vulnerabilities
– Signaling security
– Media security
Take a read through Thermos & Takanen, “Securing VoIP Networks” –
very nice review of VoIP security.
Download clients to test security – Cain & Able (poison ARP table for
eavesdropping) and SiVus (flooding, etc.)
Download softclient that supports ZRTP – try using ethereal to listen to
the RTP packets.
Configure your client to do SIPS/TLS, and use the lab’s SBC to look at
the sip messaging.
Caveat – While not quite “the blind leading the blind”, I am not close to being a
security guru .. So don’t take my comments/lecture as gospel!
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
Typical Threats to VoIP Services
• Eavesdropping (LEA => wire-tapping)
• Watching the signaling (LEA => pen, trap, & trace)
• Telephone SPAM (now called SPIT – SPam Internet
Telephony)
• DOS (Denial or Interruption/Corruption of Service) – many
different ways to do this.
• Impersonation – receiving calls intended for someone else,
or making calls pretending to be someone else.
• Fraud/Unauthorized Access -
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
Security for messaging (SIP, SMTP, etc.): Basic Concepts
• Authentication:
– Parties to a conversation can “prove”
their identity.
– => Non-repudiation (“It wasn’t me
who sent that email, it was my dog.”)
• Message Integrity
– The message was not modified after
you hit the “send” key.
• Confidentiality
– Message is encrypted so that it cannot be
intercepted and read.
• Authentication & Integrity typically provided via Digital Certificates.
• Encryption using some form of a “key” – shared secret key or a
public/private key ..
• The infrastructure for industry accepted secure protocols (TLS, IPSec,
or S/MIME) typically supported by a Public Key Infrastructure (PKI):
hardware/software + policies/procedures
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
SIP: HTTP Digest Authentication
1. 192.168.0.6:5060 ----> 192.168.0.120:5060
INVITE sip:16172538647@192.168.0.120:5060;user=phone SIP/2.0.
……
2. U 192.168.0.6:5060 <---- 192.168.0.120:5060
SIP/2.0 407 Proxy Authentication Required.
……
Proxy-Authenticate: Digest realm="asterisk", nonce="4b433621".
3. U 192.168.0.6:5060 ----> 192.168.0.120:5060
INVITE sip:16172538647@192.168.0.120:5060;user=phone SIP/2.0.
..........
Proxy-Authorization: Digest username="3002", realm="asterisk",
nonce="4b433621",
uri="sip:16172538647@192.168.0.120:5060;user=phone",
response="a6c27fc7a37b00ea11ddafde6cd9002b",
algorithm=MD5.
4. U 192.168.0.6:5060 <--- 192.168.0.120:5060
SIP/2.0 100 Trying.
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
What’s wrong with Digest Authentication?
• It does a pretty good job of preventing someone from stealing your
calls, or making calls while pretending to be you.
– OK, there are some NITs here. You can read about it, things like most
systems don’t auth BYES, or not being able to auth CANCELS or ACKs.
Also, as used in practice, it’s often only used in one direction (the
“carrier/enterprise” auths the end-user).
• IT DOESN”T PREVENT ANYONE FROM READING THE SIP
MESSAGES – I can’t pretend to be you, but I can see who you are
calling, whose calling you. Moreover, if you wanted to pass
cryptographic “keys” in the SIP message to enable RTP encryption,
those could be seen as well.
• => Need something stronger.
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
So – how to protect SIP messages
• The standard internet way – encrypt so that the message can only be
decoded by the “safe” network elements. Secure SIP (SIPS) is defined
for :
– TLS (Transport Layer Security) – basically SSL (https)
– IP:SEC (for example, over a VPN).
– S/MIME
• VLAN – figure out a way to prevent “bad guys” from being able to access
a given network. {IMO, this is a poor mechanism – it’s what is being
used at MIT, but there seem to be many holes in it .. For example, the
mechanism to determine what device is put on the VLAN seems very
susceptible. It was also used for a while at Verizon.}. Another problem is
that only works for a LAN, limits VoIP traffic to a LAN rather than WAN.
• MPLS – one can think about MPLS as a VLAN for the WAN. Some
carriers use MPLS internally, and sell to customers at the WAN edge. I
think it suffers from many of the same problems that VLANs do –
prevents (or tries to) access to the data stream, but doesn’t really provide
authentication (there is some policing) or confidentiality.
• The industry consensus to protect SIP seems clearly to be TLS!
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
TLS (Transport Layer Security ~ = Secure Sockets Layer)
TLS
Server
TLS
client
SIP User
Agent
SIPS Session
TLS
Server
TLS
TLS
`
TLS
client
`
SIP
Proxy
Web
Browser
https session
Web
Server
High Level – how does this work?
1. Client requests TLS session, presents cipher to server.
2. Server picks highest common denominator cipher (not unlike codec
negotiation).
3. Server sends client digital cert (pubic key sent!)
4. Client may confirm authenticity (certificate authenticity)
5. Client hashes random number with pubic key, sends to server
6. Server un-hashes the random number using it’s private key
7. So, now both sides know the “secret” random number => use this to create the
key for encrypting this SIP session. (How long is the session active for?)
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
SIPS Session Example
•
•
Once TLS handshake is completed, the SIP client encrypts the SIP messages
(packet payload). L2/L3 headers remain unencrypted. Normal SIP messages,
except for an indication of sips and protocol as TLS.
Typically, the encryption key for SRTP is also provided in the SDP – only now
it’s protected.
192.168.0.6:5060 -> 192.168.0.120:5060
INVITE sips:16172538647@192.168.0.120:5060;user=phone SIP/2.0.
Via: SIP/2.0/TLS 192.168.0.6;branch=z9hG4bK757784edBA3CFC9C.
From: "Elliot" <sips:3002@192.168.0.120>;tag=82E5EA28-1A192AFF.
To: <sips:16172538647@192.168.0.120;user=phone>.
CSeq: 1 INVITE.
Call-ID: 3f523dd3-3b7bc452-734bedd9@192.168.0.6.
Contact: <sips:3002@192.168.0.6>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_550-UA/3.0.1.0032.
Supported: 100rel,replaces.
Allow-Events: talk,hold,conference.
Max-Forwards: 70.
Content-Type: application/sdp.
Content-Length: 271.
.
v=0.
o=- 1238178111 1238178111 IN IP4 192.168.0.6.
s=Polycom IP Phone.
c=IN IP4 192.168.0.6.
t=0 0.
m=audio 2266 RTP/AVP 9 0 8 18 101.
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUZvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
So – what’s the problem with TLS?
• Good things:
–
–
–
–
Mutual authentication (cert based, although most auth is still one way)
Provides immunity to eavesdropping, message tampering, replay.
Lots of code (www) that has been proven
Supposedly fewer MIPS than IPSec.
• Bad things
– Not End-to-End:
• Must be separately enabled for each SIP hop
• The endpoint has no certainty that the call is protected end-end
– Not UDP (ok, how bad is this really?)
• There is a version of TLS that works over UDP – called Datagram Transport
Layer Security
– Still subject to DOS attacks
`
TLS(1)
TLS(2)
SIP
Proxy
Northeastern TSM 350G
TLS(3)
TLS(4)
SIP
SIP
Proxy
Proxy
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
`
MIT Long Term VoIP Architecture
Open Source
Analog POTS
IP-Centrex
Emergency Phones
Shared
Services
Outbound Proxy
Pilot:openSER
ENUM
(DNS)
External
Access
(Trunk Side)
Internal (routing)
Proxy
SYL
Server
Syl Control
Presence
(feature
server,
Server
registration dB)
SYL
SYLRoute
RouteServer
Server
Pliot: openSER
Messaging
(Iperia)
Other Shared Services
(conferencing,
presence, etc.)
VoIP Gateways
DMZ SBC
Public IP
Northeastern TSM 350G
PBX …..
SYL Presence
Server
Location
dB
Fax
Modem, point of
sale, alarms, etc.
Session Border Controller (SBC)
Internal
Access
(Line Side)
5/9/2007
Pilot:Cisco 5850
Carrier
SBC
PSTN
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
MIT Long Term VoIP Architecture
Open Source
Analog POTS
IP-Centrex
Un-trusted area
Emergency Phones
Internal
Access
(Line Side)
Shared
Services
Outbound Proxy
Pilot:openSER
ENUM
(DNS)
External
Access
(Trunk Side)
PBX …..
SYL Presence
Server
Location
dB
Internal (routing)
Proxy
Fax
Modem, point of
sale, alarms, etc.
Session Border Controller (SBC)
Trusted area
5/9/2007
SYL
Server
Syl Control
Presence
(feature
server,
Server
registration dB)
SYL
SYLRoute
RouteServer
Server
Pliot: openSER
Messaging
(Iperia)
Other Shared Services
(conferencing,
presence, etc.)
VoIP Gateways
DMZ SBC
Pilot:Cisco 5850
Carrier
SBC
Un-trusted area
Public IP
Northeastern TSM 350G
PSTN
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
IPSec vs. TLS
• TLS (or SSL):
IP Header TCP Header
Encrypted
Payload
– Model is usually Client  Server
• IPSec (running in Tunnel mode – other models defined for
IPSec).
New
IP Header
ESP
Header
IP Header TCP Header
Encrypted
Payload
ESP
Trailer
– Model is often Router  Router/Gateway, with clients hanging off
the Routers, or Client Router/Gateway (client VPN).
– Basically, you encrypt the entire packet rather than just the
payload. You create a tunnel for all IP packets, not just a
particularly app. (ESP => encapsulating security payload).
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
+/- of IPSec
• Good Things:
– Lots of code that has been proven, widely used protocol.
– Provides the full suite of services: authentication, confidentiality,
integrity.
– Can tunnel everything (SIP, RTP, HTTP, etc.) through one link.
• Bad Things:
– Not really functional for a large VoIP network infrastructure with
lots of routes – but works well for enterprise and limited closed
infrastructures.
– Still not end-end (I think .. need to think about this, but think that
end-end not possible if the SIP header has to be processed by
multiple proxes (multiple hops).
– Supposedly requires more MIPS than TLS (hmm .. I wonder how
true or important this really is).
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
S/MIME: Multipurpose Internet Mail Extensions
• S/MIME primarily an email protocol.
• Encryption by the sender uses the recipient's public key.
• S/MIME can be used to encrypt some of the SIP message
(for example, the SRTP key or the entire SDP portion of
the SIP header). Thus can provide end-to-end
confidentiality of the key that secures the media.
• SIPS still can be used on hop-hop basis to provide
authentication and confidentiality.
• Still issue of end-end for signaling as long as the SIP
header has to be processed by multiple proxies.
• Seems like an ideal way to support:
– Normal SIPS functionality (hop to hop for SIP header fields).
– End-end security for media, by encrypting the SRTP keys
• For some reason (not sure why), S/MIME does not seem to
have much traction.
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
SRTP: Secure RTP
• Provides authentication, integrity, and confidentiality of RTP (media
streams), and of RTCP. Why RTCP ?
• Any RTP stream (voice or video codec, e.g. G711, G729, H264, etc.)
can be encrypted. Encryption algorithm used is 128 bit AES.
• Shared secret (generates the key) carried in the SDP portion of the SIP
Message. So, in principal, the carrier or SIP provider has the ability to
provide the key to LEA.
• ZRTP (Zimerman RTP):
– The shared secret is negotiated in the RTP session itself, not in the
SIP messaging. The carrier cannot “betray” the end-users.
– Draft submitted to the IETF, there are implementations you can
download:
• http://www.twinklephone.com/ - unix softphone
• http://www.sip-communicator.org/index.php/Main/HomePage windows, mac, linux; this started out from the NIST JAIN project.
• There was a counterpath, xlite version that did ZRTP. Not sure what
happened to that.
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
Where are the threats? – everywhere!
Service Layer App Layer (Conf Bridge,
(SIP, RTP, etc.) Credit Card Calls, etc.
Platform OS’: could be CPE (phones,
PCs), Data Center Servers, etc.
Mgmt Layer (Config Mgmt,
App & Acct Mgmt, Billing ..)
Platform OS’
Network & Transport (routing, DNS, ethernet, etc.)
Platform OS’: IOS, embedded RT OS’, various flavors UNIX, etc.
Physical Layer – mostly spy/NSA stuff, but now there’s
wireless (802.,11, 2/3G, WiMax, LTE, ..)
People – phishing and more sinister aspects
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
Some Examples
• SPAM @ major US University
– May 07: user in Germany rings all numbers in the University DID
space by sending calls to sip:number@univ.edu. Rings every voip
phone at school. How to stop – put an ACL on the phone. More
generic way is to screen through an SBC.
• Cain & Able Client @ major US University
– Poison Arp table attack – able to eavesdrop on calls running on a
VLAN. Older L2 switch allowed PC running softclient to enter VoIP
VLAN, from which client was able to do a man in the middle attack.
{From this experience, I believe VLANs are suspect}.
• RTP Insertion at Major US Carrier
– I think in 2006. Carrier was not checking sequence numbers in the
RTP header. Packets for a bogus commercial were inserted into
the RTP stream of conversations for about an hour. How to stop –
have the phone check RTP sequence numbers, and discard
packets. More generic way is to either invoke end-end SRTP, or to
pass all RTP streams through an SBC and use a phone ACL (this
is not very efficient).
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.
Another Example
• Malicious Loop – brought down one of the SIP Bakeoffs:
peter1@neu.edu
– Setup call forking where elliot1@mit.edu
peter2@neu.edu
elliot1@neu.edu
– And peter1@neu.edu
elliot2@neu.edu
The number of calls grows exponentially as 2N – will kill a
server VERY FAST. Solutions
* limit max-forwards (default is 70, 2^70 is a big #)
* disable forking (not a good idea, necc functionality)
* implement sophisticated loop detection (performance
hit).
Northeastern TSM 350G
Copyright 2005 – 2009 © by Elliot Eichen. All rights reserved.