Columbia Verizon Research Security: VoIP Denial-of-Service (DoS) Eilon Yardeni Columbia University Gaston Ormazabal Verizon Labs May 23, 2006 Agenda Project Overview – Background – What is the problem? – Goals The SIP Threat Model DoS attack taxonomy Mitigation strategy Testbed and Validation strategy Demo Discussion May 23, 2006 2 Background Previous project results – Successfully implemented a large scale SIP-aware dynamic pinhole filter (firewall) – The filter is used as a first-line of defense against DoS attacks at the network perimeter Only signaled media channels can traverse the perimeter End systems are protected against flooding of random RTP or other packets But…attacks can still traverse the perimeter through the signaling port and media ports – Pinholes cannot distinguish legitimate from illegitimate traffic May 23, 2006 3 The Problem Attack traffic that traverses the perimeter could target the availability of the signaling VoIP services Telephony services migrating to IP become an attractive DoS attack target Attack targets could be supporting services (e.g. DNS), SIP infrastructure elements (proxy, softswitch, SBC) and end-points (SIP phones) May 23, 2006 4 Goals Study VoIP DoS – – – – Definition – define VoIP specific threats Detection – how do we detect an attack? Mitigation – defense strategy and implementation Validation – validate our defense strategy Generate requirements for future security network elements and test tools for their validation May 23, 2006 5 The SIP Threat Model (1) Eavesdropping Impersonation of a SIP entity Interception and Modification of SIP messages Service Abuse Denial of Service • VoIP Security and Privacy Threat Taxonomy, VoIPSA October 2005 • RFC 3261, SIP: Session Initiation Protocol, June 2002 May 23, 2006 6 The SIP Threat Model (2) Eavesdropping – Attacker can monitor signaling/media streams, but cannot or does not alter the data itself – Signaling channel is not confidential – Call Pattern Tracking Discovery of identity, affiliation, presence – Traffic Capture Packet recording – Number harvesting Unauthorized collection of numbers, emails, SIP URIs May 23, 2006 7 The SIP Threat Model (3) Impersonation of a SIP entity – Impersonate a UA Absence of assurance of a request’s originator Registration Hijacking - attacker deregisters a legitimate contact and registers its own device for that contact – Impersonate a Server UAs should authenticate the server to whom they send requests Attacker impersonates a remote server and intercepts UA’s requests May 23, 2006 8 The SIP Threat Model (4) Interception and Modification of SIP messages – Man-in-the-middle attack UA is using SIP to communicate media session keys – Call Rerouting Attacker might modify the SDP in order to route media streams to a wiretapping device – Conversation Degradation Attacker might cause intentional reduction in QoS – False Call Identification Change “Subject” so message considered Spam May 23, 2006 9 The SIP Threat Model (5) Service Abuse – Call Conference Abuse Hide identity for the purpose of committing fraud – Premium Rate Service Fraud Artificially increase traffic in order to maximize billing – Improper Bypass or Adjustment to Billing Avoid authorized service charge by altering billing records May 23, 2006 10 Denial of Service (1) Denial-of-Service – preventing users from effectively using the targeted services – Complete loss of service – Service degradation to a “not usable” point Distributed denial-of-service attacks continue to be the main threat facing network operators* Most attacks involve compromised hosts (bots), with botnets sized from a few thousands to over 100,000* * - Worldwide ISP Security Report, September 2005, Arbor Networks May 23, 2006 11 Denial of Service (2) * - Worldwide ISP Security Report, September 2005, Arbor Networks May 23, 2006 12 DoS Attack Taxonomy (1) Implementation flaws Application level Flooding May 23, 2006 13 DoS Attack Taxonomy (2) Implementation flaws – Attacker sends carefully crafted packet(s) that exploits a specific implementation flaw – Might cause excessive memory/disk/CPU consumption and/or system reboot or crash – Target vulnerability could originate in different levels of the network protocol stack or in the underlying OS/firmware May 23, 2006 14 DoS Attack Taxonomy (3) Application level - a feature of SIP is manipulated to cause a DoS attack – Registration Hijacking Attacker registers his device with other user’s URI – Call Hijacking Attacker can inject a “301 Moved Permanently” message to an active session – Modification of media sessions Attacker can spoof re-INVITE messages thereby reducing QoS, redirecting media, modifying security attributes May 23, 2006 15 DoS Attack Taxonomy (4) Application level (Cont.) – Session teardown Attacker can spoof a BYE message and inject it to an active session thereby tearing down the session – Amplification attacks Attacker can create bogus requests with falsified Via header field that identifies a target host UAs/proxies generates a DDoS against that target – Media streams attack Attacker can inject spoofed RTP packets with high seq numbers into a media stream thereby modifying playout sequence May 23, 2006 16 DoS Attack Taxonomy (5) Flooding – Attacker can flood the network link or overwhelm the target host – Usually requires more resources from the attacker – Harder to defend against – even the best maintained systems can become congested – Variants could be: UDP floods, ICPM echo attacks, SYN floods etc,. – Floods of INVITE or REGISTER messages could cause excessive processing at a SIP proxy May 23, 2006 17 Mitigation strategy (1) Implementation flaws are easier to deal with – Systems can be tested before used in production – Systems can be patched when a new flaw is discovered – Attack signatures could be integrated with a firewall Application level and flooding attacks are harder to defend against SIP end-points are “dumb” – try to defend SIP infrastructure elements There are commercially available solutions for general UDP/SYN flooding (Arbor Networks, Cisco/Riverhead) but none for SIP May 23, 2006 18 Mitigation strategy (2) A common vulnerability to SIP over UDP attacks is the ability to spoof SIP requests – – – – Registration/Call Hijacking Modification of media sessions Session teardown Requests flooding Perform return routability check – For UDP use SIP’s built-in digest authentication mechanism Use null-authentication when no shared secret is established Rate-limit spoofed sources – For TCP perform SYN relay May 23, 2006 19 SIP Digest Authentication (1) User Agent Client (UAC) Proxy Server INVITE Generate the nonce value 407 Proxy Authentication Required (nonce, realm..) ACK nonce – a uniquely generated string used for one challenge only and has a life time of X seconds Compute response = F(nonce, username, password, realm) INVITE (nonce, response…) Authentication: compute F(nonce, username, password, realm) and compare with response May 23, 2006 20 SIP Digest Authentication (2) The introduction of digest authentication accounts for nearly 80% of processing cost of a stateless server and 45% of a call stateful server 70% of additional cost is for message processing and 30% for authentication computation (hashing) SIP Security Issues: The SIP Authentication Procedure and its Processing Load, May 23, 2006 Salsano et al., IEEE Network, November 2002 21 Mitigation Solution Overview Untrusted Trusted Filter I DPPM SIP Filter II sipd SIP SIP VoIP Traffic RTP RTP Attack Traffic May 23, 2006 22 Mitigation Implementation (1) Use the CloudShield to rate-limit SIP authentication attempts to the proxy Use the firewall controlling proxy model Columbia’s SIP Proxy sipd controls the CloudShield 2000 Deep Packet Inspection Server – Utilize wire-speed deep packet inspection – State is only kept at the CloudShield – Utilize the Firewall Control Protocol to establish filters in real time – Insert filters for SIP UAs that are been challenged May 23, 2006 23 INVITE sip:test1@cs.columbia.edu SIP/2.0 Via: SIP/2.0/UDP 128.59.21.70:5060 Max-Forwards: 70 From: sip:test5@cs.columbia.edu To: sip:test1@cs.columbia.edu Contact: sip:test5@128.59.21.70:5060 Subject: sipstone invite test CSeq: 1 INVITE Call-ID: 1736374800@lagrange.cs.columbia.edu Content-Type: application/sdp Content-Length: 211 INVITE sip:test1@cs.columbia.edu SIP/2.0 Via: SIP/2.0/UDP 128.59.21.70:5060 SIP/2.0 407 Proxy Authentication Required Max-Forwards: 70 Via: SIP/2.0/UDP 127.0.0.1:7898 From: sip:test5@cs.columbia.edu From: sip:test5@cs.columbia.edu To: sip:test1@cs.columbia.edu To: sip:test1@cs.columbia.edu; Contact: sip:test5@128.59.21.70:5060 tag=2cg7XX0dZQvUIlbUkFYWGA Subject: sipstone invite test Call-ID: 1736374800@lagrange.cs.columbia.edu CSeq: 3 INVITE CSeq: 1 INVITE Call-ID: 1736374800@lagrange.cs.columbia.edu Date: Fri, 14 Apr 2006 22:51:33 GMT Content-Type: application/sdp Server: Columbia-SIP-Server/1.24 Content-Length: 211 Content-Length: 0 Proxy-Authorization: Digest username="anonymous", Proxy-Authenticate: Digest realm="cs.columbia.edu", Trusted realm="cs.columbia.edu", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", stale=FALSE, uri="sip:test1@cs.columbia.edu", algorithm=MD5, response="0480240000edd6c0b64befc19479924c", qop="auth,auth-int" opaque="", algorithm="MD5" Mitigation Implementation (2) Return-Routability Succeeds SIP UA v=0 o=user1 53655765 23587637 IN IP4 128.59.21.70 s=Mbone Audio t=3149328700 0 i=Discussion of Mbone Engineering Issues e=mbone@somewhere.com c=IN IP4 128.59.21.70 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 INVITE 407 Needs Auth INVITE, Proxy-Authorization IP 128.59.21.70 Untrusted DPPM v=0 sipd IN IP4 128.59.21.70 53655765 2353687637 Remove Add o=user1 Filter Filter s=Mbone Audio t=3149328700 0 (128.59.21.70, 407 INVITE Needs Proxy-Auth Auth NPUINVITE, i=Discussion of Mbone Engineering IssuesINVITE e=mbone@somewhere.com ”nonce”) c=IN IP4 128.59.21.70 CAM t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 RAM (128.59.21.70, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=" ) May 23, 2006 24 Mitigation Implementation (3) Return-Routability Fails Untrusted DPPM SIP UA INVITE INVITE IP 1.2.3.4 Trusted X sipd Add Filter INVITE Needs Auth NPU 407 (1.2.3.4,”nonce”) CAM RAM (1.2.3.4, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=" ) May 23, 2006 25 Mitigation Implementation (4) SYN Relay TCP Client Syn Relay SYN: Seq=A TCP Server SYNACK: Seq=X Ack=A+1 Generate Random Value X ACK: Seq=A+1 Ack=X+1 SYN: Seq=A Calculate Adjustment Y=B-X SYNACK: Seq=B Ack=A+1 ACK: Seq=A+1 Ack=B+1 ACK: Seq=B-Y+n Ack=A+1 ACK: Seq=B+n Ack=A+1 ACK: Seq=A+p Ack=B-Y+n ACK: Seq=A+p Ack=B+n May 23, 2006 26 Mitigation Implementation (5) Integrated DDOS and Dynamic Pinhole filter Linux server ASM sipd CAM DDOS Table FCP/UDP CAM SIP DDOS Static Table Inbound Lookup DPPM SIP CAM Dynamic Table Switch Outbound Drop May 23, 2006 27 Testbed and Validation Strategy SIPStone SIPStone is benchmarking tool for SIP proxy and redirect servers SIPStone attempts to measure the request handling capacity of a SIP server or a cluster of servers The implementation performs a series of tests that generates a pre-configured workload For our project SIPStone was enhanced with: – Null digest authentication – Optional spoofed source IP address SIP requests May 23, 2006 28 Testbed and Validation Strategy Methodology Use the SIPStone testing tool in a distributed environment to generate SIP traffic Generate both spoofed and legitimate source address requests Measure the following calls/sec thruput values: – – – – Legitimate requests, without authentication (Capacity) Legitimate requests, with authentication (Normal) Legitimate and spoofed requests, without authentication (Attack) Legitimate and spoofed requests, with authentication (Defense) Identify the impact of spoofed addresses floods on the calls/sec rate of legitimate requests – We should see A << N, and ideally, D = N May 23, 2006 29 Testbed Architecture Legitimate Loaders (SIPStone) GigE Switch Attack Loaders (SIPStone ) Call Handlers (SIPStone) GigE Switch Controller (SIPStone) SIP Proxy May 23, 2006 30 Demo Flood of spoofed INVITE requests – Acquire a legitimate UA IP address – Send a flood of spoofed INVITE requests using the UA’s IP address – While the firewall blocks the attacker source IP, try to send an INVITE from the legitimate UA The UA’s INVITE is blocked Session teardown attack – Sniff on the signaling channel – Acquire an active session’s dialog identifiers (Call-ID, tags) and UAs SIP URIs – Send a spoofed BYE message May 23, 2006 31 Discussion May 23, 2006 32 Impact of TLS on DOS A good number of attacks identified will be eliminated TLS is not ready for “prime time” yet – Few IP phone vendors are implementing SIP over TCP, a first step towards TLS May 23, 2006 33 Conclusions Have demonstrated SIP vulnerabilities Have implemented some “carrier-class” mitigation strategies Have built a validation testbed to measure performance Need to generalize methodology to cover a broader range of cases and apply anomaly detection, pattern recognition and learning systems May 23, 2006 34 Back up slides May 23, 2006 CS-2000 Physical Architecture Deep Packet Processing Module (DPPM) Executes Network Application Inspecting and Controlling Packet Data Real-Time Silicon Database (128 bits wide X 512K long) and Unstructured Packet Processing CAM technology Single or Dual DPPM Configurations for HA, Performance or Multiple Use Physical Connectivity: Gigabit Ethernet and OC-3/OC-12/OC-48 POS Auxiliary Slots Future use for HDD Module Telemetry Inputs/Outputs Optical Bypass/HA Module Application Server Module (ASM) Hardened Linux Infrastructure Hosts Analysis Applications Network Element Management (Web, CLI, SNMP, ODBC) Mandatory Access Control May 23, 2006 36 CS2K CALL SERVER COMPLEX XPM SMDI ISM MS/ENET FLPP VOICEMAIL SS7 LINKS STP PAIR CALEA PMA IW-SPM MS2010 SSL SSL BCT SESSION SYSTEM MAS MANAGER MANAGER SST SDM COAM (N240) COAM (N240) CMT/ IEMS MG9K EM XA-CORE SAM21 SIP ERS8600 ERS8600 ERS8600 BEARER LAN ERS8600 CS LAN LCR AER AER AER LCR ADM C6509 C6509 MG15K (PVG) ADM AER GWR C7206 SS8 OLT C2950 SS8 GR303 S/BC S/BC MG9K Session Border Controllers PON PSTN (CLASS 4/5 E911 TOPS AIS) ONT ISG2000 NETSCREEN 37 SS8 SC3100 VOICEMAIL May 23, 2006