Kodefejl sendte Mit.dk til tælling i to døgn: Leverandør insisterer på, at løsningen var gennemtestet

20 kommentarer.  Hop til debatten
Mit.dk
Illustration: Netcompany.
Selvom vinduet for en giftig kodefejl på Mit.dk blev lukket i efter godt en time, kan mange borgere have nået at snage i andres digitale post med dybt følsomme oplysninger. Det viser dokumenter fra Datatilsynet, hvor leverandøren Netcompany garanterer, at systemet var gennemtestet før opstart. 
Løsninger4. april kl. 15:00
errorÆldre end 30 dage

Man skal næppe bladre længe i sin egen digitale postkasses mange dokumenter fra skatteforvaltningen, kommunen og ens arbejdsgiver, før man kan konkludere, at det meste nok ikke vedkommer andre – og da slet ikke fuldstændigt fremmede. 

Alligevel var resultatet af en kodefejl i den stort opslåede Mit.dk-løsning fra Netcompany netop det. Ved lanceringen fik et endnu ukendt antal borgere adgang til andres postkasse, og de har dermed potentielt kunnet læse med i dybt fortrolige korrespondancer mellem borger, virksomheder og det offentlige. 

Version2 har ligesom en stribe andre medier fået aktindsigt i Netcompanys anmeldelse af databruddet til Datatilsynet, og dokumenterne giver et detaljeret billede af et særdeles kritisk forløb i timerne omkring lanceringen af visningsklienten Mit.dk, der gik i luften om morgenen mandag den 21. marts, efter en proklameret fryseperiode var overstået og Næste generation Digital Post efter flere forsinkelser endelig gik i luften.

Netcompany lancerede løsningen en time før den officielle opstart, men på trods af forspringet på en time gik der blot omkring fem kvarter, før Netcompany måtte tvinge løsningen på jorden igen.

Artiklen fortsætter efter annoncen

En af Netcompanys egne folk gjorde nemlig opmærksom på, at vedkommende havde fået adgang til en anden brugers e-mail og telefonnummer, og kun ganske få minutter senere var den så gal igen. Denne gang i form af en orientering fra en medarbejder hos Digitaliseringsstyrelsen, der havde fået adgang til en anden borgers offentlige digitale post. Det fremgår af dokumenterne fra Datatilsynet. 

Selvom Netcompany ikke selv åbner de digitale konvolutter, er leverandøren godt klar over, at indholdet er voldsomt delikat og kan indeholde »alle de forskellige typer personoplysninger som indgår i offentlig digitalpost, herunder også følsomme personoplysninger og oplysninger om straffedomme og lovovertrædelser,« som der står i anmeldelsen til Datatilsynet.

Læs mere her: Netcompany bekræfter: Borgere fik adgang til andres digitale post

Teknisk knockout 

Derfor fik katastrofemeldingen fra Digitaliseringsstyrelsens medarbejder da også Netcompany til at slå bremserne i og lukke for adgangen klokken 09.15. De næste to døgn kunne offentligheden se undrende til, mens et skilt på Mit.dk bekendtgjorde, at løsningen var ramt af problemer. Blandt de it-professionelle blev der gættet på, hvad der kunne være galt, mens man hos leverandøren knoklede på livet løs for at relancere løsningen på sikker vis.  

Screenshot fra Mit.dk.
Illustration: Screenshot fra Mit.dk..

Hos Netcompany fandt man, ifølge anmeldelsen ud af, at fejlen var en ‘kodefejl i komponenten der bruges til identifikation/autentificeringen af brugerne.’

Fejlen opstod, når flere brugere loggede på løsningen samtidig.

