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