Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)

PART IV. UC SESSION AND APPLICATION HACKING

CHAPTER 15. SIGNALING MANIPULATION

Wow, I can’t close a sale, my contact center manager is totally mad at me, and I’m going to lose my job. It seems like every time I get an inbound sales prospect, the phone rings once and when I pick it up, no one is there. Everyone else in our contact center has been meeting quotas, and it seems like the new guy in the cubicle next to me, Frederick, is getting twice as many calls as me. This has been going on since he started working here. I talked to the network administrator about it, but he couldn’t find any problems. I wonder if Frederick is up to something.

—A frustrated contact center employee who is the target of a registration addition attack

Throughout the book we have covered several forms of service disruption—from telephony denial of service (TDoS) calls to malformed packets or packet floods to disrupt service for UC systems and endpoints. In this chapter, we will cover attacks where an attacker manipulates the SIP signaling of a call to disrupt the UC service for targeted users. Similar to the other attacks we have covered, these attacks are easy to execute and can be very disruptive. We focus on SIP¹, but any UC signaling system can be manipulated, especially if the protocol is unencrypted and using UDP for transport. Our focus is on SIP because it is such a common protocol and there are many manipulation tools available. Keep in mind that similar manipulation is possible for other signaling protocols such as Cisco’s SCCP (although there are far fewer tools).

Manipulation can come in several forms. First, the UC endpoint registration process can be manipulated, in the sense that registrations can be removed, added, or hijacked to another endpoint. This will affect how incoming calls are received. Similar attacks can be performed with redirection manipulation. Sessions can also be manipulated by injecting SIP BYEs into the network. All of these attacks are covered in the following sections.

Note

We use the term “endpoint” rather than “phone” because although the examples in this chapter demonstrate attacks against phones, they can easily be used to attack any SIP-based endpoint, such as a hardphone, softphone, videophone, or messaging client.

We used the same SIP testbed used in Chapter 14. Please see Figure 14-3 for an illustration of this testbed.

Registration Manipulation

In a typical enterprise deployment, SIP endpoints register with their SIP proxy so the proxy will know where to direct incoming calls. A SIP endpoint registers itself when it boots up and reconnects at a set interval configured by the administrator. All of the SIP phones in our SIP lab were configured to 3,600 seconds (60 minutes), but other SIP endpoints can have different default values. The SIP proxy can also change the registration interval in a “200 OK” response, and the SIP phone will use this value for its registration interval.

Registration Removal

If a registration is removed (or hijacked), the SIP endpoint can’t receive calls. Removing a registration, however, does not affect the ability of the SIP endpoint to make calls or otherwise initiate sessions. You can erase all registrations for a SIP endpoint by sending a REGISTER request with the following header lines:

The key items are the Contact: * and Expires: 0 values, which remove all registrations for the SIP endpoint in the SIP proxy. When this is done, the SIP endpoint can’t receive any incoming communications. These attacks can prevent one or many of your users from receiving communications, affecting anyone in the organization from executives to administrative assistants, and they have a serious impact on your business. This is true considering that missing even a few calls is unacceptable in most enterprises.

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 send packets that erase registrations. An attacker can also gain access to the internal network through other means or can be someone within the enterprise who already has access. The registration removal attack is also possible from a public network if you use SIP trunks for access to your voice service provider.

Registration Removal with the erase_registrations Tool

To demonstrate the registration removal attack, we developed the erase_registrations tool. This tool sends a crafted REGISTER request for a SIP endpoint to a SIP proxy. The usage information for this tool is as follows:

This tool was tested against our SIP phones. It successfully erased all registrations for each of them. This is a very simple and effective attack.

The simplest use of the erase_registrations tool is to erase the registrations for one or all of the SIP endpoints, using the following commands:

You can also create a shell script and loop these commands at specific intervals, often enough to prevent a SIP endpoint from being able to renew its registration. For example, if you ran the preceding commands once every minute for, say, an entire day, you could be assured that the targeted SIP endpoints would not receive any communications and the users probably would not be aware of the problem because they could still initiate communication.

Registration Removal with SiVuS

You can also use SiVuS² to erase registrations. Use the Utilities screen to create a REGISTER request containing the Contact: * and the Expires: 0 values for the target SIP phone. Figure 15-1 illustrates this attack.

