Breaking Through IP Telephony

Editor's note: This review originally ran in Network World in May 2004.

Can you hacker-proof your IP telephony network? The short answer -- as demonstrated in the first-ever public test on this topic -- is, yes, pretty much. But it strongly depends on whose IP PBX you use, and more important, whether you're willing to spend the dollars and the time it takes in terms of network security planning, network and personnel resources, and extra security gear.

In our tests, we developed a plan for realistically assessing how secure vendors' IP telephony packages are -- or aren't -- against a determined, malicious attacker. We invited the top five vendors by VoIP market share to participate, but only Cisco and Avaya stepped up to the challenge.

Cisco's "maximum-security" VoIP configuration -- a midsize CallManager-based system, with call control, voice mail, gateway; a Catalyst 4500- and 6500-based Layer 2/Layer 3 infrastructure; a copious supply of intrusion-detection system (IDS) and PIX firewall security add-ons; plus a half-dozen Cisco security gurus supporting the test -- earned our highest rating, Secure (see rating criteria, QuickLink 51591). Our attack team couldn't disrupt, or even disturb, Cisco's phone operations after three days of trying.

Avaya submitted two configurations: A no-frills, out-of-the-box Avaya IP telephony deployment with no extra-priced security options; and a maximum-security alternative featuring the same VoIP gear but with an added firewall and Layer 2/Layer 3 infrastructure switches from Extreme Networks. Security weaknesses earned the basic Avaya configuration a so-so Vulnerable rating, while the hardened package fared better with an overall rating of Resistant.

The ground rules (see QuickLink 51592) imposed some limitations on the four-member assault team. For example, only hacker tools and attacks that were available on the Internet could be used. Attacks had to be launched via an end-user data port or IP phone connection, as if the hacker had access to a standard office cube; attackers could not disassemble or dissect the vendor's IP phone, and so on.

The objective was to disrupt phone communications. Via the data and IP phone connections, the attack team used scanning tools and other techniques to see and learn what they could of the topology. The attack team was told nothing of the vendor's configuration beforehand. After discerning and identifying "targets," the hackers then systematically launched dozens of attacks, at times in combinations concurrently.

Given the limits set by our ground rules and the duration of the tests, it's important to note that the attacks launched against these products were not as severe as those that could be encountered in an actual deployment. We consulted with a half-dozen security experts regarding these attacks, and they concluded that the attacks were of moderate intensity.

We won't disclose in this story complete details of vendors' specific vulnerabilities that were uncovered and exploited, so as not to put customers using these products at risk. These exploits are therefore discussed in general terms.

Like a Rock

Cisco proved it could build a VoIP network that a sophisticated hacker assault team could not break or even noticeably disturb. The elaborate IP-telephony package -- with underlying Layer 2 and Layer 3 infrastructure and assorted security add-ons -- is the most secure that Cisco's collective network security expertise could muster and employs every defensive weapon in the Cisco arsenal.

The Cisco topology tested certainly represents more security options and stricter security settings than most users currently employ, but all are available today for a price. The optional components included two stand-alone PIX firewalls (about $8,000 each), another firewall on a blade in the backbone Catalyst 6500 (about $35,000), an IDS blade in the 6500 (about $30,000), an entirely separate, out-of-band management subnet and various security-management applications. The price for the firewall and IDS pieces came to slightly more than $80,000. Cisco says, though, that it threw in systems that it could readily get its hands on, and that the same job could be done with less expensive firewall and IDS models from Cisco.

The firewalls brought some very useful, high-level security features to the table. One is the notion of trusted vs. untrusted sides -- and the untrusted interfaces were always pointed toward our hackers. Another is a stateful understanding of protocols, so that only specific VoIP protocols required for VoIP were allowed, with requests and responses passing only in the appropriate directions. Other firewall features that came into play during this test included the following:

• Stateful inspection of VoIP call control and the ability to network address translation and tunnel call control through the firewall.
• TCP intercept, which makes sure TCP connections are completed. This can prevent certain denial-of-service (DoS) assaults on the CallManager.
• Secure Skinny Call-Control Protocol (Secure SCCP) support. This is the newer, more secure form of Cisco's proprietary SCCP that the company used in this VoIP network. Secure SCCP uses a TCP connection rather than User Datagram Protocol (UDP) and encrypts call control information.

Enter CallManager

Version 4.0 of CallManager, which handles call control and is the heart of Cisco's IP telephony package, includes some new security-related features. Key among them is the company's first VoIP encryption implementation. At this time, voice-stream (Real-time Transfer Protocol, or RTP) encryption is supported only on Cisco's newer 7970 IP phone sets. The latest CallManager also has been additionally hardened, along with the underlying Windows 2000 operating system, according to Cisco. For our tests, this meant that open ports were closed and unnecessary services disabled.

