Voip Security

Published on January 2017 | Categories: Documents | Downloads: 12 | Comments: 0 | Views: 222
of 29
Download PDF   Embed   Report

Comments

Content

Recommendations for VoIP and IMS Security

Ari Takanen CTO Codenomicon

Picture taken from http://www.smbc-comics.com/ with permission.

WWW.CODENOMICON.COM

NOTE: PARTS OF THIS PRESENTATION ARE BASED ON THE VOIP SECURITY BOOK by Peter Thermos and Ari Takanen
2

WWW.CODENOMICON.COM

Contents of the Book
       

Chapter 01: Introduction Chapter 02: VoIP Architectures and Protocols Chapter 03: Threats and Attacks Chapter 04: VoIP Vulnerabilities Chapter 05: Signaling Protection Mechanisms Chapter 06: Media Protection Mechanisms Chapter 07: Key Management Mechanisms Chapter 08: VoIP and Network Security Controls Chapter 09: Security Framework for Enterprise VoIP Networks Chapter 10: Service Provider Architectures and Security Chapter 11: Enterprise Architectures and Security
3


       

     

WWW.CODENOMICON.COM

1. Introduction
   

VoIP is transition from closed PSTN/TDM into all-IP Security focus moves away from physical, to audits of interconnected software and protocols

WWW.CODENOMICON.COM

4


2.3 VoIP Protocols
 

Signaling / Session control:
•  •  •  •  •  • 

SIP, SIP-I, (SIP-T) MGCP/H.248 BICC SS7/Sigtran (H.323) RTSP RTP, SRTP, RTCP Mpeg1/2/4 IPv4 and IPv6 (with or without IPSEC) SCTP TLS

 

Media:
•  • 

 

Transport:
•  •  • 

 

Others: DHCP, DNS, Diameter, Radius, STUN, TURN, ...
5


WWW.CODENOMICON.COM

3. VoIP Threats and Attacks
 

Threat: The means through which someone can do something bad. A potential violation of security. Vulnerability: The flaw or weakness that enables threats, attacks or exploits. Attack: The attempt of doing something bad. Exploit: The tool of conducting something bad.

 

   

WWW.CODENOMICON.COM

6


3.1 VoIP Threat and Attack Categories
         

Service disruption and annoyance Eavesdropping and traffic analysis Masquerading and impersonation Unauthorized Access Fraud

WWW.CODENOMICON.COM

7


3.2 Service Disruption and Annoyance
 

Malformed packets DoS attack
•  •  • 

• 

Found by e.g. fuzzing Caused by broken anomalous inputs, malformed packets Buffer overflow is an example where malformed packets can be used to get full access to the device 70% of all known vulnerabilities appear to be in this category Performance flaw, or load balancing problem Also a place for fuzzing! Hard to block in real-time communications Phone rings before the unwanted media can be detected Black-lists and white-lists
8


 

Load-based flooding attacks (DDoS)
•  • 

 

“SPIT”
•  •  • 

WWW.CODENOMICON.COM

4. VoIP Vulnerabilities

WWW.CODENOMICON.COM

9


Fuzzing:

Proactive security testing for unknown vulnerabilities

WWW.CODENOMICON.COM

Overview of security testing techniques
     

Focus on robustness and reliability Load testing simulates DDoS situations The Denial of Service attack can also consist of individual malformed packets In 2002, PROTOS researchers from University of Oulu released a freely available test suites for SIP and H.323 During same year, Codenomicon released commercial tools for use in VoIP penetration testing and quality assurance

 

 

WWW.CODENOMICON.COM

11


Proactive = Fuzzing
 

Finds buffer overflows and other boundary-value flaws Fuzzing means crash-testing Also called:
•  •  • 

   

Negative testing Robustness testing Grammar/Syntax testing

 

Based on sending systematically broken (rarely random) inputs to a software, in order to crash it Two techniques of model-based fuzzers:
•  • 

 

Template-based Specification-based
12


WWW.CODENOMICON.COM

Fuzzing Interfaces
 

VoIP devices and services need to be tested on all layers Any protocol interface that is open to the public Internet is a high risk to the system 80% of all VoIP devices still crash when tested with fuzzing

 

 

RTP/RTCP/SRTP

SIGCOMP

TLS/SSL

UPnP

MGCP

TURN STUN

H.248
SCTP

RTSP

STUN TURN

H.323
TCP

SIP

UDP IPv4 / IPv6

WWW.CODENOMICON.COM

13


Interoperability (and other uses)
 

Model-based tools such as fuzzers test for the full specification coverage
•  • 

• 

Automated peer-review of specification Generate prototypes directly from specifications, and are true implementations of the specification Modelling and simulation can be used with full prototypes of the protocol interface implementations

 

Model-based tools (such as fuzzers) can be used to tests for both valid and unexpected use scenarios
• 

Also will include tests for all optional and most vendor-proprietary extensions

 

All tests are automatically generated and executed, and always repeatable
14


WWW.CODENOMICON.COM

Performance
 

Model-based tools are not slow
•  • 

• 

Negative testing results in millions of tests With modern hardware, you can execute tens of thousands of tests per second 4 million tests in less than 10 minutes!

 

Complements modern performance testing
• 

• 

A good fuzz-test takes more CPU power than a valid “nice” test case Hackers will not use conformant tests in attacks

WWW.CODENOMICON.COM

15


Failure-modes
 

Crash
•  •  • 

