Voipkunders login og kodeord kompromitteret

Telefonityveri
Telefonityveri

En bruger skriver i Voipsnaks forum, at han via linket til provisioneringen af sin adapter, har fået adgang til andre kunders brugernavn og adgangskode. Det er i givet fald et alvorligt problem og derfor arbejder vi på at få be- eller afkræftet at det forholder sig sådan. Vi har skrevet til brugeren via privatbeskedsmuligheden på voipsnak, men har endnu ikke fået noget svar.

Det fremgår ikke af indlægget hvilken udbyder det handler om, men hvis det der beskrives er muligt, sidder der mindst én udbyder med en alvorlig og meget kritisk sikkerhedsbrist. En brist vil betyde, at en lidt fingernem kunde, vil kunne ringe fra andre kunders numre og på den måde stjæle taletid.

Vi har prøvet at kombinere os frem ud fra det brugeren tidligere har skrevet i forummet. Ud fra dette kan vi finde tre muligheder: Musimi, Gratissip og Fonet. Da brugeren nævner sælgere og provisionering i sit indlæg (to ting som Musimi og Gratissip ikke tilbyder), så har vi regnet dem ude. Vi skrev til Fonets direktør Flemming Fogtmann for at høre hans mening, men hans tilbagemelding var at det ikke var dem der var tale om.

Jeg kan med sikkerhed oplyse, at det ikke er en FONET kunde. Vi har ikke denne form for provisionering.

Så sporet ender pt. blindt. Det kunne være interessant at få at vide om der er tale om noget enestående for en enkelt udbyder, eller om der er tale en en fejl i nogle af de meget anvendte programmer til at styre telefoni som fx Asterisk eller OpenSer.

Hvorom alting er, så vil vi stadig forsøge at finde ud af hos hvem fejlen ligger. Kom gerne med tip som kommentar til dette indlæg eller via kontaktformularen.

