| ||
Popularity: | 6 |
Simplicity: | 8 |
Impact: | 6 |
Risk Rating: | 7 |
In a typical enterprise deployment, a SIP phone registers itself with the SIP proxy so the proxy knows where to direct incoming calls. A SIP phone registers itself when it is booted and at some set interval, which can be configured. All the SIP phones tested default to 3600 seconds (60 minutes), but other SIP phones might have different values. Note that the SIP proxy can change the requested registration interval in the 200 OK response. The SIP phone should use this value for its registration interval.
If a registration is removed (or hijacked, which is covered next ), the SIP phone can't receive calls. Removing a registration, however, does not affect the ability of the SIP phone to make calls. You can erase all registrations for a SIP phone by sending a REGISTER request with the following header lines:
Request-Line: REGISTER sip:10.1.101.99 SIP/2.0 Method: REGISTER Resent Packet: False Message Header Via: SIP/2.0/UDP 10.1.101.99:5060; branch=83c598e0-6fce-4414-afdd-11a8acd30527 From: 4000 <sip:4000@10.1.101.99>; tag=83c5ac5c-6fce-4414-80ce-de7720487e25 To: 4000 <sip:4000@10.1.101.99> Call-ID: 83c5baaa-6fce-4414-8ff6-f57c46985163 CSeq: 1 REGISTER Max-Forwards: 70 Contact: * Expires: 0 Content-Length: 0
The key values are the Contact: * and Expires: 0 values, which remove all registrations for the SIP phone in the SIP proxy. When this is done, the SIP phone can't receive any incoming calls.
To demonstrate this attack, we developed the erase_registrations tool. This tool sends a properly crafted REGISTER request for a SIP phone to a SIP proxy. The usage information for this tool is as follows :
erase_registrations: ./erase_registrations EthernetInterface TargetUser TargetDomainIP DestinationIP h -v Usage Example: ./erase_registrations eth0 3000 10.1.101.2 10.1.101.30 Mandatory parameters: EthernetInterface the Ethernet interface, e.g., eth0. TargetUser - "" or john.doe or 5000 or "1+210-555-1212". TargetDomainIP The IPV4 address of the SIP proxy to which the REGISTER request will be sent. DestinationIP IPV4 address of the target SIP phone. Optional Parameters: -h Help Prints this usage information. -v Verbose Enables verbose output.
This tool was tested against each of the SIP phones. It successfully erased all registrations for each of them. This is a very simple and very effective attack.
The simplest use of the erase_registrations tool is to erase the registrations for one or all of the SIP phones, using the following commands:
./erase_registrations eth0 3000 10.1.101.2 10.1.101.30 ./erase_registrations eth0 3500 10.1.101.2 10.1.101.35 ./erase_registrations eth0 4000 10.1.101.2 10.1.101.40 ./erase_registrations eth0 4500 10.1.101.2 10.1.101.45 ./erase_registrations eth0 6000 10.1.101.1 10.1.101.60 ./erase_registrations eth0 6500 10.1.101.1 10.1.101.65 ./erase_registrations eth0 7000 10.1.101.1 10.1.101.70 ./erase_registrations eth0 7500 10.1.101.1 10.1.101.75
You can also place these commands into a script with a loop, which runs the command often enough to defeat when a SIP phone re-registers itself. For example, if you re-ran the previous commands once every minute, for say an entire day, you could be pretty much assured that the targeted SIP phones would not receive any calls.
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 13-1 illustrates this attack.
These attacks can prevent one or many of your users from receiving phone calls, affecting your executives, customer interaction lines, customer support lines, and so forth. Obviously, these attacks can have a serious impact on your business. This is especially true considering that failing to receive 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. The erase registrations attack is also possible from a public network if you use SIP trunks for access to your voice service provider.
You can employ several countermeasures to prevent an attacker from erasing registrations. These same countermeasures can be used to address registration hijacking attacks, which are described in the next section. The goal here is to secure the registration process and prevent the SIP proxy from being tricked into accepting invalid registrations. Several countermeasures are addressed here.
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 into accepting a spoofed registration.
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 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 6. |
When TCP is used, it is also possible to use 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. TLS also provides strong authentication, which makes it very difficultif 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 phones; 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 phones use TLS, but others do not, then the security model breaks down. While those SIP phones that use TLS might be secure, those that don't are still vulnerable to registration attacks.
Unfortunately, the Asterisk SIP proxy does not support TCP, and neither the Asterisk nor the SER SIP proxy currently supports TLS. Most SIP phones support TCP; most do not support TLS.
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 manipulate registrations from a compromised PC. Additional countermeasures include MAC filtering and 802.1x port authentication.
It may 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 mimic the softphone and manipulate registrations.
It is also possible to get spoofed registration packets onto the voice VLAN if a rogue PC is added to the LAN switch port configured for the voice VLAN.
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. Only internal or enterprise SIP phones should be registering, so you can enable authentication and set strong passwords for each SIP phone. This is in contrast to requests such as INVITES, which can come from an external network ( assuming SIP trunks to the public network are used). INVITE requests occur more frequently, so you could argue against the added overhead.
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.
You can also decrease the registration interval, causing the SIP phones 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 phone will recover after a minute and resume receiving calls.
The 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.
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 registration manipulation attacks. A SIP firewall is essential when connecting to a public network. SIP firewalls are available from several vendors , including SecureLogix (http://www.securelogix.com), Sipera (http://www.sipera.com), Borderware (http://www.borderware.com), and Ingate (http://www.ingate.com). Some traditional firewalls, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS) also provide support for SIP.