[NEWS] Notify Message Spoofing Vulnerability With VoIP Phones

SecuriTeam <[email protected]>
Newsgroups gmane.comp.security.securiteam
Message-ID <[email protected]>
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  Notify Message Spoofing Vulnerability With VoIP Phones
------------------------------------------------------------------------


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".

DETAILS

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.

Example:
Attacker spoofs the SIP-Proxy's IP, here: 10.1.1.1 Victim 10.1.1.2
UDP-Message from Attacker to Victim:
Session Initiation Protocol
 Request-Line: NOTIFY sip:[email protected] SIP/2.0
  Message Header
   Via: SIP/2.0/UDP 15.1.1.12:5060;branch=000000000000000
    From: "asterisk" <sip:[email protected]>;tag=000000000
     To: <sip:[email protected]>
      Contact: <sip:[email protected]>
      Call-ID: [email protected]
      CSeq: 102 NOTIFY
                  User-Agent: Asterisk PBX
      Event: message-summary
      Content-Type: application/simple-message-summary
      Content-Length: 37
        Message body
                Messages-Waiting: yes\n
                Voicemail: 3/2\n

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.


ADDITIONAL INFORMATION

The information has been provided by  
<mailto:[email protected]> Tobias Glemser .
The original article can be found at:  
<http://pentest.tele-consulting.com/advisories/05_07_06_voip-phones.txt> 
http://pentest.tele-consulting.com/advisories/05_07_06_voip-phones.txt



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: [email protected] 
In order to subscribe to the mailing list, simply forward this email to: [email protected] 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any kind. 
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.