Boundary value condition Buffer overflow Memory exceptions Busy loops Memory leaks Error handling problems Bad asserts Error handling

 

Slow performance
•  •  • 

 

Data leaks
•  • 

 

Others…
16


WWW.CODENOMICON.COM

Summary
   

Full dynamic tests built from protocol models Protocol models automatically generated from protocol specifications (if possible) 100% TTCN Free! (No programming needed) 200+ protocols on all layers
•  •  • 

   

Conformance testing Performance testing Negative testing

 

But most importantly, finds security problems proactively
17


WWW.CODENOMICON.COM

The IMS Study: Learnings from several IMS audits during 2010
WWW.CODENOMICON.COM

Overview of the 2010 IMS Study
   

Unfortunately the report is NOT public Focus was to build a secure lifecycle model for IMS deployments
•  •  •  •  • 

business considerations design procurement deployment maintenance

 

Defined a set of about 30 best practices for deploying IP Multimedia Subsystem (IMS) networks and systems securely We are only covering about 7 of those here…
19


 

WWW.CODENOMICON.COM

The Vulnerability Assessment of IMS
 

Threat modelling or comprehensive attack surface analysis helps in mapping the injection vectors into the IMS core or through it between UA’s A network scan (nmap + nessus) will not provide enough insight in what needs to be tested A traffic analysis provides clear mapping of all interfaces, protocols, and both server and client-side implementations that need testing Also IMS-core internal traffic can be seen
20


 

 

 

WWW.CODENOMICON.COM

WWW.CODENOMICON.COM

21


Most Relevant Attack Vectors in Rel6/Rel8

WWW.CODENOMICON.COM

22


Attack Vector Analysis of the Rel8

WWW.CODENOMICON.COM

23


Key Threats for IMS
 

P-CSCF / S-CSCF / I-CSCF / IBCF
•  •  • 

Messages from UA? Messages from “interconnect” i.e. another operator? B2BUA or Proxy?

 

Border Control Functions
•  •  •  • 

TS 23.228 clause 4.14 and Annex I Mx reference point Co-location of I-CSCF with IMS-ALG Helps security testing as targets are narrowed down to IBCF and TrGW

WWW.CODENOMICON.COM

24


Use of Fuzzers For Security Review
   

Some threats cannot be blocked SIP UA can always attack the IMS core and all intermediary proxies using fuzzers Most probable attack vectors are SIP OPTIONS and SIP REGISTER
• 

 

Why?

 

Fuzzers simulate these and many other attack scenarios and test the reliability of the platforms and VoIP applications processing SIP messages
25


WWW.CODENOMICON.COM

ENUM and DNS Attacks
 

ENUM E.164 queries make number harvesting feasible for SPIT or “Phishing” Sample NAPR record:

 

$ dig any NAPTR 3.1.1.7.4.0.0.0.8.7.3.4.e164.arpa +trace
;; Warning, extra type option
; <<>> DiG 9.6.0-APPLE-P2 <<>> any NAPTR 3.1.1.7.4.0.0.0.8.7.3.4.e164.arpa +trace
;; global options: +cmd
. 19878 IN NS G.ROOT-SERVERS.NET.
[…]
3.1.1.7.4.0.0.0.8.7.3.4.e164.arpa. 600 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .
3.1.1.7.4.0.0.0.8.7.3.4.e164.arpa. 600 IN NAPTR 100 10 "u" "E2U+web:http" "!^.*$!http://q.nemox.net/!" .
3.1.1.7.4.0.0.0.8.7.3.4.e164.arpa. 600 IN NAPTR 100 10 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .
1.1.7.4.0.0.0.8.7.3.4.e164.arpa. 600 IN NS dns4.nemox.net.
1.1.7.4.0.0.0.8.7.3.4.e164.arpa. 600 IN NS dns1.nemox.net.
1.1.7.4.0.0.0.8.7.3.4.e164.arpa. 600 IN NS dns2.nemox.net.
1.1.7.4.0.0.0.8.7.3.4.e164.arpa. 600 IN NS dns3.nemox.net.
;; Received 396 bytes from 87.106.40.145#53(dns3.nemox.net) in 52 ms

WWW.CODENOMICON.COM

26


The Promised 7 Selected Key Findings from our IMS Audits
1. 

There is no requirement to follow any IMS Release “by the book” Authentication and encryption are critical, even inside the IMS core Separated VLANs for IMS interfaces help Attack surface analysis and detailed study of interfaces and protocols Repeatable test plans for regression tests Product inventory (including HW + OS) Remember to treat proxies as potential attackers (note: SIP-I vs. SIP-T)
27


2. 

3.  4. 

5.  6.  7. 

WWW.CODENOMICON.COM

Summary
 

VoIP security is not only about security mechanisms For full security analysis, you should study:
•  •  •  •  • 

 

Threats Attacks Vulnerabilities Architectures Countermeasures

 

There is no one way of doing VoIP security, different techniques apply for different needs Security is a process not a product!
28


 

WWW.CODENOMICON.COM

PROACTIVE SECURITY AND ROBUSTNESS SOLUTIONS

THANK YOU – QUESTIONS?

“Thrill to the excitement of the chase! Stalk bugs with care, methodology, and reason. Build traps for them. .... Testers! Break that software (as you must) and drive it to the ultimate - but don’t enjoy the programmer’s pain.” [from Boris Beizer]

WWW.CODENOMICON.COM

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close