bugtraq - Re: VoIP-Phones: Weakness in proccessing SIP-Notify-Messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <434D1A8A.5090200@tele-consulting.com>
Date: Wed, 12 Oct 2005 16:15:38 +0200
From: Tobias Glemser <tglemser@...e-consulting.com>
To: bugtraq@...urityfocus.com
Subject: Re: VoIP-Phones: Weakness in proccessing SIP-Notify-Messages


List,

I just wanted to inform you that I wrote a tiny script, which enables 
you to test the discussed vulnerability with your equipment.

This script works perfect with Grandstream BT100, Cisco phones won't 
work on the fly. Please refer to the README for more information.

You can download the script here:
http://www.tele-consulting.com/index.php?where=download&part=download&what=snf

(german website, but you should be able to download it. If not, feel 
free to send me an eMail).


Cheers,

Tobias Glemser
Tele-Consulting security | networking | training GmbH

Tobias Glemser wrote on 06.07.2005 18:20:
>                   Tele-Consulting GmbH
>             security | networking | training
>            
>                 advisory 05/07/06
> 
> URL of this advisory:
> http://pentest.tele-consulting.com/advisories/05_07_06_voip-phones.txt
> 
> 
> Topic:
>     Weakness in implemenation of proccessing SIP-Notify-Messages
>     in VoIP-Phones.
> 
> Summary:
>     Due to ignoring the value of 'Call-ID' and even 'tag' and
>     'branch' while processing NOTIFY messages, VoIP-Hardphones
>     process spoofed status messages like "Messages-Waiting".
>     
>     According to RFC 3265, Chap 3.2 every NOTIFY has to be em-
>     bedded in a subcription mechanism. If there ain't knowledge
>     of a subscription, the UAC has to respond with a "481
>     Subscription does not exist" message.
> 
>     All tested phones processed the "Messages-Waiting" messages
>     without prior subscriptions anywhere.
> 
> Effect:
>     An attacker could send "Messages-Waiting: yes" messages to
>     all phones in a SIP-environment. Almost every phone proccesses
>     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 resetted Call-ID,
>     'branch' and 'tag' sent by a spoofed IP-Adress.
> 
> Example:
>     Attacker spoofs the SIP-Proxys IP, here: 10.1.1.1
>     Victim 10.1.1.2
>     
>     UDP-Message from Attacker to Victim
>     
>     Session Initiation Protocol
>          Request-Line: NOTIFY sip:login@...1.1.2 SIP/2.0
>          Message Header
>              Via: SIP/2.0/UDP 15.1.1.12:5060;branch=000000000000000
>              From: "asterisk" <sip:asterisk@...1.1.1>;tag=000000000
>              To: <sip:login@...1.1.2>
>               Contact: <sip:asterisk@...1.1.1>
>               Call-ID: 00000000000000@...1.1.1
>              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 subcription such an attack would
>     be possible. Background is given by the way dialogs are des-
>     cribed in RFC 3261 and the sections 5.5 and 3.2 of RFC 3265.
> 
> 
> Affected products:
>     Cisco 7940/7960
>     Grandstream BT 100
>     others will be tested in future
> 
> 
> -- 
> Tobias Glemser
> 
> 
> TTTTTTT CCCC
>   TT   C  tglemser@...e-consulting.com         +49 (0)7032/97580  (fon)
>   TT  C   pentest.tele-consulting.com          +49 (0)7032/74750  (fax)
>   TT  C
>   TT   C  Tele-Consulting GmbH, Siedlerstrasse 22-24, 71126 Gaeufelden
>   TT    CCCC             security | networking | training
>