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

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

3.1 VoIP Threat and Attack Categories

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

WWW.CODENOMICON.COM

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

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 UAs 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:enum-milliwatt-test@sip.nemox.net!" .
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:info@nemox.net!" .
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 dont enjoy the programmers pain. [from Boris Beizer]

WWW.CODENOMICON.COM