Billede af Aunto
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.
Vi fik nys om problemet på Voipsnak og tog kontakt til brugeren Hasse, som opdagede hullet. Hasse var dog ikke til at presse. Han ville gerne have at udbyderen (som på daværende tidspunkt stadig var os ukendt), havde rettet hullet, før vi bragte historien.
Det lyder på Hasses forklaring som om det ikke er alle og enhver der kan gøre dette, men har man bare lidt teknisk indsigt, vil det kunne lade sig gøre. Og har man både teknisk indsigt og ond vilje, så er det rigtig trist.
Vi har fået Perspektiv Bredbands direktør i Sverige Fredrik Winbladh i tale om dette problem:
Der var ganske rigtigt i sikkerhedsproblem i vores IP-telefoni som én med stor teknisk viden ville have kunnet finde. Problemet er nu afhjulpet og vi er meget taknemmelige, for at have fået oplysninger om problemet, så vores kunder ikke kan rammes af en eventuel indtrængning. Jeg vil pointere at fejlen ikke kunne have ført til aflytning af samtaler! En indtrænger ville have kunnet ringe fra en andens telefonnummer, men vi har ingen beviser for at det er sket. Men der har været en risiko for at det kunne have sket og det ville være meget let at spore hvis det skulle være tilfældet.
Hvad var fremgangsmåden så? Her er hvad Hasse fortalte os:
Serveren fortalte selv hvilken nøgle den manglede
Ved at kigge nærmere på den trafik der går mellem voip-boksen og Perspektiv Bredbånds server, fik Hasse at vide at trafikken var ukrypteret og han fik et svar i stil med: “Du har ikke inkluderet nøglen “asdfasdfg978asdf7890sdfg89d7″, når han forsøgte at kontakte provisioneringsserveren. Ved næste forsøg brugte han så denne nøgle, og så fik han oplyst både brugernavn og adgangskode til telefonkontoen.
Fredrik Winbladh siger:
Der var en fejl der gjorde at hvis man opfangede trafikken mellem en af vore ATA-bokse og vores server, så kunne man finde ud af protokollen for at hente denne information, og hvis man derefter gættede en anden kundes MAC-adresse, kunne man se konfigurationen for boksen (inkl. kodeordet). Det rettede vi i april i år.
Hasse kunne dog stadig foretage denne manøvre den 23. maj, selvom Perspektiv lovede at den var udbedret den 6. april. Perspektiv rettede dog fejlen den 23. maj umiddelbart efter Hasses anden henvendelse til Perspektiv Bredband. Til det siger Fredrik Winbladh
Den første fejl (det at man kunne få fat i konfigurationsoplysningerne vha. en MAC-adresse) blev rettet med det samme. Og vi ændrede også kodeordene. De øvrige forholdsregler tog længere tid, for det indebar en stor systemændring, men det gik hurtigt, når man tænker på omfanget af ændringer.
Mac-adressen på boksen
Når man kender kodeordet til provisionering og brugernavn og adgangskode til telefonkontoen, har man bare brug for en ip-adresse. Perspektiv Bredband anbefaler, at man sætter voip-boksen før sin router, så en evt. firewall ikke blokerer for trafikken. Når man kender sin egen ip adresse, så er det ikke svært at finde andres adresser. Man skal bare gætte (IP adresser er tit fortløbende numreserier hos udbyderne) eller sætte en portscanner op til at finde alt der svarer til den port hvor Perspektiv Bredband har lukket op for web-konfiguration.
Samme admin-kodeord til alle bokse
Perspektiv Bredband havde valgt at bruge samme admin-kodeord til alle deres bokse. Derfor kunne man logge ind og se folks sip-brugernavne og kodeord.
Fredrik Winbladh fra Perspektiv bredband fortæller os hvad De har gjort for at sikre at en sådan sikkerhedsbrist ikke indtræffer igen.
Systemet er korrigeret så hver boks får et unikt ID ved registrering og dette ID bruges ved kommunikation med serveren. Det kan man ikke gætte sig til, så man kan ikke lure sig til en andens information fra serveren.
Administratorkodeordet for ATA-boksene er unikt for hver boks og ændres en gang om måneden. Så selvom man knækker koden til sin egen boks, hjælper det ikke med at komme ind i andres bokse. Heller ikke selvom man kender en anden boks’ IP-nummer og den ikke er bag en firewall.
Kodeord for SIP-kontoen ændres en gang om måneden (og efter at vi blev gjort opmærksomme på dette problem). Dermed er ingen eventuelt kompromitterede data korrekte.
Vi mener, at der med denne historie er sat fokus på én af de problematikker, der kan være med provisionering. Glædeligt er det dog at Perspektiv Bredband nu har taget et stort skridt til at sikre deres løsning.
Robert Sand
Ole Rasmussen
Chano Andersen
Arne Bolen
Version 2 har valgt at bringe historien. Den bliver dog ikke bragt meget videre end copy/paste af nogle væsentlige afsnit.
Hos Musimi kan man anvende en hvilken SIP enhed man ønsker, man skal bare selv sætte det op og der er vejledninger til en del.
Anvender man en Linksys/Sipura SPA så er der en udmærket wizard til hjælp. Der blev også på et tidspunkt lavet en testløsning til SPA, hvor man styrede opsætning med provisioning, men denne løsning blev efter min opfattelse aldrig færdiggjort, i hvert fald mener jeg at dette hos Musimi var sikkerhedsmæssigt en tand værre end beskrevet her.
På Musimi hjemmesiden blev der oprettet et menupunkt til denne ‘test provisioning’. Det betød at en del anvendte provisioning opsætningen uden at vide at de satte deres løsning op med noget der ikke var færdigudviklet. Vi var nogle stykker som forsøgte at adressere problemerne, fx bare at få fjernet menupunktet igen, når de egentlige problemer ikke blev løst. Efter Tellio overtog Musimi så har der tilsyneladende ikke været ressourcer til at ændre på noget som helst. Jeg har læst at Musimi provisioning nu fejler, så det ikke længere er anvendeligt og godt det samme, for så er der jo ikke flere som bruger det. Jeg har dog ikke selv haft tid til at afprøve om det nu er i lykkelig udu. Menupunktet SIP-enheder er der stadig (på bedste Musimi stil).
Jeg er ellers udmærket tilfreds med Musimi og jeg synes ikke der er nogen grund til nu at blæse op, hvad det var i deres provisioning, som var værre, selv om det der er beskrevet i indlægget her ellers kunne være en udmærket reference.
mvh / Herman
Jeg har faktisk talt lidt med Hasse om Musimis provisionering som du omtaler Herman. I følge ham, så fungerer den stadig.
Jeg har desværre ikke en Sipura mere, da den er gået videre i systemet
men hvis der er andre, som har én liggende og kan teste, så ville det da være spændende at høre om Musimis provisionering stadig fungerer.
Hej Thomas – på din opfordring så har jeg just prøvet med Musimi provisionin. Som det kører nu hos Musimi så kan man ikke snuppe en andens opsætning. Så Musimi er ok. – Jeg vender tilbag med mere info. Har ikke lige tid til at formulrer det nu. mvh/ Herman
Ok,
Jeg legede igen lidt med Musimi provisioning, og jeg faldt ikke over noget som gør at løsningen kan misbruges til at smutte ind med forbrug på andres konti. Dette er dog ingen garanti for at alt er ok. Man skal både kende en andens MAC adresse og provisioning kodeord for at kunne plagiere ham. Det fandt jeg ikke en måde man kan hos Musimi.
Forløbet i opsætningen hos Musimi:
Inden vi starter med Musimi provisioning har vi i vores opsætning hos Musimi valgt telefonnummer og vi har valgt vores SIP login kodeord for dette nummer. Som vi også gør ved manuel opsætning. Informationen ligger derefter i databasen hos Musimi.
Når vi sætter vores SPA’s provisioning op hos Musimi, via Musimi menu punktet SIP-enheder, kan vi kun vælge iblandt de telefonnumre vi selv har. Vi skal derefter taste SPA’s MAC adresse og IP-adresse. Hertil giver Musimi lidt vejledning i, hvordan vi finder det for vores SPA. Med disse informationer henter Musimi de øvrige data som fx SIP login i det vi tidligere har lagt ind, og sender provisioning opsætningen til SPA. Det virker stadig.
SPA er hermed sat op så den med mellemrum (hver time og ved genstart), med provisioning, henter en ny kopi af sine opsætningsdata hos Musimi. Den får sandsynligvis også ny SIP login kode, hvis vi senere vælger at ændre på det i vores opsætning hos Musimi.
Der kunne være forskellige hackertiltag, som man kunne have lyst til at prøve, fx om man kan snyde med MAC adressen. Men det alene er ikke nok til at plagiere en andens opsætning.
Kodeord tildelt til provisioning er lang og det er nok en unik kode Musimi laver til hver. Der er nok ingen problemer her, og dermed må Musimi provisioning være ok. Det jeg bl.a. mente at kunne huske fra da jeg for længe siden prøvede dette sidst, var at koden var kort og det lignede noget, som måske var ens for alle. Den er i hvert fald ikke kort nu og det kunne godt ligne noget Musimi genererer som en unik kode.
Skulle man snyde sig ind på en andens provisioning så skal man både have hans MAC adresse og hans kodeord til provisioning. MAC adressen kunne man nok prøve sig lid med, men når kodeordet er lang og unikt så er det nærmest umuligt.
Man kan sandsynligvis sniffe sig til meget, endvidere ved Musimi provisioning aktivt så kan man let gå ind på sin egen opsætning via SPA’s web-brugersnitflade, fordi Musimi låser ikke SPA med Admin og User password. Her kan man fx hente, hvad det er for streng der sendes (Provisioning Profile Rule:) når der hentes en ny opdatering med provisioning, men man kan ikke ud af informationen her gætte sig til en anden brugers streng. Og man har jo ikke ved normale forhold mulighed for at sniffe andres trafik af data. Jeg kunne godt forestille mig at dataen der sendes ved Musimi provisioning er let læseligt, at det ikke sendes krypteret, så det er let at sniffe. Hvis jeg har 2 SPA på mit lokalnet, så kan jeg sniffe dem begge. Operatørerne hos min internetudbyder kan også sniffe mine data. Jeg har også hørt om modificerede kabelmodems, hvor man kan sniffe data på den streg man sidder på, men det er ikke noget folk normalt har adgang til. Der kunne måske være noget sikkerhedsmæssigt her, men ikke noget jeg umiddelbart falder over.
Problemet med Musimi provisioning
Der er dog stadig det problem ved Musimi provisioning at man ikke ved, hvilke parametre der med provisioning styres i SPA, og hvilke man selv kan og bør styre. Brugerne har jo selv adgang til at sætte, hvad som helst op. Hvis man så mener at et eller andet bør være anderledes i måden man bruger SPA, så kunne det være en parameter, som provisioning indenfor en time sætter tilbage igen til hvad det var tidligere, fordi denne parameter sættes via provisioning. Det har drillet en del når brugere søgte vejledning i Musimi forumet. Blot et eksempel: Styrer Musimi provisioning om der skal køres med STUN eller ej. Jeg mener at Musimi provisioning oprindelig styrede dette, men det gør Musimi provisioning tilsyneladende ikke nu.
Software opdatering af SPA kan også styres via provisioning og blev brugt tidligere. Det gav ingen problemer for mig mens jeg testede her. Men jeg mener det har været et problem hos Musimi fordi man ikke holdte opdateringer ajour. Måske har Musimi nu blot koblet muligheden fra selv om SPA med sin provisioning opsætning stadig sættes op så SPA skal checke om der er nyt. Det kan jo så være at serveren nu bare ikke svarer her.
SPA på offentlig IP
Sætter man sin SPA op så der er adgang til web-brugersnitfladen fra internettet og hvor der ikke er unikt kodeord for Admin og for User så kan andre ændre i parametrene. Med kun User login har man dog ikke adgang til det hele. Kan andre komme ind som Admin så kan de ændre hvad som helst og de kan hente en kopi af opsætningen som de så kan lægge ind i deres egen SPA. Kører man med provisioning så har de sådan set fat i det hele til at snylte på en anden bruger. Kører man med manuel opsætning så skal de stadig gætte hvad man har i SIP kodeord. Med SPA-2100 og lignende skal man vælge at der skal være adgang fra WAN siden før der er et problem her.
Hvis man selv kan finde ud af at sætte sin SPA op uden provisioning, så er sikkerheden her helt på egen hånd, og ikke noget halvgjort med provisioning – Det er hvad jeg har valgt.
I øvrigt, der findes et smart lille program SipuraUtil.exe, som i hvert fald kan bruges til de ældre SPA, som min SPA-3000. Med den tog jeg en kopi af min opsætning, inden jeg gik i gang med at prøve med provisioning, og når jeg så er færdig med at lege provisioning, så smækkede jeg lige med drag-and-drop min oprindelige opsætning ind på SPA igen.
Super kommentar Herman. Tak for uddybningen af hvordan det fungerer hos Musimi.
Jeg havde selv provisionering kørende, da jeg i sin tid købte en SPA2000. Men det var uden at have de fjerneste fornemmelse af hvad der egentlig foregik
Hej,
Lige to kommentarer:
Man har hos musimi mulighed for at bruge https til “Provisioning Profile Rule” URL’en (faktisk mener jeg det er default, man skal aktivt vælge en http indgang til Musimi for at få en http url), og så er det ikke muligt at blive sniffet af andre på sit LAN eller hos ISPen på vejen.
Mht. problemet, så husker jeg det som at vi endte med at have to URLer til provisionering: En med kun sip-server/brugernavn/kodeord/hvad der nu var under “SIP Konti”, og en anden som ud over det havde nogle regionale indstillinger for f.eks ringetoner.
Support-mæssigt er provisionering rigtigt smart. Man kan se hvornår adapteren sidst har bedt om nye indstillinger, og man er sikker på at kodeord er skrevet korrekt ind (#1 grund til “Hjælp jeg kan ikke ringe”).
Mvh,
Søren