Figure 15-1 Registration removal with SiVuS

Registration Removal Countermeasures

You can employ several countermeasures to prevent an attacker from erasing registrations. These same countermeasures can be used to address other attacks in this chapter (and are also similar to those used to address the fuzzing and flooding attacks described in Chapter 14). The goal here is to secure the registration process and prevent the SIP proxy from being tricked into accepting invalid registrations.

Use TCP for SIP Connections

To be compliant with RFC 3261, SIP proxies and SIP endpoints must support both UDP and TCP. When TCP is used, SIP endpoints generally establish persistent connections with each other. For example, SIP endpoints 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 into accepting a spoofed registration.

For TCP to be an effective countermeasure against registration attacks, it must be used for all SIP endpoints communicating with the SIP proxy. Any SIP endpoint that does not use TCP will be vulnerable to the registration manipulation attacks.

Note

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

When TCP is used, it is also possible to use Transport Layer Security (TLS).³ TLS uses encryption to provide privacy and prevent 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 proxy into accepting spoofed registrations.

TLS is used to secure single connections between SIP proxies and SIP endpoints; however, TLS is not an end-to-end protocol. For a call to be secure, TLS must be used for all connections between SIP endpoints participating in the call. TLS also shares a disadvantage with TCP, in that if some SIP endpoints use TLS, but others do not, then the security model breaks down. Although those SIP endpoints that use TLS might be secure, those that don’t are still vulnerable to registration attacks.

Use VLANs to Separate Voice and Data

As we have discussed throughout the book, manufacturers recommend using VLANs to separate the voice and data traffic for UC deployments. Although VLANs will not prevent attacks, they will add another layer of security in a traditional defense-in-depth security model, as we discussed in Chapter 10. There are several ways to implement VLANs, including MAC filtering, configuring the switch ports to allow traffic to specific VLANs only, and also 802.1x port authentication.

The use of softphones and UC messaging clients 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 mimic the softphone and manipulate registrations.

Enable Authentication

Of all the SIP requests, it makes the most sense to support authentication for REGISTER requests. REGISTER requests are not exchanged frequently, so the overhead for authentication is minimal. This is in contrast to requests such as INVITEs, which can come from an external network if SIP trunks are used. INVITE requests occur more frequently, so you could argue against the added overhead.

Only internal or enterprise SIP endpoints should be registering, so you can enable authentication and set strong passwords for each SIP endpoint. Remember that for authentication to be useful, it is essential to use strong passwords. If the passwords are weak or “mechanically” generated, such as the phone extension backward, an attacker can easily guess them and defeat authentication. We cover authentication cracking in a later section.

Decrease the Registration Interval

You can also decrease the registration interval, causing the SIP endpoints to register themselves more frequently. For example, if you set the registration interval to 60 seconds, even if a registration is removed (or hijacked), the SIP endpoint will recover after a minute and resume receiving calls.

Change Well-Known Ports

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

Use Session Border Controllers (SBCs) and SIP Firewalls

An SBC and/or SIP firewall can be deployed to inspect all signaling sent to the SIP proxy. The SIP firewall can detect various forms of attacks, including registration manipulation attacks. An SBC or SIP firewall is essential when connecting to a public network. SBCs and SIP firewalls are available from numerous vendors:

Several traditional firewalls, intrusion detection systems (IDSs), and intrusion prevention systems (IPSs) also support some basic detection of SIP attacks. Companies such as SecureLogix offer application-level firewalls and IPSs that support SIP.

Registration Addition

The registration managed within the SIP proxy can have multiple contacts, allowing a user to register several locations—such as their office, a conference room, and a production lab—all of which will ring when an inbound call arrives. When multiple SIP endpoints “ring,” the first one accessed will accept the communications. This behavior creates the opportunity for several types of attacks. For example, you could add several contacts for each user, causing many SIP phones to ring for each inbound call, which would likely annoy and confuse users. You could also add the address of a SIP phone you control and then quickly pick it up when it rings, thereby performing a basic registration hijack.

These attacks can irritate and confuse your users. In an extreme case, where multiple contacts are added for many SIP endpoints, it is possible for a user’s endpoint to “ring” continuously. A registration hijacking attack can also be serious, which we will discuss in the next section.

