Security Challenges in Hybrid Telephony - PowerPoint PPT Presentation

About This Presentation
Title:

Security Challenges in Hybrid Telephony

Description:

X. DHCP server insertion. X. DHCP starvation. X. ICMP flood. X. X. Physical Attacks. Transport. Internet. Avail-ablity. Integ-rity. Confidentiality. Attack Vector ... – PowerPoint PPT presentation

Number of Views:197
Avg rating:3.0/5.0
Slides: 48
Provided by: fcc
Category:

less

Transcript and Presenter's Notes

Title: Security Challenges in Hybrid Telephony


1
Security Challenges inHybrid Telephony
  • Richard Hovey
  • Communications Systems Analysis Division
  • February 8, 2007

Observations are my own and are not a reflection
of views of CSAD or PSHSB.
2
Hybrid IP-TDM Telephony
Security Issues
Session Initiation Protocol (SIP)
SignalingInterop
Domain Name System Interop (DNS)
Routing Interop (BGP)
IP PBX
TDM Network
IP Network
Smartphone
3
Security Challenges in Hybrid Telephony Outline
  • Perspectives on telecom convergence
  • "Very-Next" Generation c.2007-2010
  • Telephony on the commodity Internet
  • Tutorial basic SIP signaling
  • SIP Security challenges
  • Hybrid Telephony IP TDM
  • Tutorial basic SS7 signaling SIP SS7
    Interworking
  • SIP-SS7 security challenges
  • Emerging components concerns
  • Open Source IP PBX
  • Smartphone

4
Security Challenges in Hybrid Telephony Advisory
Message
  • The Sky isn't exactly falling
  • but the Sea Level is rising.
  • Net effect The Sky is getting closer.

CSAD Advisory System
Severe Risk of Sky Falling
High Risk of Sky Falling
Significant Risk of Sky Falling
General Risk of Sky Falling
Low Risk of Sky Falling
5
Perspective on Convergence Very-Next Generation
Residential Broadband
  • Today parallel access to distinct
    infrastructures
  • Future common IP core infrastructure?
  • Vision of "Carrier ISPs"
  • First test adoption of NGN Release 1

local servers
6
Tutorial IP-IP Telephony Session Initiation
Protocol Signaling (SIP)
7
Tutorial IP-IP Telephony SIP Basics
  • Session Initiation Protocol (SIP)
  • Text-based protocol with a readable syntax,
    similar to HTTP
  • Used for controlling multimedia sessions over IP
    (i.e., signaling)
  • Telephony is a type of audio-only multimedia
    session
  • INVITE message
  • Used to establish a session analogous to ISUP
    IAM message
  • IP-IP phone example (Kevin calls Michael over
    Internet)
  • INVITE sipmichael_at_mkpgroup.com SIP/2.0
  • Via SIP/2.0/UDP 165.135.228.985060
  • Max-Forwards 50
  • To Michael ltsipmichael_at_mkpgroup.comgt
  • From Kevin ltsipkevin_at_fcc.govgttag8055002911
  • Content-type application/sdp
  • Content-length 142

INVITE sipmichael_at_mkpgroup.com SIP/2.0 Via
SIP/2.0/UDP 165.135.228.985060 Max-Forwards
50 To Michael ltsipmichael_at_mkpgroup.comgt From
Kevin ltsipkevin_at_fcc.govgttag8055002911 Content-t
ype application/sdp Content-length 142
8
Tutorial IP-IP Telephony Session Initiation
Protocol Signaling (SIP)
? Kevin "calls" Michael
9
IP-based Telephony SIP Signaling -Challenges
  • SIP and Privacy (withholding identity)
  • Identity carried in SIP URI and optional Display
    Name
  • e.g., Kevin ltsipkevin_at_fcc.govgt
  • Appears in numerous fields in SIP messages
  • e.g., From, Contact, Reply-to
  • Identity Info also appears in
  • e.g., Via, Call-Info, User-Agent,
    Organization, Server
  • Some are functional and have to be included
  • Complicated by intermediary proxy servers that
    add headers
  • and can examine the other header content

