Cyberangreb mod flere kommuner

DISCLAIMER: Jeg arbejder ikke for nogen af de ramte kommuner og artiklen her snakker altså i generelle termer og jeg laver nogle kvalificerede antagelser som muligvis kan være forkerte.

Flere medier rapporterer at flere kommuner er ramt af ransomware: (et mallware produkt der inficerer din computer, krypterer harddisken og kræver penge for at de-kryptere de igen)

For det første har der været meget lidt info om hvordan det er sker, umiddelbart vil jeg antage at der har været tale om ganske almindelig masseudsendt ransomware, dvs. der er ikke tale om en målrettet trussel.

Jeg tror mailen er sendt til en uerfaren bruger der uden at vide hvad han/hun gjorde har startet et program i mailen … altså _intet_ nyt i det. Der er heller ikke noget nyt i at folk der kender hinanden, i dette tilfælde kommuner, er blevet ramt samtidig. Det er netop ofrenes mail-kontakter der anvendes til videresendelse af spam.

Medierne får det til at fremstå (sikkert med god hjælp fra kommunens PR folk) som en mægtig fjende der målrettet er gået efter kommunen – hvilket ikke er tilfældet. Det betyder også at deres undskyldning falder til jorden – de er ikke oppe imod en mægtig fjende, de er oppe imod dumme brugere der ikke forstår at betjente deres maskiner på en sikker måde.

De er oppe imod en administrator der ikke forstår at sikre kommunens data på en tilpas effektiv måde, vi er oppe imod kommuner der ikke mener at IT Sikkerhed er tilpas vigtigt til at der skal bruges nok resourcer på det.

  1. Angrebet skulle slet ikke have været lykkedes i første omgang
    Uddan jeres medarbejdere, især medarbejdere med adgang til data. De skal vide hvad de må og hvad de ikke må. Angrebbet skulle være stoppet allerede der.
  2. Infrastrukturen skulle have fange den udførbare fil.
    Filer der skal udføres på maskinerne skal godkendes af en system administrator, almindelige medarbejdere skal ikke have lov at downloade en .exe fil eller noget som helst anden med en fjern chance for at kunne indeholde udførbar-kode.
  3. Medarbejderens PC Skulle ikke have haft adgang til at ændre alt
    Umiddelbar skriveadgang til mountede netværksdrev skal bare ikke være en mulighed, igen jeg kender ikke den konkrete løsninger. Men der findes mange forskellige systemer der kan løse dette.
  4. Masse-overskrivningen burde være detekteret automatisk
    Det kan godt være at Microsoft’s server ikke kan det, men så må det kobles på som et trediepartsplugin.
  5. Backup og snapshots reder dagen.
    Hvis det her var sket på et ordentligt sikret netværk havde vi fået vores filer tilbage ved at genetablere backupen, hvis de sidste 24 timers arbejde er tilpas vigtigt tager vi automatisk snap-show on-write og dermed havde vi rullet ændringerne tilbage på minutter.

Vi er altså oppe på 5 åbenlyse fejl som kommunerne selv har begået, i forbindelsen med løsningen af problemet er fejlene næsten ligeså slemme:

  1. Hvis dine filer er så vigtige så betal dummebøden!!!
    Du har ingen reel chance for at bryde krypteringen, hvis du laver network attack, debugger app’en og ham der har designet den er en idiot … så kan du måske knække den.Hvis ikke … så har du tabt.Der behøves nærmest ingen viden for at lave sådan et crypto-attack der ikke kan knækkes indenfor vores levetid.
  2. Fyr de ansvarlige medarbejdere
    En fejl af denne kaliber falder tilbage på IT Afdelingen og personen der startede malwaren på kommunens netværk. Jeg ener ikke nødvendigvis de skal fyres – men IT Chefen skal ihvertfald udskiftes. Han har ikke været sit job voksent, overhovedet.Han skal degraderes til IT Administrator og sendes på kursus, og vi skal have en ny IT Chef eller evt. en decideret Sikkerhedschef.Den menige medarbejder skal have en skriftlig advarsel, og sendes på kursus i sikkerhed for ikke IT-Folk, og nu vi er igang kan vi sende resten af afdelingen med.
  3. Sagen er meldt til politiet.
    For almindelige mennesker lyder det måske meget ansvarligt, for IT Sikkerhedsfolk ? Not so much … politiet kan intet gøre – og vi får intet ud af at finde den ansvarlige. Det eneste resultat er at vi spilder en masse resourcer og vi kommer videre til normaldrift.Rent teknisk er det rigtigt at forbryderen sider ude i verden og er skyldig, men praktisk set er skylden intern.Det her svigt er så alvorligt at det kan sammenlignes med at bankdirektøren glemmer nøglen til boksen på den lokale bar.

