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.