[VOIPSEC] VoIP-Phones: Weakness in proccessing
Geoff Devine
gdevine at cedarpointcom.com
Fri Jul 8 08:01:10 CDT 2005
I'd point out that this kind of problem is the most glaring security weakness with SIP. As a completely unstructured text-based protocol, you can't possibly test all permutations of SIP messages. It's fairly straightforward to construct a mal-formed SIP message or message sequence that kills a device. It might not be such a big deal with a single SIP soft client UA on a PC but it's pretty serious when you stop to think that you could take out all the carrier-class media gateway controllers in a network once you stumble across that "message of death" that kills the box. If you adopt a lightweight architecture where all you have between a PC-based SIP UA and a Media Gateway Controller is lightweight SIP Proxies that merely route packets and insert headers, you have a huge vunlerability. The only real solution in an open network is to insert filters into the signaling stream to perform deep packet inspection, protocol profiling, and protocol policing. Your lightweight SIP Proxies on the edge of your network become heavyweight SIP Back-2-Back User Agents where the B2B UA has to understand every last bit of signaling in each SIP message. When you build your network this way, it's very difficult to achieve "rapid feature and service creation" since you have to lock down the signaling to keep your network stable. The IMS/3GPP 3rd Generation Cell Phone approach to solving this problem is to keep the SIP variant spoken by the cell phone extremely simple, to make the edge proxy the cell phone talks to (P-CSCF) a Back-2-Back User Agent, and to implement most of the features in the core rather than fully distributed out to the cell phone.
Geoff
________________________________
Date: Thu, 07 Jul 2005 20:06:35 -0400
From: Mark Teicher <mht3 at earthlink.net>
Subject: Re: [VOIPSEC] VoIP-Phones: Weakness in proccessing
SIP-Notify-Messages
To: Tobias Glemser <tglemser at tele-consulting.com>
Cc: voipsec at voipsa.org
Message-ID: <6.2.3.4.2.20050707200355.034ad1f0 at pop.earthlink.net>
Content-Type: text/plain; charset="us-ascii"; format=flowed
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 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
>
>
>--
>Tobias Glemser
>
>
>TTTTTTT CCCC
> TT C tglemser at tele-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 at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
------------------------------
_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
End of Voipsec Digest, Vol 7, Issue 4
*************************************
More information about the Voipsec
mailing list