An impressive array of network self-defense features is included in the Catalyst IOS versions tested. Specifically, we had IOS 12.2(17b)sxa on a core Catalyst 6500, and IOS 12.1(20)ew on an access Catalyst 4500. These capabilities did more to thwart our assaults than any other component in the Cisco topology because they were the first line of defense. They include the following:

• Traffic policing and committed access rate, which were very successful in fending off our DoS assaults.
• Layer 2 port security, which restricts the number of media access control (MAC) addresses on a port.
• Layer 2 Dynamic Host Configuration Protocol snooping, which prevents dynamic host configuration protocol exhaustion attacks.
• Dynamic Address Resolution Protocol inspection, which stops ARP poisoning and ARP spoofing attacks. This, too, frustrated a number of our attack team's more insidious assaults.
• IP Source Guard, which prevents impersonation attacks.
• Virtual LAN (VLAN) access control lists, which restrict the traffic that can reach IP phones.

Cisco Security Agent (CSA) is a host-based intrusion-prevention system (IPS) that is now an integral security component in CallManager IP telephony servers. It was also on Cisco's Unity voice mail server and all other Win 2000 servers (seven CSA agents in all) deployed throughout Cisco's network topology. The CSA agent runs automatically and unattended, and it provides some powerful safeguards at the server, including these:

• Buffer overflow protection, which protects the server's protocol stack from attacks involving malformed data packets.
• Network worm and Trojan prevention (not tested).
• Prevention of unauthorized application from running.
• Protection against syn flood attacks -- a family of DoS attacks against the server's TCP processing.
• Detection of port scans, which all hackers employ to determine vulnerabilities based on a server's responses to specific services and port numbers.

After three days, the attack team could not find a perceptible disruption to phone communications. We only had two minor concerns about the Cisco system as tested.

First, our hackers could readily insert a passive probe into an IP phone station connection. From that vantage point they could observe and collect full traffic details -- protocols, addresses, and even capture RTP, which is the VoIP protocol that runs above UDP and carries all voice samples in all VoIP systems. VoIP streams to/from Cisco 7970 phones can be 128-bit encrypted, however. Our hacker team readily acknowledged that it could not hope to decrypt those streams.

Second, with the network information collected via the inserted probe, the hackers could insert their own computer, gain access to the voice virtual LAN and send traffic to other devices on the VLAN. They could not impersonate an IP phone or spoof an IP phone call, however. With all the other controls in place, they could not further exploit the system.

Achieving what Cisco did -- orchestrating effective security across so many layers and platforms -- is no mean feat. The subtle inter-relationships and correct setup of all these security pieces is daunting. But despite all the Cisco security experts on hand to tune, monitor and configure the various systems, we still uncovered configuration problems.

One of the firewalls as configured by Cisco was passing no traffic in either direction -- that might be secure, but it isn't very practical. Also a vulnerable service mistakenly was left running on one node. While these things, and others, were promptly fixed, the point is that even the best laid security plan can be affected, even compromised, because of improper or incorrect settings.

Avaya, Part 1

The first configuration Avaya submitted for security assessment had a minimal network infrastructure. In fact, there was no Layer 3 network infrastructure at all. All IP communications traversed a single, flat, switched Layer 2 network, segregated into two isolated VLANs, one for voice and the other for data. No firewalls were employed.

Despite this minimal network infrastructure, the Avaya VoIP package does feature various inherent security mechanisms. Consider the VoIP infrastructure, for example:

• Call control, in the form of a set of redundant S8700 Media Servers, connects the call control to a private LAN, which isolates and insulates them from the production network. The servers connect only to a specialized IP System Interface module, running Version 5 housed in the G650 Media Gateway chassis.
• Voice mail connects via analog trunks, which Avaya says is a plus when there are problems with or threats promulgating from the IP network. Even if all phones are IP, calls still can be received from the public switched telephone network and routed to voice mail, regardless of the state of the IP network.
• Rather than connect via the Internet, Avaya endorses a secure-modem connection for remote diagnostics and testing. But while this certainly avoids IP-based assaults, it hardly represents the state of the art in data networking or security.
• System software uploads involve a two-step process: The administrator downloads new software onto a laptop and then uploads the software from the laptop into the call-control system.

However, the Avaya topology call-control information is not encrypted, and the passwords used for IP phone authentication are not very strong.

The Avaya Cajun P333 switch does offer some security features. Those applied in our test environment were the following:

• 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 and 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 they 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.