Både NemID og dankort-systemer kan være ramt af alvorligt sikkerhedshul

10. april 2014 kl. 14:0822
Både NemID og dankort-systemer kan være ramt af alvorligt sikkerhedshul
Illustration: Jesper Stein Sandal.
Situationen er alvorlig, lyder det fra Nets, der er ved at undersøge, hvorvidt systemer som NemID og dankort-infrastrukturen er ramt af det alvorlige sikkerhedshul Heartbleed.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Både betalingsinfrastrukturen i Danmark og NemID kan være påvirket af et alvorligt sikkerhedshul, der kom for dagens lys tidligere på ugen, og som potentielt kan have blotlagt strengt fortrolige oplysninger på et stort antal servere verden over.

Det fremgår af en tilbagemelding fra Nets, der står bag NemID. Ud over den digitale logon-løsning står Nets også bag Dankort-systemet, både det fysiske, men også det virtuelle i forbindelse med kortbetaling i netbutikker.

»Det er en problemstilling, som vi tager meget alvorligt og vi er i gang med at analysere alle Nets’ systemer for at se, om problematikken påvirker vores systemer. Vi kan ikke udtale os om eventuelle påvirkninger, før konklusionerne af denne analyse er klar. Det er som sagt noget, vi tager meget alvorligt, og som vi arbejder med lige nu, men jeg kan ikke sige, hvornår vi har konklusionerne af analysen,« oplyser Ulrik Marschall fra Nets' kommunikationsafdeling i en e-mail.

Sikkerhedshullet, kaldet Heartbleed, gør det kort fortalt muligt for vilkårlige personer at koble op til en server, der anvender en sårbar udgave af det såkaldte OpenSSL-bibliotek. Herefter kan serveren narres til at sende fortrolige data tilbage fra dens hukommelseslager til en angriber.

Artiklen fortsætter efter annoncen

Data kan ifølge Codenomicon, virksomheden, der opdagede sikkerhedshullet sammen med en Google-ansat, være den private nøgle, der bliver brugt til at identificere serveren over for besøgende. Det kan også være brugernavn, kodeord og andet vilkårligt dataindhold. Eksempelvis indholdet af en chatbesked, indholdet af en e-mail eller oplysningerne fra et betalingskort.

Sårbarheden har eksisteret siden 2012, men er først blevet lukket i april i år. Blogger på Version2 og it-sikkerhedsekspert fra virksomheden Solido Networks Henrik Kramshøj opfordrer alle over en bred kam til at skifte det eller de kodeord, de anvender - og i øvrigt anvende forskellige kodeord forskellige steder.

I den forbindelse er det en god idé at tjekke, om en server stadig er sårbar, inden kodeordsskifte, da det nye kodeord ellers også risikerer at blive kompromitteret. Det kan gøres her http://filippo.io/Heartbleed/. Man bør således ikke skifte sit kodeord, før man er sikker på, at serveren er opdateret.

22 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
16
10. april 2014 kl. 18:26

Artiklen skriver:

I den forbindelse er det en god idé at tjekke, om en server stadig er sårbar, inden kodeordsskifte, da det nye kodeord ellers også risikerer at blive kompromitteret. Det kan gøres her <a href="http://filippo.io/Heartbleed/">http://filippo.io/Heartbleed/</a&gt;. Man bør således ikke skifte sit kodeord, før man er sikker på, at serveren er opdateret.

Så vidt jeg kan forstå er det ikke nok, at softwaren på websiten er blevet udskiftet med den nyeste udgave. Den private nøgle knyttet til det hidtidige certifikat kan nemlig være blevet kompromitteret mens softwarehullet var åbent (ifølge heartbleed.com), hvilket betyder at lyssky personer – herunder NSA og andre efterretningstjenester, men også andre kriminelle organisationer ;-) – fortsat uden problemer kan aflytte al krypteret trafik mellem brugerens browser og den pågældende website, herunder aflæse den nye adgangskode.

Websites berørt af Heartbleed-buggen skal derfor også generere et nyt privat/offentligt nøglepar og derefter anskaffe og installere et nyt SSL-certifikat svarende til det nye nøglepar, før de kan sige, at kommunikationen med deres website igen er nogenlunde sikker.

Så man bør altså også tjekke, at websitens certifikat er udstedt efter ca. 7. april 2014, hvor hullet blev offentliggjort. I visse tilfælde, fx hos Google, kan det dog være sket lidt før, da Google jo kendte til fejlen tidligere og derfor kunne anskaffe nyt certifikat lidt før resten af verden. I den forbindelse undrer det mig dog, at fx mail.google.com's certifikat i skrivende stund stammer helt tilbage fra 12. marts 2014. Det samme gælder www.google.com's certifikat. Kendte de mon til hullet allerede da?