10
IP-based Telephony SIP Signaling -Challenges
  • Utility of protecting SIP with encryption?
  • i.e., protect SIP messages with IP Security
    (IPsec) at IP Layer
  • Hop-by-hop impact on Call Set-up time is
    significant
  • Almost certainly unacceptable

No IPSec Proxy IPSec End-End IPSec
IP-IP 4.6 7.5 20.2
IP-TDM 7.6 9.5 21.8
TDM-IP 5.2 8.0 12.7
TDM-IP-TDM 6.9 9.3 14.3
Source Telcordia
  • Once connected phone-phone, delay acceptable
  • About 10 (8 msec)
  • Implications for NGN?

11
IP-based TelephonyVulnerabilities in SIP devices
  • Dozens of vulnerabilities impacting IP-based
    telephony
  • Includes commodity Internet risks at other layers
  • Attacks on vulnerabilities
  • can impact confidentiality, integrity,
    availability
  • can trigger device hangs, crashes, restarts
  • Hundreds of SIP devices software implementations
  • both SIP phones and SIP Servers
  • Next some approaches to mitigating risks
  • Security thru obscurity dont reveal
    implementation
  • Security thru testing use test tools to check
    implementation

12
IP-based Telephony IP Telephony Vulnerabilities
by Protocol Layer
Layer Attack Vector Confidentiality Integ-rity Avail-ablity
Net Interface
Physical Attacks X X
ARP cache X X X
ARP flood X
MAC spoofing X X X
Internet
IP spoofing
Device X X X
Redirect Via IP spoof X X X
Malformed packets X X X
IP frag X X X
Jolt X
Transport
TCP/UDP flood X
TCP/UDP replay X X
Applicaition
TFTP server insertion X
DHCP server insertion X
DHCP starvation X
ICMP flood X
Layer Attack Vector Confidentiality Integ-rity Avail-ablity
App. cont
SIP Registration Hijacking X X X
SIP MGCP Hijack X X X
SIP Message modification X X
SIP RTP Insertion
SIP Spoof via header X X X
SIP Cancel / bye attack X
SIP Malformed method X
SIP Redirect method X X
RTP SDP redirect X
RTP RTP payload X
RTP RTP tampering X
RTP Encryption X X X
RTP Default configuration X X X
RTP Unnecessary services X X X
RTP Buffer overflow X X X
RTP Legacy Network X X X
RTP DNS Availability X
Source UC Boulder
13
IP-based Telephony Security thru Obscurity?
  • A vulnerable implementation becomes an explicit
    target
  • e.g., Windows vulnerabilities
  • SIP standard defines a "User-Agent" field
  • announces software version
  • can turn it off so software details are not
    revealed
  • But turning off explicit identification doesn't
    really help
  • sufficient info in protocol responses to
    determine software
  • probing technique manipulates headers, log
    responses
  • each device has a unique fingerprint
  • Does suggest some security improvements
  • e.g., don't respond to non-compliant messages
  • e.g., randomize fields and attributes

14
IP-based Telephony Security thru Obscurity?
SIP device fingerprints
Source CMU IBM Watson
15
IP-based Telephony Security thru Testing
  • Commercially-available VoIP testing tools
  • vulnerability scanners
  • Inject abnormalities into SIP messages
  • E.g., one tool 4500 test cases
  • but only for SIP INVITE message
  • Analysis of seven testing tools
  • based on lab tests of four tools claims of three
    others
  • even combined, address less than half of known
    vulnerabilities

