SIP Phone Attacks

A typical SIP network will contain many SIP phones, perhaps from multiple vendors . SIP phones are vulnerable to a number of attacks, in some cases because of weak security, limited processing power, and lack of protection by dedicated security products (you can't afford to put a SIP firewall in front of every SIP phone).

Attack Target SIP Phones with UDP Floods Using the udpfl ood Tool

Popularity:

9

Simplicity:

9

Impact:

5

Risk Rating:

7

We also used the udpflood tool to target the SIP phones. As with the attacks on the SIP proxies, we sent 1,000,000 packets to each SIP phone directly using the udpflood tool. Running Wireshark on a system bridged between the Ethernet switch and the SIP phone showed that approximately 25 percent to 30 percent of the packets were received. The commands for these attacks used the following basic form:

 ./udpflood eth0 hacker_box SIPPHONE 9 5060 1000000 

We attacked both on-hook and off-hook SIP phones. For each attack, we tested the SIP phone's ability to perform the following functions:

  • User interface usable?   Indicates whether the SIP phone user interface/ buttons were usable. During some attacks, the SIP phone appeared "dead."

  • Make calls?   Indicates whether the SIP phone could make calls.

  • Receive calls?   Indicates whether the SIP phone could receive calls.

  • Media-in usable?   Indicates the quality of inbound media.

  • Media-out usable?   Indicates the quality of outbound media.

  • Recovered after attack?   Indicates whether the SIP phone recovered after the attack was stopped .

The following table summarizes the results for each SIP phone tested:

 

User Interface Usable?

Make Calls?

Receive Calls?

Media-In Usable?

Media-Out Usable?

Recovered After Attack?

Cisco 7940

Yes, but slow

Yes

Yes

No

Partially

Yes

Cisco 7960

Yes, but slow

Yes

Yes

No

Partially

Yes

Grandstream 300

Yes

Yes

Yes

Partially

Partially

Yes

Avaya 4602

No

No

No

N/A

N/A

Yes

Snom 190

No

No

No

N/A

N/A

Yes

In summary, this attack is very effective against all of the SIP phones. The Avaya 4602 and Snom SIP phones are completely unusable. The Cisco SIP phones are able to make and receive calls, but the media isn't usable. The Grandstream SIP phone is able to make and receive calls, and the media is present, but of poor quality

We also used the udpflood tool to target the off-hook SIP phones with an active call in progress. The results are categorized similarly to the previous table.

 

User Interface Usable?

Media-In Usable?

Media-Out Usable?

Recovered After Attack?

Cisco 7940

Yes, but slow

No

Partially

Yes

Cisco 7960

Yes, but slow

No

Partially

Yes

Grandstream 300

Yes

Partially

Partially

Yes

Avaya 4602

No

No

No

Yes

Snom 190

No

No

No

Yes

This attack is also very effective against all of the SIP phones. The Avaya 4602 and Snom SIP phones are completely unusable. The Cisco phones are able to transmit media, but not receive it. The Grandstream SIP phone is able to process inbound and outbound media, but the media quality is poor.

In addition to targeting the signaling ports, you can also target the media ports. The media for a call is carried with the Real-Time Protocol (RTP), which appears on a static or dynamic port. All SIP phones tested allow you to configure a port or range of ports to use. The default ports for each SIP phone are as follows :

  • Cisco 7940 and 7960 SIP phone   Default port range is 16384 to 32766. For each call, the Cisco SIP phone uses a port number that is four greater than that used for the previous call.

  • Grandstream SIP phone   Default port is 5004. The Grandstream phone always uses the set port.

  • Avaya SIP phone   Default port is 16384. The Avaya phone selects a random port that is zero, two, four, six or greater than the default port.

  • Snom SIP phone   Default port range is 49152 to 65535. The Snom SIP phone uses a random port in this range.

For those SIP phones using a dynamic port, you can generally determine the port number by capturing the SIP INVITE request and/or the SIP OK response. The following Wireshark traces show the relevant portions of the SIP/SDP packets that contain the media ports:

 Request-Line: INVITE sip:3000@ser_proxy SIP/2.0      Method: INVITE      Resent Packet: False  Message Header      Via: SIP/2.0/UDP 10.1.101.35;branch=z9hG4bKd3eb18e03c927842      From: "GS 2" <sip:3500@ser_proxy>;tag=6a81db91b12d3fac      To: <sip:3000@ser_proxy>      Contact: <sip:3500@10.1.101.35>      Supported: replaces      Call-ID: 1b605490cdcfb164@10.1.101.35      CSeq: 6891 INVITE      User-Agent: Grandstream BT110 1.0.8.12      Max-Forwards: 70      Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE      Content-Type: application/sdp      Content-Length: 384  Message body      Session Description Protocol          Session Description Protocol Version (v): 0          Owner/Creator, Session Id (o): 3500 8000 8000 IN IP4 10.1.101.35          Session Name (s): SIP Call          Connection Information (c): IN IP4 10.1.101.35          Time Description, active time (t): 0 0  Media Description, name and address (m):   audio 5004 RTP/AVP 0 8 4 18 2 9 111 125  Session Initiation Protocol     Status-Line: SIP/2.0 200 Ok         Status-Code: 200         Resent Packet: False     Message Header         Via: SIP/2.0/UDP ser_proxy;branch=z9hG4bKa73e.301b21f1.0         Via: SIP/2.0/UDP 10.1.101.35;branch=z9hG4bKd3eb18e03c927842         Record-Route: <sip:ser_proxy;ftag=6a81db91b12d3fac;lr=on>         From: "GS 2" <sip:3500@ser_proxy>;tag=6a81db91b12d3fac         To: <sip:3000@ser_proxy>;tag=75jmhn8jwu         Call-ID: 1b605490cdcfb164@10.1.101.35         CSeq: 6891 INVITE         Contact: <sip:3000@10.1.101.30:2051;line=xuahyhk7>         User-Agent: snom190/3.60x         Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,          PRACK, MESSAGE, INFO         Allow-Events: talk, hold, refer         Supported: timer, 100rel, replaces         Content-Type: application/sdp         Content-Length: 218  Message body      Session Description Protocol         Session Description Protocol Version (v): 0         Owner/Creator, Session Id (o): root 1711562323 1711562324 IN          IP4 10.1.101.30         Session Name (s): call         Connection Information (c): IN IP4 10.1.101.30         Time Description, active time (t): 0 0  Media Description, name and address (m):   audio 60722 RTP/AVP 0 125  

Note that this can be tricky for some SIP proxies that operate as B2BUAs, including Asterisk. In this case, media ports are established initially with each SIP phone and the SIP proxy/B2BUA and then changed so that the two SIP phones exchange media directly with each other.

Once you have identified the ports on either or both SIP phones, use the udpflood tool. As with the other attacks on the SIP phones, we used the udpflood tool to send 1,000,000 packets directly to each SIP phone. Running Wireshark on the system bridged between the Ethernet switch and the SIP phone showed that approximately 25 percent to 30 percent of the packets were received. The commands for these attacks used the following basic form:

 ./udpflood eth0 hacker_box SIPPHONE 9 RTP_PORT 1000000 

The following table summarizes the results for each SIP phone tested:

 

User Interface Usable?

Media-In Usable?

Media-Out Usable?

Recovered After Attack?

Cisco 7940

Yes, but slow

No

Partially

Yes

Cisco 7960

Yes, but slow

No

Partially

Yes

Grandstream 300

Yes

Partially

Partially

Yes

Avaya 4602

No

No

No

Yes

Snom 190

No

No

No

Yes

In summary, this attack is very effective against all of the SIP phones. The Avaya 4602 and Snom SIP phones are completely unusable. The Cisco SIP phones are able to transmit media, but not reliably receive it. The Grandstream SIP phone is able to process inbound and outbound media, but the quality of the inbound media is poor.

Attack Target SIP Phones with UDP Floods Using the rtpfl ood Tool

Popularity:

9

Simplicity:

9

Impact:

5

Risk Rating:

8

We modified the udpflood tool to generate RTP. The new rtpflood tool builds a UDP packet containing the proper RTP header and 160 bytes of payload. The payload is random values. The rtpflood tool does not spoof the source MAC address, because MAC addresses are not a security factor for SIP. Spoofing the MAC address is not necessary to trick any of the SIP phones into processing the flood packets. It also does not spoof the RTP sequence numbers , timestamps, or SSRC. More sophisticated tools are described in Chapter 13. The usage information for this tool is as follows:

 rtpflood: ./rtpflood EthernetInterface SourceName DestinationName SourcePort DestinationPort NumPackets Usage Example: ./rtpflood eth0 5000 hacker_box SIP_phone 1000000 Mandatory parameters: EthernetInterface - the Ethernet interface to write to. SourceName  host name or IPV4 address of attacking system. DestinationName  host name or IPV4 address of the target system. SourcePort - IP port of the attacking system. DestinationPort  IP port of the target system that is processing RTP. 

The RTP is carried on a static or dynamic port. All SIP phones tested allow you to configure a port or range of ports to use. The default ports for each SIP were covered previously. For those SIP phones using a dynamic port, you can generally determine the port number by capturing the SIP INVITE request and/or the SIP OK response. An example of this was also provided previously.

Note that this can be tricky for some SIP proxies that operate as B2BUAs, including Asterisk. In this case, media ports are established initially with each SIP phone and the SIP proxy/B2BUA and then changed so that the two SIP phones exchange media directly with each other.

Once you have identified the ports on either or both SIP phones, use the rtpflood tool. We sent 1,000,000 packets to each SIP phone directly using the rtpflood tool. Running Wireshark on a system bridged between the Ethernet switch and the SIP phone showed that approximately 25 percent to 30 percent of the packets were received. The commands for these attacks used the following basic form:

 ./rtpflood eth0 hacker_box SIPPHONE 9 RTP_PORT 1000000 

The following table summarizes the results for each SIP phone tested:

 

User Interface Usable?

Media-In Usable?

Media-Out Usable?

Recovered After Attack?

Cisco 7940

Yes, but slow

No

Partially

Yes

Cisco 7960

Yes, but slow

No

Partially

Yes

Grandstream 300

Yes

Partially

Partially

Yes

Avaya 4602

No

No

No

Yes

Snom 190

No

No

No

Yes

In summary, this attack is very effective against all of the SIP phones. The Avaya 4602 and Snom SIP phones are completely unusable. The Cisco SIP phones are able to transmit media, but not reliably receive it. The Grandstream SIP phone is able to process inbound and outbound media, but the quality of the inbound media is poor.

Attack Target SIP Phones with INVITE Floods Using the invitefl ood Tool

Popularity:

9

Simplicity:

7

Impact:

5

Risk Rating:

7

This set of attacks disrupts service for a SIP phone. A number of attacks are possible, including those done through the SIP proxy and those targeting the SIP phone directly. For these attacks, we targeted the SIP phone directly. You can perform these attacks through a SIP proxy, but direct attacks against the SIP phone are more interesting because the SIP proxy is not aware of the attacks.

We first flooded each SIP phone with 1,000,000 INVITE requests. For these attacks, running Ethereal on the system bridged between the Ethernet switch and the SIP phone showed that approximately 25 percent to 30 percent of the packets were received. The commands used for these attacks varied, due to some phones being stricter about the structure of the INVITE requests . For each phone, the commands used were

 Grandstream and Cisco: ./inviteflood eth0 3500 10.1.101.2 10.1.101.35 1000000 ./inviteflood eth0 4000 10.1.101.2 10.1.101.40 1000000 Avaya: ./inviteflood eth0 4500 10.1.101.2 10.1.101.45 1000000 i 10.1.101.2 S 5060 Snom: ./inviteflood eth0 3000 10.1.101.2 10.1.101.30 1000000 i 10.1.101.2 D 2051  l xuahyhk7 

The Grandstream and Cisco SIP phones are easy to trick into accepting the INVITE requests. If you send a simple INVITE request to the Avaya SIP phone, it starts to ring (it "chirps"), but stops when the hacker_box responds to the TRYING/RINGING response with an ICMP Destination Unreachable message. If you pass it the source IP address of the SER SIP proxy and its SIP port number, then the attack works. The Snom phone is the most difficult to trick. It tells the SIP proxy to use port 2051 (by default) in its REGISTER request. It also passes a tag of the form line=random string , which must be included in both the INVITE request heading line and the To: line. We verified that the string used is static and unique for each SIP phone. So for this attack to work against the Snom SIP phone, you must capture this string.

We attacked both on-hook and off-hook SIP phones. For each attack, we tested the SIP phone's ability to perform the following functions:

  • Basic behavior   Indicates whether the SIP phone just rings or is completely dead.

  • User interface usable?   Indicates whether the SIP phone user interface/ buttons were usable. During some attacks, the SIP phone appeared "dead."

  • Receive calls?   Indicates whether the SIP phone could receive calls. Note that it is not applicable to test whether the SIP phone can make calls, since it is constantly ringing with inbound calls.

  • Recovered after attack?   Indicates whether the SIP phone recovered after the attack was stopped.

The following table summarizes the results for each SIP phone tested:

 

Basic Behavior

User Interface Usable?

Receive Calls?

Recovered After Attack?

Cisco 7940

Both lines ring. When answered , there is no media. When put on-hook, the lines ring again.

Yes, but slow

No

Yes

Cisco 7960

Both lines ring. When answered, there is no media. When put on-hook, the lines ring again.

Yes, but slow

No

Yes

Grandstream 300

Rings. When answered, there is no media. When put on-hook, it rings again.

Yes

No

Yes

Avaya 4602

Dead.

No

No

Yes

Snom 190

Rings. When answered, there is no media. When put on-hook, it rings again.

No

No

No

The Snom SIP phone seems to queue up the INVITE requests and attempts to process calls well after the attack has ceased. Note that the Snom SIP phone has to be reset to eliminate the calls.

Attack Target SIP Phones with INVITE Floods Using SiVuS

Popularity:

7

Simplicity:

5

Impact:

5

Risk Rating:

6

In addition to targeting SIP proxies, SiVuS can be used to target SIP phones. By building a request and sending one or many to a SIP phone, you can disrupt service for the various SIP phones. You can send requests through a SIP proxy or to most of the SIP phones directly. (SiVuS does not allow you to specify the "line" parameter, which is needed to target the Snom SIP phones.) Figure 12-14 illustrates an example in which 1,000,000 INVITE requests are sent to the Grandstream SIP phone.

image from book
Figure 12-14: Targeting SIP phones with INVITE fl oods using SiVuS

While SiVuS is not capable of generating requests fast enough to affect the SIP proxies, it is able to disrupt service for the SIP phones. The following table summarizes the results for each SIP phone tested:

 

User Interface Usable?

Make Calls?

Receive Calls?

Media-In Usable?

Media-Out Usable?

Recovered After Attack?

Cisco 7940

Yes, but slow

Yes

Yes

No

Partially

Yes

Cisco 7960

Yes, but slow

Yes

Yes

No

Partially

Yes

Grandstream 300

Yes

Yes

Yes

Partially

Partially

Yes

Avaya 4602

No

No

No

N/A

N/A

Yes

In summary, this attack is very effective against all of the SIP phones. The Avaya 4602 SIP phone is completely unusable. The Cisco SIP phones are able to make and receive calls, but the media is not usable. The Grandstream SIP phone is able to make and receive calls and the media is present, but the media quality is poor.

Of course, you can also use SiVuS for other disruption of service attacks, such as sending an INVITE request to all of the SIP phones, causing them all to start ringing. This attack is described in detail in the next section.

Attack Disrupt SIP Phones and Harass Users Using the invitefl ood Tool

Popularity:

7

Simplicity:

9

Impact:

5

Risk Rating:

7

You can also use the inviteflood tool to disrupt SIP phone operation by causing them to start calls and ring continually. While this attack does not totally disrupt the SIP phones, it does render them useless. This attack can also be used to harass or irritate one or more users, whose SIP phones will continually ring. The best way to execute this attack is to target the SIP phones directly, which has the advantage of not alerting the SIP proxy. The inviteflood tool has an additional parameter, -s , which can be used to set the number of seconds between transmitted INVITE requests. By setting this value to 10 or 20 seconds, you can cause a SIP phone to ring and then ring again a few seconds after the user picks up the call. The command invocations are similar to those used in the earlier section, "Other SIP Proxy Disruption Attacks Using the inviteflood Tool."

 Grandstream and Cisco: ./inviteflood eth0 3500 10.1.101.2 10.1.101.35 100 s 20 ./inviteflood eth0 4000 10.1.101.2 10.1.101.40 100 s 20 Avaya: ./inviteflood eth0 4500 10.1.101.2 10.1.101.45 100 i ser_proxy S 5060  s 20 Snom: ./inviteflood eth0 3000 10.1.101.2 10.1.101.30 100 i ser_proxy D 2051 l line=xuahyhk7 s 20 

Each of these commands sends 100 INVITE requests to a SIP phone, with a 20-second interval between the requests. All of these commands cause the SIP phone to ring. When the SIP phone is answered and hung up, the SIP phone rings again in a few seconds. This continues for approximately 30 minutes. Note that the Snom SIP phone queues up calls, so if the calls are not answered, it ends up with 30 queued calls. You would have to answer and terminate 30 calls or reset the SIP phone to mitigate the attack.

This attack has quite a few interesting permutations . The following command causes a SIP phone to ring once a minute for an entire workday :

 ./inviteflood eth0 4000 10.1.101.2 10.1.101.40 500 s 60 

You could also execute multiple commands to cause any or all SIP phones to start ringing or easily write a script to read extensions from a file and target hundreds or thousands of SIP phones as well.

These sorts of attacks are particularly nasty because the packet attack rate is very low and is very unlikely to be detected by a LAN switch or firewall/IDPS. Also, because the attacks bypass the SIP proxy, there will be no alert that the attack is going on.

Attack TCP SYN Flood Attacks

Popularity:

9

Simplicity:

8

Impact:

7

Risk Rating:

8

You can also generate TCP SYN flood attacks against SIP phones. Because TCP isn't commonly used yet (and isn't supported by all the SIP phones), we did not perform actual tests. We did test TCP SYN flood attacks against Avaya IP phones in Chapter 8, however. Refer to that chapter for the results.

