| |
|
|
|
|
 |
Nieuws: |
 |
|
|
Pagina's: [1]
|
 |
|
Auteur
|
Onderwerp: risicovolle numbermatching en number injection (gelezen 598 keer)
|
voop-fellow
Administrator
Jr. Member
 Offline
Berichten: 75
|
In de Asterisk non commercial mailing list is door Olle Johansson een discussie gestart over het risico van "number injection" bij het gebruik van de gangbare manier van number matching. Een voorbeeld van een risicovolle regel is:
exten => _XXXXX.,n,Dial(SIP/{EXTEN},40,t)
Als met een softphone 505&DISA gebeld wordt en er is een DISA extension dan zal die gebeld worden terwijl dit natuurlijk helemaal de bedoeling niet is. Ook kan zo het telefoon nummer van de directeur gebeld worden terwijl dit volgens het belplan niet kan. Dit zijn maar voorbeelden maar er kunnen allerlei ongewenste en niet bedoelde nummers en extensies gebeld worden.
De oorzaak van het veiligheids risico ligt niet in de code van Asterisk zelf maar in de manier waarop sinds jaar en dag belplannen gemaakt worden in Asterisk. Het is heel wonderlijk dat met alle knappe koppen die betrokken zijn bij Asterisk dit nooit eerder is opgemerkt of gezien. De mogelijkheid van number injection is nu in het volle licht gebracht en het is belangrijk dat iedereen die een Asterisk machine heeft draaien zijn of haar belplan doorloopt op "risico volle" numbermatching. Zie de onderstaande e-mail van Olle en zie de discussie op de Asterisk non commercial mailing list. http://archives.free.net.ph/thread/20100217.090755.f965ff40.nl.html
Onder de naam meetmecall heb ik een mogelijke oplossing toegevoegd die ongeveer hetzelfde doet als TRIM() . Met de door mij geposte oplossing kun je een string laten controleren op toegestane characters. Als een niet toegestaan karakter wordt gebruikt wordt de call setup beeindigd. TRIM() verwijdert de niet toegestane karakters uit een string. Als voor het gebruik van TRIM() de string langer is dan erna dan kan de call setup via een regel in het belplan beeindigd worden.
Resumé:
- Er is een security alert.
- Het is niet een met de code van Asterisk gerelateerd security issue.
- Het dringende advies is om belplannen goed te controleren op het gebruik van "risicovolle" number matching
- Het dringende advies aan leveranciers van grafische front ends voor Asterisk is om de codegenerator aan te passen ingeval "risicovolle" numbermatching gegenereerd wordt.
- Er zijn verschillende oplossingen beschikbaar waaronder TRIM() aangevuld met een controle op lengte en de door mij geposte Asterisk macro.
- Het probleem heeft nu de volle aandacht.
- Het is belangrijk dat iedereen die een Asterisk server heeft draaien op de hoogte gebracht wordt.
Met vriendelijke groet,
Erik de Wild
<<mail Olle Johansson>>
While we continue discussing all possible solutions to this and build an expanding knowledgebase, I would like to repeat myself and kindly ask everyone that blogs, twitters, talks and teaches about Asterisk to please spread the word and the links. Later today, there will be an official Asterisk Security Advisory published on http://www.asterisk.org. Take this as an oppurtunity to repeat yourselves and make sure that no Asterisk admin anywhere talking any language can miss this information.
If you are involved in a third-party project or commercial company that builds a GUI or anything that manages Asterisk dialplans, please make sure that your users are aware of this and that your project also releases information about this and if needed, updates your platform. If you are a distributor of Asterisk-related equipment, please don't hesitate to inform your resellers and customers.
Let's use all the resources we have to make sure that we limit the damage that this issue causes. And thank you to all of you that has already been forwarding information about this issue.
Best regards,
/Olle
My original alert is to be found here:
http://lists.digium.com/pipermail/asterisk-users/2010-February/244721.html
|
|
|
|
« Laatste verandering: februari 17, 2010, 03:13:55 pm door voop-fellow »
|
Gelogd
|
|
|
|
husky
Hero Member
Offline
Berichten: 1064
|
Kun je iets meer zeggen over de reproduceerbaarheid van deze alert.
Als ik met x-lite direct naar mijn asterisk server bel. Dus zonder hem aan te melden/registeren. Dan lukt het mij niet om dit gedrag te krijgen.
|
|
|
|
|
Gelogd
|
|
|
|
voop-fellow
Administrator
Jr. Member
Offline
Berichten: 75
|
Het is een algemeen risico bij het gebruik van _XXXX. numbermatching. Het probleem is dat er met de punt aan het eind geen limiet meer is voor de lengte van de invoer of de tekens die gebruikt worden en Asterisk vervolgens de ingevoerde string "verwerkt". Het heeft niet zozeer te maken met het wel of niet geregistreerd zijn van een softphone. Wel is het zo dat juist de meeste softphones toestaan dat er zowel letters als cijfers als bijzondere tekens waaronder & ingevoerd kunnen worden.
Mijn advies is om de informatie die hierover op korte termijn op www.asterisk.org zal verschijnen goed te lezen en te handelen naar het advies. Het artikel dat Olle Johansson geschreven legt uit wat de kern van het veiligheids issue is. De discussie op de mailing list geeft aanvullende info. Het ongewijzigd handhaven van numbermatching regels met een punt zonder aanvullende regels (bijvoorbeeld een aanroep van mijn macro) in het belplan is niet verstandig.
|
|
|
|
« Laatste verandering: februari 17, 2010, 10:34:30 pm door voop-fellow »
|
Gelogd
|
|
|
|
husky
Hero Member
Offline
Berichten: 1064
|
Ok, dat begrijp ik. Maar ik wil mijn servers hier op testen.
Niet aangemelde/onbekende telefoons komen in een andere extensie terrecht.
Vandaar dat ik dit hier mee als eerste uitprobeerde.
Als ik in x-lite bijvoorbeeld extensie 200 draai dan gaat die gewoon over.
(Als je in x-lite op de spatie balk drukt dan toggle je tussen numeriek en alphanumerieke invoer)
Draai ik dan 200&201 dan gaat het fout. ik krijg de melding "user not found"
of
Draai ik dan 200&disa dan gaat het fout. ik krijg de melding "user not found"
Is mijn configuratie dan veilig?
|
|
|
|
|
Gelogd
|
|
|
|
voop-fellow
Administrator
Jr. Member
Offline
Berichten: 75
|
Bedenk dat je ook een Local channel kunt aanroepen met een string. Een local channel is niets anders dan een context/extensie combinatie die aangeroepen wordt. Je kunt dus vanuit een deel van het belplan waar dat niet de bedoeling is een extensie aanroepen en dat is onveilig.
exten => _XXXXXXXX.,n,Dial(${TRUNK}/${EXTEN},40,t)
Stel ${EXTEN} heeft waarde 0592123456& Local/101@speed_dial
en in het belplan de context [speedial] bestaat met een lijst van korte nummers die doorverbinden naar externe nummers.
[speed_dial]
exten => 101,1,Answer()
exten => 101,n,Dial(${TRUNK}/0623417689,40,t) ; nummer burgemeester
exten => 101,n,Hangup()
Het gevolg is dat de burgemeester gebeld wordt. Dit is de kern van de geconstateerde onveiligheid. Dit los je op door TRIM() te gebruiken om niet toegestane tekens uit de invoer te halen , door mijn macro te gebruiken of op een andere manier te borgen dat daar waar het de bedoeling is dat één nummer ingevoerd wordt met het gebruik van & en de verdere invoer feitelijk 2 nummers ingevoerd kunnen worden.
Als 0592123456 een niet bestaand nummer is dan zal het local channel als enige aangeroepen worden en de telefoon van de burgemeester overgaan.
|
|
|
|
|
Gelogd
|
|
|
|
|
|
husky
Hero Member
Offline
Berichten: 1064
|
Ik snap het hele veiligheids probleem 
Ik wil het echter testen. De test die ik tot nu toe heb gedaan gaven aan dat mijn configuratie veilig was. Echter weet ik niet of ik goed getest hebt. (wil geen vals gevoel van veiligheid hebben)
Kun je aangeven hoe jij je server getest hebt. M.a.w. welke softphone gebruik je en welk nummer kies je bijvoorbeeld?
|
|
|
|
|
Gelogd
|
|
|
|
voop-fellow
Administrator
Jr. Member
Offline
Berichten: 75
|
Ik heb alle plaatsen in het belplan waar met _(XXX). gewerkt wordt of mijn eigen macro gebruikt (zie asterisk users mailing list) of de noodzaak om met _(XXX). te werken weggenomen. Ik heb het risico dus opgelost, ongeacht of in de specifieke situatie hiertoe de noodzaak bestond. Dit is ook de veiligste manier. Je kunt wel een anlyse maken en tot de conclusie komen dat er niets aan de hand is maar als je hierbij een vergissing maakt kan dit een heel dure vergissing zijn.
Mijn advies is dan ook om maatregelen te nemen op al de plaatsen in het belplan waar een _(XXX). number matching wordt gebruikt door of TRIM( ) te gebruiken, of mijn macro of een andere oplossing. Het per geval beoordelen of er daadwerkelijk sprake is van een risico is volgens mij niet verstandig en niet hanteerbaar. Het gebruik van _(XXX). numbermatching zonder voorafgaande check is naar mijn idee onverstandig, is per definitie niet veilig en dient om die reden dan ook vermeden te worden.
|
|
|
|
|
Gelogd
|
|
|
|
|
Pagina's: [1]
|
|
|
|
|
|
