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

[Tobias Glemser]

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 :) ].

http://www.tele-consulting.com/index.php?where=download&part=download&what=ssf

Cheers,

Tobias Glemser
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.
> 
> 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
>>
>>
>>
> 
> 
> 
>