IP networks are now used to handle an increasing number of voice calls. While the bulk of this telephone traffic is currently enterprise, consumers are dabbling in IP Telephony (alias Voice over IP, VoIP). As products are commoditized and public services mature, new voice-data applications will be offered, encouraging even broader adoption. IP telephony will also encourage underlying medium agnosticism, catering in particular to mobile applications: indeed, voice over Wireless (Vo-Fi) may be the most disruptive twist to an already disruptive technology trend. A single handheld device, entirely mobile, for office and personal purposes for voice, messaging, computing, browsing, gaming and secure business application access, over any flavor of RF, is only a matter of time.
The marriage of voice, IP, and wireless packet offers many benefits, but there's a dark side of this union. The combined attack targets and vectors present a formidable triple whammy of security threats to users and VOIP service providers (private and public voice and data network operators). You see VOIP; the attacker sees and thinks, "A new phone service I can exploit as I have POTS or cellular"; "A new set of applications and protocols I can probe for specification and implementation flaws"; and "More systems I can try to exploit using traditional (TCP/IP) protocol exploits".
Many of the motivations to attack VoIP users are the same as plain old telephone service (POTS) attacks: to benefit financially, via toll fraud, identity and information theft, and to gain notoriety, by disrupting service and inconveniencing users. Such attacks are similar to attacks we have seen on cellular and landline phones for years. Others are all too familiar attacks we see against networked computers. VOIP phones and computers running VOIP software (softphones) are more computer than phone. They have operating and file systems, use Internet protocols, and run data and management as well as voice applications. They are vulnerable to unauthorized access, privilege escalation and "system" misuse, viruses and worms, and all the "classic" denial of service attacks that exploit network protocols (TCP, IP, ICMP, ARP).
Many of these attacks take advantage of the IP Telephony protocols (Figure 1).
Current implementations of VOIP call signaling (SIP), voice message delivery (RTP), and control protocols (RTCP) do not provide adequate call party authentication or end-to-end integrity and confidentiality measures on call signaling and call data (e.g., encoded speech). Until these security features are implemented and put into service, attackers have many exploit opportunities. I group these into four general categories.
Eavesdropping on call signaling packets exchanged between SIP servers and SIP phones may provide attackers with VOIP user identities, PINs, and SIP phone numbers. An attacker who gains possession of a VOIP user's account information and password can alter any user-settable service profile information: for example, in conjunction with a stolen account, the attacker might want to try to change a user's calling plan, alter a voice mail message, or change a call forwarding number. Attackers can also invade VOIP caller privacy and eavesdrop on an VOIP call by capturing packets associated with a voice conversation, then later replaying the conversations to obtain sensitive business or personal information.
Several identity theft, identity fraud, and toll fraud attacks are possible. An attacker can connect a rogue VOIP phone to a network and use a stolen or guessed user account and password (PIN) to place phone calls at the victim's expense, much as he would a stolen cell phone or calling card. Attackers can also hijack VOIPconversations using techniques similar to those used to hijack TCP connections. The attacker can send a SIP control packet to an endpoint, directing an in-progress to a different device (typically under the attacker's control). The caller is misled into communicating with someone other than the intended party (e.g., the attacker, masquerading as a party to this call).
VOIP call integrity can be compromised if message or packet authentication is not used (the common situation). For example, attackers can corrupt conversations by intercepting RTP packets, altering the contents and forwarding the modified packet to the original recipient. Other, similar man-in-the-middle attacks are also possible when message integrity is not provided over wireless LANs. For example, an attacker can inject speech, noise or delay (silent gaps) into active call from a rogue access point.
Denial of service attacks can be launched against the VOIP signaling protocol, SIP. Similar to control packet attacks against TCP (SYN, RST), such attacks flood an VOIP device with call invitation and registration requests in an attempt to exhaust its resources, to force disconnects, or to falsely signal a busy condition. Call data flooding attacks can be directed at RTP, the protocol that carries digitized voice. Like UDP flooding, attacks of this kind try to exhaust resources by bombarding an VOIP device with large volumes of call data. VOIP implementations may also be vulnerable to DOS attacks against TCP, UDP, ICMP, and underlying (e.g., wireless) networks. Operating systems and network protocol (TCP/IP "stack") on which VOIP applications and hardware devices are built may be susceptible to implementation-specific DOS attacks as well. An attacker can instigate a particularly spiteful service disruption attack by forging and sending a password (PIN) change control packet to an VOIP phone. The authorized user, unaware of the change, will be unable to place calls.
Part II considers attacks against IPT operators, both enterprise and public service provider. Part 3 discusses security measures for user devices and IPT servers, and discusses deployment considerations for converged (voice and data) networks.
I do agree with all the points regarding VoIP solutions threats to subscriber. Thanks for describe in easy language, which help every users to go through it and understand clearly about it.
Posted by: strategic communications | 11/02/2011 at 06:40 AM