19 tanker om “Voipkunders login og kodeord kompromitteret

  1. Jeg har kontaktet Herman Ransborg, der er en meget erfaren herre indenfor voip og også har kommenteret et par indlæg eller tre her på bloggen, og han bekræfter at under bestemte forhold, vil det kunne lade sig gøre at aflure andre kunders kodeord mv. Det kunne være rigtigt interessant at høre hvilken udbyder der har været så lemfældig i sin systemkonfiguration at noget sådant er/har været muligt.

  2. Hej,
    mystisk jeg sendt dig et svar på din personlige besked et par timer efter at du havde stillet det.
    Gratissip, har været uregelmæssig så det er muligt at det ikke er kommet frem.

    Under alle omstændigheder havde jeg selv tænkt på at nogen ville finde mine tidligere indlæg for at finde frem til hvilken udbyder jeg hentyder til.
    Jeg ville derfor naturligvis ikke skive det omtalte indlæg hvis jeg vidste at nogen kunne finde frem til min udbyder.

    Du stiller mig spørgsmålet:
    “Kan du be- eller afkræfte at Fonet har denne sikkerhedsbrist?”

    og dertil svarede jeg:
    Nej, der er mig bekendt ikke nogen sikkerhedsproblemer med Fonet.

    Jeg har af personlige og arbejdsmæssige grunde haft travlt i de seneste dage og jeg har derfor endnu ikke taget kontakt til min udbyder da det kræver en hvis toldmodighed og tid at få dem i tale.

    Det er ikke den store åbenbaring jeg har fundet, men jeg vil naturligvis give selskabet mulighed for at rette fejlen før jeg kan sige mere.

    Jeg forsøger at komme igennem til dem i morgen.

  3. Hej Hasse

    Tak for dit svar.

    mystisk jeg sendt dig et svar på din personlige besked et par timer efter at du havde stillet det.
    Gratissip, har været uregelmæssig så det er muligt at det ikke er kommet frem.

    Ja, men selvom Gratissip har været ustabil pga. nedbrændte diske mm. så er det nok Voip-user, der er problemet her, jeg skriver lige til Thorkild som er admin derovre. :-)

    Det er ærgeligt at dit svar ikke kom igennem, for Karsten og jeg var jo edderspændte på hvem det kunne dreje sig om.

    Du stiller mig spørgsmålet:
    “Kan du be- eller afkræfte at Fonet har denne sikkerhedsbrist?”

    og dertil svarede jeg:
    Nej, der er mig bekendt ikke nogen sikkerhedsproblemer med Fonet.

    Vores første mistanke gik på Fonet, men efter at Flemming fra Fonet svarede på vores henvendelse, så var den tanke lidt ude af vinduet. Det efterlader jo nærmest kun Musimi som en kandidat, men du nævner i dit indlæg at udbyderen ikke ville lade dig styre din egen adapter, og det er jo netop én af Musimis forcer, at de lader brugerne styre deres egen hardware. Så du må have erhvervet dig en ny udbyder siden december 2007, hvor du kun havde 3 udbydere.

    jeg har derfor endnu ikke taget kontakt til min udbyder da det kræver en hvis toldmodighed og tid at få dem i tale.

    Er det Onfone ;-) De har i hvert fald deres problemer med svartider for tiden…

    Det er ikke den store åbenbaring jeg har fundet, men jeg vil naturligvis give selskabet mulighed for at rette fejlen før jeg kan sige mere.

    Det synes jeg er en god indstilling til sagerne, selvom vi stadig er meget nysgerrige. Det kunne dog være interessant at høre mere, når du har informeret udbyderen.

  4. Hejsan,

    Nu bliver Gratissip lige gættet på et par gange, så jeg vil da lige byde ind.

    Gratissip har heller ikke den slags provisionering der tales om; Provisionering af indstillinger på Sipura adaptere (hvad jeg lige kan læse af posten).

    Sipura adaptere har mulighed for at hente indstillinger ned gennem en ganske normal URL. Typisk optræder f.eks. MAC adressen i URL’en. Hvis man har minimal sikkerhed bør der også være en ekstra nøgle i URL’en, som kun brugeren kender. Hvis man ikke vil binde en MAC-adresse til kunden, så kan man også “bare” bruge kundens nummer i URL’en til at identificere adapteren – ja, der er mange dårlige løsninger :-)

    Eksempler på URL’er som jeg har beskrevet:
    http://provider.dk/provision?mac=123456789012 (bare MAC-adressen)
    http://provider.dk/provision?mac=123456789012&key=asdfasdflkja (MAC-adresse + noget som kun kunden kender)
    http://provider.dk/provision?number=80808080 (telefonnummeret)

    Telefonnummeret er nok det ringeste, da de fleste godt kan gennemskue at en udbyder kun råder over nogle bestemte nummerblokke, så man kan prøve alle i blokken.

    MAC-adressen er minimalt bedre. Hvis udbyderen tilbyder provisionering er det nok også fordi de “giver” adaptere til kunderne. Hvis de gør det, er det sandsynligt at de tager partier hjem af adaptere, hvor MAC-numrene så fra fabrikken vil være fortløbende, så også her let at gætte andre kunders MAC-numre.

    Hvis man så bare tilføjer et “hemmeligt” element, som skal matche før provisionerings-indstillinger gives, så vil det være meget vanskeligt at gætte URL’en til andre brugeres provisionerings indstillinger.

    Det her er så på side 1 af elementær web-applikation sikkerhed bogen – og meget lig f.eks. denne. Men, et hint er altså at kigge efter udbydere som “giver” SPA’ere til kunderne, og tilbyder at det “bare virker” uden at de skal gøre noget…

    Musimi havde i sin tid sådan noget, men jeg kan ikke huske hvordan det virkede, og da jeg lige vil prøve det, ser det ikke ud til at det virker mere på hjemmesiden, så den er vist udelukket – desuden tvivler jeg også på at Musimi/Telio har lavet pre-sale som lover kunden noget :-) (og, jeg går selvf. også ud fra at jeg selv ville have lavet det ordentligt i sin tid)

    Mvh,
    Søren

  5. Gratissip har dog provisionering af Grandstream adaptere: http://gratissip.dk/firmware/ – Grandstream’s tftp protokol er ikke helt så avanceret som SPA (nu er den ved at blive det dog), så der er en disclaimer

    please be aware that it is probably not a good idea to save settings like passwords on our servers. While we take the most care of securing the servers, you must be aware that you are giving away your password to a 3rd party (Gratissip).

    Mvh,
    søren

  6. Det er længe siden jeg prøvede Musimi provisioning. Så vidt jeg husker så var feltet Provisioning -> Profile Rule: https://prov.musimi.dk:4430/sipura/?unikkey=… – Jf. Sørens indlæg.

    Det der så stod i unikkey mener jeg ikke var noget vi valgte som bruger, men det blev tildelt af Musimi og man kunne have mistanke om at der faktisk stod det samme for alle :)

    Man skulle taste MAC adressen ind hos Musimi – Så ved Musimi provisioning blev man valideret ud fra MAC adressen og sikkert reelt ikke andet.

    Det normale er vel, når der bruges provisioning at der også samtidig bliver lavet en user og admin login til web konfig siden så brugerne her ikke har mulighed i at se, hvad der står i SPA feltet Provisioning -> Profile Rule.

    Musimi låste ikke med user og admin login

    Så i tilfældet Musimi provisioning så tror jeg faktisk godt man kunne snyde sig over på en anden bruger ved i SPA opsætningen at ‘klone’ en anden MAC adresse, og så håbe på at en anden bruger har netop denne adresse. I Musimi provisioning kunne det måske tænkes, at en af parametrene som blev sat var at man ikke får mulighed for at vælge klonet MAC adresse. Så kunne man nok ikke snyde.

    Men et er at tro det og et andet er at vide – og jeg havde aldrig prøvet. Og ifølge Søren, så virker Musimi provisioning ikke længere, så det kan ikke afprøves.

    – For at undgå at brugerne kan manipulere med provisioning så er det nok nødvendig at man ikke kan komme ind på web konfig siderne, og som Søren nævnte, at der er en ægte personlig kode i feltet Provisioning -> Profile Rule. Og måske det at man ikke kan vælge at klone MAC adressen.

    En garvet hacker ville så nok sniffe engen trafik på nettet for at prøve at få fat i egne parametre (jeg ved ikke om de er krypteret), og dernæst for at prøve om man med et program kan simulere andre, så man der kunne få deres SIP login. Her kommer så igen, hvis der er en unik nøgle, som kun kunden kender, så er det vanskeligt.

  7. Jeg tænkte i går, at jeg skulle have fat i Hasse igen, og skæbnen ville det, at Søren vakte dette indlæg til live igen :-)

    Jeg har skrevet til Hasse, og han vil gerne sige lidt mere snart, da udbyderen er informeret og har rettet fejlen.

    De udbydere vi havde i spil i vores lille detektivarbejde ;-) var udelukkende basseret på Hasses aktivitet på Voip-User, men udelukkelsesmetoden synes at udelukke alle tre, og så sad vi tilbage med forhåbningen om at Google ville kunne hjælpe os, men ak nej :-)

    Men det er rart lige at høre hvordan provisioneringen virker hos Gratissip og Musimi.

  8. Hej Herman,

    Jeg tænkte mere på at prøve det i Web interfacet, jeg kunne ikke oprette min telefon under “SIP-enheder”.

    Det der så stod i unikkey mener jeg ikke var noget vi valgte som bruger, men det blev tildelt af Musimi og man kunne have mistanke om at der faktisk stod det samme for alle :)

    Jeg er i tvivl om hvordan den unikkey blev beregnet ja, men jeg er ret sikker på at det ikke er den samme for alle brugere. Det ville ikke give nogen mening med en unikkey hvis den var.

    Det normale er vel, når der bruges provisioning at der også samtidig bliver lavet en user og admin login til web konfig siden så brugerne her ikke har mulighed i at se, hvad der står i SPA feltet Provisioning -> Profile Rule.

    Det var ikke den måde Musimi’s provisionering virkede. Musimi var/er et ‘bring your own device’ produkt, man går ikke ind og laver den slags på folks egne bokse. Det der blev provisioneret var “simple” settings, som sip-brugernavn, sip-kodeord, sip-server, ringe/busy/no-such-number toner, og lign., altså ikke noget som på nogen måde skulle hemmeligholdes for brugeren.

    Man kan selvf. argumentere hvorfor brugerens kodeord også, men som sagt sikkernheden ligger i at det er https (så andre ikke kan “sniffe” dit kodeord over nettet) og så den unikke nøgle som andre ikke kan gætte (Brugeren må hjertens gerne selv se nøglen, det er jo hans egne indstillinger).

    Det kunne i princippet have været et kodeord brugeren selv valgte i stedet for den beregnede nøgle. Erfaringen var bare at det er lettere at kode noget unikt end at bede folk om selv at indtaste noget – mener vores statistik var noget ala ~3% der havde deres telefonnummer som kodeord, og ~40% som havde et 4 eller 6 cifret kodeord (hint: deres fødselsdag :-) )

    Men som sagt, det er kun hvordan jeg husker at Musimi blev kodet, jeg har ikke den gamle source kode mere så jeg kan tjekke det, og selv om jeg havde, så kan der være lavet ændringer (noget er der ihvertfald lavet siden det svjks. ikke virker :-) ).

    Det sagt, så kan Musimi sikkert godt være et emne (bortset fra det med pre-sale og portering af nummer, som Hasse beskriver). Mener bare man kunne kigge på de parametre som jeg beskrev før; 1) Udbydere der har Sipura/Linksys som deres førstevalg, og 2) Som lover automatisk provisionering (at det er “let og man ikke skal gøre noget”).

    Mvh,
    Søren

  9. >Mener bare man kunne kigge på de parametre som jeg beskrev før

    Helt enig

    Det var heller ikke for at angribe hvordan Musimi provisioning var, at det var den jeg gik ud fra, men jeg havde minimal erfaringer der som bruger og ikke fra andre :)

  10. #10

    Nej nej, heller ikke opfattet sådan, bare en uddybning og nogen tanker om hvordan sådan noget virker ;-)

    Lad os håbe ham Hasse kommer ud af busken inden længe så vi ikke behøves gætte for meget…

    Mvh,
    Søren

  11. Furthermore, i believe that mesothelioma cancer is a extraordinary form of melanoma that is usually found in those people previously subjected to asbestos. Cancerous cells form while in the mesothelium, which is a shielding lining which covers the vast majority of body’s areas. These cells usually form inside the lining on the lungs, abdomen, or the sac which actually encircles one’s heart. Thanks for expressing your ideas.

  12. Ännu ett recept som mÃ¥ste provköras! Här hos fam Jonsson-Sjöberg sÃ¥ bestÃ¥r matsedeln av ca 80% ”Ã…se recept”, antingen ifrÃ¥n din underbara bok eller ifrÃ¥n bloggen. Bara smaskens, love it!! =)) Minus 17 kg nu!!12-Ã¥riga sonen sa häromdagen: ”Mamma all mat är ju jättegod men om du säger Ã…se en gÃ¥ng till sÃ¥ dör jag!”

Skriv et svar

Din e-mailadresse vil ikke blive offentliggjort. Krævede felter er markeret med *

Disse HTML koder og attributter er tilladte: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>