12 Kommentarer

  1. Karsten Pedersen
    Karsten Pedersen april 2, 200814:01 | | Svar

    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. Hasse
    Hasse april 2, 200822:28 | | Svar

    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. Thomas Clausen
    Thomas Clausen april 3, 200807:40 | | Svar

    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. Søren
    Søren april 24, 200822:11 | | Svar

    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. Søren
    Søren april 24, 200822:13 | | Svar

    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. -herman Ransborg
    -herman Ransborg april 25, 200803:52 | | Svar

    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. Thomas Clausen
    Thomas Clausen april 25, 200808:58 | | Svar

    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. Søren
    Søren april 25, 200809:25 | | Svar

    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. Søren
    Søren april 25, 200809:40 | | Svar

    Og lige en update fra Musimi’s tid:
    https://musimi.dk/index.php/forum2/thread/forumid=3/id=2018/

    Mvh,
    Søren

  10. -herman Ransborg
    -herman Ransborg april 26, 200823:47 | | Svar

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

  11. Soren
    Soren april 29, 200812:51 | | Svar

    #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

  12. Alvorlig sikkerhedbrist hos Perspektiv Bredband nu rettet | VoipBloggen

    [...] Perspektiv Bredband der tidligere er kendt som CPH-Metronet har igennem længere tid haft en alvorlig sikkerhedbrist i opsætningen af deres provisionering (det at udbyderen kan fjernstyre en voip-boks). Bristen har betydet, at samtlige Perspektiv Bredbands telefonikunder har haft deres login og kodeord kompromitteret. [...]

Skriv en kommentar