Columbia Verizon Research Security: VoIP Denial-of-Service (DoS)

1. Columbia Verizon Research Security:VoIP Denial-of-Service (DoS) Eilon Yardeni Columbia University Gaston Ormazabal Verizon Labs

2. Agenda • Project Overview • Background • What is the problem? • Goals • The SIP Threat Model • DoS attack taxonomy • Mitigation strategy • Testbed and Validation strategy • Demo • Discussion

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

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

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

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

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

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

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

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

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

12. Denial of Service (2) * - Worldwide ISP Security Report, September 2005, Arbor Networks

13. DoS Attack Taxonomy (1) • Implementation flaws • Application level • Flooding

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

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

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

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

18. 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 todefend 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

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

20. User Agent Client (UAC) Proxy Server INVITE ACK Generate the nonce value 407 Proxy Authentication Required (nonce, realm..) Authentication: compute F(nonce, username, password, realm) and compare with response Compute response = F(nonce, username, password, realm) INVITE (nonce, response…) SIP Digest Authentication (1) nonce – a uniquely generated string used for one challenge only and has a life time of X seconds

21. 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, Salsano et al., IEEE Network, November 2002

22. Mitigation SolutionOverview Untrusted Trusted Filter I Filter II sipd DPPM SIP SIP SIP VoIP Traffic Attack Traffic RTP RTP

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

24. 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 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 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: 3 INVITE Call-ID: 1736374800@lagrange.cs.columbia.edu Content-Type: application/sdp Content-Length: 211 Proxy-Authorization: Digest username="anonymous", realm="cs.columbia.edu", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", uri="sip:test1@cs.columbia.edu", response="0480240000edd6c0b64befc19479924c", opaque="", algorithm="MD5" v=0 o=user1 53655765 2353687637 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 SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 127.0.0.1:7898 From: sip:test5@cs.columbia.edu To: sip:test1@cs.columbia.edu; tag=2cg7XX0dZQvUIlbUkFYWGA Call-ID: 1736374800@lagrange.cs.columbia.edu CSeq: 1 INVITE Date: Fri, 14 Apr 2006 22:51:33 GMT Server: Columbia-SIP-Server/1.24 Content-Length: 0 Proxy-Authenticate: Digest realm="cs.columbia.edu", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", stale=FALSE, algorithm=MD5, qop="auth,auth-int" INVITE INVITE INVITE, Proxy-Authorization INVITE 407 Needs Auth Add Filter (128.59.21.70, ”nonce”) Remove Filter (128.59.21.70, ”nonce”) 407 Needs Auth INVITE, Proxy-Auth Mitigation Implementation (2)Return-Routability Succeeds Untrusted Trusted DPPM sipd SIP UA NPU CAM RAM IP 128.59.21.70 (128.59.21.70, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=")

25. INVITE INVITE INVITE 407 Needs Auth Add Filter (1.2.3.4,”nonce”) 407 Needs Auth Mitigation Implementation (3)Return-Routability Fails Untrusted Trusted DPPM sipd SIP UA NPU X CAM RAM IP 1.2.3.4 (1.2.3.4, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=")

26. ACK: Seq=A+p Ack=B+n SYN: Seq=A SYN: Seq=A Mitigation Implementation (4) SYN Relay TCP Client Syn Relay TCP Server Generate Random Value X SYNACK: Seq=X Ack=A+1 ACK: Seq=A+1 Ack=X+1 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

27. CAM Dynamic Table SIP SIP DDOS CAM CAM DDOS Table Static Table Outbound Inbound Mitigation Implementation (5)Integrated DDOS and Dynamic Pinhole filter Linux server ASM sipd DPPM FCP/UDP Lookup Switch Drop

28. Testbed and Validation StrategySIPStone • 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

29. Testbed and Validation StrategyMethodology • 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

30. Controller (SIPStone) Testbed Architecture Legitimate Loaders (SIPStone) Attack Loaders (SIPStone) Call Handlers (SIPStone) GigE Switch GigE Switch SIP Proxy

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

32. Discussion

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

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

35. Back up slides

36. 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 CS-2000 Physical Architecture

37. SSL SESSION MANAGER SSL SYSTEM MANAGER CMT/ IEMS MG9K EM SST XPM SAM21 IW-SPM MS2010 ERS8600 ERS8600 ERS8600 ERS8600 BEARER LAN CS LAN SC3100 ISG2000 C2950 C7206 SS8 SS8 CS2K CALL SERVER COMPLEX SMDI VOICEMAIL ISM SS7 LINKS FLPP MS/ENET STP PAIR CALEA PMA COAM (N240) COAM (N240) BCT MAS SDM XA-CORE SIP LCR AER AER AER AER ADM LCR C6509 C6509 MG15K (PVG) ADM GWR GR303 S/BC S/BC MG9K OLT Session Border Controllers PON PSTN (CLASS 4/5 E911 TOPS AIS) ONT NETSCREEN SS8 VOICEMAIL