Exploiting the Network

This section goes along with the networking-based attacks we outlined in Chapters 4, 5, and 6.

Attack Application Port Flooding Attacks

Popularity:	9
Simplicity:	8
Impact:	9
Risk Rating:	9

Chapter 12 covers testing of the SIP and RTP application ports. Please refer to that chapter for an introduction to flood-based disruption-of-service attacks. Chapter 12 also describes command-line usage of the udpflood tool described later.

For our purposes, we configured an IAX channel between the Asterisk IP PBX's to facilitate interdomain calls. We then used the udpflood tool to attack the IAX channel port (4569) of the Asterisk IP PBX running at 10.1.101.2. The attacks were launched before the call was established and during the call.

We ran a minimum of ten trials in each scenario. The attack consisted of transmitting a flood of 500,000 UDP packets from the hacker box PC connected to the same switch as the other endpoints/servers. Each packet in the flood was identicalthey were approximately 1400 byte datagrams. For each trial, a call was originated from a SIP phone served by the Asterisk IP PBX not under attack (Domain 1) to an endpoint served by the Asterisk IP PBX under attack in Domain 2 (refer to Figure 9-2 for the test configuration). The originating and terminating SIP phones, were from different manufacturers and varied during the trials. The Asterisk IP PBXs remained in their B2BUA roles during interdomain calls over the IAX channel. SIP signaling from an endpoint to its respective Asterisk IP PBX was translated to the IAX protocol signaling exchanged between the Asterisk IP PBXs over the interdomain IAX channel, as necessary. RTP (audio) tunneled through the IAX channel between the Asterisk IP PBXs using a G.711 codec, and the RTP exchanged between an Asterisk IP PBX and its endpoint varied. We observed use of the G.711 and the GSM codecs. When the G.711 codec was not used for upstream or downstream audio exchange between an endpoint and its serving Asterisk IP PBX, that Asterisk IP PBX had to perform transcoding of the audio to and from G.711.

For the trials under the first scenario, we always delayed originating the interdomain call until the attack was already well underway (in other words approximately 100,000 packets). For the trials under the second scenario, the call was already established (several seconds) before the attack was launched. The usage for the udpflood tool is as follows :

 ./udpflood EthernetInterface SourceName DestinationName SourcePort DestinationPort NumPackets 

We used the following invocation of udpflood for all trials:

 ./udpflood eth0 10.1.101.1 10.1.101.2 4569 4569 500000 

The tool was instructed to use the IP address of the Domain 1 Asterisk IP PBX as the source IP address.

For the first scenario, none of the calls failed to connect while the attack was underway, and there were no calls dropped as a consequence of the attack. Audio, however, degraded seriously after approximately 100,000 packets were transmitted during a call. For the first scenario, the audio degraded approximately 200,000 packets into the attack when we judged it to be below a level where a conversation could be held effectively. Audio delay and audio dropout were significant in some trials (for example, except for occasional blips, the audio essentially ceased at the earpiece of the endpoint in the domain under attack). Until the attack was completed, the audio remained degraded.

At that point, however, normal audio exchange resumed almost immediatelyexcept when an endpoint in a trial was one of the Cisco IP phones (7940 or 7960). The audio presented at the earpiece of a Cisco phone at the completion of the attack was usually delayed one to two seconds from the utterance of the audio to the mouthpiece of the other phone in the trial. It didn't seem to matter whether the Cisco endpoint was served by the domain being attacked (Domain 2) or in the calling domain (Domain 1). The delay improved slowly following the completion of the attack, and after approximately one minute, it was undetectable.

Countermeasurs Network DoS Attack Countermeasures

There are several countermeasures you can employ to control and/or protect the open ports on an Asterisk system. These are covered in the following sections.

Use a Firewall to Protect the IP PBX

You can program a firewall to protect access to the Asterisk IP PBX. This will help prevent attackers from accessing or attacking open ports.