16
IP-based Telephony IP Telephony Vulnerabilities
Addressed by Tools
Layer Attack Vector Addressed by STools
Net Interface
Physical Attacks
ARP cache
ARP flood
MAC spoofing
Internet
IP spoofing X
Device X
Redirect Via IP spoof X
Malformed packets
IP frag
Jolt
Transport
TCP/UDP flood X
TCP/UDP replay
Application
TFTP server insertion
DHCP server insertion
DHCP starvation
ICMP flood
Layer Attack Vector Addressed by STools
App. cont
SIP Registration Hijacking X
SIP MGCP Hijack
SIP Message modification
SIP RTP Insertion
SIP Spoof via header X
SIP Cancel / bye attack
SIP Malformed method X
SIP Redirect method X
RTP SDP redirect X
RTP RTP payload X
RTP RTP tampering X
RTP Encryption X
RTP Default configuration
RTP Unnecessary services
RTP Buffer overflow X
RTP Legacy Network X
RTP DNS Availability X
Source UC Boulder
17
IP-based Telephony Denial of Service Attacks
  • Background
  • Brute force attacks are much easier than clever
    exploits
  • Attack targets
  • SIP infrastructure (SIP servers, Gateways)
  • Supporting services (DNS)
  • End points (SIP phones)
  • Commercially available solutions for UDP/SYN
    flooding
  • But currently none for SIP

18
IP-based Telephony Denial of Service Attacks
  • Carrier-class Analysis
  • Two types of attacks used General and
    VoIP-specific
  • Bi-directional Speech grade-of-service metrics
    collected
  • Results
  • VoIP-specific attacks effective at low rates
    against all devices
  • No service let alone grade of service - to
    record
  • General attacks caused a wide-range of effects
  • Unexpected all devices adversely affected by TCP
    SYN attacks
  • Conclusions (November 2004)
  • Keep VoIP on private secured networks (off
    the public Internet) where practical
  • Design DDOS mitigation products to be
    VoIP-aware

Sprint Adv. Tech. Labs
19
IP-based Telephony Denial of Service Attacks
Voice Quality during TCP SYN attack on a network
element
?Attack Level 20 of bandwidth
20
IP-based Telephony Denial of Service Attacks
  • Current carrier-class work
  • Addressing perimeter protection problem of VoIP
    service
  • Strategy two detection and mitigation filters
  • SIP Rule-based detection and mitigation filters
    (only valid SIP)
  • Media SIP-aware dynamic pinhole filtering (only
    signaled RTP)

21
IP-based Telephony Denial of Service Attacks
Columbia U Verizon Labs
22
IP-based Telephony Denial of Service Attacks
  • Carrier-class Prototype
  • Rely on wire-speed, deep-packet inspection
  • 300 calls/second10K-30K concurrent calls
  • Conclusion (October 2006)
  • Need to generalize methodology to cover a
    broader range of cases and apply anomaly
    detection, pattern recognition and learning
    systems

