Bogdan's Blog

Homeland Security Telephony System Breach

On August 20th, the department of Homeland Security had a hacker breach their telephone system. The hacker managed to exploit a security opening in the system's voice mail when it was upgraded by a system administrator. Over 400 calls were made to the Middle East and Asia with an approximate cost of around $12,000.

While it seems that (DHS is not disclosing more details of the hack) the classic oversight of using default password settings in the voice mail system let to this exploit, the fact it happened to DHS and the calls were made to the Middle East is fairly ironic. We cannot say with certainty whether the system in question was VoIP based or whether it was using PSTN or IP based trunks, but from a voice security perspective, this event clearly shows that everyone is vulnerable to the simplest and most basic exploits regardless of the technology we use.

From the voice security practitioner point of view, following industry best practices such as changing default settings immediately after systems are put into production or when there is a major upgrade to the components,  is a common sense practice. And in another bit of irony, in 2003 DHS issued a warning about this very vulnerability. However, in practical situations, due to a human error or omission, the default passwords often are left unchanged leading to potential exploits. The scope of this problem is amplified by the fact that today’s PBX is a complex application serving thousands of users with hundreds of features and multitude of options. 

When managing multiple IP-PBXs, manual processes can’t effectively track the configuration details and is prone to errors and mistakes: such is the cast at DHS. An automated VoIP assessment and compliance management tool would enable administrators to track conformity with voice security best practices and security vulnerabilities in all stages of a PBX’s life cycle, including staging, day-to-day usage, upgrades, patching, etc. Such a tool, if used on a consistent basis, would prevent most of these problems from occurring. Whether this tool is used on an ad-hoc or periodic basis, it allows identifying most of common problems and mistakes made by the PBX users and administrators.

VoIP Security - Myth #5

Myth #5 - My VoIP infrastructure is secure because...

"I have deployed VoIP infrastructure using proprietary protocols and applications from vendor X. They assured me that my VoIP is fully secure."

This is good, but how do you know? There are hundreds of known vulnerabilities related to all VoIP vendors. And most of the vendors does not even talk about security until they finalize the sale.

I suggest you start with a good risk analysis process. Identify your corporate assets that are vulnerable  because they are stored/transmitted over VoIP infrastructure. Any revenue generating services you provide to your customers using telecommunication network. Internal business processes that relay on Unified Communication. And remember your data networks could be attacked through VoIP exploits and vice versa.  Once you established your risk areas you can define the ways to minimize the risks associated with security breaches.

A commonly used approach from the data security world, vulnerability assessment (VA) is particularly effective as a proactive way of finding security problems and fixing them before they become real problems.  By performing a VoIP VA in the lab, before any VoIP equipment and applications are deployed organizations are able to verify the vendor claims and identify security flaws early in the deployment cycle. Executing a VoIP VA of all components prior to the commissioning of   
the VoIP infrastructure is recommended as interactions and dependencies between VoIP applications and devices could potentially create additional security vulnerabilities not visible during earlier assessments in the lab. Once VoIP is deployed, periodic or, where required, continuous vulnerability assessments should become cornerstone of an overall proactive VoIP security process. Once security vulnerabilities are identified they should be addressed by appropriate actions such as patching, re-configurations and network tuning.

Within the VoIP network, various security architectures and solutions should be deployed to protect VoIP services from security threats during their life cycle. Any security architectures and solutions deployed must be “VoIP aware” so they do not impact VoIP service quality and reliability. It is recommended deploying multi-layer security infrastructure that provides both perimeter as well as internal network protection. In most cases, it will consists of a number of security devices and host based applications. A comprehensive VoIP aware protection security infrastructure should include VoIP aware firewalls, Session Border Controllers (SBC), VoIP Intrusion Prevention Systems (VIPS), VoIP DoS defenses, VoIP Network Intrusion Detection Systems (IDS), Host VoIP IPS, VoIP Network Access Control (VNAC) and VoIP Anti-SPIT. All the devices and applications have to be coordinated via a higher level application providing unified view of the end-to-end VoIP infrastructure.