»I de tilfælde, kunne autentificeringsnøglen fra en bruger ("A") potentielt overskrive autentificeringsnøglen fra en anden bruger ("B»), hvorved bruger B kunne få adgang til bruger A’s digitale post. Fordi de fleste brugere loggede på for første gang, var konsekvensen i første omgang, at de berørte brugere kunne få vist kontaktoplysninger (telefonnummer og e-mail) for en anden bruger, hvis dette var registreret i Digital Post hos Digitaliseringsstyrelsen. Brugeren kunne derfor aktivt vælge enten at ændre kontaktoplysninger og/eller fortsætte ind i den digitale postkasse,« står der i anmeldelsen.  

TIDSLINJE: De kritiske timer for Mit.dk

Den 21. marts 2022

  • Klokken 08:02 blev adgang til mit.dk, Netcompanys visningsklient til Digital Post, der er en pendant til e-Boks, åbnet for offentligheden.  Officielt skulle denne først åbne kl. 09.00 og det var derfor i høj grad Netcompany ansatte der loggede på før tid.

  • Klokken 08:55 blev Netcompany gjort opmærksom på, at en bruger af mit.dk ved en fejl havde adgang til en anden brugers e-mail og telefonnummer i forbindelse med den indledende brugerregistrering. 

  • Få minutter efter modtog Netcompany også en orientering fra en medarbejder fra Digitaliseringsstyrelsen som kunne oplyse, at medarbejderen havde kunnet tilgå og læse en anden borgers offentlige digitale post.

  • Netcompany foretog straks en fuldkommen lukning mod offentligheden samt indledte en analyse afproblemets karakter og omfang. Denne nedlukning var fuldendt for både web- og mobilklienten for mit.dk kl.09:15.

  • Netcompany indledte derefter en analyse af den bagvedliggende årsag til fejlen. I samme forbindelse blev der indledt en undersøgelse af, hvor mange borgere, der var berørt af bruddet samt hvilke personoplysninger, der måtte være blevet kompromitteret.

  • I perioden fra den 21. marts 2022 til den 23. marts 2022 arbejdede Netcompany på fejlretning, herunder implementering af en yderligere sikkerhedsforanstaltning, der skulle sikre, at fejlen ikke ville indtræffe igen når mit.dk blev åbnet på ny. Netcompany foretog en række tests, herunder bl.a. reproduktion af fejlen og verifikation på underliggende (ikke produktion) miljøer. 

Den 23. marts 2022

  • Klokken 13:20 havde Netcompany løst den bagvedliggende fejl og alt fungerede som forventeligt, hvorefter Netcompany genåbnede mit.dk igen den

  • Netcompany er fortsat i gang med analysearbejdet i forhold til, hvor mange borgere, der var berørt af bruddet samt hvilke personoplysninger, der måtte være blevet kompromitteret.

Kilde: Netcompanys anmeldelse af sikkerhedsbruddet til Datatilsynet

»I de tilfælde, hvor login ikke blev afbrudt, har de angivne borgere både haft adgang til at se afsendere af og emnefelterne på en anden borgers digitale post. Potentielt har borgeren også kunne åbne den digitale post og gøre sig bekendt med indholdet heraf,« står der videre. 

Læs mere her: Netcompany: Mit.dk-nedbrud skyldtes menneskelig fejl

Fejlen opstod ifølge Netcompanys anmeldelse som et resultat af, at flere brugere loggede på løsningen på det eksakt samme tidspunkt. Det hul blev ikke opdaget under diverse foregående test, og er ifølge leverandøren et resultat af at ‘hundredvis af brugere er logget ind samtidig i netop samme øjeblik, samt en ekstraordinært lang svartid fra NgDP (Next generation Digital Post).’ 

I forsøget på at genskabe fejlen viste test, at det ville kræve ‘hundredvis af loginforsøg inden for samme sekund/millisekund for at fejlen kunne genskabes.’ I de mere end to døgn, hvor visningsklienten Mit.dk var sendt til tælling fandt Netcompany fejlen og rettede den. Det skete via en ‘en kodeændring, der reelt set medfører, at der ikke kan ske en sammenblanding af de brugte ID’er’ samt en »en ændring til transaktionen mellem mit.dk og NgDP.

Testet før start 

En naturligt spørgsmål er i sagens natur, om man ikke burde have fanget den her slags problemer i en form for test?

I anmeldelsen til Datatilsynet forsikrer Netcompany om, at man i arbejdet med visningsklienten har underkastet Mit.dk omfattende test.

»For at validere sikkerheden af mit.dk, blev der inden go-live først gennemført en intern penetrationstest af Netcompany's sikkerhedsteam. Senere blev der gennemført en sikkerhedstest af en tredjepart, F-Secure, hvor konklusionen var at løsningen var klar til ibrugtagning fra et sikkerhedsmæssigt perspektiv,« skriver virksomheden og uddyber: »Der er lavet omfattende performance-tests af løsningen inden go-live, herunder også af den komponent som var involveret i hændelsen. Det er dog ikke umiddelbart muligt, at lave store automatiserede performancetests som også involverer realistiske NemID-logins (pga. kravet om to-faktor autentificering). Derfor blev testen lavet med et simuleret login som omgik det almindelige loginflow via NgDP og Nemlog-in. Dette simulerede login kørte hurtigere end det rigtige login-flow på grund af, at NgDP kørte ekstra langsomt under det helt store peak-load der skete ved go-live af både borger.dk, virk.dk, e-Boks og mit.dk klienterne. Performance-test af mit.dk fandt ikke problemet ved programmeringsfejlen og ville heller ikke havde kunnet finde den,« konstaterer Netcompany i sin anmeldelse.

Læs mere her: Efter mere end to døgn er Netcompany-indgang til Digital Post nu tilgængelig

Ukendt antal borgere berørt

Ifølge anmdelsen til Datatilsynet er det ikke muligt at fastslå præcist, hvor mange borgere der reelt set har haft mulighed for at snage i andres digitale postkasse via fejlen på Mit.dk. 

Netcompany er således ifølge dokumenterne, der er stemplet den 31. marts, fortsat i gang med at analysere, hvor mange borgere det reelt set drejer sig om. Analysen viser på anmeldelsestidspunktet, at 2182 borgere nåede at logge på Mit.dk, inden man fra centralt hold lukkede løsningen ned.

Af dem nåede 1356 borgere at åbne mindst ét dokument. Men så begynder klarheden også at erstattes af en mere spekulativ tåge. For det er svært at klarlægge, hvor mange af de borgere, der så rent faktisk blev præsenteret for andre borgeres post. 

»Netcompany vurderer derfor, at det reelle antal af berørte borgere, der faktisk har været berørt af hændelsen, er markant lavere end det antal borgere som angivet ovenfor. Det er derfor vores skøn, at det reelle antal berørte borgere ligger mellem 10 – 50 og er for de situationer, hvor deres digitale post er gjort tilgængelig for en eller flere andre brugere,« står der i papirerne. 

Netcompany arbejder på at underrette de borgere, der konkret har været berørt af hændelsen og har angivet, at det senest vil være sket d. 8 april.

Læs mere her: Netcompanys Digital Post-løsning kæmper med driftforstyrrelser efter hård debut

20 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
31
28. april kl. 09:33

Ja, så kom der en ny version (1.1.1) af appen mit.dk til Android, men det hjalp ikke (den "gamle" afinstalleret før nyinstallation) Jeg kan stadig ikke komme forbi "Fortsæt" uden at få en "Bad Request" på gateway.digital.post.dk.

22
5. april kl. 07:42

Hvis man skal lære noget af det, må det være, at ordentlige tests af hele systemet er vigtigt. Man kan ikke nøjes med små hurtige unittests.

25
5. april kl. 07:48

Fuldstændig enig. Og inden man starter testen kunne man passende få nogle erfarne systemarkitekter til at gå de koncpetuelle designkriterier for Mit.dk igennem. I lyset af den omtalte fejl kunne man passende få dem til at sætte fokus på bl.a. alt hvad der kan ske, når man skifter sessionsnøgle mellem frontend og backend, med specielt fokus på sessionens kobling til MitID. Det er noget af en opgave, bl.a. fordi forskellige browsere har kedelige tendenser til at behandle sessionsbegrebet forskelligt.

21
5. april kl. 07:40

Diagnosen er forkert - der er ikke tale om en kodningsfejl! Det der beskrives i artiklen er en konceptuel og arkitekturmæssig designfelj - ikke en kodefejl. En kodefejl beskriver en fejl, hvor et stykke software gør noget andet end tiltænkt. Beskrivelsen her afdækker, at softwaren gør nøjagtigt som tiltænkt, men at tankerne bag funktionen er forkert.

En strid om ord? Nej, bestemt ikke. Kodefejl opstår når en systemkoncept omsættes til kode. Den beskrevne fejl er sket på konceptniveau - hvor det åbenbart er besluttet at bruge en forkert sessionsidentifikation i systemet - formodentlig fordi den sessionsidentifikator som frontenden vedligeholder, åbenbart ikke er god nok, eller ikke kan overføres til backend systemerne. At skifte sessionsnøgler under vejs er der intet odiøst i, men her er konceptet udviklet uden hensyn til eller forståelse for løsningens realtidsegenskaber.

Den slags fejl skal fanges på designtedspunktet - ikke i kodetest, og da slet ikke i "slutbrugertest" med live data.

Er det ikke lige meget - når nu fejlen er fundet og rettet? Absolut ikke. Når der opstår konceputelle fejl på dette niveau, er det alvorligt. Risikoen for, at lignende fejl ligger andre steder i løsningen er overhængende, netop fordi den aktuelle fejl afslører mangel på systemforståelse. Blot for at nævne nogle få problemområder: Tilgangen til og låsningen af records i backend systemets databaser; Håndtering af sessionsudløb eller afslutning i frontenden, med låste records i backenden; Spærring eller udløb af brugerens MitID under en kørende session; Samtidig tilgang fra samme bruger via forskellige apps (web, mobilapps osv.), med samme MitID, men med forskellige sessioner; Samtidig tilgang fra to forskellige brugere til samme persons data (muligt via værgemåls tilgang).

30
9. april kl. 11:12

Jeg synes nu det lyder ganske plausibelt.

Mit gæt på hvad der er sket, er at nøglen er blevet gemt i et felt i en service som er tilgængelig for flere tråde og at der på den måde er sket en forurening på tværs. Jeg har set andre udviklere lave netop denne fejl og med fuldstændig de beskrevne konsekvenser.

Services er som regel lavet som singletons og hvis man kommer til at opbevare en værdi i et for stort scope, så kan det være ganske svært at fange i en test.

Det er noget som skal fanges af en udvikler i et kode review. Dog vil jeg mene det er en ret simpel fejl, det er sgu ret pinligt.

Årsagen til det måske ikke kan fanges ved en automatiseret test er som de beskriver, at lige præcis login delen op til Nemlog-in kan være utrolig svært at automatisere på grund af to faktor elementet.

27
5. april kl. 11:59

Absolut korrekt. Denne type fejl løses ikke ved hverken unit-test, integrations-test, performance-test etc. Det er et design review af løsningen med deltagelse af erfarne folk med 'sikkerheds briller' på, og ikke nødvendigvis den billigste.

29
6. april kl. 09:03

Jeg er meget uenig. Den helt konkrete fejl vile blive fanget af en integrationstest af 75 minutters simulering af normal drift. Det er faktisk en utrolig ussel lille test.

Hvis nogen påstår, at sådan en test er for ressourcekrævende til at kunne gennemføres, må jeg spørge om følgende: Hvordan kan man så finde ressourcer til at drifte det 24/7/365 bag efter?

Men du har ret i, at typen af fejl kan være så sporadisk, at den ikke kan findes via tests. Men det gælder ikke for den konkrete fejl i artiklen.

28
5. april kl. 12:47

Denne type fejl løses ikke ved hverken unit-test, integrations-test, performance-test etc. Det er et design review af løsningen med deltagelse af erfarne folk med 'sikkerheds briller' på, og ikke nødvendigvis den billigste.

Enig - og typisk løses den type af konceptuelle designfejl heller ikke på to døgn. Risikoen for fejl i uigennemtænkte og utestede lappeløsninger er alt for stor.

Og ja, prisen for erfarne systemarkitekter med 'sikkerheds briller' er høj - men det er prisen for at undgå de monumentale fejl der opstår i kølvandet på dårligt design og forkerte koncepter.

Som man siger: Hvis du synes det er dyrt at bruge dyre konsulent, så vent og se hvad det kommer til at koster at bruge billige. QED.

17
4. april kl. 17:50

Netcompany forklarer, at det ville kræve ‘hundredvis af loginforsøg inden for samme sekund/millisekund for at fejlen kunne genskabes.’

Men kun 2182 borgere nåede at logge på Mit.dk mellem forpremieren kl. 8 og nedlukningen kl. 9.15. Selv hvis alle først loggede på efter det officielle åbningstidspunkt kl. 9, giver det kun ca. 150 pr. minut i snit. Har der virkelig siddet hundredvis parat for at logge ind præcis på sekundet?

16
4. april kl. 17:02

Hvornår lavet Version2 en artikel om deres eget kommentar system, og, hvordan man designer UX komponent state. ?

15
4. april kl. 16:59

Shit, nu blev jeg også ramt af den fejl.

9
4. april kl. 16:53

Jeg kommer stadig ikke forbi "Fortsæt" på forsiden, dvs. jo, til et "Bad Request" på gateway.digital.post.dk. :-)

