[VOIPSEC] VoIP-Phones: Weakness in proccessingSIP-Notify-Messages
tglemser at tele-consulting.com
Mon Oct 17 00:55:28 BST 2005
Right you are, but with some phones you also have to spoof the IP Adress
of the SIP Proxy.
For that I released a new version of the script, enabling you to send
invite packets and also to spoof ip-adresses [fo that the script was
renamed from SIP Notice Fun to SIP Send Fun :) ].
Tele-Consulting security | networking | training GmbH
on 12.10.2005 22:04 mailinglist wrote:
> NOTIFY-Fun? Try INVITE-Fun!!! Send an INVITE packet to all devices listening
> on port 5060 on UDP.
>>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
>>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
>>You can download the script here:
>>(german website, but you should be able to download it. If
>>not, feel free to send me an eMail).
>>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:
>>> Weakness in implemenation of proccessing SIP-Notify-Messages
>>> in VoIP-Phones.
>>> 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.
>>> 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
>>> All tested phones process the message with a resetted Call-ID,
>>> 'branch' and 'tag' sent by a spoofed IP-Adress.
>>> 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 220.127.116.11: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
>>> 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.
>>> Cisco 7940/7960
>>> Grandstream BT 100
>>> others will be tested in future
>>Voipsec mailing list
>>Voipsec at voipsa.org
More information about the Voipsec