Min pointe mere kort:

Det her er kommunens egen skyld, det er den lokale IT Afdeling og KUN dem der kunne have stoppet det her fra at ske.

IT Sikkerhedsberedskabet i danske virksomheder og offentlige enheder stinker vi er mange der har råbt op om det i årtier, og vi er blevet ignoreret hen af en stribe.

Din opgave som almindelig borger er nu at stille krav til kommunen, til dit el-værk og til din tandlæge om at dokumentere at de har styr på sikkerheden. Kan eller vil de ikke det, så skift, råb op – gør verden opmærksom på det.

Det bliver ikke bedre før det gør ondt at svigte!

Tag abuse-henvendelser seriøst!!!

I starten af ugen modtog vi et angreb fra en stor dansk internet udbyder, vi fik alarmer og få minutter efter var angrebet afværget, fuldstændig standard procedure. Vi samlede logfiler og fandt kraftige indicier på at der ikke var tale om et botnet men faktisk en dansker der sad og afprøvede forskellige hackerværktøjer imod en af vores kunder server.

Jeg dokumenterede det aktuelle angreb (bruteforce attack mod WordPress) og sendte tidspunkter og logfiler til internet udbyderen, informerede dem om at ip adresse var blokeret og først ville blive clearet igen når de engang havde fået ryddet op på deres netværk.

100% standard procedure, og normalt fungerer det sådan at man får en mail med en undskyldning og en besked om at kunden er blevet informeret om problemet og at det enten er løst eller ved at blive løst.

Jeg modtager så følgende svar et par dage senere:

Hej Mikkel,

Jeg kan bekræfte, at IP-adressen har tilhørt en af vore privatkunder. Vi går ikke yderligere ind i sager som denne, da restriktioner over for vore kunders internetfærden hører uden for vore beføjelser. Vi behøver ingen information om, hvilke af vore IP-adresser, I blokerer. Dog skal jeg gøre opmærksom på, at vore IP-adresser er dynamisk tildelte, og at jeres blokering derfor kan betyde, at I også vil blokere andre [stor-dansk-isp]-kunder end den, der eventuelt har været skyld i angrebet.

Med ønsket om en god dag.
Support-nisse, stor-dansk isp A/S

 Efter at have læst den besked ved jeg da godt hvem jeg skal købe en internet forbindelse fra hvis jeg vil have lov at lave ballade uden konsekvenser … jeg var chokeret, sådan et svar havde jeg forventet at få fra Brasilien (faktisk er Latin-Amerikanske og Asiatiske ISP’er ofte meget mere imødekommende) … ikke fra en Dansk udbyder.

Så jeg rev mig lidt i skægget og skrev så flg. svar:

Hej Support-Nisse

Tak for dit svar, normal kotume når man modtager en abuse-repport fra en anden isp på internettet er at tage henvendelsen seriøst og sætte en stopper for det rapporterede angreb idet at det er i alles interesse at holde den slags på et absolut minimum, det antager jeg at i selvfølgelig også gør? med mindre det er jeres politik at tilbyde sikker-havn til hackere der ønsker at DDOS’e eller køre Bruteforce angreb fra jeres netværk?

Det er ikke korrekt at i ikke har beføjelser til at gribe ind overfor angreb udført fra / i jeres net, tværtimod er det normalt noget den enkelte internet udbyder håndterer internt og din besked om at i ikke går ind i sager som denne bekymrer mig, og det giver mig et indtryk af at min mail måske er nået frem til den forkerte.

Derfor har jeg tilladt mig at sætte dine direktører på CC af denne mail, da jeg er overbevist om at de forstår vigtigheden af en seriøs sikkerhedspolitik og et omdømme der ikke kan kobles sammen med dårlig sikkerhed og passivitet overfor kriminelle aktiviteter.

Dbh

Mikkel Christensen

Og den mail var så sendt cc til Adm. Direktør og Teknisk direktør i virksomheden (som jeg fandt på hjemmesiden). Jeg er virkelig chokeret over den uansvarlige opførsel fra en ISP’s abuse afdeling og jeg håber at der bliver taget hånd i hanke om problemet.

Hvordan håndtere dú dine abuse-repports?

