Risk A/F - The fragile switch

A typical remote branch office in the enterprise consists of some VoIP endpoints connected to a switch, followed by a router to the outside world. The problem with traditional switches is that the majority do not implement proper security; the majority are susceptible to ARP spoofing attacks, whereby an attacker can emulate an endpoint with the proper custom software. The is emulation could be passive or very disruptive such as toll fraud, etc. To the the fact that this risk is categorized as local, meaning the attacker needs local access to the network, the difficulty of exploiting such a risk is fairly high. Moreover, even the newer switches that have a security packages built in using VLAN's, etc. are still susceptible as it is fairly trivial to break VLAN security by simply breaking the VLAN protocol itself or finding the right MAC address(s).

Recent attacks related to VLAN hopping are not a surprise since the segmentation of voice and data on a VLAN is nothing more than a magic VLAN tag per packet; finding this VLAN tag is trivial since its running over an unsecured layer 2 protocol called Cisco Discovery Protocol (CDP); knowing the weaknesses and assumptions is the key to a successfully attack.

Possible Remedies

• Introduce a switch that supports VLAN tagging, put each endpoint on its own port/vlan. Keep the MAC addresses of the phones hidden, turn off PING replies on all endpoints and disable any ports which are not required.
• Introduce MAC filtering, to restrict access of every port to certain static MAC addresses. Even though mac addresses are easily identified by attackers it does not hurt to turn on this extremely easy but sometimes effective feature.
• Introduce 802.1x, that forces endpoints to authenticate via EAP before joining the network. Without the proper credentials an attackers packets would no go very far.
• Create a VoIP DMZ which has static IP addresses fixed for all Phones, DHCP turned off and good IP ACL rules for all traffic coming to and from the Call servers via the signaling path.
• Introduce a IDS/IPS with a state full ARP spoofing engine to detect/mitigate against ARP spoofing in the first place.

• Let's take a look at the first point. Most enterprise switches today support VLAN's and robust security policy administration. If you're in the pre-deployment phase then its a no-brianer - choose one of these enterprise switches. If you are in post-deployment and lacking VLAN's check your vendor to see if they have upgrade possibilities in the form of firmware upgrades. At the end of the day it comes down to how much you're willing to spend on getting another few points of security for your branch VoIP endpoint deployment.
• The second point is more interesting; today's market is flooded with IDS/IPS products claiming they can protect you against everything except god himself. Find one with a robust ARP spoofing mitigation solution for the best price coupled with a good support contract and you will be fine.
  Even though this endpoint network can be categorized as being of medium importance, do remember that good VoIP security strategies cover all bases.

Risk B - SPIT in the cluster

Even though SPIT (Spam over VoIP) is traditionally found at the signaling layer, there are still security risks inherent directly in the voicemail warehouse. The problems present here are few but important to consider. Firstly, lets talk about call recorders and IVR (Interactive Voice Recorder)'s. Both of these devices are related to either collecting and storing voice calls or allowing interactive sessions with a user via a telephone prompt. These devices interact with the remaining VoIP infrastructure via some sort of application protocol. This protocol is our focus; if there are security issues we will find them there.

For example, the Cisco voicemail system ("Unity") communicates with the Cisco call server ("Call Manager") via the proprietary protocols. Some could argue this proprietary nature protects; people! do not be so naive. Every protocol has flaws, it only takes one vulnerability targetted against the Call server which cascades into a garbage encoded packet to travel to the Unity server resulting in an unforeseen buffer overflow, thereby taking down your very important voicemail system.

Possible Remedies

• Introduce an application layer VoIP aware firewall, SBC, Voice IPS that has an updateable database of signatures that could protect against application layer attacks specific to the VoIP protocol traveling to your voicemail cluster.

• The feasibility of the above point is directly related to how paranoid you, or your security entourage is. While the likelyhood of attack taking place on your voicemail cluster via some unknown vulnerability at the call server is small, remember it takes only one incident. Again back to my point that a good VoIP security strategy is only as strong as its weakest link.

Risk C - IP PBX is exposed

In VoIP there are two main phases, call control ("session") and the media path ("voice"). In order to link up one or more endpoints with another set of endpoints, the call server must federate a request to the appropriate parties. Once the parties are in synch with exactly who is where and talking what language, the media path can be established without the help of the central call controller. Since the call control plane precedes the media path it would be logical to protect and safeguard this important step in the process. An attacker that can wreak havoc with your call control plane is a very dangerous individual indeed.