Columbia U Verizon Labs
23
Tutorial TDM-TDM circuit switched
TelephonyInter-exchange Signaling (SS7)
TDM Network 1
24
Tutorial TDM-TDM TelephonyInter-exchange
Signaling (SS7)ISDN User Part (ISUP) Protocol
W
X
? number idle?
? dial digits
B
A
? connect to trunk
Subscriber Line
Voice Trunk
Signaling Link
25
Tutorial TDM-TDM TelephonyInitial Address
Message (IAM)
26
Tutorial IP-TDM Telephony
MGC
27
Tutorial IP-TDM Telephony SIP to SS7
  • Media Gateway Controller (MGC)
  • Also referred to as a "Softswitch" or "Call
    Agent"
  • Has logical interfaces facing both networks
  • Translates between SIP and ISUP messages
  • SS7 protocol Level 4 (e.g. "INVITE" ? "IAM)
  • Media Gateway (MG)
  • Has trunking interfaces facing both networks
  • Translates between IP and TDM voice streams
    (i.e. RTP?T1)
  • MGC and MG can be merged in one box or kept
    separate
  • Signaling Gateway (SG)
  • Performs mapping of Signaling Network Messages
  • SS7 protocol Level 3
  • Level 3 controls congestion, balances loads,
    re-routes traffic

28
Tutorial IP-TDM Telephony SIP to SS7
  • Questions wrt Media Gateway Controller
  • How do they map fields? e.g. "INVITE" ? "IAM?
  • e.g., "From" ? "Calling Party Number and
    "Charge Number"
  • What call records do they maintain?
  • significant implications for Authenticating source

29
Tutorial IP-TDM Telephony SIP to SS7
  • INVITE message
  • IP-to-Wireline phone example (Kevin calls Michael
    from Internet)
  • INVITE sip12126441200_at_ss1.fcc.govuserphone
    SIP/2.0Via SIP/2.0/UDP client.kevin.fcc.gov5060
    Max-Forwards 50To Michael ltsip12126441200_at_ss
    1.fcc.govuserphonegtFrom Kevin
    ltsip12024180100gttag8055002911Content-type
    application/sdpContent-length 142

30
Tutorial IP-TDM Telephony SIP to SS7
IP
  • Signaling Gateway (SG) function
  • Performs mapping of signaling network messages
  • SS7 Level 3 congestion, balances loads, traffic
    re-routing
  • Transporting SS7 over IP Network

TDM
  • Bottom line SG can appear as an SS7 SP at the
    interface

31
Tutorial IP-TDM Phone Service SIP-SS7 Signaling
  • Questions?

32
IP-TDM Phone ServiceSignaling Interworking
Vulnerabilities
  • Background
  • New players (CLECs) increasing the number of SS7
    access points
  • Signaling Gateway looks like another SS7 SP to an
    STP
  • Absence of message integrity and authentication
    in SS7
  • Could use IPSec in hybrid environment but ends
    at the SG
  • Recent Analysis (December 2006)
  • Hijacked or misbehaving SS7 nodes
  • Open to Signaling Network Management (SNM)
    injects
  • Injections towards MGC can disrupt VoIP services
  • Hijacked or misbehaving Signaling Gateway
  • Can affect functioning of SS7 network
  • Threats arising in either network due to
    misprovisioned or malicious signaling nodes are
    not confined to that network alone but may affect
    the other network as well.

GMU - UNT
33
IP-TDM Phone ServiceSignaling Interworking
Vulnerabilities
Critical Management Messages in IP and SS7
networks just SS7 level 3
SS7 protocol layer and its management messages SS7 network management messages in an IP network
Message Transfer Part Level 3 MTP3 SIGTRAN layer M3UA
Signaling Network Management msgs Emergency Changeover Order Changeover Order Transfer Prohibited Transfer Controlled Transfer Restricted At Signaling Gateway, M3UA provides interworking with MTP3 function by using ASP management messages Destination Restricted Destination Unavailable Signaling Congestion Destination User Part Unavailable
34
IP-TDM Phone ServiceSignaling Interworking
Vulnerabilities
  • Only widely deployed security solution
  • Telcordias Gateway Screening Specification
  • Implemented at gateway STPs
  • Generally screens out only message headers
  • Doesnt check content and structure of most
    signaling messages
  • Commercial products to secure SS7 are emerging
  • Content-based and signal-sequence firewalls
  • Network Access Meditation (Sevis)
  • SS7 Security Gatekeeper (Verizon)
  • Proposed MTPSec to secure SS7 network layer

35
Open Source PBXBe Your Own Phone Company
36
Be Your Own Phone CompanyAsterisk Corporate
PBX
37
Open Source PBX Spoofing - Service
Do-It-Yourself
38
Be Your Own Phone Company Spoofing - Service
Do-It-Yourself
  • Things to know
  • Can use standard SetCallerID(nnnnnnnnnn) command
  • PBX-like not efficient for per-call spoofing
  • Asterisk software is easily patched to do Caller
    ID spoofing
  • Add the following lines to extension config file
    exten gt 33,1,Answer exten gt
    33,2,AGI(cidspoof.agi)
  • Download the cidspoof.agi script changing line 77
    tothe correct username / hostname for VoIP
    service provider, and copy to /var/lib/asterisk/ag
    i-bin/
  • Start Asterisk
  • Call extension 33, enter number you wish to spoof
    from, followed by number you wish to spoof to.

39
Open Source PBX
  • Authentication concerns (CPN, BTN)
  • manipulation now much cheaper
  • isolation from traceability much greater

40
Smartphone SecurityGeneral Outlook
  • Virus problem seems relatively small and
    manageable
  • Cell phone carriers have strong incentives to
    keep under control
  • Cell phone carriers have good control points
    (e.g., gateways)
  • Incidents to date haven't been widespread or fast
    spreading
  • Many categorized as low-threat "proof of concept"
  • Q "Is the Sky Falling?"
  • A "Probably not not at the moment."
  • But the ocean

41
Smartphone Security General Outlook
  • But cell phones are an increasingly attractive
    target
  • Applications becoming more PC-like e.g., email
    attachments(smart phones make up about 5 of
    cell phones)
  • Operating System uniformity increases appeal to
    hackers (i.e., Symbian, PocketPC, PalmOS
    dominate smart phones)
  • Standard Markup Languages create openings (e.g.,
    java scripts)
  • Phones increasingly carry sensitive info (e.g.,
    business info)
  • Phones increasingly can make small financial
    charges
  • by accepting "reverse SMS" micropayment charges
  • i.e., there's a direct link to money
  • Potential impact of viruses seems high

42
Smartphone Security General Outlook
  • Q What can mobile viruses do?
  • Spread via Bluetooth, MMS
  • Send SMS messages
  • Infect files
  • Enable remote control of the smartphone
  • Modify or replace icons or system applications
  • Install false or non-operational fonts and
    applications
  • Combat antivirus programs
  • Install other malicious programs
  • Block memory cards
  • Steal data

43
Smartphone Security Symbian OS
  • Dominant smartphone OS (50 of phones shipped)
  • Allows user to install untrusted code
  • post-installation antivirus software not as
    mature as PC
  • Once installed code has access to all resources
  • extract phone numbers, email
  • send SMS, MMS, email make HTTP connections
  • dial numbers connect via Bluetooth
  • Possible to avoid detection
  • run in background (server) wait for long idles
    delete logs
  • user unaware of filesystem
  • Possible to avoid removal, short of reflashing

44
Smartphone Security Bluetooth
  • Devices
  • 13 of phones sold worldwide in 2004 4 in U.S.
  • Distances
  • Nominal range is 10 meters (often boosted to
    100m)
  • Hijacking phones has been demonstrated at over a
    mile
  • Suggested cipher vulnerabilities
  • see Wetzel
  • Observation
  • a "personal networking standard" vulnerable to
    personal misjudgments and oversights

45
Smartphone Security Creating the Conditions for
a Perfect Storm?
Internet
Bluetooth
46
Smartphone SecurityEvolution
  • By early 2005 main types of mobile viruses had
    evolved
  • Very few in last 18-24 months are truly original
  • Now 31 families, 170 variants.
  • MMS will eventually become common method of
    propagation

Increase of known mobile malware variants
6/2004 ?
47
Service ProvidersCyber Security Practice
  • Background
  • History
  • Network Reliability Interoperability Council
    (NRIC)
  • NRIC VI VII assembled Cybersecurity Best
    Practices
  • applicable as appropriate voluntary,
  • more of a checklist where one would like a
    culture
  • Stipulation
  • Technical complexity industry's superior
    expertise resources
  • Regulation may not result in adoption of
    underlying philosophy

48
Service ProvidersCyber Security Practice
  • Question
  • Are ISP businesses "Markets for Lemons" wrt
    security?
  • asymmetric information gt willingness to pay only
    average price
  • above average security will be driven out of the
    market?
  • Challenge
  • Are there approaches to improving security and
    reliability of infrastructure that benefit both
    users and providers?
  • What are the incentives?
  • Are ISP businesses dynamics and industry sectors
    different?
Write a Comment
User Comments (0)
About PowerShow.com