Til gengæld er login.yahoo.com's certifikat blevet opdateret netop 7. april 2014, hvilket er et godt tegn på at Yahoo har taget problemet seriøst og ikke bare har lappet deres OpenSSL-software, men også anskaffet et nyt certifikat. (Man næsten antage at det nye certifikat så faktisk er baseret på et nygenereret nøglesæt.)

Dropbox har dog ikke opdateret deres certifikat, selv om de også benyttede OpenSSL. Certifikatet er i skrivende stund fra 10. december 2013.

22
11. april 2014 kl. 14:50

Opfølgning: Dropbox opdaterede deres certifikat i går. Så hvis man vil være mere sikker på sin Dropbox-konto og allerede har ændret adgangskoden før det opdaterede certifikat var på plads, så bør man ændre den igen nu.

Det er fordi ens brugernavn og den nye adgangskode i princippet kunne være blevet læst af uvedkommende, da man opdaterede den. Nemlig hvis disse uvedkommende havde snuppet Dropbox's private SSL-nøgle mens Dropbox's OpenSSL var sårbar, for så ville de i princippet være i stand til at dekryptere den krypterede forbindelse mens man opdaterede sin adgangskode. Dog kun hvis de pågældende også havde adgang til at aflytte internetforbindelsen.

12
10. april 2014 kl. 16:29

Jeg kan ikke helt frigør mig for tanken om at NSA har haft en finger med i spilet. Det har i hvert tilfælde været fremme at NSA har forsøgt at kompromitterer sikkerheden hos RSA.

Samtidig kan man hører diverse politikere råbe højt og larmende om hvor meget Snowdens afsløringer har skadet dette og hint land.

Hvor meget har NSA så skadet de samme lande ved at give "den onde fjende" let adgang til beskyttet materiale på alle vores serverer.

Mon ikke at vi ser denne række af afslørede sikkerhedshuller fordi der er flere der er begyndt at kikke nærmere i koden. Men hvis det virkelig er efterretningsfolk uden moral/omtanke der planter disse huller, er det så ikke en håbløs kamp.

10
10. april 2014 kl. 15:48

For Microsoft... Den liste med de opdaterede servere bør ha en kolonne med "var aldrig udsat for heartbleed sårbarheden da OpenSSL ikke var i brug"...

Som fx det system der sikre alle laborstorie blodprøve bestillinger i Danmark... Lidt ironisk at de er sikre mod den her sårbarhed da de anvender Microsoft server IS...Https://www.webreq.dk

Men at den server så er på en public ip er lidt dumt ;)

13
10. april 2014 kl. 17:05

Microsoft servere har vel så mange andre huller, betalte eller ej, så det er vel ligemeget. Pointen er igen at Open Source software kan blive gennemset af eksperter, og huller rettet. Det sker jo ikke med lukket kode: for det første fordi der er langt færre der kigger koden igennem, og for det andet at mange af de huller der er, er blevet betalt af NSA og andre. Man lukker jo ikke et hul som man har fået penge for eller er blevet truet til at have.

14
10. april 2014 kl. 17:38

Men eksperterne har (som det har vist sig flere gange over de sidste par måneder) ikke haft tid til at lave kode review og med 450k linjer kode i OpenSSL så er det nok en opgave man ikke lige laver på en weekend...

Så selv om closed Source coden i terorien er mere sikker så virker det ikke helt i virkeligheden specielt da det slet ikke er et behov for at ha Source kode for at finde sikkerhedshuller (de mange indberetninger for ikke opensource software viser det er et fakta). Så det virker som om dogmet om at opensource er mere sikker fordi det er open Source er under pres....

Har nok også noget at gøre med at nogle bugs er det nemmere at få fikset når det står på en målaftale og man har tid og resourcer til at finde fikse og teste løsningen... Selvfølgeligt får man også status af at fikse noget i et opensource program men det er få der får løn for det... Og en del af dem er betalt af Apple/Microsoft/Google/HP osv...

Så mm man kan være ligeglad med om at driftsatte løsninger breaker så man kan sætte det nye patchede opensource lib ind uden at har voldsomme konsekvenser (hvilket vel er definitionen på en hobby) så er opensource lidt hurtigere til at patche huller der er blevet opdaget... Ikke at man generelt set benytter en kodebase der er reviewet mere grundigt end en closed source løsning...

