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