Impact and Probability of Occurrence

These attacks partially or fully disrupt operation of your SIP phones. This means that users who are targets of these attacks will not be able to make or receive phone calls reliably, affecting key users, such as executives, sales, customer support, and so on. These attacks can have a serious impact on your business especially true considering that dropping even a few calls is unacceptable in most enterprises .

For these attacks to take place, the attacker needs access to your internal network. Access can occur as a result of a user downloading a worm or virus with the ability to perform a UDP or INVITE flood or if the attacker gains access to the internal network through another means. The INVITE flood attack is also possible from a public network if you use SIP trunks for access to your voice service provider.

Countermeasures

You can employ several countermeasures to address these attacks against SIP phones. These are described next.

Countermeasurs Use TCP/IP for SIP Connections

RFC 3261compliant SIP phones must support both UDP and TCP. When TCP is used, the SIP phones generally establish persistent connections with the SIP proxy. Because of features inherent in TCP, such as the use of sequence numbers, it is more difficult for an attacker to trick a SIP phone into accepting packet floods. The SIP phone will still consume resources processing the flood packets, but it will be able to discard them at a lower protocol layer, preventing the SIP phone from ever "seeing" an INVITE flood. Note that if you use TCP for a SIP phone, be sure to disable use of UDP. Some SIP phones will, by default, accept calls for both protocols.

