Notify Message Spoofing Vulnerability With VoIP Phones
7 Jul. 2005
Summary
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls, multimedia distribution and instant messaging. The SIP protocol is described in RFC3261 (with extensions contained in RFC3265).
Due to ignoring the value of 'Call-ID' and even 'tag' and 'branch' while processing NOTIFY messages, VoIP-Hard-phones process are vulnerable for spoofing of status messages such as "Messages-Waiting".
Vulnerable Systems:
* Cisco 7940/7960
* Grandstream BT 100
* Other vendors might be vulnerable as well
According to RFC 3265, Chap 3.2 every NOTIFY has to be embedded in a subscription mechanism. If there isn't any knowledge of a subscription, the UAC has to responds with a "481 Subscription does not exist" message.
An attacker could send "Messages-Waiting: yes" messages to all phones using the SIP-environment. Almost every phone processes this status message and shows the user an icon or a blinking display to indicate that new messages are available on the voice box. If the attacker sends this message to many recipients in a huge environment, it would lead to server peaks as many users will call the voice box at the same time. Because there are no new voice messages as indicated by the phone the users will call the support to fix this alleged server problem.
All tested phones process the message with a reseted Call-ID, 'branch' and 'tag' sent by a spoofed IP-Address.
Solution:
Phones who receive a NOTIFY message to which no subscription exists, must send a "481 Subscription does not exist" response. It should be possible to use the REGISTER request as a non-SUBSCRIBE mechanism to set up a valid subscription.
This would reduce the possibility of an attack in a way, that only with a sniffed and spoofed subscription such an attack would be possible. Background is given by the way dialogs are described in RFC 3261 and the sections 5.5 and 3.2 of RFC 3265.
