Voip Security
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
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