As with registration removal, the attacker needs access to the internal network or possibly through SIP trunks if the enterprise is using them.

Registration Addition with the add_registrations Tool

To demonstrate this attack, we developed the add_registrations tool. This tool sends a properly crafted REGISTER request containing a new contact for a user. The usage information for this tool is as follows:

This tool was tested against Asterisk and Kamailio, and of course each of the proxies behaves differently. The Kamailio proxy adds the new contact. The Asterisk SIP proxy replaces the current contact with the new one, and behavior prevents you from using the add_registrations tool to add more than one new contact for the Asterisk SIP proxy. The tool could be modified to accept a list of new contacts.

Annoying Users by Adding New Contacts

You can provide additional contacts for one or more SIP endpoints so that when the intended user receives an inbound call, multiple SIP endpoints will “ring.” When this attack is repeated for multiple SIP endpoints, every time there is an inbound call, there will be so many SIP endpoints constantly “ringing” that no one will know who is calling whom. The following commands add five contacts for the Kamailio SIP proxy to an existing SIP endpoint:

In this example, when an inbound call to extension 2004 occurs, six SIP phones will ring. The first user who goes off hook will answer the call. This example can easily be expanded to add multiple contacts for every phone.

Basic Registration Hijacking

The add_registrations tool can be used to add a new contact, thus performing a simple registration hijacking attack, which we discuss in detail in the next section. This new contact would be for a SIP endpoint accessible to the attacker, who can answer the call more quickly than the actual user. This attack could be used very effectively if the target user is away from their SIP endpoint. Here are some sample commands:

These commands add a contact, extensions 2000 and 2005, to extensions 2003 and 2004. When an inbound call to extension 2003 or 2004 is made, a total of three SIP phones will ring (the original extension and the two added extensions). If an attacker at extension 2000 or 2005 can answer the call before the called party, they can essentially deny service to them and possibly conduct a phishing or some other attack.

Note

If you don’t want the target user’s SIP phone to ring at all, you can use the erase_registrations tool and they won’t even hear the phone ring.

Adding Registration Using SiVuS

SiVuS can also be used to add registrations. Use the Utilities screen to create a REGISTER request for the current registration while adding a new contact. Figure 15-2 illustrates this attack.

Figure 15-2 Registration addition with SiVuS

Registration Addition Countermeasures

The countermeasures for registration addition attacks are identical to the countermeasures described for erasing registrations.

Registration Hijacking

Registration hijacking refers to a scenario where an attacker replaces the legitimate registration with a false one. Some possible attacks include routing inbound calls to a nonexistent device, such as a fake extension, routing inbound calls to another SIP endpoint, such as routing the CEO’s calls to their internal SIP phone, and routing calls to a rogue application, which we will discuss in the next section. Figure 15-3 illustrates a hijacked registration.

Figure 15-3 Registration hijacking

Rogue applications are also a fun SIP destination to send calls that have been hijacked. An attacker can mimic the intended user, or even use the rogue application to perform an application-level man-in-the-middle (MITM) attack, allowing it to be in the middle of the signaling and media streams. In this position, the rogue application can modify signaling and media or simply record interesting values in the signaling, along with the media. Figure 15-4 illustrates this form of registration hijacking.

Figure 15-4MITM registration hijacking

Registration hijacking can be very nasty. You can use this attack to switch SIP endpoints’ registration around, route inbound sales calls to a competitor, or simply route calls randomly throughout an enterprise, resulting in significant disruption of the UC service.

You can also use registration hijacking to route inbound calls to a rogue application and trick callers into giving up sensitive information. The rogue application could easily mimic a voicemail system by answering calls and playing a generic message (“The party you are trying to reach is not available. Please leave a message after the tone”). Most users would not realize that it isn’t the corporate mail system. A sophisticated attacker could easily record messages from actual voicemail systems and make the attack even harder to detect. Even though many users have personalized their internal and external caller voicemail greetings, if these were replaced by a greeting that sounded legitimate enough, it would fool virtually all callers.

As with registration removal and addition, the attacker needs access to the internal network or possibly through SIP trunks if the enterprise is using them.