Basalt set fordi selv om man kan læse sourcen er ikke det samme som at det bliver gjort, og selv der skal den person der læser den være istand til at finde fejlene... Selv om opensource er et fantastisk concept og nogen løsninger er da super så er det ikke immunt overfor at folk der skriver kode er ikke perfekte...

9
10. april 2014 kl. 15:46

Blandt de tjenester, hvor man bør skifte sine kodeord, er Googles Gmail

Ifølge de rapporter jeg har læst har Gmail aldrig været udsat. Hvor får i det fra?

6
10. april 2014 kl. 15:23

»Det er en problemstilling, som vi tager meget alvorligt og vi er i gang med at analysere alle Nets’ systemer for at se om problematikken påvirker vores systemer. Vi kan ikke udtale os om eventuelle påvirkninger før konklusionerne af denne analyse er klar. Det er som sagt noget vi tager meget alvorligt, og som vi arbejder med lige nu, men jeg kan ikke sige hvornår vi har konklusionerne af analysen,« oplyser Ulrik Marschall fra Nets kommunikationsafdeling i en mail.

Tager de det alvorligt hvis de venter på en rapport engang om lang tid? hvis man ikke aner hvad der foregår i sin infrastruktur så LUK det og undersøg på en evt. mistanke...

5
10. april 2014 kl. 15:21

Er der nogen der har vedligeholder en liste over hvilke hjemmesider der har opdateret? Dvs. hvilke en liste over hvilke sider man skal skifte kodeord og hvilke sider man bør vente lidt endnu?

2
10. april 2014 kl. 14:32

Det var et - kluntet - forsøg på at skrive officielt kendt. Det er rettet. Send gerne en mail en anden gang. Jakob - Version2

3
10. april 2014 kl. 14:39

Jeg har lige skimmet alle Version2's artikler om emnet, og ingen af dem siger noget om Ars Technica's påstand om at angriberne har kendt til hullet længe. Hvilket er en ret central pointe. Så jeg syntes at det var relevant at linke offentligt på Version2 til artiklen.

Bruce Schneier skriver også https://www.schneier.com/blog/archives/2014/04/heartbleed.html :

At this point, the probability is close to one that every target has had its private keys extracted by multiple intelligence agencies. The real question is whether or not someone deliberately inserted this bug into OpenSSL, and has had two years of unfettered access to everything. My guess is accident, but I have no proof.

Det antager så også at sikkerhedstjenesterne lader hullet være åbent i deres nationale virksomheder - hvilket vist stemmer meget godt overens med hvad man har set i Snowden-lækket. Jeg følger lidt med i sikkerheds-nyheder, og det er påfaldende at jeg ikke husker at have set NSA indsende rettelser som lukker sikkerhedshuller, givet hvor mange sikkerhedseksperter NSA må have ansat.

4
10. april 2014 kl. 14:56

Arstechnica's kilde er SeaCat.mobi. Der er nu en update:

"Update: SeaCat and Teska have now qualified their comments: "e. EFF correctly pointed out that there are other tools, that can produce the same pattern in the SeaCat server log". Dvs ingen beviser for før-7.-april-skan.

18
10. april 2014 kl. 20:22
7
10. april 2014 kl. 15:28

EFF har også bedrevet en artikel om emnet.

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013

Det kan være svært at lave en signatur der matcher bestemte angreb og den eksisterende logning som foretages - af det sårbare program er formentlig i langt de fleste tilfælde utilstrækkeligt. Ofte vil eksempelvis et buffer overflow også gøre at der slet ikke logges på det succesfulde request, fordi afviklingen overtages af exploitet.

Så November 2013 teorien er formentlig utroværdig, men det er ikke umuligt andre har kendt til denne eller den har været kendt i noget længere tid af de involverede. Det kunne være rart med en timeline fra discovery til nu, udover de timelines der pt. starter ved 7. april, som eksempelvis https://community.rapid7.com/community/metasploit/blog/2014/04/09/metasploits-heartbleed-scanner-module-cve-2014-0160 der linker til git.openssl.org med datoerne:

Add heartbeat extension bounds check.
author Dr. Stephen Henson <a href="mailto:steve@openssl.org">steve@openssl.org</a&gt;
Sat, 5 Apr 2014 23:51:06 +0000 (00:51 +0100)
committer Dr. Stephen Henson <a href="mailto:steve@openssl.org">steve@openssl.org</a&gt;
Mon, 7 Apr 2014 16:53:31 +0000 (17:53 +0100)