strip_ampersands(${EXTEN})?
On Sun, Feb 14, 2010 at 10:56 AM, C F <[email protected]> wrote:
> On Sun, Feb 14, 2010 at 3:26 AM, Olle E. Johansson <[email protected]> wrote:
>>
>> 14 feb 2010 kl. 03.25 skrev C F:
>>
>>> Excellent and very informative article, Thanks Olle.
>> You're welcome.
>>>
>>> I ran thru lots of my dialplans now quickly to see if I have a catch
>>> all exten anywhere. I couldn't find any that are accessible
>>> unauthenticated, I always declare all fixed length extensions using
>>> patterns the exception being international calls, but those are in
>>> contexts accessible only from an inside - therefore authenticated -
>>> SIP client.
>> While I understand you, I don't want to recommend any policy saying that
>> "the inside are allowed to do anything". Experience in network security
>> tells us that many problems start on the inside. You simply can't divide
>> issues like this between "inside" and "outside" when working with security.
>>
> Agreed. Using your filtering technique we would accomplish alot more.
>
>>> In my opinion there is really no reason why a catch all exten should
>>> be used for unauthenticated clients.
>>> Neither should it be used in any default contexts like [default]. If
>>> one declares all fixed lengths extens and doesn't expose any non fixed
>>> length ones then s/he is safe.
>> Well, it's not that easy. In Sweden we have variable length phone numbers,
>> as do many international dial plans. If you want to allow calling to these
>> PSTN destinations, you will need pattern matching. Which makes you also want
>> to use filters.
>
> Why cant there be 2 or 3 declared fixed length extensions? like
> _XXXXXXXXXX for 10 digit length and _XXXXXXXXXXX for 11 digit and so
> on. The point is there shouldn't be any _X. or _. .
> Anyhow, as pointed out by others, while fixed length will allow to
> filter out long extensions it will not filter out short ones, which
> even though in my opinion practically fixes the problem. The real
> solution is only to actually filter out ${EXTEN}.
>
>>
>> Allowing calling to Internet-based SIP uri's is a different story, but you
>> can easily handle those too.
>>
>>> However your article is very
>>> informative about how to filter them.
>>> The fix for this - at least at the moment - is education. I doubt it
>>> will take too long to see script kiddies exploiting this.
>> I can not agree more!
>>
>> Thank you for the feedback.
>>
>> Regards,
>> /Olle
>>>
>>>
>>>
>>> On Sat, Feb 13, 2010 at 6:04 PM, Olle E. Johansson <[email protected]> wrote:
>>>> Friends,
>>>>
>>>> Last week, Hans Petter Selansky alerted us of a potential security issue
>>>> in all releases of Asterisk. In fact, it doesn't involve the code, but the
>>>> most common way to construct dialplans. If you have something like this in
>>>> your Asterisk, you need to update your dialplans:
>>>>
>>>> [incoming-from-voip]
>>>> exten => _X., 1, dial(SIP/${EXTEN})
>>>>
>>>> Many VoIP protocols support a large character set, that may cause harm in
>>>> your dialplan
>>>> ====================================================================
>>>>
>>>> I've written an article about this on my blog, where my summary says:
>>>>
>>>> "Because of a conflict between allowed characters in the called number or
>>>> name in many VoIP protocols and the way Asterisk handles channel
>>>> variables, there is a security risk hidden in many dialplans based on
>>>> examples provided over the years by the Asterisk developers, trainers and
>>>> community. The primary risk is that by using an ampersand in the
>>>> dialstring, a user can access protected resources or misuse the pbx
>>>> services. However, this character is not the only problem, as other
>>>> characters may cause unexpected or problematic behaviour."
>>>>
>>>> There will be an Asterisk Security Advisory document coming out from
>>>> Digium soon, as well as updated documentation and examples within the
>>>> Asterisk source code tree. I strongly advise everyone to follow these and
>>>> stay updated. (I have no access to the ASA system myself and can't
>>>> generate an official security alert).
>>>>
>>>> For more information about this issue and some code examples of what I
>>>> personally currently think are good ways to prevent misuse of your
>>>> services, please read my blog article at
>>>>
>>>> http://www.voip-forum.com/?p=241&preview=true
>>>>
>>>> Please help us to distribute this message!
>>>> =================================
>>>> We need help from all involved in the Asterisk eco-system. This is not
>>>> something that the development team can solve by itself. We can add
>>>> documents, READMEs and fix our own examples. But that won’t fix it. We
>>>> need everyone involved to pump this information out in all the veins that
>>>> runs through the Asterisk eco-system. In all languages needed, we shall
>>>> say: "Audit your dialplans, fix this issue. And do it now."
>>>>
>>>> Everyone that runs a web site with dialplan examples - audit your
>>>> examples, fix them. Everyone that has published books on Asterisk -
>>>> publish errata on your web site. Please help us - and do it now.
>>>>
>>>> If you add web links, please add links both to http://www.asterisk.org
>>>> where the official documents will soon be published, as well as to my blog
>>>> (if you like, of course). But don't just refer to my blog entry alone.
>>>>
>>>> I have updated my own servers and will now start auditing my customers'
>>>> servers. After that I will have to update all my training materials so I
>>>> don't repeat the bad examples. There's no magic bullet, no wonderful code
>>>> patch, that can fix this, just hard work with all dialplans that accept
>>>> calls over VoIP channels.
>>>>
>>>> Let us all work together to fix this!
>>>>
>>>> With Asterisk greetings!
>>>>
>>>> /Olle
>>>>
>>>> PS. If someone can update the entries on Queue() and Dial() in
>>>> voip-info.org, that would be considered a good thing (TM).
>>>> --
>>>> _____________________________________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> asterisk-users mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>> ---
>> * Olle E Johansson - [email protected]
>> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
>>
>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