At the beginning of the chapter, we showed how easy it is to erase registrations, especially in an unauthenticated UDP environment. Now, we will show how easy it is to use new and existing tools to hijack registrations. Note that of all SIP requests, REGISTERs are the most likely to require authentication, so we will demonstrate how to circumvent them. You can use a few tools to break the authentication, including svcrack and authtool. We will start by looking at authtool.

Breaking Authentication with authtool

If digest authentication is used for REGISTER requests, the SIP proxy will respond and require authentication from the SIP endpoint. The response includes information needed to calculate an MD5 digest to be supplied in a new REGISTER request. To assist with cracking authentication, we developed a command-line tool called authtool to extract information from SIP requests and responses to crack passwords offline. The command-line arguments are as follows:

The authtool tool attempts to determine the password for each user referenced in a set of provided SIP requests and responses. The username/password pair(s) produced by this tool can be used directly for registration hijacking. Before encountering an Authorization header line, the tool expects to find at least one REGISTER (or INVITE, OPTIONS, and so on) request line and at least one From: header line.

When an Authorization header line is encountered, the authtool tool extracts the parameters required to recompute the MD5 digest that must also be present on that Authorization line. Depending on the command-line options, the tool then performs a dictionary attack using a list of passwords or a single password. When it encounters a password that matches the MD5 digest product found in the Authorization header line, then the username, the password, and the From URI are printed to the standard output or written to a file if the –r switch and a filename have been specified on the command line.

Note

Both SiVuS and Cain and Abel provide SIP hash-cracking functions as well. We showed an example of how to use Cain and Abel for SIP hash cracking in Chapter 11.

We enabled authentication for the Kamailio proxy to illustrate use of the authtool tool (and for subsequent registration hijacking examples). The SIP phones were provisioned with passwords that are the same as their extensions. This is not recommended, of course, but helps to illustrate how to use authtool. A short file was created containing sample passwords (although you would use a much longer dictionary for an actual attack). The contents of this file are listed here:

Following is a list of SIP requests and responses captured for a call between extensions 2001 and 2003. We used an INVITE as an example, but this could also be done with a REGISTER:

The Kamailio proxy challenged the caller (2003) in the second message. The fourth message is the INVITE message that the phone at extension 2001 updated in response to the challenge. The phone used the parameters supplied to it in the 407 Proxy Authentication Required response, its username (2003), and its secret password (also 2003) in order to produce the MD5 digest it added to the INVITE message in the Proxy-Authorization header line.

When the authtool tool is run on a file with the previous SIP messages, it scans until it encounters the INVITE (or REGISTER) request with the Proxy-Authorization header line. It then uses the parameters in that header line, together with other MD5 digest parameters from the request, to compute an MD5 digest for each password in the dictionary file until the dictionary file is exhausted or the tool produces an MD5 digest matching the digest in the request. Because the password for the phone at extension 2003 is in the dictionary, a password solution is output for user 2003. The tool then continues scanning the captured messages until the messages are exhausted. The actual output for the command is shown here:

As discussed, the authtool results can be used directly or as input to the registration hijacking tool described in the next section.

Breaking Authentication with svcrack

In Chapter 4 we discussed SIPVicious⁴, which is a suite of tools for assessing SIP environments, developed by Sandro Gauci of Enable Security. One tool that works well for breaking SIP authentication is svcrack, which allows you to perform the authentication-cracking attacks against the SIP proxy using REGISTER requests that the tool sends. When the proxy responds requiring authentication, the tool calculates responses based on the nonce and realm values in the authentication messages from the SIP proxy. You can use a password file or specify a range of numbers to try. Here are the command-line arguments available for the tool:

Because we already know that the passwords are the same as the extensions, we will specify a range of numbers to try while calculating the authentication response. Here is the actual output from the tool:

You can see from the output that the tool was able to determine the password. Clearly, because we knew the password and limited the pool of numbers to try, it didn’t take very long. However, according to the SIPVicious website, svcrack is able to crack up to 80 passwords per second, making it a useful tool to have in your arsenal.

Registration Hijacking with the reghijacker Tool

The registration hijacker, reghijacker, is a Linux-based tool that hijacks one user at a time in the designated domain. This tool has the following command-line options:

