As a mission critical service, VoIP deployments require careful assessment to identify and eliminate security vulnerabilities in VoIP clients, applications, and infrastructure. But what exactly should you hunt for? Let's explore a few security cracks commonly found in VoIP products that use SIP.
Right from the get-go, this architecture inherits the same old vulnerabilities that can plague any networked application. Within the public switched telephone network, systems are trusted and insulated from outsiders. But in many VoIP deployments, user agents live outside the trusted network, requiring SIP and RTP to traverse unknown and potentially hostile territory. Furthermore, when converged IP networks support both data and VoIP, SIP user agents and servers may be readily accessible to other LAN hosts.
This exposure makes SIP and RTP vulnerable to network-borne attacks. For example, a hacker can flood a SIP server or proxy with REGISTER or INVITE messages, or flood a SIP client with RTP sessions, exhausting resources and making VoIP service unavailable. Or he can extract a caller's identity from SIP messages to steal service or impersonate an authorized user. Unless RTP is encrypted (for example, by SRTP), a hacker can easily capture and reconstruct voice payload for the purposes of call eavesdropping or replay. SIP calls can also be redirected, hijacked, degraded, or disrupted altogether.
While these attack details are specific to SIP and RTP, the underlying methodologies are familiar and common to most clear-text TCP/IP protocols. As such, existing network security measures can be used to help mitigate them. For example, firewalls can protect SIP servers and applications from Denial of Service floods, while LAN authentication methods like 802.1X can deter impersonation. Extensions are often necessary to satisfy VoIP-specific demandsfor example, firewalls must process RTP without undue latency or jitter, while intrusion prevention systems need SIP attack signatures. To learn more, see VOIP security appliances by Sipera, SecureLogix, and Ingate.
For example, when the Oulu University Secure Programming Group (OUSPG) tested INVITE message processing by SIP agents and proxies, just one of nine implementations survived this relatively basic exercise. This "fuzzing" test sent 4,527 crafted messages to representative SIP implementations, looking for buffer overflows, unhandled exceptions, and unexpected behavior. Failure impacts ranged from unexpected system behavior and denial of service to arbitrary code execution on the system under test.
Although the affected implementations have since been patched (see CERT Advisory CA-2003-06), this test demonstrates the likelihood of code flaws in newly released VoIP products and the importance of applying available patches. Fuzzing (i.e., functional testing) finds many of these problems during product development, but consumers can verify robustness using open source tools like SIPp or the OUSPG PROTOS SIP tester (now a commercial test tool, Codenomicon).
SIP registrar/proxy servers are not the only devices that should be tested for security bugs. Applications and handsets/phones also deserve plenty of scrutiny. For example:
These examples illustrate a range of potential flaws and consequences. The bottom line: diligent patching is a must for every system in your VoIP deployment. Public databases that can be monitored for relevant security advisories include:
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.