Table of contents
- How to think about VoIP security
-- An introduction to VoIP security and which specific issues of security for Voice over IP are of particular importance.
- VoIP security vs. voice quality
-- This section discusses how security tools and solutions can interfere with voice quality.
- Finding vulnerabilities
-- A brief discussion on VoIP and IPT vulnerabilities and how voice personnel can prepare to handle a previously unknown threat to service.
- What data security threats exist in VoIP/IPT?
-- Security threats on the data network will eventually need to be considered on the voice network -- it's never too early to start thinking about them!
- Securing the elements of the VoIP network
-- As voice is added to the network mix, security issues will increase in frequency. This section discusses how these can occur and considerations for handling these situations.
- What makes VoIP security different?
-- Even though more enterprises are running voice on the data network, voice security still has a number of different aspects that do not concern the data side. This section also contains a list of threats that can be found in an IP-based telephone network.
- What security tools exist to protect a VoIP network?
-- Voice security issues can be resolved more quickly with the assistance of the right tool.
How to think about VoIP security
Security requires constant vigilance. Security is all about the protection of resources -- data, devices, networks, applications and people. While access to these resources is the goal of the user, securing access to these resources means the administrator of the resources wants to limit, even prevent, that access. Enterprises already have many security problems with their data network infrastructure, servers, desktops and software. Adding VoIP and IPT to the mix only compounds the security problems.
There are several security issues with VoIP networks:
- The VoIP/IPT devices, servers, gateways and phones share the data network and inherit the data network's security problems.
- There will be data attacks on voice devices such as Denial of Service (DoS) and malware.
- It is easier to eavesdrop on IP calls than on TDM calls.
- The centralized TDM PBX is gone. The VoIP/IPT resources are scattered around a network.
- The operating systems of the VoIP/IPT devices are less secure than the TDM operating systems of the past.
- Systems (PBX) administration can be located at multiple locations and can be accessed by Web browsers.
It may not be apparent, but security tools and solutions will conflict with voice quality. The more barriers there are in the network and endpoints for security purposes, the more interference there will be with voice quality.
One of the first issues is the firewall. The firewall can block calls because it cannot process the signaling or dynamically allocate the UDP ports for the calls to pass through it. Firewalls may not read the QoS markers in the voice packet, thereby degrading the packet delivery service. Other issues include:
- Voice packets, when they pass through security devices, can cause added delay, jitter and packet loss during the call.
- Intrusion prevention systems perform considerably more processing than a firewall and have been proven to cause voice quality degradation.
- Encryption and decryption add delay to the calls.
- VPN connections encrypt the QoS markers. The routers consequently cannot deliver the needed QoS for the voice packets.
The security vs. voice quality conflict will be hard to resolve. The voice manager, obviously, does not want poor-quality calls. If the calls are poor, then why have calls travel over the data network in the first place? The security manager does not want to open the network and endpoints to security exposures that will not only compromise the voice services but weaken the data functions as well. This will require a great deal of negotiation and compromise. Security is important, but not at the cost of an unacceptable voice service.
There are two sites that demonstrate the software security threats to the data functions. These lists now include VoIP/IPT vulnerabilities. Both lists are funded by the federal Homeland Security Administration. The first is hosted at Mitre. This site has a dictionary of standardized names and descriptions for Common Vulnerabilities and Exposures (CVE). The second site hosts the National Vulnerability Database at the federal National Institute of Standards and Technology (NIST).
The voice staff has not encountered many security problems with traditional TDM PBXs, but voice staff may not be prepared for the new range of security issues that will become evident as the enterprise migrates to IPT or VoIP. The VoIP personnel will either have to take on their own security responsibilities or use the existing security personnel. In either case, the new responsibilities for VoIP security will require education, possibly some organizational adjustment, and expanded job descriptions.
Most of the people working with Ethernet and IP networks today were not around when these technologies debuted. No security was integrated into the Ethernet design. Ethernet endpoints were to be responsible for security, not the Ethernet network. The creation of TCP, UDP and IP protocols also left security to the endpoints. Security problems such as viruses were considered a novelty in 1988 and were not given serious consideration. We do not want to make the same mistake with VoIP security.
IPT vendors have been moving to common operating systems (Linux, UNIX and VxWorks), as well as continuing to use Windows. All of these operating systems will be attacked, whether they support data or voice applications. The threats to the operating systems for VoIP will be the same as those encountered for data function support.
The following data threats are not yet as prevalent for VoIP as they are in data networks, but they will become more common in the future.
- Viruses and worms (in call servers, gateways and phones)
- Trojan horses
- Port scanning (for signaling and RTP speech ports)
- Malicious executable software (even in the IP phone)
- Spoofing source identity (pretending to be the call server)
- Spyware (in IP phones)
- Password/identity cracking
- Denial of Service (both traditional DoS and new types for VoIP/IPT)
These data threats will only increase with time as more people learn about VoIP and more products are installed. IP telephony systems use the data DHCP, DNS, TFTP and NTP servers. If these servers are not well protected (they are vulnerable in many enterprises), the IPT system is also vulnerable to security threats. Verify the security of these servers with the appropriate staff before you allow the IPT system, gateways and IP phones to access them.
A good set of security resources can be found at the National Institute of Standards and Technology. Look for the following publications:
- SP 800-100, Information Security Handbook: A Guide for Managers SP 800-12, An Introduction to Computer Security: The NIST Handbook (look for the latest version)
- Draft Special Publication 800-94, Guide to Intrusion Detection and Prevention (IDP) Systems
- Draft Special Publication 800-80, Guide for Developing Performance Metrics for Information Security
The first conclusion is that VoIP security issues that occur in the data network should be managed and solved by the existing network security personnel. They already do the job and have the responsibility for protecting data traffic. The security problems may not be new, but the problems will occur more frequently as VoIP is added to the network traffic mix.
The IPT call server is not quite the same as the data server. Data servers normally correspond with a desktop and deliver the information or service to the desktop. The call server exists for signaling, but once the call is set up, voice traffic bypasses the call server and is no longer in a signaling dialog with the IP phone. Call server security is concerned with PBX administration, call control, performance, call admission control, management, features and functions assignment, and restriction.
The security of the call server should be assigned to the same group that manages the data server security. DoS, tampering and malicious code, which are problems for the data server, will be problems for the call server as well. There will be more attempts to access the call server to modify privileges and restrictions assigned to the IP phones and gateways. An intruder may attempt to register rogue phones.
If there are firewalls in front of the data servers, there should be a firewall in front of the call server. Check with the call server vendor to determine whether third-party security software can be resident in its call server product. Some call server vendors will optionally supply their own security software but will not allow third-party security software to be resident. Resident third-party security software may impair call server performance.
IP phones with two Ethernet ports can be used to invade the data network by connecting a laptop to the second Ethernet port on the phone. Someone could disconnect an IP phone with a single Ethernet port and plug in a laptop that simulates an IP phone in order to gain unauthorized access to the data network.
Voice security may be initialized by the call server, but the voice connection security operation is the responsibility of the endpoints: phones and gateways. The endpoints can be attacked without interfering with the call server. The call server can be fooled into thinking that the endpoint security is satisfactory. The IP phones should be considered as a desktop endpoint and managed as a desktop with some unique problems. They can be attacked like any other IP device.
The gateway presents a new set of problems because it connects to legacy analog and digital phones, faxes and other analog devices, as well as PSTN trunks. Some IPT vendors offer security software in the gateway, such as an integrated firewall. The security of legacy connections has issues that will be new to the data security personnel. These issues will be covered in the next tip.
The IP side of the gateway should be managed like any other data device by the same personnel who handle the endpoints -- most likely the desktop security personnel. The desktop security personnel may be reluctant to accept this responsibility because the gateway is so different from the typical desktop.
Although the data network, server and desktop security problems will also occur in VoIP devices, the voice staff may have holes left in the VoIP security picture. The existing security personnel see disruptions caused by deploying VoIP as weakening their security controls. New policies, and probably new hardware and software, will be necessary to fully protect the IPT environment from existing data security threats.
In addition to data security issues, VoIP is plagued by other problems that will expand the definition of information security. Part of the problem for the VoIP implementer is that legacy TDM PBXs and phones have very few security problems. Not only is security strong, but the user is also used to a high level of privacy. The primary security issues for TDM-based PBX systems were toll fraud and tampering with feature/function privileges and restrictions. Both of these problems have been significantly reduced in the past several years.
Security personnel have to broaden their perspective in response to VoIP's security problems. There will be security issues with the server. Many of the new threats will relate to the phones and gateways. The attack or threat may appear to be the same as that found in data security, but the results will be different. Many of the threats will be generated behind the firewall by internal employees, individuals who are on site temporarily, and contractors. Some threats are not really attacks but are caused by negligence or abuse.
The threats can be variations of those found in data networks or can be specific to VoIP. Here are some of the security threats found in IP-based telephone networks:
- Signaling tampering
- Fuzzing is a tool used by developers to locate problems. It can also be used to attack a signaling protocol implementation. Fuzzing discovers vulnerabilities by creating packets that push a protocol to its breaking point. SIP can be attacked this way. This can create denial of service (DoS), endless loops, logic errors, buffer overflow, configuration errors, access validation flaws and information leaks.
- A PC can be loaded with server software and behave as the real call server by spoofing other devices. The rogue call server is then in control, supporting the signaling protocol.
- Flood-based DoS can be caused by a PC on the network sending many "register" packets that can tie up the phone operation.
- Another DoS can be created by sending many "invite" packets that cause the phone to ring. (The user picks up the phone, and no one is there; he then hangs up, and the phone rings again.)
- In session teardown, an attacker sends "bye" packets that cause the phones to hang up.
- Directory tampering
- Registration manipulation can erase, add or hijack a phone's registration.
- Calls can be redirected to another phone without the caller's knowledge.
- Feature and function tampering
- These can be enabled and disabled without authorization from the administrator.
- Incoming and outgoing calls can be blocked by the setting arranged in the call server.
- Applications in the call server can be blocked or enabled improperly.
- This is SPAM over Internet Telephony. SPIT can rob the network of bandwidth, interfere with QoS and overload voicemail systems. It also takes longer to eliminate SPIT from a voicemail box when the caller is unknown and the listener must hear the call to determine whether it is legitimate.
- RTP attacks
- RTP attacks can inject sounds into a phone conversation. The speaker does not know of the injected sounds and the listener thinks the sounds are coming from the speaker, not a third device injecting other sounds. (What if someone is on a conference call or calls home to say he is working late, but the listener hears restaurant or bar sounds instead?)
- Check-sync messages
- These can be sent to the endpoints, causing repeated reboots that do not allow the phones to work properly.
- Caller ID spoofing
- Caller ID is now carried in a data packet that can be generated falsely. This can have an adverse effect because attackers can pretend to be valid executive or special phones, IVR or call centers. The caller ID simulation cannot be detected by an unknowing caller or called party.
- This is easier to perform with IP-based calls than TDM-based calls. Any protocol analyzer can pick and record the calls without being observed by the callers. There are software packages for PCs that will convert digitized voice from standard CODECs into WAV files.
- The speakerphone function can be turned on remotely, with the caller on mute so that there is no sound coming from the phone. This has happened with some IP phones in executives' offices. Their offices can be listened to without their knowledge.
- PCs and laptops that have microphones attached or integrated into them can be enabled as listening devices without the user's knowledge. There is a rootkit available for this purpose.
What security tools exist to protect a VoIP network?
VoIP security tools can help the enterprise's security staff test IP telephony vulnerability and take measures to prevent security breaches.
- Sniffing and manipulating the packet stream
When discussing IP telephony vulnerability test tools, there is always the issue that publicizing information will be considered unethical because it can fall into the hands of potential attackers.
However, many VoIP sniffing tools are publicly known. Attackers will use them anyway, and hiding this information from the public ensures that the tools will be more useful to the attackers. The attackers will become reliant on the ignorance of the enterprise security staff if the tools are not known to the public. When the enterprise security staff has access to these tools, they can move forward to mitigate security problems.
>>Click for an extensive list of free IP telephony vulnerability test tools.
- IP telephony fuzzing tools
Fuzzing is a form of stress testing using malformed packets. Fuzzing is also known as functional protocol testing or robustness testing. It is usually used to automate vulnerability discovery. It finds bugs and vulnerabilities by producing different packet types that target a protocol. The fuzzing attack pushes the protocol's design specifications to the breaking point. It is often used by developers and vendor internal QA groups to test their protocol implementations.
>>Click for a list of IP telephony fuzzing tools.
About the author:
Gary Audin has more than 40 years of computer, communications and security experience. He has planned, designed, specified, implemented and operated data, LAN and telephone networks. These have included local area, national and international networks, as well as VoIP and IP convergent networks, in the U.S., Canada, Europe, Australia and Asia.
Ask the expert: Can outsiders access my VoIP line and gather confidential data?
This was first published in May 2007