Subject: [MEDIACTRL] Partial security review of draft-ietf-mediactrl-ivr-control-package-02

From: Dan York <[email-masked]>
Date: Thu, 20 Nov 2008 08:18:15 -0600

MEDIACTRL team,

Back at the interim meeting, I agreed to do a security review of both  
the IVR and MIXER control packages.  What follows are some of my  
comments on the IVR package.

My first comment would be that I would strongly recommend that Section  
7 on Security Considerations should be expanded to list what some of  
the specific threats could be if the confidentiality and integrity of  
the Media Control Channel Framework is not addressed.  The statement  
there in Section 7 is purely that confidentiality and integrity MUST  
be addressed, but I would suggest that some examples should be  
included here of WHY it is so important. (And I'm glad to help work on  
some text.)

Here are some example attacks that could occur if there was not proper  
authentication or if the XML streams were able to be modified by an  
attacker (for instance, if they were going across a network in  
cleartext). This is not at all an exhaustive list but rather just some  
quick thoughts that came to me while I was reading the text:

1. DoS WITH <dialogterminate> - An attacker could create a script that  
simply did a

     <dialogterminate dialogid="XXXX" immediate="true">

for iterative values of "XXXX" and terminate any ongoing dialogs (note  
that this is tremendously easier with <audit> as I mention below).

2. RESOURCE EXHAUSTION DoS - An attacker could send into the server  
new packets (or modify existing packets) with, for instance,  
<dialogprepare> elements with an incredibly long fetchtimeout  
attribute and a bogus source URL. At some point this could exhaust the  
number of connections that the MS is able to make and the server is  
basically sitting there waiting to download files it will never be  
able to download.

