asterisk users - Feb 2010 - Important security alert: update your dialplans now!

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).

Excellent and very informative article, Thanks Olle.

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.
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. 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.



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
>

While I like these solutions, they should never be substituting a good
secure dialplan.

On Sun, Feb 14, 2010 at 3:04 PM, Steve Edwards
<asterisk.org at sedwards.com> wrote:
> On Sun, 14 Feb 2010, Kyle Kienapfel wrote:
>
>> strip_ampersands(${EXTEN})?
>
> (sip.conf)
>
> [general]
> ? ? ? ?allow-characters ? ? ? ? ? ? ? ?= all
> ? ? ? ?disallow-characters ? ? ? ? ? ? = "&"
>
> [example-did-provider]
> ? ? ? ?allow-characters ? ? ? ? ? ? ? ?= "[:numeric:]"
>
> --
> Thanks in advance,
> -------------------------------------------------------------------------
> Steve Edwards ? ? ? sedwards at sedwards.com ? ? ?Voice: +1-760-468-3867
PST
> Newline ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Fax: +1-760-731-3000
>
> --
> _____________________________________________________________________
> -- 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
>

Or one could simply rewrite to:

[incoming-from-voip]
exten => XXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)
exten => XXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)
exten => XXXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)
exten => XXXXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)

[incoming-from-voip-old]
exten => _X., 1, dial(SIP/${EXTEN})

To avoid extensive rewriting and fix the current issue.
l.


2010/2/14 Steve Edwards <asterisk.org at sedwards.com>
> On Sun, 14 Feb 2010, Kyle Kienapfel wrote:
>
> > strip_ampersands(${EXTEN})?
>
> (sip.conf)
>
> [general]
>        allow-characters                = all
>        disallow-characters             = "&"
>
> [example-did-provider]
>        allow-characters                = "[:numeric:]"
>
>  -


-- 
Loway - home of QueueMetrics - http://queuemetrics.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100215/4c5de0cf/attachment.htm

I have read the posts about the security issue and from what I  
understand there should be a check to make sure that the characters  
used are actually allowed. I wrote a very straightforward and not so  
rocket science kind of macro that will do the job I guess. Just two  
parameters, one with the allowed characters and one with the string to  
check. The allowed characters can be stored in a global variable if  
this set has a global character. It is just one extra line in the  
dialplan and a little bit extra cpu load.

It is used like this:



exten => _XXXXXXXXX.,1,Macro(alfa_num_check,1234567890,${EXTEN})
exten => _XXXXXXXXX.,n,Dial(SIP/315927xxxxxx/${EXTEN},40,t)
exten => _XXXXXXXXX.,n,Hangup()

If not allowed characters are used the call setup will end.

And the actual macro does just have 20 lines of Asterisk code. I'm  
sure there will be better solutions in the future but for the short  
time this might be useful. A clever scripter might be able to write a  
script that scans the dialplan line by line and adds the macro line  
above the _XXXX.,n,DIAL() lines and adjust the numbering of the line  
if needed.   I have done some testing and the code in this mail  
ishould work, at least it did on my Asterisk box.


Friendly regards,




Erik

[macro-alfa_num_check]
;;;;;;;;;;;;;;;;;;;;
; written by  : erik de wild
; company  : Tripple-o    Your Asterisk migration partner
; e-mail        : info   at   tripple-o.nl
; date           : 16 februari 2010
;
; everybody is free to use, improve and modify this code
; as long as credits will be addressed, no costs are charged
; and this header stays with the code.
;;;;;;;;;;;;;;;;;;;;;
exten => s,1,NoOp(This is a macro to check the content of the ${EXTEN}  
variable to cope with the vulnerabilily of number injection)
exten => s,n,Set(ALLOWED_CHARACTERS=${ARG1})
exten => s,n,Set(STRING_TO_CHECK=${ARG2})
exten => s,n,Set(LEN_ALLOWED_CHARACTERS=${LEN(${ALLOWED_CHARACTERS})})
exten => s,n,Set(LEN_STRING_TO_CHECK=${LEN(${STRING_TO_CHECK})})
exten => s,n,Set(COUNTER=0)

exten => s,n(start_loop),SET(CHAR_TO_CHECK=${STRING_TO_CHECK:$ 
{COUNTER}:1})
exten => s,n,NoOp(Character to check is ${CHAR_TO_CHECK}. This  
Character should be in this list of characters -> ${ALLOWED_CHARACTERS})
exten => s,n,Set(COUNTER2=0)
exten => s,n,NoOp(character to check: ${CHAR_TO_CHECK}    -> $ 
{ALLOWED_CHARACTERS:${COUNTER2}:1})

exten => s,n(start_loop2),GotoIf($["${CHAR_TO_CHECK}" = "$ 
{ALLOWED_CHARACTERS:${COUNTER2}:1}"]?exit_loop2)     ;
exten => s,n,Set(COUNTER2=$[${COUNTER2} + 1])
exten => s,n,GotoIf($["${COUNTER2}" =
"${LEN_ALLOWED_CHARACTERS}"]?
hangup)
; if the character to control is not in the list of allowed   
characters then the setup of the call has to stop

exten => s,n,Goto(start_loop2)
exten => s,n(exit_loop2),NoOp(character checked is allowed, go for the  
next charachter!!)

exten => s,n,Set(COUNTER=$[${COUNTER} + 1])
exten => s,n,GotoIf($["${COUNTER}" =
"${LEN_STRING_TO_CHECK}"]?
macroexit)

exten => s,n,Goto(start_loop)

exten => s,n(hangup),NoOp(the checked character is not in the allowed  
charachter string. Call setup has to stop)
exten => s,n,Hangup()

exten => s,n(macroexit),MacroExit()




On 14 feb 2010, at 00:04, Olle E. Johansson 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