You can specify a file containing usernames and passwords using the -f parameter or designate a single username and password with the -u and -p parameters. When a file is specified, each line in the file must contain one username/password pair, such as those derived from either authtool or svcrack.

The reghijacker tool first sends a REGISTER request to unbind the target user from all present contacts. As described earlier, this consists of changing the Contact header line to the wildcard parameter (*) and changing the Expires header line to the value 0 (zero). Together, these lines request the registrar to remove all bindings for the target user URI specified in the To header line.

When all contacts have been deleted, a second REGISTER request is sent with a new Contact header line for that user and is obtained from the command line. The URI for the new contact information is constructed by using the values for newcontact from the command-line and enclosing that value in angle brackets, as seen here: <sip:hacker@10.1.101.30>; this is added to the hijack contact string. An arbitrary expiration interval is requested in the Expires header line of the second REGISTER request (for example, 60 minutes or 1 day).

We determined that two REGISTER requests are required in order to erase all existing and presumably valid contact information for the targeted user. However, a hijack of sorts could be achieved by simply adding a hijack contact to the current list of registered user contacts, as we demonstrated earlier with the add_registrations tool.

The reghijacker tool can calculate the MD5 digest when challenged by the registrar using the realm and nonce specified by the challenge response, the method (in other words, REGISTER), the URI of the registrar in the REGISTER request-URI line, and the targeted username and corresponding password. There are optional parameters that a challenger might require in the MD5 digest calculation—for example, qop (quality of protection), opaque, cnonce, nonce-count. These are not supported by the reghijacker tool at this time. Neither the Kamailio nor Asterisk SIP proxy required these values.

The number of messages exchanged during a hijacking doubles when authentication is enabled as a result of the registrar challenging each REGISTER request it receives that does not incorporate the Authorization header line expected. The attack approach used by the reghijacker tool is summarized in Figure 15-5.

Figure 15-5 Registration hijacker attack approach

The reghijacker tool supports authenticated and unauthenticated environments. The example shows registration hijacking occurring in an authenticated domain:

This command hijacks the registration for the SIP phone at extension 2002 and changes the registration to the 10.1.1.137 system. It also causes inbound calls to extension 2002 to be routed to the 10.1.1.137 system while running a softphone to allow you to answer the call. The SIP messages exchanged as a result of this attack are shown here between the attacking system at 10.1.1.137 and the Kamailio proxy at 10.1.13.250. Note that in this example, authentication is enabled and doubles the amount of messages between the systems:

These attacks work for both the Kamailio and Asterisk SIP proxies, although the messages exchanged differ slightly in that Asterisk responds with a “100 Trying” response before sending the “200 OK” response. The Asterisk SIP proxy also overrode the one-day expiration period and replaced it with one hour. A number of attack scenarios are possible with the reghijacker tool. We discuss some of the obvious ones in the next few sections.

The reghijacker tool can be used to wreak havoc in several different ways. Although none of them are totally devastating, they are annoying, they decrease productivity, and most users will be quick to blame the UC system for the problem as opposed to blaming an attack. The simplest scenario using the reghijacker tool is simply to hijack a registration and have the calls go to an offline or fake destination, resulting in inbound calls to the hijacked endpoint being dropped. A couple of sample reghijacker attack commands are shown here:

This attack registers extensions 2001 and 2002 to hacker@10.1.1.99 and presumes there isn’t a SIP endpoint on the 10.1.1.99 system. If you are in a domain without authentication, you can specify a file containing users with the –f command-line argument and hijack a list of extensions. If authentication is used, it would be more difficult because you would need passwords for all of the endpoints you’re attacking. Because we know that some enterprises use “mechanically” generated passwords (such as the extensions in our examples), if you are able to sniff and break one password, you may be able to break them all.

You can use reghijacker to swap registrations for SIP endpoints, causing communications to go to destinations they shouldn’t. Some examples could include swapping registrations between two phones and even sending the registrations for multiple phones to one phone, such as the SIP phone used by an executive. These attacks are trivial without authentication, although still very annoying to users. For example, to swap the registrations for extensions 2001 and 2002, we would do the following:

