Fwd: [VOIPSEC] VoIP-Phones: Weakness in proccessing SIP-Notify-Messages
FYI
---------- Forwarded message ----------
From: Mark Teicher <mht3@xxxxxxxxxxxxx>
Date: Jul 7, 2005 7:06 PM
Subject: Re: [VOIPSEC] VoIP-Phones: Weakness in proccessing SIP-Notify-Messages
To: Tobias Glemser <tglemser@xxxxxxxxxxxxxxxxxxx>
Cc: voipsec@xxxxxxxxxx
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@xxxxxxxx SIP/2.0
> Message Header
> Via: SIP/2.0/UDP 15.1.1.12:5060;branch=000000000000000
> From: "asterisk" <sip:asterisk@xxxxxxxx>;tag=000000000
> To: <sip:login@xxxxxxxx>
> Contact: <sip:asterisk@xxxxxxxx>
> Call-ID: 00000000000000@xxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx +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@xxxxxxxxxx
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
_______________________________________________
Voipsec mailing list
Voipsec@xxxxxxxxxx
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org