Breaking through IP telephony

In tests, Avaya and Cisco attempt to strut VoIP security stuff.

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 importantly, 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. While we invited the top five vendors by VoIP market share to participate, 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 most Secure rating (see rating criteria, below). 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 Resistant rating.

VoIP security rating scale

Overall rating

Maximum impact that assault team could achieve
SecureNo perceptible disruption to voice service.
ResistantOnly minor and/or temporary disturbance(s).
Vulnerable Phone service affecting many phone users could be disrupted for a protracted period, via a sophisticated or coordinated attack.
Open

Phone service affecting most phone users could be significantly disrupted, indefinitely, via a fairly straight-forward assault.

UnsecurePhone system or service affecting all users could be readily and indefinitely disabled.

The ground rules (see below) 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 is important to note that the attacks launched against these products are 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 will not disclose in this story complete details of vendors' specific vulnerabilities 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 (see "Cisco maximum-security topology") - is the most secure that Cisco's collective network security expertise could muster, and employs every defensive weapon in the Cisco arsenal.

Cisco maximum-security VoIP topology

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 also 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:

Ground rules for VoIP security testing

Before the test, these ground rules were adopted as a means of setting a level playing field for consistent testing practices across all vendors tested.
1. The vendor has complete control over the IP telephony environment and underlying network infrastructure — which products to include and how everything would be configured.
2. A midsize, local-only VoIP environ-ment (campus or building) would be simulated. No VoIP traffic would be carried via WAN between remote, distributed locations.
3. After setup, IP telephony and Layer 2/Layer 3 data networking could not be functionally limited because of security settings, including normal IP phone calling out to/from the PSTN.
4. After setup, vendors could not actively manipulate or reconfigure their network. They could, however, continue to passively monitor security alert/ alarm logs.

5. Assaults would all be attempted via these specific attack points:

a. Via an “office-cube” data-LAN port, which the assailant can legitimately access (for example a valid MAC address).

b. Via an “office-cube” IP phone, which the assailant is authorized to use, including the “data switch port” on the back of the phone, for a desktop or laptop. These scenarios represent typical “insider-attack” scenarios.
6. All assaults would employ or be based on tools and attacks that are publicly available via the Internet. No new programming or other unique or custom attacks could be applied.
7. Assailants could not procure or disassemble and dissect a vendor IP hard phone.

•  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 [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:

•  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), and 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 provides some powerful safeguards at the server, including:

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

Bottom line

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 - which might be secure, but not 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 one

The first configuration Avaya submitted for security assessment had a minimal network infrastructure (see "Avaya no-frills VoIP security topology"). 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.

Avaya no-frills VoIP security topology

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, connect 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:

1 2 Page
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies