VoIP Security

German WWII EnigmaQuantum Key Exchange

Mary “Queen of Scots”Nomenclature cipher

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!

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 -

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

SIP: HTTP Digest Authentication

1. 192.168.0.6:5060 ----> 192.168.0.120:5060INVITE 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:5060SIP/2.0 100 Trying.

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.

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!

TLS (Transport Layer Security ~ = Secure Sockets Layer)

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

`

TLS client

Web Browser

TLS

Web Server

TLSServer

https session

TLS

SIP Proxy

TLS client

TLSServer

SIP User Agent SIPS Session

High Level – how does this work?

SIPS Session Example

192.168.0.6:5060 -> 192.168.0.120:5060INVITE 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

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

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(3) TLS(4)TLS(2)

SIP Proxy

SIP Proxy

SIP Proxy

MIT Long Term VoIP Architecture

Internal (routing) Proxy

Pliot: openSER

Outbound ProxyPilot:openSER

PSTNPublic IP

External Access

(Trunk Side)

Shared Services

Internal Access

(Line Side)

ENUM (DNS)

Location dB

Open Source

VoIP GatewaysPilot:Cisco 5850

IP-Centrex

Session Border Controller (SBC)

SYL Presence Server

Syl Presence Server

SYL Control Server (feature server, registration dB)

SYL Route ServerSYL Route Server Messaging(Iperia)

DMZ SBC Carrier SBC

PBX …..

Fax

Modem, point of sale, alarms, etc.

Analog POTS

Emergency Phones

Other Shared Services (conferencing, presence, etc.)

5/9/2007

MIT Long Term VoIP Architecture

Internal (routing) Proxy

Pliot: openSER

Outbound ProxyPilot:openSER

PSTNPublic IP

External Access

(Trunk Side)

Shared Services

Internal Access

(Line Side)

ENUM (DNS)

Location dB

Open Source

VoIP GatewaysPilot:Cisco 5850

IP-Centrex

Session Border Controller (SBC)

SYL Presence Server

Syl Presence Server

SYL Control Server (feature server, registration dB)

SYL Route ServerSYL Route Server Messaging(Iperia)

DMZ SBC Carrier SBC

PBX …..

Fax

Modem, point of sale, alarms, etc.

Analog POTS

Emergency Phones

Other Shared Services (conferencing, presence, etc.)

5/9/2007

Un-trusted area

Un-trusted area

Trusted area

IPSec vs. TLS

• TLS (or SSL):

– Model is usually Client Server

• IPSec (running in Tunnel mode – other models defined for IPSec).

– 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).

IP HeaderEncrypted

PayloadTCP Header

IP HeaderEncrypted

PayloadTCP Header

ESP Header

ESP Trailer

NewIP Header

+/- 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).

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.

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.

Where are the threats? – everywhere!

Service Layer (SIP, RTP, etc.)

App Layer (Conf Bridge, 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

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

Another Example

• Malicious Loop – brought down one of the SIP Bakeoffs:

– Setup call forking where elliot1@mit.edu

– And peter1@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).

peter1@neu.edu

peter2@neu.edu

elliot1@neu.edu

elliot2@neu.edu