SIP Phone Reboot

RFC 3265 (http://www.ietf.org/rfc/rfc3265.txt) describes extensions to SIP, whereby SIP endpoints subscribe to and receive notifications for asynchronous events. An example is a notification that a user has a voicemail available, which causes a SIP phone to illuminate a message light. The SIP endpoint sends a SUBSCRIBE request to a SIP proxy, for instance, that includes the event it is interested in. The SIP proxy will, as appropriate, generate NOTIFY requests containing the requested information.

We have found that certain SIP phones process NOTIFY requests, even if they have not explicitly requested certain events. Worse still, some events can adversely affect the SIP phone. For example, the check-sync event causes some SIP phones to reboot. An example NOTIFY request that causes this reboot is shown here:

 NOTIFY sip:4500@10.1.101.45:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1.101.99  Event: check-sync  Call-ID: 8d677e989828-t77y7n3hhsrt@10-1-101-99 CSeq: 1000 NOTIFY Contact: Content-Length: 0 

Attack SIP Phone Reboot with check_sync_reboot Tool

Popularity:	7
Simplicity:	9
Impact:	8
Risk Rating:	8

To demonstrate this attack, we developed 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 :

 check_sync_reboot: ./check_sync_reboot EthernetInterface TargetUser DestinationIP D DestinationPort h -v Usage Example: ./check_sync_reboot eth0 4500 10.1.101.45 Mandatory parameters: EthernetInterface  The Ethernet interface to write to. TargetUser - john.doe or 5000 or "1+210-555-1212". DestinationIP  IPV4 address of the target SIP phone. Optional Parameters: -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. -h  Help  Prints this usage information. -v  Verbose  Enables verbose output. 

We ran the check_sync_reboot tool against each of the SIP phones. The following table summarizes the results:

SIP Phone	Result
Cisco 7940	No effect
Cisco 7960	No effect
Grandstream 300	Reboots
Avaya 4602	Crashes completely
Snom 180	Reboots

Attack SIP Phone Reboot with SiVuS

Popularity:	7
Simplicity:	9
Impact:	8
Risk Rating:	8

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 13-6 illustrates this attack.

Figure 13-6: SIP phone reboot with SiVuS

Impact and Probability of Occurrence

This attack is very disruptive for certain 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 .

For these attacks to take place, the attacker needs access to your internal network, which can occur as a result of a user downloading a worm or virus with the ability to send NOTIFY requests. This can also occur if an attacker gains access to the internal network through another means.

Countermeasurs Countermeasures

You can employ several countermeasures to prevent an attacker from sending illicit check_sync_reboot events. The goal here is to prevent the SIP phone from being tricked into accepting illicit session check_sync_reboot events. See the applicable material in the "Countermeasures" section for session teardowns.