Webudvikling: Sikker håndtering as passwords

Der er mange webudviklere som reelt ikke har den fjerneste ide om hvordan et password skal behandles, selv store sites som f.eks. LinkedIn har for nyligt vist at de ikke har styr på det.

1. Opbevar altid passwords krypteret

Hvis du som website udvikler på noget tidspunkt kan læse en brugers password, så er det en fejl. Passwords skal altid gemmes på en sådan måde at de ikke kan læses igen når de først er indtastet, det kaldes populært for “krypteret” mén faktisk er det forkert, fordi kryptering er pr. definition two-vejs, du kan kryptere og du kan afkryptere.

One-way hashing kan ikke “afkrypteres” men tilgengæld ved vi at det samme password altid vil give den samme hash og vi kan derfor blot sammenligne hashen af det gemte password med hashen af det indtastede password.

Som en sidste kommenar skal du altid bruge en sikker hash-algoritme, world-wide vækst indenfor computerkraft er eksponentielt og algoritmer der var sikre i 90’erne er idag nemme at bryde og dem der var sikre i 70’erne er endnu nemmere. Det betyder at f.eks. den populære md5 hash-function er usikker og ikke bør bruges, brug istedet sha-256 eller sha-512 som f.eks. kan implementeres med Php’s hash() funktion, derudover skal du bruge en unik salt pr. bruger/password.

2. E-Mail er så sikker som et postkort

Når du sender en email til en person så skal du forvente at det bliver læst af mindst 20 andre mennesker, din chef,  systemadministrator, internet udbyder, din kone, dine børn og et par tilfældige efterretningstjenester, hackere og spyware produkter.

Så det er aldrig acceptabelt at sende et password i en email, for det første fordi du ikke må have kendskab til brugeres password ifht. punkt 1, derudover giver du resten af verden hovednøglen til din bruger konto – og andre konti hvor denne bruger samme password.

Det er selvfølgelig heller ikke iorden at sende Visa/Dankort detaljer eller andre personlige information via E-Mail – og hvis du har behov for at sende f.eks. et password til en kunde, så generer et one-time-password til kunden som kun kan bruges én gang.

3. Begræns ikke password og udnyt entropy

Passwords skal være unikke og de skal være komplekse, hvis brugeren indtaster mærkelige tegn eller mellemrum, samt store og små bogstaver så er det alt sammen med til at gøre password sværere at gætte og hvis brugeren selv vælger at bruge disse tegn har kunden  formodentligt også styr på at taste password rigtigt hver gang.

Der er nogle sider der fjerner store og små bogstaver og specialtegn fra passwords, eller som giver en fejl hvis man indtaster et password med mellemrum i eller hvis man bruger specialtegn.

Jeg føler lidt at det er spild af jeres tid og sige det her, men jeg har set det flere steder og det er hamrende uprofessionelt og der er INGEN undskyldning for at simplificere brugerens password og da slet ikke for at begrænse brugerens password.

Det eneste du bør gøre ved dine brugeres indtastninger i et password felt er at hashe det, og gemme hashen. Punktum!

4. Undgå Information leaks

Når dine brugere glemmer deres passwords, og det gør de. Så skal de kunne genetablere det, det foregår typisk ved at du indtaster din email adresse på hjemmesiden og modtager en email med en one-time-url til at ændre dit password.

Det er sådan set fint nok, med mindre at formularen kan bruges til at gætte brugernavne med. Hvis du kan indtaste bruger@domæne.com og få beskeden “Beklager meget, men den indtastede adresse findes ikke i vores system” eller hvis du kan indtaste brugernavn og password og få beskederne hhv. “Dit brugernavn er forkert” og “Dit password er forkert”.

Ovenstående giver en angriber mulighed for at gætte sig frem til et gyldigt brugernavn, og det er selvfølgelig noget der skal undgåes.

Enkelte steder har jeg enddog opdaget at jeg blot ved at taste min email adresse får adgang til mit navn, adresse, telefon og email samt ordrehistorik.

Dette er selvfølgelig en stor fejl og skal undgåes, sørg for at en bruger altid skal oplyse både email og password, eller email kombineret med modtagelse af en email for at opnå adgang til opbevaret information.

5. Undgå at bruge passwords

Jeg kom lidt ind på det før med modtagelse af emails, hvis vi kan bygge et system uden brug af passwords vil det øge sikkerheden væsentligt.

