May 23, 2006

Columbia Verizon Research Columbia Verizon Research Security:Security:

VoIP Denial-of-Service (DoS) VoIP Denial-of-Service (DoS)

Eilon YardeniEilon YardeniColumbia UniversityColumbia UniversityGaston Ormazabal Gaston Ormazabal

Verizon LabsVerizon Labs

2May 23, 2006

AgendaAgenda Project Overview

– Background– What is the problem?– Goals

The SIP Threat Model DoS attack taxonomy Mitigation strategy Testbed and Validation strategy Demo Discussion

3May 23, 2006

BackgroundBackground 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

4May 23, 2006

The ProblemThe 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)

5May 23, 2006

GoalsGoals

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

6May 23, 2006

The SIP Threat Model (1)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

7May 23, 2006

The SIP Threat Model (2)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 CapturePacket recording

– Number harvestingUnauthorized collection of numbers, emails, SIP URIs

8May 23, 2006

The SIP Threat Model (3)The SIP Threat Model (3)

Impersonation of a SIP entity– Impersonate a UA

Absence of assurance of a request’s originatorRegistration Hijacking - attacker deregisters a legitimate

contact and registers its own device for that contact

– Impersonate a ServerUAs should authenticate the server to whom they send

requestsAttacker impersonates a remote server and intercepts

UA’s requests

9May 23, 2006

The SIP Threat Model (4)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 ReroutingAttacker might modify the SDP in order to route media

streams to a wiretapping device

– Conversation DegradationAttacker might cause intentional reduction in QoS

– False Call IdentificationChange “Subject” so message considered Spam

10May 23, 2006

The SIP Threat Model (5)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

11May 23, 2006