Most major IP PBX vendors use some proprietary protocol to do their main signaling, Cisco - Skinny, Nortel - UNIStim, Avaya - H323 but also support SIP for trunking and interoperability. The proprietary protocols introduce added complexity because they are not open - hence proprietary. To fully understand their structure you must take type to decipher the protocol language via pre-attack reconnaissance or get the information from somewhere. Luckily, the basic implementations of both Cisco';s and Nortel's protocols are implemented in the Open-source Asterisk PBX. An attacker can learn at least the core inner-working of the protocol, from the server side to the endpoint side. Given this good starting point, discovery of vulnerabilities is assured - trust me. It is possible to do allot of ballet with the server by simply throwing strange combinations of protocol packets at it, a lot of which could be avoided by having a proper security system in place to stop this ballet routine.

Moreover, there are many vectors of attack that are strongly related to the context. Let me explain; a call system is programmed to handle a finite set of commands or actions in deterministic orders, times, etc. The majority of them do so very well, however what they do poorly is understand context. By context I refer to something as simple as the source. What normally be considered as a legitimate command sent to the call server, is really disastrous if sent from the wrong source, this source should be banned and restricted from even talking to the server; whether that is accomplished via external policies such as IP ACL's or simply done at the software level. It's importance should not be underestimated. I have seen to many instances of vulnerabilities in PBX system be causes by allowing a very legitimate action to take place from an illegitimate partie - common guys lets think about it and introduce some sort of context understanding.

Possible Remedies

• Introduce an application layer VoIP aware firewall, SBC, Voice IPS that has an updateable database of signatures that could protect against application layer attacks specific to VoIP signaling that your server supports.
• Use IP ACL's in front of the signaling path to block out everyone except your endpoints of interest. Spoofing an IP address is easy, as is the MAC address, so ACL's can only go so far. However you would be surprised how effective it can be given its ease of introduction.
• If you have the slack to encrypt and authenticate, do it - its a no brain-er. If you can't do full blown encryption, just do authentication, its simple and effective, given that signaling is less "real-time" than media.
• Do constant vulnerability assessments with whatever tools you have, whether commercial or open source. Most of them have steady updates that could expose newer exploits in your PBX. It takes time but can make all the difference when it comes to attack time.

• Let's look at the first point. There are a variety of signaling protocols out there, each vendor usually has a proprietary one or a derivative proprietary version of one. The problem with today's security solutions environment is twofold: there are numerous vulnerabilities present in all signaling protocols and there are few or no real VoIP security products that can credibly protect against a comprehensive set of VoIP signaling protocols. Until a good solution shows itself, there is really little that can be done. Ignore the fake propaganda from vendors that claim to have VoIP security, masqueraded in a data network security product with some VoIP "awareness". Again back to my point that a good VoIP security strategy is only as strong as its weakest link.
• Access Control Lists are very practical and easy way to narrow the attack vector to your server. However, they are fairly easy bypass given some expertise. I always advocate for mandatory IP ACL's everywhere that is possible, there is no harm done doing so unless you're always running DHCP.
• Most VoIP deployments come out of the box un configured for a real enterprise deployment. I have seen too many deployments just taken out of the box, plugged in and that's it. The vendors have taken allot of time to implemented sophisticated security strategies for encryption/authentication and I suggest you find someone that can help you unlock and use as many of the features as possible.
• Vulnerability assessments usually require some maintenance window to perform. Some tools are passive, some are the opposite. Understanding of the features of a vulnerability assessment tools is paramount so that you can effectively plan against the worst. Depending on your expertise of your team will dictate which tolls you should really be looking at. Commercial tools can either be really good or really bad, some are just data vulnerability assessment systems wrapped up in some VoIP propaganda. On the other hand open source tools even worse, most of the time bring prone to extremely high cases of false positives/negatives. Their only advantage is cost and customization. There is no quick answer of what to use, but the underlying point is that it should be done, and done regularly to upgrade your visibility of Call server's vulnerability plane.

Feel free to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it and stay tuned for Part 2 where we continue our analysis of Trunking and VoIP to PSTN.

This article is subject to copyrights against its respective writer. Feel free to contact them if you wish to use the article in some intermediate form.

---