Supporten sendte den til 2. level support for 11 dage siden, og i dag efter at have gentaget oplysninger om version af app (1.0.0) (seneste på Google Play) og mærke/model på mobil samt OS-version og screendump af "Bad Request" på gateway.digital.post.dk givet første gang, blev den igen sendt til 2. level support.

Jeg har ingen problemer med MitID, NemID, e-Boks, MinSP, Sundhedkort, kørekort osv.

18
4. april kl. 18:58

Jeg kommer stadig ikke forbi "Fortsæt" på forsiden, dvs. jo, til et "Bad Request" på gateway.digital.post.dk. :-)

Jeg oplevede samme fejl med e-Boks. Har du prøvet at nulstille app'en? Jeg mistænker at en gammel fejl fra Digital Post/NemLog-in kan 'gemmes' i en cookie, men det er noget besværligt at slette cookies i en app. I browseren skulle jeg slette samtlige cookies fra e-Boks, NemLog-in, mitid.dk og Digital Post og så kunne jeg komme ind.

20
5. april kl. 00:02

Den "Bad Request" jeg får, er exception "invalid character found in request target"

19
4. april kl. 23:45

Jeg har afinstalleret mit.dk og geninstalleret appen. På PC i browser er der ingen problemer, og jeg har aldrig tilgået e-Boks, NemLog-in, mitid.dk og Digital Post i en browser på mobilen, og har aldrig installeret appen Digital Post.