The reghijacker tool can also be used to facilitate social engineering attacks. For example, if you know the extension of a department within an enterprise, such as IT support or human resources, you can hijack the registration for that department and attempt to gather more information from callers, including passwords, social security numbers, and any other sensitive information that can be used to an attacker’s advantage.

Man-in-the-Middle (MITM) Attacks

Perhaps the most sinister reghijacker attack is to hijack the registration for a key SIP phone user and send the calls to a rogue softphone application that performs a B2BUA function and creates an MITM attack. A rogue B2BUA would see all the signaling and media and could potentially record the signaling, drop calls, transfer calls, or simply record the audio between the caller and callee as the MITM. A sample command invocation of the reghijacker tool is shown here:

This assumes that a MITM application, such as the sip_rogue tool, is running on the 10.1.101.99 system. In this attack, the sip_rogue tool will perform a MITM attack and relay the call to the intended recipient. While relaying the call, it will be able to monitor and change both the signaling and media. Some of the possible attacks are covered in Chapter 11.

Registration Hijacking Countermeasures

To address registration hijacking attacks, you can use the countermeasures for erasing and adding registration attacks.

Redirection Attacks

In SIP, a proxy or endpoint can respond to an INVITE request with a “301 Moved Permanently” or “302 Moved Temporarily” response. The initiating endpoint should use the value in the Contact header line to locate the moved user. The 302 response will also include an Expires header line that communicates how long the redirection should last. If an attacker is able to monitor for the INVITE request or is a MITM, he or she can respond with a redirection response, effectively denying service to the called party and possibly tricking the caller into communicating with a rogue endpoint.

Redirection attacks are similar in impact to registration hijacking attacks in that they both subvert inbound calls to a specific SIP phone. Redirection attacks are arguably less disruptive, however, because they affect inbound calls to a SIP phone from a single other SIP phone (at least using the tool we provided).

As with registration attacks, the attacker needs access to the internal network or possibly through SIP trunks if the enterprise is using them.

Redirection Attacks Using the redirectpoison Tool

To demonstrate this attack, we developed the redirectpoison tool. This monitors for an INVITE request and responds with a 301 Moved Permanently response. The usage information for this tool is as follows:

Although the redirectpoison tool doesn’t need to be run as a MITM, it does need access to SIP signaling. On way an attacker can accomplish this is if they’re connected to a hub where the target SIP signaling messages are flowing. We discuss some of the ways to facilitate this type of access in Chapters 10 and 11. The redirectpoison tool monitors SIP signaling messages for an INVITE destined for the target host and replies with a 301 Moved Permanently response. This response must be sent and received before any other provisional or final responses are received; in other words, the attack needs to win the race condition. To ensure the race condition is won, redirectpoison raises its execution priority to the most negative numerical setting: –20. You must run this tool as root to allow this priority to be set. The Readme.txt file for redirectpoison has much more information on the tool, if you’re interested.

The redirectpoison tool runs until terminated by the user. The proxies we tested, including Asterisk and Kamailio, didn’t check if the Contact returned for a 301 response was the same as what was provided in the To: header of the INVITE request. There are several different kinds of attacks you can produce with redirectpoison. These include redirecting calls to a nonexistent SIP phone, resulting in a DoS condition for both the caller and called parties. A sample redirectpoison command line for this scenario is shown here:

You can also use the redirectpoison tool to redirect calls to a random or unsuspecting user, resulting in a DoS condition to the called party and confusing the caller and the new called party. A sample redirectpoison command line is shown here:

You can also use the redirectpoison tool to redirect calls to a rogue SIP phone, which could be used to imitate the intended called party. The rogue could trick the caller into leaving a voicemail or could possibly involve a human who tricks the caller into disclosing important information. A sample redirectpoison command-line invocation is shown here:

Redirection Attacks Using the redirectpoison Tool Countermeasures

To address redirection attacks, you can use the countermeasures for erasing and adding registration attacks and solve the problem.

Session Teardown

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

If an attacker can observe the necessary values, session teardown attacks can be disruptive. How disruptive will depend on which calls and how many of them 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.

As with registration attacks, the attacker needs access to the internal network or possibly through SIP trunks if the enterprise is using them.

Using the teardown Tool to Terminate Sessions Through the SIP Proxy

