Message-ID: <84789390507080654370c4dee@mail.gmail.com>
Date: Fri, 8 Jul 2005 08:54:58 -0500
From: gary madsen <gmads.seclists@...il.com>
To: bugtraq@...urityfocus.com
Subject: Fwd: [VOIPSEC] VoIP-Phones: Weakness in proccessing SIP-Notify-Messages


FYI

---------- Forwarded message ----------
From: Mark Teicher <mht3@...thlink.net>
Date: Jul 7, 2005 7:06 PM
Subject: Re: [VOIPSEC] VoIP-Phones: Weakness in proccessing SIP-Notify-Messages
To: Tobias Glemser <tglemser@...e-consulting.com>
Cc: voipsec@...psa.org


Interesting results when executed against the Avaya Softphone and
Avaya 4620.  The Avaya Softphone throws an exception msg handler
window and the application process handler becomes unresponsive  :)

At 03:16 AM 7/7/2005, Tobias Glemser wrote:
>                   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
>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec@...psa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


_______________________________________________
Voipsec mailing list
Voipsec@...psa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

Powered by blists - more mailing lists