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.
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.
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
EAN: 2147483647
Pages: 158