1 / 37

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

Columbia Verizon Research Security: VoIP Denial-of-Service (DoS) . Eilon Yardeni Columbia University Gaston Ormazabal Verizon Labs. Agenda. Project Overview Background What is the problem? Goals The SIP Threat Model DoS attack taxonomy Mitigation strategy

gina
Download Presentation

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

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

More Related