Hvis vi f.eks. kan bruge two-factor authentifiation i form af email, sms eller telefonopkald så øger vi sikkerheden eksponentielt. Forestil dig at blive ringet op af en person der kender dig og blive spurgt om du er ved at logge ind på din webmail, hvergang du logger på. Personen kender din stemme og kender en række detaljer om dig. Så hvis personen ikke er sikker på stemmen bliver du spurgt om ting som farven på din bil, eller antallet af børn – eller lign.

Det giver sig selv at gør det meget sværere at omgå sikkerheden, men samtidig er det også lidt kluntet at skulle blive ringet op 10 gange om dagen – så lige mht. webmail er det måske ikke det smarteste, med mindre selvfølgelig du lægger en cookie på brugerens computer og lader telefonopkaldet gælde for lige netop dén computer i et bestemt antal dage, og i denne periode kan brugeren logge ind kun med sit password.

Telefonopkald af en personlig bekendt er måske i overkanten til langt de fleste applikationer, men SMS Verifikation er idag let tilgængeligt og billigt at implementere.

6. Anvend autogenererede passwords

Enkelte steder er det upraktisk at skifte passwords hele tiden og samtidig er det praktisk at kunne oplyse brugeren om sit password, det er f.eks. tilfældet ifht. webhosting hvor du har databaser og email konti der er indtastet flere forskellige steder.

Det er bestemt ikke optimalt men i mange situationer er det den udvej man rent administrativt har valgt, og derfor kan det give mening af opbevare passwords.

Til den slags konti skal du bruge autogenererede passwords sådan at du ikke risikere at kunden selv bruger sin dankort kode eller password til sin netbank, det skal være et unikt genereret tokken som kun bruges til den ene ting, du kan f.eks. bruge http://www.sikkeradgangskode.dk

Derudover anbefaler jeg at kombinere den type adgang med en ekstra for for kontrol, f.eks. logning af tilgang, ip adresse blokering eller lign.

Epilog

Er vi i mål nu? Nej … på ingen måde, men vi er godt igang. Hvis alle ovenstående punkter er nye for dig, tillykke, så er du en af de få der laver tingene ordentligt første gang.

Jeg har selv været ude for at må tage genveje på grund af deadlines eller nærige chefer, og har også selv været den der måtte ryde op efter det var gået galt.

Det koster som regel mere at ryde op når det ér gået galt, end det ville have kostet at gøre det rigtigt fra starten af og jeg vil også gerne understrege at det langt fra altid er programmørens skyld. Ligeså ofte er det projektlederen, direktøren eller marketingsafdelingen der stiller krav om at det f.eks. skal være muligt at oplyse kunden sit password.

 

Er dit CPR Nummer hemmeligt? Og hvor farligt er det egentlig hvis en hacker sletter CPR-Registeret?

Som bekendt blev CVR.DK hacket for et par uger siden, når vi snakker IT Sikkerhed er det oceaner af tid siden. Ikke desto mindre hørte jeg idag i radioen et indslag hvor en såkaldt “sikkerhedsekspert” fra et større dansk, også såkaldt “sikkerhedsfirma” fremsatte et par påstande der chokerede mig lidt, godt nok på en lidt anden måde end journalisten forventede.

De to udtallelser var (frit fra hukommelsen):

  1. Hvis en hacker får adgang til CPR Registret og sletter alting, går verden istå herhjemme, banken kan ikke udbetale din løn og lægen kan ikke give dig medicin.
  2. Hvis en hacker får adgang til dit, ellers fortrolige, CPR Nummer kan han ringe ned til banken og f.eks. optage et lån i dit navn.

Jeg er lidt ked af at jeg ikke kan finde citatet på skrift, det ville nemlig have være på sin plads at nævne virksomheden og personen ved navn. Men det må desværre blive ved tanken.

Er dit CPR Nummer hemmeligt? 
Nej dit CPR nummer er ikke mere hemmeligt end din adresse eller dit fulde navn, formålet med et CPR nummer er udelukkende at have en unik måde at identificere dig på. Lidt på samme måde som nummerpladen på din bil, så derfor kan du selvfølgelig ikke optage et lån i en andens navn blot ved at kende personens CPR Nummer.

Der findes fejlagtigt personer der tror dette, ligesom der findes eksempler på virksomheder der bruger kendskab til CPR Nummer til at autentificere personer … f.eks. dating sider. Det er i bedste fald en meget svag autentificering, i værste fald er det komplet ligegyldigt idet at et dating-site kan få adgang til CPR Registret så kan en hvilken som helst virksomhed med den rette økonomi også få adgang.

