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

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.

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.

Læs også: Hul i OpenSSL: En halv million hjemmesider er sikkerhedsudsat

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.

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.

Læs også: Ekspert om omfattende SSL-sårbarhed: Derfor skal du skifte alle dine kodeord

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thue Kristensen

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.

Finn Aarup Nielsen

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.

David Nielsen

»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...

Henrik Kramshøj Blogger

EFF har også bedrevet en artikel om emnet.

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agenc...

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/metasp... der linker til git.openssl.org med datoerne:

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

Jakob Damkjær

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 ;)

Jesper Nielsen

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.

Keld Simonsen

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.

Jakob Damkjær

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...

Per Hansen

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 http://filippo.io/Heartbleed/. 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.

Thue Kristensen

"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.

Den ene af de to er sandsynligvis udelukket. Den anden ligner stadig "the real thing". Og kom fra et botnet som overvågede IRC-kanaler, hvilket EFF theoretiserer passer bedst på en national efterretningstjeneste.

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agenc...

Brian Dyrehauge
Per Hansen

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.

Log ind eller Opret konto for at kommentere