Whether or not BYE requests are routed through the SIP proxy, SIP endpoints 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:

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

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 for the command-line arguments of the teardown tool. This entire process could be fully automated by developing a tool that monitors for calls and lets you select which calls are to be terminated. As it should happen, we have developed a tool that monitors calls and can select which call is terminated, among other features, called Call Monitor. It is discussed in Chapter 17.

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.

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 Kamailio SIP proxies. The command-line arguments used are as follows:

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.

Using the teardown Tool to Terminate Sessions Directly to an Endpoint

You can use the teardown tool to send SIP BYE requests directly to SIP endpoints. Assuming the correct information is observed for the call setup, this attack works for all SIP phones tested. The command invocations used are as follows:

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.

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 modified. Like the teardown attack described in the previous section, you need to observe various call-specific values and send the CANCEL request at the proper time. Although this attack is possible, it is difficult to execute in practice, and there’s little point in executing this attack when the session teardown attack is easier to perform.

Session Teardown Countermeasures

To address teardown attacks, you can use the countermeasures for registration manipulation attacks.

SIP Phone Reboot

RFC 3265⁵ describes extensions to SIP, where SIP endpoints subscribe to and receive notifications for asynchronous events. One example is notifying a user when a voicemail is available by illuminating the phone’s message light. The SIP endpoint sends a SUBSCRIBE request to a SIP proxy that includes events of interest. The SIP proxy will then generate NOTIFY requests containing requested information when appropriate.

Certain SIP phones will process NOTIFY requests, even if they have not explicitly requested certain events, and some events can produce an adverse effect. For example, the check-sync event causes some SIP phones to reboot. A sample NOTIFY request that causes this reboot is shown here:

This attack is very disruptive for some SIP phones. In an environment where the attacker knows the extensions and IP addresses of the SIP phones (and assuming no authentication), the attacker can cause all SIP phones to reboot once or multiple times. This attack could be especially disruptive if key users are targeted.

As with registration attacks, the attacker needs access to the internal network or possibly through SIP trunks if the enterprise is using them.

SIP Phone Reboot with the check_sync_reboot Tool

To demonstrate this attack, we have the check_sync_reboot tool. This tool sends a properly crafted NOTIFY request, containing the check_sync event. The usage information for this tool is as follows:

This tool’s effectiveness depends on how the target is configured. We have found phones will actually reboot, but they have to be configured to do so, such as in the case of select Polycom and Cisco phones and most Snom phones. This feature is configured either in the XML configuration files, such as on a Cisco phone, or through a web interface as in the case of the Polycom phones. Since the first edition of the book, Snom phones now have a setting configured in the web interface that can require authentication before rebooting to prevent unauthorized check-sync attacks.

SIP Phone Reboot with SiVuS

You can also use SiVuS to send check-sync events. Use the Utilities screen to create a NOTIFY request containing the Event: check-sync header for the target SIP phone. Figure 15-6 illustrates this attack.

Figure 15-6 SIP phone reboot with SiVuS

SIP Phone Reboot Countermeasures

The best countermeasure is to disable this feature on all of your SIP endpoints and phones. Also, to address these attacks, you can use the countermeasures for registration manipulation attacks.

Other Signaling Manipulation Tools

You can find a number of other signaling manipulation tools on the Internet. Here are three notable ones:

Summary

SIP-based systems, including SIP proxies, SIP phones, and media gateways, are vulnerable to various types of signaling manipulation attacks. This is especially true of systems using UDP, which are easy to trick into accepting spoofed packets. The registration process, even when it uses authentication, can be attacked, resulting in lost or otherwise manipulated calls. Other types of attacks, such as tearing down active calls and rebooting SIP phones, are also easy to perform.

References

1. Session Initiation Protocol (SIP), www.ietf.org/rfc/rfc3261.txt.

2. SiVuS, www.voip-security.net/index.php/downloads/security/summary/30/299.

3. Transport Layer Security (TLS), www.ietf.org/rfc/rfc5246.txt.

4. SIPVicious, http://code.google.com/p/sipvicious/.

5. NOTIFY extensions to SIP, RFC 3265, www.ietf.org/rfc/rfc3265.txt.