As discussed in Chapter 6 and mentioned previously, attacks against TCP are still possible.

When using TCP, you can also employ Transport Layer Security (TLS) (http://www.rfc.net/rfc2246.html). TLS uses encryption to provide privacy and strong authentication. TLS prevents attackers from eavesdropping on signaling. TLS also provides strong authentication, which makes it very difficult (if not impossible ) for an attacker to trick a SIP phone into accepting packet floods. As with TCP, this means that spoofed packets will be discarded at the TLS layer and the SIP phone application will not "see" an INVITE flood. Of course a SIP phone may still be incapacitated, simply because it is seeing so many packets. TLS is superior to TCP alone, because it uses encryption for authentication, thereby making it even more difficult to spoof packets.

TLS is used to secure single connections between SIP proxies and SIP phones. TLS is not an end-to-end protocol. For a call to be secure, you must use TLS for all the connections between SIP endpoints participating in the call. TLS also, of course, requires that you trust the SIP proxies that interact with the call.

Unfortunately, not all SIP phones support TCP. For example, the Cisco SIP phones do not support TCP/IP. Several of the SIP phones do not support TLS. Unfortunately, TLS support is not required for SIP phones.

Countermeasurs Use VLANs to Separate Voice and Data

Most enterprise-class SIP systems use VLANs to separate voice and data. While VLANs are designed primarily to assist with performance, they also provide a layer of separation and security. With VLANs and properly configured LAN switches, you can block a DoS attack from a compromised PC. MAC filtering and 802.1x port authentication are additional countermeasures.

It is possible to get flood packets onto the voice VLAN if a rogue PC is added to the LAN switch port configured for the voice VLAN.

Countermeasurs Use DoS Mitigation in LAN Switches

Many LAN switches offer DoS detection and mitigation. Use this feature to detect various types of floods and prevent the packets from reaching the target SIP phone.

Countermeasurs Change Well-Known Ports

The SIP phones allow the default SIP port of 5060 to be changed. While this is a "security through obscurity" technique, it does provide some limited protection. Note that some of the SIP phones, such as the Snom, already use a different port by default.

Countermeasurs Use SIP Firewalls

A SIP firewall can be deployed to inspect all signaling sent to the SIP phone. The SIP firewall can detect various forms of attacks, including UDP and INVITE floods, and mitigate them. Of course, you will have to deploy a SIP firewall somewhere in the network that allows it to see traffic targeted at the SIP phone.

Attack Targeting a Media Gateway

Popularity:

7

Simplicity:

9

Impact:

10

Risk Rating:

9

A media gateway converts between VoIP and TDM calls. Media gateways are present in virtually all VoIP systems to allow communication with analog devices and the PSTN. Single port/low density media gateways are commonly used to connect analog phones and fax machines to a VoIP network.

Media gateways are also almost always used to connect a campus VoIP/SIP network to the PSTN. These critical, high-density media gateways are used to convert internal VoIP/SIP calls to TDM, so they can be carried over the PSTN. Media gateways will continue to be used for some time, until enterprises use SIP trunks to connect to the public voice network. Figure 12-15 illustrates the operation of a media gateway.

image from book
Figure 12-15: Operating a media gateway in a SIP network

Media gateways are configured in different ways. Some may not have "public" signaling interfaces to the LAN because they don't exchange signaling with SIP phones. Media gateways must, however, always have "public" media interfaces because SIP phones communicate with them in order to send media to the PSTN for external calls. A variety of signaling protocols are used for media gateways, including MGCP, H.323, and SIP. If the media gateway has a public SIP interface to the LAN, then it can be attacked with the same tools used for SIP proxies and SIP phones. These attacks can be lethal because they can tie up resources and trunks used for access to the public network, possibly preventing inbound and outbound calls.

We did not have a media gateway in our test bed, so we did not perform actual testing. However, we provide the following commands, which you can use to attack media gateways. First, you can use the udpflood tool to attack the SIP signaling port:

 ./udpflood eth0 hacker_box media_gateway_IP 5060 5060 1000000 

If you observe the RTP ports used for one or more of the media sessions, you can target them as well using either the udpflood or rtpflood tool:

 ./udpflood eth0 hacker_box media_gateway_IP 9 media_port1 1000000 ./udpflood eth0 hacker_box media_gateway_IP 9 media_port2 1000000 ./udpflood eth0 hacker_box media_gateway_IP 9 media_portx 1000000 .rtpflood eth0 hacker_box media_gateway_IP 9 media_port1 1000000 .rtpflood eth0 hacker_box media_gateway_IP 9 media_port2 1000000 .rtpflood eth0 hacker_box media_gateway_IP 9 media_portx 1000000 

You can also use the inviteflood tool:

 ./inviteflood eth0 1-900-222-333 10.1.101.1 media_gateway_IP 1000000 


Hacking Exposed VoIP. Voice Over IP Security Secrets & Solutions
Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions
ISBN: 0072263644
EAN: 2147483647
Year: 2004
Pages: 158

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net