[VOIPSEC] VoIP-Phones: Weakness in proccessingSIP-Notify-Messages

[mailinglist]

NOTIFY-Fun? Try INVITE-Fun!!! Send an INVITE packet to all devices listening
on port 5060 on UDP.

http://lists.digium.com/pipermail/asterisk-users/2004-January/031868.html

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Tobias Glemser
> Sent: Wednesday, October 12, 2005 6:31 PM
> To: voipsec at voipsa.org
> Subject: Re: [VOIPSEC] VoIP-Phones: Weakness in 
> proccessingSIP-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=d
> ownload&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 07.07.2005 09:16:
> >                   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 at 10.1.1.2 SIP/2.0
> >          Message Header
> >              Via: SIP/2.0/UDP 15.1.1.12:5060;branch=000000000000000
> >              From: "asterisk" <sip:asterisk at 10.1.1.1>;tag=000000000
> >              To: <sip:login at 10.1.1.2>
> >               Contact: <sip:asterisk at 10.1.1.1>
> >               Call-ID: 00000000000000 at 10.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
> > 
> > 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
>