3. MODIFICATION OF MEDIA SOURCES - An attacker with access to the  
stream could modify the "loc" attribute of the <media> element in a  
dialog to point to some other audio file that had different  
information than the original. This could perhaps include a different  
phone number for people to call if they want more info (which could  
send the caller to an IVR system under the attacker's control) or it  
could just be a modified/degraded/edited version of the original.

4. GRAMMAR MODIFICATION - Similarly, the grammar of an application  
could be modifed by an attacker, either through the directly included  
SRGS or again through modifying the source URL.

5. SECOND RECORDING? - One item that wasn't clear to me in section  
4.3.1.4 or 4.3.1.5 is this - can there be multiple <media> elements in  
a <record> for the same MIME type?  i.e. could an attacker modify the  
XML stream so that he/she could insert a second <media> element that  
would stream the audio out to another site?  Something like this  
(abbreviated):

   <record .... >
      <media type="audio/x-wav" loc="(Good URL)"/>
      <media type="audio/x-wav" loc="(Attacker's URL)"/>
   </record>

If so, it's a wonderful attack for the attacker in that the  
instructions to the MS are modified in transit and the MS would simply  
stream the recorded audio to the two locations - without the  
originator of the XML file probably ever knowing.

I could go on, but you get the point - without protection of the  
transport stream and without proper authentication, there are a  
zillion ways that an attacker can seriously mess with a system.

This point really needs to be driven home in the Security  
Considerations section.

------------------

My second major comment is that the <audit> element in section 4.4  
scares the absolute <insert-favorite-expletive> out of me!   With the  
very simple action of sending just "<audit/>", an attacker gets  
basically everything that he/she needs to know about how to abuse or  
modify the system.  Who needs to do the enumeration I mention in #1  
above when you can simply get back an <auditresponse> that has ALL  
that info in it?

It is tremendously dangerous if exposed to an attacker - and is  
another reason why proper transport protection and authentication  
needs to again be STRONGLY emphasized in the Security Considerations  
section.

------------------

My third comment relates to the remote management capabilities  
mentioned in section 4.4, "Audit Elements" on text page 56, where it  
states:

    Second, auditing enables
    discovery of the existence and status of dialogs currently managed  
by
    the package on the MS.  This allows one AS to take over management  
of
    the dialogs when the AS which initiated the dialogs fails or is no
    longer available.

I know from other email exchanges that this relies on capabilities in  
the underlying framework - but I think mention of this, and how such  
access can be restricted, definitely should be brought into the  
Security Considerations section of this document.

Those were the major points that jumped out at me as I went through  
the document looking at it from a security point-of-view.   I did not  
do an exhaustive study of all the various interactions, but these were  
the ones that jumped out at me.

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 21 Nov 2008 16:12:23 +0000

Hi Dan,

These are great comments and I will strengthen the Security Section and add the examples of attacks.

Two issues:

1. Multiple recordings of same MIME type. I don't see any reason why this shouldn't be permitted (could be used to send a recording to a second location for backup, etc). If there any objections, please let me know.

2. Remote management capabilities mentioned in Section 4.4 Audit Elements. I would really appreciate your input on this one, including framework versus package security levels. I had mentioned this on the list before but we decided not to include detail solutions (like passing a channel authorization token) and to defer to a general security policy statement in the Framework's Security Considerations section. We can discuss it offline and bring a proposal to the group.

Thanks

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: Thursday, November 20, 2008 15:18
To: [email-masked]
Subject: [MEDIACTRL] Partial security review of draft-ietf-mediactrl-ivr-control-package-02

MEDIACTRL team,

Back at the interim meeting, I agreed to do a security review of both the IVR and MIXER control packages.  What follows are some of my comments on the IVR package.

My first comment would be that I would strongly recommend that Section
7 on Security Considerations should be expanded to list what some of the specific threats could be if the confidentiality and integrity of the Media Control Channel Framework is not addressed.  The statement there in Section 7 is purely that confidentiality and integrity MUST be addressed, but I would suggest that some examples should be included here of WHY it is so important. (And I'm glad to help work on some text.)

Here are some example attacks that could occur if there was not proper authentication or if the XML streams were able to be modified by an attacker (for instance, if they were going across a network in cleartext). This is not at all an exhaustive list but rather just some quick thoughts that came to me while I was reading the text:

1. DoS WITH <dialogterminate> - An attacker could create a script that simply did a

for iterative values of "XXXX" and terminate any ongoing dialogs (note that this is tremendously easier with <audit> as I mention below).

2. RESOURCE EXHAUSTION DoS - An attacker could send into the server new packets (or modify existing packets) with, for instance, <dialogprepare> elements with an incredibly long fetchtimeout attribute and a bogus source URL. At some point this could exhaust the number of connections that the MS is able to make and the server is basically sitting there waiting to download files it will never be able to download.

3. MODIFICATION OF MEDIA SOURCES - An attacker with access to the stream could modify the "loc" attribute of the <media> element in a dialog to point to some other audio file that had different information than the original. This could perhaps include a different phone number for people to call if they want more info (which could send the caller to an IVR system under the attacker's control) or it could just be a modified/degraded/edited version of the original.

4. GRAMMAR MODIFICATION - Similarly, the grammar of an application could be modifed by an attacker, either through the directly included SRGS or again through modifying the source URL.

5. SECOND RECORDING? - One item that wasn't clear to me in section
4.3.1.4 or 4.3.1.5 is this - can there be multiple <media> elements in a <record> for the same MIME type?  i.e. could an attacker modify the XML stream so that he/she could insert a second <media> element that would stream the audio out to another site?  Something like this
(abbreviated):

   <record .... >

If so, it's a wonderful attack for the attacker in that the instructions to the MS are modified in transit and the MS would simply stream the recorded audio to the two locations - without the originator of the XML file probably ever knowing.

I could go on, but you get the point - without protection of the transport stream and without proper authentication, there are a zillion ways that an attacker can seriously mess with a system.

This point really needs to be driven home in the Security Considerations section.

------------------

My second major comment is that the <audit> element in section 4.4
scares the absolute <insert-favorite-expletive> out of me!   With the
very simple action of sending just "<audit/>", an attacker gets basically everything that he/she needs to know about how to abuse or modify the system.  Who needs to do the enumeration I mention in #1 above when you can simply get back an <auditresponse> that has ALL that info in it?

It is tremendously dangerous if exposed to an attacker - and is another reason why proper transport protection and authentication needs to again be STRONGLY emphasized in the Security Considerations section.

------------------

My third comment relates to the remote management capabilities mentioned in section 4.4, "Audit Elements" on text page 56, where it
states:

    Second, auditing enables
    discovery of the existence and status of dialogs currently managed by
    the package on the MS.  This allows one AS to take over management of
    the dialogs when the AS which initiated the dialogs fails or is no
    longer available.

I know from other email exchanges that this relies on capabilities in the underlying framework - but I think mention of this, and how such access can be restricted, definitely should be brought into the Security Considerations section of this document.

Those were the major points that jumped out at me as I went through
the document looking at it from a security point-of-view.   I did not
do an exhaustive study of all the various interactions, but these were the ones that jumped out at me.

Regards,
Dan