Jeg prøvede lige at slette "Brugerdata" og "Cache", men det hjalp ikke.

Så hvordan er det lige man sletter cookies i en app?

6
4. april kl. 16:45

Så så drenge - husk at netcompany kun ansætter unge & højtudannede.

Det er jo lidt svært at udvikle asynkrone applikationer, såsom at hindre at "nodes" forveksles. Enhver der har progget fx. et interrupt-drevet system, ved at man skal cleare alle andre for at undgå dette. Absolut amatøragtigt....

Men måske røg opgaven til Indien ad bagdøren ! Hvem ved ?

Men I Danmark hænger man ordener på idioter (citat: Heiberg i eksil om DK). Vi skal stadig leve med logning etc..

7
4. april kl. 16:48

Shit - man skal aldrig klikke "udgiv" flere gange, selv om der ikke sker noget.....

2
4. april kl. 16:31

Mit.dk

Lader til at være oppe (mandag 4/4, kl 16:00) - og finder de samme dokumenter som fx e-boks.dk.

Så vidt, så godt - i hvert fald bedre end forleden. Hvad fejlen bestod i, vil man selvfølgelig ikke ud med:

Hos Netcompany fandt man, ifølge anmeldelsen ud af, at fejlen var en ‘kodefejl i komponenten der bruges til identifikation/autentificeringen af brugerne.’

Det kunne enhver amatør, sikkert også regne ud. Så påstod man ovenikøbet at "løsningen" var testet, inden den åbnede. Det må være den slags test man i branchen almindeligvis kalder "åben Alpha".

1
4. april kl. 16:14

Så den menneskelige fejl ( https://www.version2.dk/artikel/netcompany-mitdk-nedbrud-skyldtes-menneskelig-fejl ) var fordi et menneske havde lavet designet forkert eller implementeret det forkert. Og ingen havde opdaget at en loginsession blev identificeret af et tidsstempel og ikke noget med brugercertifikater eller andet hejs. Ikke en Netcompany fejl, men en individuel persons fejl.

Mange ting var også meget lettere hvis man kunne forvente seriel eksekvering, dumme brugere der prøver at logge på samtidigt!