Denial of Service Denial of Service (1)(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

12May 23, 2006

Denial of Service (2)Denial of Service (2)

* - Worldwide ISP Security Report, September 2005, Arbor Networks

13May 23, 2006

DoS Attack Taxonomy (1)DoS Attack Taxonomy (1)

Implementation flaws Application level Flooding

14May 23, 2006

DoS Attack Taxonomy (2)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

15May 23, 2006

DoS Attack Taxonomy (3)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 HijackingAttacker can inject a “301 Moved Permanently” message

to an active session

– Modification of media sessionsAttacker can spoof re-INVITE messages thereby

reducing QoS, redirecting media, modifying security attributes

16May 23, 2006

DoS Attack Taxonomy (4)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 attacksAttacker can create bogus requests with falsified Via

header field that identifies a target hostUAs/proxies generates a DDoS against that target

– Media streams attackAttacker can inject spoofed RTP packets with high seq

numbers into a media stream thereby modifying playout sequence

17May 23, 2006

DoS Attack Taxonomy (5)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

18May 23, 2006

Mitigation strategy (1)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

19May 23, 2006

Mitigation strategy (2)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

20May 23, 2006

SIP Digest Authentication (1)SIP Digest Authentication (1)User Agent

Client (UAC)ProxyServer

INVITE

Generate thenonce value

407 Proxy Authentication

Required (nonce, realm..)

INVITE

(nonce, response…)

Authentication: computeF(nonce, username, password, realm)

and compare with response

ACK

Compute response =F(nonce, username, password, realm)

nonce – a uniquely generated string used for one challenge only

and has a life time of X seconds

21May 23, 2006

SIP Digest Authentication (2)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

22May 23, 2006

Mitigation SolutionMitigation SolutionOverviewOverview

VoIP Traffic

Attack Traffic

Untrusted

DPPM sipd

Trusted

SIPSIP SIP

RTP RTP

Filter I Filter II

23May 23, 2006

Mitigation Implementation (1)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

24May 23, 2006

NPU

DPPM

RAM

Mitigation Implementation (2)Mitigation Implementation (2)Return-Routability SucceedsReturn-Routability Succeeds

SIP UA sipd

INVITE407 Needs Auth

IP 128.59.21.70 CAM

(128.59.21.70, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=" )

Untrusted Trusted

INVITE, Proxy-AuthRemove Filter(128.59.21.70,

”nonce”)INVITEINVITE

INVITE sip:test1@cs.columbia.edu SIP/2.0Via: SIP/2.0/UDP 128.59.21.70:5060Max-Forwards: 70From: sip:test5@cs.columbia.eduTo: sip:test1@cs.columbia.eduContact: sip:test5@128.59.21.70:5060Subject: sipstone invite testCSeq: 1 INVITECall-ID: 1736374800@lagrange.cs.columbia.eduContent-Type: application/sdpContent-Length: 211 v=0o=user1 53655765 23587637 IN IP4 128.59.21.70s=Mbone Audiot=3149328700 0i=Discussion of Mbone Engineering Issuese=mbone@somewhere.comc=IN IP4 128.59.21.70t=0 0m=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000

Add Filter(128.59.21.70,

”nonce”)407 Needs Auth

SIP/2.0 407 Proxy Authentication RequiredVia: SIP/2.0/UDP 127.0.0.1:7898From: sip:test5@cs.columbia.eduTo: sip:test1@cs.columbia.edu; tag=2cg7XX0dZQvUIlbUkFYWGACall-ID: 1736374800@lagrange.cs.columbia.eduCSeq: 1 INVITEDate: Fri, 14 Apr 2006 22:51:33 GMTServer: Columbia-SIP-Server/1.24Content-Length: 0Proxy-Authenticate: Digest realm="cs.columbia.edu", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", stale=FALSE, algorithm=MD5, qop="auth,auth-int"

INVITE sip:test1@cs.columbia.edu SIP/2.0Via: SIP/2.0/UDP 128.59.21.70:5060Max-Forwards: 70From: sip:test5@cs.columbia.eduTo: sip:test1@cs.columbia.eduContact: sip:test5@128.59.21.70:5060Subject: sipstone invite testCSeq: 3 INVITECall-ID: 1736374800@lagrange.cs.columbia.eduContent-Type: application/sdpContent-Length: 211Proxy-Authorization: Digest username="anonymous", realm="cs.columbia.edu", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", uri="sip:test1@cs.columbia.edu", response="0480240000edd6c0b64befc19479924c", opaque="", algorithm="MD5" v=0o=user1 53655765 2353687637 IN IP4 128.59.21.70s=Mbone Audiot=3149328700 0i=Discussion of Mbone Engineering Issuese=mbone@somewhere.comc=IN IP4 128.59.21.70t=0 0m=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000

INVITE, Proxy-Authorization

25May 23, 2006

Mitigation Implementation (3)Mitigation Implementation (3) Return-Routability FailsReturn-Routability Fails

SIP UA

NPU

DPPM sipd

INVITE INVITE407 Needs Auth

407 Needs A

uthIP 1.2.3.4 CAM

Add Filter(1.2.3.4,”nonce”)

INVITEX

Untrusted Trusted

(1.2.3.4, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=" )

RAM

26May 23, 2006

Mitigation Implementation (4) Mitigation Implementation (4) SYN RelaySYN Relay

TCPClient

SynRelay

SYN: Seq=A

SYNACK: Seq=X Ack=A+1

TCPServer

ACK: Seq=A+1 Ack=X+1 SYN: Seq=A

SYNACK: Seq=B Ack=A+1

ACK: Seq=A+1 Ack=B+1

ACK: Seq=B+n Ack=A+1ACK: Seq=B-Y+n Ack=A+1

ACK: Seq=A+p Ack=B-Y+n ACK: Seq=A+p Ack=B+n

Generate Random Value X

Calculate Adjustment

Y=B-X

27May 23, 2006

Mitigation Implementation (5)Mitigation Implementation (5)Integrated DDOS and Dynamic Pinhole filterIntegrated DDOS and Dynamic Pinhole filter

DPPM

Inbound Outbound

SIP

Linux server

sipdASM

Switch

FCP/UDP

Drop

Lookup

CAM CAM

DynamicTable

StaticTable

CAM CAM SIPDDOS

DDOSTable

CAM CAM

28May 23, 2006

Testbed and Validation StrategyTestbed and Validation StrategySIPStoneSIPStone

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

29May 23, 2006

Testbed and Validation StrategyTestbed and Validation StrategyMethodologyMethodology

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

30May 23, 2006

Testbed ArchitectureTestbed Architecture

GigE Switch GigE Switch

SIP Proxy

Call Handlers

(SIPStone)

Controller(SIPStone)

AttackLoaders

(SIPStone)

Legitimate Loaders

(SIPStone)

31May 23, 2006

DemoDemo 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

32May 23, 2006

DiscussionDiscussion

33May 23, 2006

Impact of TLS on DOSImpact 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

34May 23, 2006

ConclusionsConclusions 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

Back up slidesBack up slides

36May 23, 2006

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

Application Server Module (ASM) Hardened Linux Infrastructure Hosts Analysis Applications Network Element Management

(Web, CLI, SNMP, ODBC) Mandatory Access Control

Auxiliary Slots

Future use for HDD Module Telemetry Inputs/Outputs Optical Bypass/HA Module

37May 23, 2006

LCR

MS/ENET

ISM

FLPP

XPM VOICEMAIL

STP PAIR

SMDI

SS7 LINKS

ERS8600 ERS8600CS LAN

ERS8600ERS8600BEARER LAN

COAM(N240)

COAM(N240)

CALEAPMA

MG9KEMSDM

CMT/IEMSMS2010 SST SAM21XA-COREIW-SPM

SSLSYSTEM

MANAGER

SSLSESSION

MANAGERBCTMAS

CS2K CALL SERVER COMPLEX

AER

AER LCR

GWR

OLT

ONT

PON

GR303

MG9K

ADMMG15K(PVG)

Session Border Controllers

ADM

S/BC S/BC

C6509 C6509

ISG2000

SS8C2950

SS8VOICEMAIL

NETSCREEN

SC3100

AER

AER

PSTN(CLASS 4/5

E911 TOPS AIS)

SS8C7206

SIP