Jeg mener det er skadeligt at både det offentlige og samfundet generelt betragter CPR numre som noget hemmeligt, jeg har sågar hørt en receptionist på apoteket tysse på mig da jeg oplyste mit CPR nummer og jeg blev bedt om ikke at sige min pinkode højt, og i stedet vise mit sygesikringskort. Lige i situationen var jeg feberramt og havde ikke lige energi til en diskusion, så jeg stak hende mit kort og fik udleveret min penicillin.

Fun Fact. Kim Larsen udgav tibage i 1979 en plade hvor hans eget CPR Nummer udgør titlen på pladen.

Datatilsynet er hurtigt ude med riven ifht. registrering af CPR Numre, det virker som om at de også er af den opfattelse at CPR Numre kan og bør bruges som autentificerings-tokkens, og jo det ville da være rart med en sikker og officiel metode at autentificere danske statsborgere, men CPR Nummeret ér altså ikke metoden. Hvis vi for et øjeblik antager at det giver mening med et statisk tokken for at autentificere en person hvad er så problemet med at bruge CPR Nummeret til det?

  • 4 cifre det giver umiddelbart 9999 muligheder, hvoraf personnumre udstedt før 2007 endda kan indsnævres yderligere vha. bla.a. modulus 11 kontrol og hvis du kender personens alder (i år 2008 kan “07” både være en 1 år gammel baby eller en 101 år gammel pensionist) kan du ydermere helt eliminere første ciffer i løbenummeret, hvorefter vi er nede på 3 cifre. Alt i alt betyder det at for alle voksne mennesker idag er der reelt kun 540 gyldige cpr numre.
  • Dernæst skal cifferet selvfølgelig kunne skiftes i tilfælde af at kriminelle elementer får fingrene i det.
  • Dernæst skal det selvfølgelig være muligt at give autentificering til firma a uden at en personen der håndterer din autentificering får adgang til data om dig (dit cpr nummer)

Kort opsummering: Personer der tror at hele eller dele af et cpr nummer er hemmeligte, og kan bruges til autentificering er en omvandrende sikkerhedsrisiko og bør under ingen omstændigheder tituleres “sikkerhedsekspert”

Hvad sker der hvis en hacker sletter hele CPR Registeret?

Med chance for at skabe et antiklimaks i artiklen så sker der det simple at en operatør (evt. en ekstern konsulent såfremt de ikke har kompetencen inhouse) hos Det Centrale Personregisters datacenter bliver vækket, og sendt på arbejde. Han vil identificere fejlkilden, finde ud af hvordan hackeren kom ind og få lukket hackerens adgang. Derefter vil han med hjælp fra sine logfiler afgøre hvor længe hackeren har været i systemet og genskabe den seneste hacker-fri backup … og ja, så er man lige nødt til at gen-registrere de sidste par dages dødsfald og fødsler på ny.

Ovenstående er basseret på at dem som har designet systemet har gjort det med hovedet under armen, hvis det er bare nogenlunde ligevægtige systemdesignere der har bygget systemet, så logger de simpelthen bare ind på databasen og hiver transaktionsloggen ud og finder den kommando hackeren har udført for at slette alting, fjerner den og kører replay af loggen.

Med andre ord, det er langt fra katastrofalt at en hacker sletter hele CPR Registret, katastrofen indtræder først hvis han hacker det uden at blive opdaget, og efterfølgende vælger at misbruge data i systemet. F.eks. kan det blive meget svært for dig at overbevise din bank om at du ikke er død, hvis det i CPR Registret pludselig fremgår at du er afgået ved døden.

Enhver med bare en smule erfaring indenfor sikkerhedsbranchen ved at hvis du er blevet hacket og hackeren har gjort opmærksom på sig selv ved at slette alting, eller plante propaganda, eller gå i pressen med opdagelsen så har hackeren gjort dig en tjeneste, en stor tjeneste.

Folk der siger andet er en flok amatører som du er bedst tjent med at ignorere og på ingen måde involvere i beslutningsprocessen vedr. IT Sikkerheden i din organisation, og de har bestemt heller ikke fortjent at blive fremhævet i radioen som “Sikkerheds eksperter”.

IT Sikkerhed er noget der startes i designfasen og løbende vedligeholdes under hele den givne løsnings levetid, det inkluderer først og fremmest at regelsæt baseret på sund fornuft og generel mistro til alt indtil det explicit verificeres ikke at udgøre en trussel.