In addition to a traditional firewall, you can deploy application-layer or VoIP firewalls. VoIP firewalls are available from several vendors , including SecureLogix (http://www.securelogix.com), Sipera (http://www.sipera.com), Borderware (http://www.borderware.com), and Ingate (http://www.ingate.com). Some traditional firewalls, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS) also provide support for VoIP. Note, however, that at this time, none of these products provides in-depth analysis of IAX signaling to detect attacks.

Network-Level DoS Mitigation

As with any IP-enabled device, LAN-based DoS limits exist with the DoS protection and mitigation mechanisms a product can implement. Thereafter, network-based protection mechanisms must be implemented to mitigate and/or prevent such flooding-based attacks.

Attack Denial of Service (Crash) and OS Exploitation

Popularity:	9
Simplicity:	8
Impact:	8
Risk Rating:	8

Because the Asterisk IP PBX is software, it is the responsibility of the person installing Asterisk to ensure that the underlying platform is secure. In the case of a distributed configuration, this extends to all of the IP PBXs' platforms and supporting network infrastructure.

The operating system and how well it is hardened affects which ports are seen and whether or not they can be exploited. Because this is completely implementation dependent, it doesn't make sense to probe these ports or make assumptions about what vulnerabilities might exist.

Countermeasurs Denial of Service (Crash) and OS Exploitation Countermeasures

There are several countermeasures you can employ to protect the underlying operating system.

Harden Operating System and Monitor for Known Vulnerabilities/Patch Management

There are a number of books and other references that you can use to help to harden various operating systems, such as Linux. Digium also provides a commercial version of the software, Asterisk Business Edition, that includes its own Linux distribution, installer, and basic configuration, making the setup process somewhat simpler. Digium also provides warranty and customer support.

Network Intrusion Prevention Systems

Network-based Intrusion Prevention Systems (NIPSs) are inline network devices that detect and block attacks at wire speed. A NIPS can be deployed in a network in much the same way as a switch or a router. The NIPS inspects each packet that passes through it, looking for any indication of a malicious exploitation of a vulnerability.

When the NIPS does detect an attack, it blocks the corresponding network flow. As an element of the network infrastructure, it must also identify attacks without blocking legitimate traffic.

NIPSs also buy IT administrators time to patch enterprise-wide by providing a sort of virtual patch for any exploits that may emerge soon after a new vulnerability is discovered in the public domain.

There are a plethora of NIPS vendors, including

• Cisco Systems

• Forescout Inc.

• Fortinet Inc.

• Internet Security Systems

• Juniper Networks

• Lucid Security

• McAfee

• NFR Security

• NitroSecurity Inc.

• Panda GateDefender Integra

• Radware

• Refl ex Security

• SecureWorks

• Third Brigade

• TippingPoint

• Top Layer

Attack Eavesdropping and Interception Attacks

Popularity:	5
Simplicity:	7
Impact:	7
Risk Rating:	6

As you remember from Chapters 5 and 6, we demonstrated a variety of attacks that took advantage of weaknesses in network design and architecture in order to eavesdrop and alter VoIP signaling and conversations. These attacks, along with Cisco network-specific countermeasures, are also covered in Chapter 7. Virtually all of the attacks described in these chapters are also possible in an Asterisk environment, unless the countermeasures are followed.

IAX does not encrypt the media path or headers between endpoints. This means an attacker with access to the network where IAX is transmitted can see both signaling headers and media.

Asterisk also does not support encryption of SIP or H.323 signaling. Again, an attacker with access to the network where SIP or H.323 is transmitted will see all the signaling.

Some of the SIP phones support signaling or media encryption. However, since Asterisk does not support encryption (at least at this time), it isn't usable.

Countermeasurs Eavesdropping and Interception Countermeasures

You can use a Virtual Private Network (VPN) to encrypt IAX communications between two instances of Asterisk IP PBXs.