Review all your security processes, procedures and training materials. The existing security related processes should be reviewed and modified to accommodate specific requirements of VoIP networks. Also, the compliance and auditing processes should include VoIP as a component. For example, only certified VoIP soft-client should be used on the network. Also phone conversations that are confidential should only be allowed on encrypted links to prevent eavesdropping. GLBA compliance could require providing documented vulnerability assessment results and mitigation steps undertaken to address the discovered vulnerabilities.

If you implement these recommendation you'll be able to report to your management that your VoIP infrastructure is pretty secure and you should be able even to prove that.

VoIP Security - Myth #4

Myth #4 - My VoIP infrastructure is secure because...

"I implemented VoIP aware firewall and/or Session Border Controller (SBC)."

A VoIP aware firewall and SBC are closely related applications with similar functionality. You will see the VoIP aware firewalls most likely deployed in Enterprises and SBC deployed in VoIP service provider's networks. I will use term SBC throughout this blog.

SBC was designed to manage SIP traffic and enable it to cross NAT or firewall perimeter in service provider environment. Signaling protocols such as H.323, MGCP, and Session Initiation Protocol (SIP) transfer information including media session endpoint IP addresses and UDP port numbers. This information cannot be seen by a normal firewall or NAT device, so the subsequent sessions set up are not recognized, do not pass through firewalls, and have incompatible IP addresses across NAT boundaries. SBCs allow NAT and firewall traversal, normally by incorporating those elements with signaling controllers for the required signaling protocols. As such the SBC is a proxy that manipulates packets and is not transparent to the VoIP traffic.

Security functionality was added to SBC as an afterthought. It does not have signature based engine at all. The security functions it provides are protocol scrubbing and anomaly detections usually offered by the most expensive SBC implementations. And these implementations have a number of weaknesses:

1.    The false-positive ratios for exploit detection are much higher for anomaly detection engines than for signature based solutions.

2. They only recognize standard VoIP protocol anomalies (SIP, RTP). Even for these vendor's "non-standard" extensions are not recognized.

3. There are hundreds of attack vectors that could be exploited by a potential attacker to harm VoIP infrastructure. Only small number is related to SIP and RTP. Majority of the problems could be traced to other VoIP layers such as applications, databases, web servers, and OS. Existing SBC can't protect against those at all.

4.    Any updates to the anomaly detection engine require new software loads/releases and long verification/testing cycles.

5.   Support for new protocol extension/changes requires new software loads and long verification/testing cycles

Clearly, SBC provides only very rudimentary security protection. Providing in-depth, multilayer security driven by risk management principles require that SBC/VoIP  aware firewalls  solutions were augmented by other security applications designed specifically to deal with a wide range of VoIP exploits and attacks. These include VoIP Intrusion Prevention Systems, VoIP Network Access Control and Anti-SPIT.  Risk management approach to security requires VoIP Vulnerability and Compliance Assessment tools. And then you need to enhance your security policies and processes to include VoIP as well.

VoIP is not a simple application. And there are no simple security solutions for VoIP. Period. 

VoIP Security - Myth #3

This is the third installment of the VoIP security myths series. In the previous two I talked about common security myths related to VoIP network topology and deployment. In the following blogs I will analyze issues surrounding VoIP security infrastructure.   

 
Myth #3 - My VoIP infrastructure is secure because...

"I have a solid security infrastructure on my data network and VoIP is part of it."

Enterprises deploying VoIP have already invested significant resources in securing their data networks using a combination of security applications, devices and processes. The problem is that VoIP can't be secured by just simply extending data security infrastructure.

Key to understanding this statement is the fact that VoIP is not just another data application. It operates differently than data services. For example, in order to establish real-time communication VoIP is using various signaling protocols such as SIP to identify the calling parties, define call characteristics and ring the phone. Once the call is established conversation is carried over IP network using packetized voice. Signaling protocols have their own specific characteristics such as dynamic assignment of ports for RTP traffic. There are also issues related to NAT impact on signaling protocols. Existing data security solutions are not designed to deal with these issues. New, specialized devices such as VoIP aware firewalls and SBC (Session Border Controllers) have to be deployed.

While the signaling phase is handled by PBX/Call Manager, in most implementations RTP traffic is routed in Peer-to-Peer (P2P) mode between calling parties, completely bypassing PBX/Call Manager. From security point of view it is very difficult to protect end-points using P2P communication. Firstly, RTP traffic is a stream of packets with random, binary content created by digitizing human speech. Secondly, all the VoIP phones regardless of the vendor and geographical location are using this protocol. Thirdly, it flows directly between phones without any centralized controllers. And then what if RTP could be exploited by hackers, even over PSTN? How do you protect millions of end-points many of them mobile using P2P?

VoIP applications and devices introduce hundreds of new vulnerabilities (see my Myth #1 blog) that the existing security protection applications are simply not able to recognize. No matter how many gigabits of traffic per second they process existing data IPS/IDS, HIPS, Anti-virus applications just don’t have the signatures that would enable them to recognize and stop these exploits.

The high VoIP sensitivity to QoS parameters such as packet loss, jitter and delay requires all the in-line security devices to be optimized to minimize impact on VoIP QoS. Many of the data security in-line applications are rated based on their ability to process gigabits of traffic per second. Since VoIP isn’t bandwidth intensive application minimizing impact on QoS parameters is far more important. In addition the VoIP in-line devices should be able to match Busy Hour Call Attempts (BHCA)/Call per Second (CPS) capabilities of the PBX/Softswitches they protect.

And then you have SPIT (Spam over Internet Telephony). While conceptually it is similar to email spam there is one significant difference. Existing anti-spam applications can analyze the entire email including the header and the content resulting in pretty good false-positive ratios and high efficiency. In the VoIP world we could relatively easily analyze information carried by the signaling protocols. The problem is that it could also be easily spoofed or altered. So to achieve the same efficiency as the existing anti-spam applications we should also analyze the content of voice conversations. What it really means is to intercept the conversation in real time and analyze the speech against pre-defined speech patterns. But what if these patterns span hundreds of packets - you need to wait for all them to arrive before you could analyze the content. And then you have to insert them back into voice stream or drop the call if it is identified as SPIT. And if there are thousands of SPIT calls per second massive amounts of processing power/DSP will be required to preserve VoIP QoS. Bottom line: this is a very difficult technical problem to solve.

Most of the enterprises have a set of security policies and procedures. But again they are applicable to the data networks. Do you need to update them to cover VoIP and Unified Communication? I bet you do. Do you have policies related to voice mail passwords? PBX configuration passwords? Using soft-phones while traveling? Using Skype to call your business from abroad? Skype clients running on Blackberries?

In the companies I worked for we always had IT department including security group and telecommunication department taking care of the phone system. They never talked to each other since the data and voice had separate infrastructures. This is changing now but does your telecommunication department have full understanding of IP networking and security?  Do your IT and security staff have good understanding of voice communication? If they do you are very lucky. If not, make sure they work together well otherwise you will have a lot of problems implementing VoIP security infrastructure and policies.

User education is also very important. People usually are suspicious of any unusual emails or web sites. But what if they see Caller ID showing someone calling from their HR department asking for personal information? I am sure they will provide all the required information. Or Legal department asking for specific patent information? Yes, they will give all the details. What about IT department calling and asking for the laptop password? Are they going to say no? Caller ID spoofing is extremely easy to do and people still trust the phone system.  The end result is that VoIP should be seen the same way as email or web browsing – use with caution.

To have a solid data security infrastructure is a good thing. But it will not help you too much in securing you VoIP and Unified Communication. Having knowledgeable IT and security personnel is great. But without having good understanding of telecommunications you may not be able to implement even basic VoIP security policies and infrastructure.

VoIP Security - Myth #2

Myth #2 - My VoIP infrastructure is secure because...

"My VoIP is implemented using VLAN infrastructure and it is isolated from data networks”.

A virtual LAN commonly known as a VLAN, is a group of devices that communicate as if they were attached to the same LAN, regardless of their physical location. VLANs address issues such as scalability, security, and network management.

Let's look closer at the role of VLANs in VoIP deployments. A PBX/Call Manager with PSTN trunking and bunch of hardphones attached is usually implemented on a dedicated VLAN. Clearly in this case VLANs provide some degree of additional security just by virtue of isolating VoIP from data traffic. Sounds good but here you have a tool that you can use to hack this configuration: http://forums.remote-exploit.org/showthread.php?t=12116. There is also a good paper that explains VLANs and their interaction with PBX/hardphone/PC VoIP implementations: http://www.securityfocus.com/infocus/1892

Unfortunately introduction of softphones running on mobile platforms such as laptops or smartphones breaks this nice concept of "isolation" since these devices need to be present on both data and voice networks to perform its functions. And in most cases, they will be located outside the IT core networks as it is in the case of telecommuters or mobile workers so VLANs are not really helping here too much. They are becoming a major source and threats for both data and VoIP networks. Many analysts predict that enterprises will stop buying the hardphones in the near future and switch entirely to the softphones.

While signaling traffic is handled by PBX/Call Manager, the following voice conversation is carried over RTP/RTPC protocols and in many cases in peer-to-peer mode is bypassing PBX/Call Manager entirely. Again the traffic patterns will not follow any pre-defined groupings or VLANs. And just to make this more complicated IP trunking is becoming more popular and replacing "secure" PSTN connection.

Clearly VLAN is not a silver bullet that would make your VoIP secure. However, some vendors would like you to believe that they are and therefore you should not worry about VoIP security anymore. Well, that would be great.

In reality VoIP security is as complex as data security and it requires a methodical approach that takes into account enterprise business needs, VoIP specific characteristics, available security solutions, security policies and compliance requirements. No silver bullets here.

VoIP Security - Myth #1

Myth #1 - My VoIP infrastructure is secure because... 

"because our PBX is connected directly to PSTN network and I am not using SIP/H.323 trunking”.

Well this brings fond memories of the old days when voice security meant to have a good lock on the doors leading to the telecommunication closet with a PBX in it. Unfortunately the fact that there are no IP trunks doesn't mean your VoIP is secure.

Look at the diagram of a single VoIP device, in this case a Call Manager (a modern term for the PBX). It is very complex system consisting of VoIP applications, protocol stacks, common network services such as DHCP and web server, OS and complex configuration databases. Each of these layers has vulnerabilities that could be exploited locally or remotely. These vulnerabilities could be also combined and used to create pretty sophisticated exploits spanning multiple layers. For example there are vulnerabilities that enable an attacker to send a crafted command to a particular service running on CM and obtain a shell on the attacker's console. From there the attacker could transfer a harmful software to Call Manager. Then the attacker would exploit another vulnerability related to a soft clients reset process by modifying the startup sequence and transfer a worm to the soft client an d obtain shell on that machine as well. Pretty scary scenario.

SIP/H.323 trunks are just a small component of the typical Call Manager software and not that attractive to any potential attacker. As a matter of fact there are much more attractive attack vectors that could be used to exploit Call Manager vulnerabilities than IP trunks. 

Imagine how complex this picture becomes when you deal with a real VoIP deployment with PBX, phones, soft phones, gateways, voice mail, IVR, ADC, etc. The potential attacker can penetrate the VoIP infrastructure remotely through direct attacks on VoIP applications/devices or indirectly through data network or VoIP applications residing on the dual use devices such as soft clients or smartphones. Another interesting observation is the fact that these pesky softphones will, with time, replace all the hardphones we use today. And since they reside on common PC platforms such as laptops and in the near future on the wireless smartphones they are present in both data and VoIP networks. As such they present very attractive vector of attack against VoIP as well as data networks.

These attacks could come from external sources such as the global Internet and ISP networks or internal malicious employees, unknowingly malicious employee or directly connected third-party company, business partner or consultant. And let me assure you that my guys working in the research division can show you many of these exploits, some of them very, very scary.

Trying to implement VoIP security by using PSTN network as a firewall/IPS is not a viable solutions and it can’t substitute for a real VoIP security architecture that can protect your VoIP infrastructure from external and internal threats. And soon or later VoIP is going to replace PSTN anyway. So get ready now.

Welcome to Bogdan's Blog

Hi, my name is Bogdan Materna and I am the CTO and founder of VoIPshield Systems. You can find more details about me and my company on our website www.voipshield.com .

In the following weeks and months I will be blogging about a wide range subjects related to VoIP security including research, vulnerabilities and exploits, products, architectures, processes and best practices. From time to time you may see my commentary on new VoIP security developments, interesting blogs and other relevant events. I would like to make this blog as interactive as possible so feel free to comment or ask questions. If you want to send me an email you can reach me at bmaterna@voipshield.com. Enjoy!