Breaking through IP telephony

1 2 Page 2
Page 2 of 2

•  For port security the administrator can lock down the port to one, two or three MAC addresses, once the switch has learned the MAC(s). This was applied in our environment, locking the switch port to one MAC. If a user moves with his PC to another location and switch port, the administrator has to manually release and then relock the switch ports. But because we readily could observe and record traffic on our data and voice links, we could have our hacker computer use a legitimate MAC address. The switch never knew the difference.

•  Management-access restrictions, such as closing out all IP-based management access to the switch (Web and Telnet), allow access only via the serial console port.

•  SNMP traps can be issued for VLAN violations and for any configuration changes.

Our hackers learned quite a bit by querying Avaya's IP phones via SNMP, using the universal default SNMP community name "public." But the phones could not be reconfigured, disabled or otherwise exploited via SNMP sets (writes).

Bottom line

Two of our attack team's main penetration and surveillance tricks that were successful in getting into the Cisco system worked equally well in this Avaya environment. The hackers could readily insert a passive probe into an IP phone station connection, and observe and collect full traffic details. VoIP streams to/from the Avaya 4620 IP phones also were encrypted. The hackers also could insert their own computers, gain access to the voice VLAN and contact other devices on the VLAN - but could not impersonate an IP phone or spoof an IP phone call.

The attack team then uncovered two serious vulnerabilities that could be exploited to disrupt voice communications.

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 two

Avaya took home the lessons it learned from the first round and returned with a more hardened, more secure configuration (see "Avaya maximum-security topology").

Avaya maximum-security topology

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 changes that enhanced security were:

•  Rate limiting of IP traffic by the Summit switch prevented any TCP, UDP or broadcast packet stream from exceeding 1M bit/sec.

•  Individual VLANs per IP phone port were set up. 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 resistant rating for this maximum-security configuration.


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 left 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.

VoIP security special report

Miercom's recently released special report, 2004: A VoIP Secuirty Assessment, includes detailed information on VoIP vulnerabilities overall, attack scenarios and how to best defend against them. In addition, Miercom's program of IP telephony and VoIP security testing is ongoing. Find out about the lastest tests and results, including re-tests of vendors that have patched and otherwise addressed previously exposed vulnerabilities in the report here.

Learn more about this topic

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 with Miercom. Thayer is principal investigator with Canola & Jones, a security research firm based in Mountain View, Calif. They can be reached at, and, respectively.

NW Lab Alliance

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

Archive of Network World reviews

Subscribe to the Product Review newsletter

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2004 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2