[asterisk-users] Important security alert: update your dialplans now!

C F shmaltz at gmail.com
Sun Feb 14 12:56:31 CST 2010


On Sun, Feb 14, 2010 at 3:26 AM, Olle E. Johansson <oej at edvina.net> 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 <oej at edvina.net> 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 - oej at edvina.net
> * 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
>



More information about the asterisk-users mailing list