VoIP Security: SIP Versatile but Vulnerable

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

Something old, something new
Uncovering SIP code vulnerabilities
Eliminating configuration weaknesses
Better safe than sorry
RELATED NEWS AND ANALYSIS

Something old, something new

Many VoIP handsets and softphones use SIP signaling to register with a server and place or receive calls through a proxy. During calls, voice is digitized, encoded, compressed, and transported by RTP messages between calling and called parties (SIP user agents). Those SIP and RTP messages are exchanged over IP networks—hence the moniker Voice over IP.

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 demands—for 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.

Uncovering SIP code vulnerabilities

While some security vulnerabilities are caused by using weakly authenticated, unencrypted protocols, others are introduced during VoIP product development.

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:

A vulnerability in certain versions of Asterisk lets remote attackers access the SIP channel driver using a specially crafted “From” header (see Asterisk Advisory).
A verification flaw lets attackers use the Vonage Motorola Phone Adapter VT 2142-VD to send spoofed INVITE messages (CERT Advisory 2007-5791).
A flaw the snom 320 SIP Phone could let a remote attacker use this desk phone to place arbitrary phone calls (X-Force Advisory 41171).
Even a bug-free softphone on a host without OS patches or anti-virus signatures could be infected by malware that sends voice spam (SPIT), like this proof-of-concept IRC-VOIP bot.

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:

Sipera Threat Advisories
VOIPshield Vulnerabilities List
National Vulnerability Database (search SIP RTP)
Wireless Vulnerabilites and Exposures (search VOIP)

Eliminating configuration weaknesses

The final battlefront against SIP attacks—and the one over which you probably have the most control—is secure network and system configuration.

For example, several of the aforementioned security advisories recommend the use of ingress, egress, and broadcast traffic filters to block SIP messages sent to/from systems that should not do so. In networks that use VLANs to compartmentalize VoIP traffic, switches and access points should be configured to avoid VoIP hopping. The premise here is simple: the fewer systems that are exposed to SIP, the lower the risk of falling victim to SIP-based attacks.

Many VoIP servers and user agents are easily compromised as the result of basic configuration mistakes like failure to disable risky services or change default passwords. VoIP phones tend to be particularly vulnerable to mis-configuration because (a) they aren’t managed like ordinary desktop computers and (b) their debug and admin interfaces are frequently hidden or not well advertised to end users. For example:

The Cisco 7920 VOIP phone contains an open UDP port used for remote debugging that can expose sensitive information (WVE-2006-0009).
The Hitachi IP5000 VOIP phone uses a hard-coded password that enables remote configuration viewing and modification (WVE-2006-0010).
The UTStarcom F1000 VOIP phone accepts Telnet connections using a default login that facilitates unauthorized configuration access (WVE-2006-0015).

These three vulnerabilities must be addressed through patching or workarounds (e.g., blocking Telnet or debug traffic). However, many VoIP phones have configurable ports, passwords, and wireless keys that should be changed to prevent unauthorized access. Devices that run softphones also require hardening, using the same techniques commonly applied to any Internet-connected host.

Better safe than sorry

SIP deployments need not fall victim to these common attack vectors. The trick is to proactively identify and eliminate security holes before hackers get a chance to exploit them. Start your vulnerability assessment with conventional network security tools like port scanners and application banner grabs. But don’t stop there—pursue SIP-specific tests that can uncover the vulnerabilities described here and many others.

To learn more about VIP secure assessment techniques and tools, consult the VOIPSA Security Tools List and the Hacking VoIP Exposed Security Tools List.

And keep your eyes peeled on VoIPplanet.com, as, over the coming months, we will follow up this article with one on free tools for mitigating SIP vulnerabilities and another on commercial solutions.

This article was first published on EnterpriseVoIPPlanet.com.