One particularly effective attack involved just the IP phones. This was a fairly sophisticated, two-step assault. By sending a high rate of a particular traffic type to an IP phone for a few minutes, the phone in many cases would reboot. Rebooting made the phone susceptible to the second part of the assault, delivery of a handful of special packets, which disabled the phone for 20 minutes. Many phones could be disabled in this manner, one at a time. By repeating the part-two packet stream during the 20-minute period, affected phones could be disabled indefinitely.
Other vulnerabilities were exposed, too, but time did not permit them to be fully exploited. One of these is that the switch data port on the back of Avaya's IP phone accepts and passes user traffic with VLAN tags appended. This makes the hacker's job easier. For example, the hacker computer could then plug in the back of the phone and start sending spoofed voice traffic -- with the appropriate voice-VLAN tag; you don't even need to unplug the phone.
We also observed that certain traffic types sent to particular ports on the call-control equipment could increase the time it takes for calls to be processed. And in the hacker world, if you can cause it to slow down, it indicates a vulnerability that you can, with enough time, exploit to gum up the whole works.
Avaya, Part 2
Avaya took home the lessons it learned from the first round and returned with a more hardened, more secure configuration.
Officially, Avaya says its IP-telephony package is switch-agnostic with regard to the Layer 2 and Layer 3 equipment that underlies the VoIP infrastructure. So the Avaya Cajun P333 switch employed in the first test round was replaced in the second round with Layer 2/Layer 3 switches from Extreme, with which Avaya partners.
The key new components, all additions to the network infrastructure, included an Avaya SG208 Security Gateway ($15,000), an Extreme Summit 300-48 Layer 2/Layer 3 switch ($8,000) and an Extreme Alpine 3804 Layer 3 switch ($10,000). The Avaya VoIP equipment was unchanged. In fact, the same software loads were run in this retest, for the Avaya S8700, the G650 Media Gateway, the Control LAN (CLAN) and media processing modules, and even the same IP phone firmware release. The CLAN module ran firmware Version 9, the media processing module ran firmware Version 75, and the IP phone ran Version 2.0 firmware.
The Avaya Cajun P333 switch used in the first round was replaced with Summit 300-48. So, the frills necessary to shore up Avaya's security story in the second test round amount to about $30,000.
Architecturally, the addition of Layer 3 IP routing and other key configuration changes prevented the type of attack that was developed in the first test round, where a rogue hacker computer directly assaulted other IP phones.
The following changes enhanced security:
- Rate-limiting of IP traffic by the Summit switch prevented any TCP, UDP or broadcast packet stream from exceeding 1Mbit/sec.
- Individual VLANs were set up for each IP phone port. An IP phone cannot directly assault another IP phone if it is on a different VLAN. Then any traffic between phones has to be routed. And then it can be examined, blocked by protocol, even rate-limited, as noted. Managing per-port VLANs also can be an administrative nightmare, especially when IP phones number several hundred or more. So the scalability of this approach in large VoIP deployments is dubious.
- A process Avaya calls "shuffling" is disabled. Shuffling is the ability of an IP phone to directly exchange RTP voice streams with another IP phone. With shuffling disabled, all VoIP streams must pass through the media processing module. So disabling shuffling provides for good control and network security, but it makes the media-processing module a bottleneck. An Avaya source says a media-processing module can handle up to about 64 concurrent calls. So the scalability of this approach is questionable.
The Extreme Alpine can restrict traffic it passes to known IP phone MAC addresses. That means a hacker has to spoof a legitimate IP phone's MAC address to send traffic through the Alpine. That is exactly what our attack team did. The passive monitoring insert cable our team developed lets all active network addresses be seen and captured, even in this hardened Avaya configuration.
The SG208 firewall was configured to let only traffic of specific ports pass to and from the call-control equipment. Only traffic within a narrow, specific UDP port range was allowed to pass to the media processing module, and only the ports and protocols associated with Avaya's H.323-based call-control signaling were passed to the CLAN module. It didn't take the hackers long, with straightforward techniques, to figure out which ports were open. Their surveillance confirmed that call processing was H.323, and that meant certain ports had to be in use. And using borrowed real-phone IP identities, they were able to contact the call-control infrastructure and get responses.
It is not necessary to emulate all aspects of a legitimate IP phone's operation, or even to know its password, for example, to penetrate the call-control infrastructure. Full emulation of an IP phone's password, protocols and packet streams is necessary to place an unauthorized phone call. But most hackers have more sinister objectives.
Bottom Line
As in the first Avaya test and the Cisco test before that, the attack team readily could insert its passive probe into an IP phone station connection and observe and collect full traffic details but not decipher the encrypted voice streams.
Similarly, with the network information they collected, the hackers successfully could insert their own computer and -- using the MAC, IP and VLAN tag of a legitimate IP phone -- gain access to the voice infrastructure and contact other devices within the VoIP infrastructure.
The attack that worked in the previous test round against other IP phones no longer worked with this Avaya configuration. But the attack team did turn up another vulnerability. By issuing a very low volume of packets, using a specific protocol and port to the call-control equipment, IP phones could be prevented from registering. In normal circumstances this would affect just a small number of phones: An IP phone registers only when it's first plugged in.
So unless a phone was moved or unplugged, it normally wouldn't need to re-register. Still, phones could be prevented from registering for as long as the very low-volume traffic stream continued to be sent to the call controller.
Avaya determined that a software patch to its call-control software was necessary to address this vulnerability. The company committed to fixing the problem.
In the final analysis, and given the relatively minor nature of this security hole, we gave Avaya an overall rating of Resistant for this maximum-security configuration.
Conclusion
Our findings underscore a tenet of network security: Effective security has to address all layers. Cisco applied effective measures at Layers 2 and 3 (Catalyst switches), Layers 4 and 5 (firewalls and IPS), Layer 6 (RTP voice stream encryption -- still limited to certain phones, though), and Layer 7 (with server-based software such as the Cisco Security Agent).
The first Avaya configuration had limited Layer 2 defenses and very few defenses at Layers 3 and above, except for Layer 6. To its credit, Avaya does have good RTP encryption (Layer 6) support on all its phones. Avaya's hardened, maximum-security configuration addresses Layers 3, 4 and 6 more effectively but still leaves some holes.
VoIP security, spawned by the popularity and proliferation of IP telephony, is a critical issue, and we challenge other IP telephony providers to throw their hats into the ring.
Mier is a network technologist, consultant, author and founder of Miercom, a network product test center in Cranbury, N.J. Birdsall is senior test engineer at Miercom. Thayer is principal investigator at Canola & Jones, a security research firm based in Mountain View, Calif. They can be reached at edmier@miercom.com, rbirdsall@miercom.com and rodney@canola-jones.com, respectively.
Mier, Birdsall and Thayer are also members of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.nwfusion.com/alliance.
VoIP Goes Mainstream
Stories in this report:
- VoIP Goes Mainstream
- VoIP: Ready for Prime Time
- Snapshot: The Seattle Times Co.
- VoIP Case Study: Small Project Works Out the Kinks
- VoIP Case Study: Wireless Joins Hospital's VoIP Mix
- VoIP Case Study: Call Centers Put on Speed Dial
- VoIP Case Study: Fashion Designer Gets Hip to IP
- VoIP Is Scary
- The Hidden Costs, and Savings, of VoIP
- The VoIP Management Challenge
- Breaking Through IP Telephony
- VoIP Security Rating Scale
- Ground Rules for VoIP Security Testing
- Laying the Groundwork for IP Telephony
- Bridging the IP Migration Gap
- The VoIP security checklist
- VoIP Security a Moving Target
- A VoIP Security Plan of Attack
- Avoiding Potholes on the VoIP Path
- Computerworld VoIP Data Points
This story, "Breaking Through IP Telephony" was originally published by Network World.