RECOMMENDATIONS FOR VOIP AND IMS SECURITY - ARI TAKANEN CTO
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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
WWW.CODENOMICON.COM
2
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
WWW.CODENOMICON.COM
3
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
Media:
• RTP, SRTP, RTCP
• Mpeg1/2/4
Transport:
• IPv4 and IPv6 (with or without IPSEC)
• SCTP
• TLS
Others: DHCP, DNS, Diameter, Radius, STUN,
TURN, ...
WWW.CODENOMICON.COM
5
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
Load-based flooding attacks (DDoS)
• Performance flaw, or load balancing problem
• Also a place for fuzzing!
“SPIT”
• Hard to block in real-time communications
• Phone rings before the unwanted media can be detected
• Black-lists and white-lists
WWW.CODENOMICON.COM
84. VoIP Vulnerabilities
WWW.CODENOMICON.COM
9Fuzzing:
Proactive security testing for
unknown vulnerabilities
WWW.CODENOMICON.COMOverview 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
11Proactive = 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
WWW.CODENOMICON.COM
12Fuzzing 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
H.248
RTSP
TURN
H.323
STUN
STUN
SIP
SCTP TCP UDP
IPv4 / IPv6
WWW.CODENOMICON.COM
13Interoperability (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
WWW.CODENOMICON.COM
14Performance
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
15Failure-modes
Crash
• Boundary value condition
• Buffer overflow
• Memory exceptions
Slow performance
• Busy loops
• Memory leaks
• Error handling problems
Data leaks
• Bad asserts
• Error handling
Others…
WWW.CODENOMICON.COM
16Summary
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
WWW.CODENOMICON.COM
17The IMS Study:
Learnings from
several IMS audits
during 2010
WWW.CODENOMICON.COMOverview 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…
WWW.CODENOMICON.COM
19The 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
WWW.CODENOMICON.COM
20WWW.CODENOMICON.COM
21Most Relevant Attack Vectors in Rel6/Rel8
WWW.CODENOMICON.COM
22Attack Vector Analysis of the Rel8
WWW.CODENOMICON.COM
23Key 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
24Use 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
WWW.CODENOMICON.COM
25ENUM 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
26The Promised 7 Selected Key Findings
from our IMS Audits
1. There is no requirement to follow any IMS
Release “by the book”
2. Authentication and encryption are critical,
even inside the IMS core
3. Separated VLANs for IMS interfaces help
4. Attack surface analysis and detailed study
of interfaces and protocols
5. Repeatable test plans for regression tests
6. Product inventory (including HW + OS)
7. Remember to treat proxies as potential
attackers (note: SIP-I vs. SIP-T)
WWW.CODENOMICON.COM
27Summary
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!
WWW.CODENOMICON.COM
28PROACTIVE 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.COMYou can also read
