1 / 44

Columbia - Verizon Research Security : VoIP Denial-of-Service

Columbia - Verizon Research Security : VoIP Denial-of-Service. Somdutt B. Patnaik Gaston Ormazabal Columbia University Verizon Labs CS Department. Agenda. Project Overview Previous Work Problem Areas Goals The SIP Threat Model DoS attack taxonomy

charla
Download Presentation

Columbia - Verizon Research Security : VoIP Denial-of-Service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Columbia - Verizon ResearchSecurity : VoIP Denial-of-Service Somdutt B. Patnaik Gaston Ormazabal Columbia University Verizon Labs CS Department

  2. Agenda • Project Overview • Previous Work • Problem Areas • Goals • The SIP Threat Model • DoS attack taxonomy • Detection and Mitigation strategy • Testbed and Validation strategy • Demo • Discussion

  3. Previous Work • Successfully implemented a large scale SIP-aware Firewall (using dynamic pinhole filtering) • The filter is used as a first-line of defence against DoS attacks at the network perimeter and it enforces the following: • Only signalled media channels can traverse the perimeter • End systems are protected against flooding of random RTP or other attacks.

  4. Extension to Previous Work • The firewall(pinhole filtering) approach is a great first-line of defense but it does not address the following: • Attackers can still traverse the perimeter through the signalling port and media ports; viz., Pinholes cannot distinguish legitimate from illegitimate traffic • This lead us to define the new problem...

  5. Mitigation SolutionSchematic Description Untrusted Trusted Filter I Filter II sipd DPPM SIP SIP SIP VoIP Traffic Attack Traffic RTP RTP

  6. Motivation • Telephony services migrating to IP become an attractive DoS attack target • Attack traffic that traverses the perimeter could target the availability of signalling VoIP service • Attack targets could be supporting services (e.g. DNS), SIP infrastructure elements (proxy, softswitch, SBC) and end-points (SIP phones)

  7. VoIP Threat Taxonomy (adopted from VOIPSA) Scope of our research Refer to http://www.voipsa.org for more details on this taxonomy

  8. Scope of Our Research Scope of current work

  9. Goals • Study VoIP DoS • Definition – define VoIP specific threats • Detection – how do we detect an attack? • Mitigation – defence strategy and implementation • Validation – validate our defence strategy • Generate requirements for future security network elements and test tools for their validation

  10. THE SIP THREAT MODEL • REFERENCES: • VoIP Security and Privacy Threat Taxonomy, VoIPSA October 2005

  11. The SIP Threat Model • Eavesdropping • Impersonation of a SIP entity • Interception and modification of SIP messages • Service Abuse • Denial of Service

  12. SIP Threat Model details (1) • Eavesdropping • Attacker can monitor signalling/media streams, but cannot or does not alter data itself • Signalling 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

  13. SIP Threat Model details (2) • Impersonating of a SIP entity • Impersonate a UA • Absense 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 interceptsthe UA's request

  14. SIP Threat Model details (3) • Interception and modification of SIP messages • Man-in-the-middle attack • UA is using SIP to communicate media session keys • Call Re-routing • Attacker might modify the SDP in order to route media streams to a wire-tapping device • Conversation Degradation • Attacker might cause intentional reduction in QoS • False Call Identification • Change “Subject” so message considered Spam

  15. SIP Threat Model details (4) • 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

  16. SIP Threat Model details (5) • Denial of Service • Denial-of-Service – preventing users from effectively using the target 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

  17. SIP Threat Model details (6) • Denial of Service (contd.) • Worldwide ISP Security Report, September 2005, Arbor Networks

  18. SIP Denial of Service Attacks – A detailed view

  19. DoS Attack Taxonomy • Implementation flaws • Application level • Flooding

  20. DoS Attack Taxonomy details (1) • Implementation flaws • Attacker send carefully crafter packet(s) that exploits a specific implementation flaw • Target vulnerability might originate in different levels of the network protocol stack or in the underlying OS/firmware. • Might cause excessive memory/disk/CPU consumption and/or system reboot or crash

  21. DoS Attack Taxonomy details (2) • Application level – a feature of SIP is manipulated to cause a DOS attack • Registration Hijacking • Attacker registers his device with another 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 • Attacker can request arbitrarily large bandwidth in SDP thereby choking the available bandwidth of the proxy

  22. DoS Attack Taxonomy details (3) • Application level (Contd.) • 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 the media streams thereby changing the playout sequence

  23. DoS Attack Taxonomy details (4) • 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 networks can become congested • Variant could be: UDP floods, ICMP echo attacks, SYN floods, etc. • Floods of INVITE or REGISTER messages could cause excessive processing at a SIP proxy

  24. Our Mitigation Strategy

  25. Basic Strategy and motivation • 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

  26. Main Focus of our Strategy... • VULNERABILITY: A common vulnerability to SIP over UDP attacks is the ability to spoof SIP requests • Registration/Call Hijacking • Modification of Media sessions • Session teardown • Request flooding • Bandwidth over-claim using SDP requests • MITIGATION: 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 • Maintain a Cloudshield CAM database of INVITE IPs to verify and accept a BYE message only from legitimate IP addresses • Limit bandwidth grants to SDP requests (based on some heuristics) • For TCP perform SYN relay

  27. The Scheme Untrusted Trusted Filter I Filter II sipd DPPM SIP SIP SIP VoIP Traffic Attack Traffic RTP RTP

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

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

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

  31. 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 Cloudshield • Utilize the Firewall Control Protocol to establish filters in real time • Insert filters for SIP UAs that are being challenged

  32. 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=")

  33. 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=")

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

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

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

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

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

  39. Discussion...

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

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

  42. Backup Slides…

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

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

More Related