Transcript Verizon-DDOS - Columbia University

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:[email protected] SIP/2.0
Via: SIP/2.0/UDP 128.59.21.70:5060
Max-Forwards: 70
From: sip:[email protected]
To: sip:[email protected]
Contact: sip:[email protected]:5060
Subject: sipstone invite test
CSeq: 1 INVITE
Call-ID: [email protected]
Content-Type: application/sdp
Content-Length: 211
INVITE sip:[email protected] 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:[email protected]
From: sip:[email protected]
To: sip:[email protected]
To: sip:[email protected];
Contact: sip:[email protected]:5060
tag=2cg7XX0dZQvUIlbUkFYWGA
Subject: sipstone invite test
Call-ID: [email protected]
CSeq: 3 INVITE
CSeq: 1 INVITE
Call-ID: [email protected]
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:[email protected]",
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
[email protected]
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
[email protected]
”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