Nets vurderer, at Heartbleed er gået uden om NemID og dankortet

Illustration: leowolfert/Bigstock
Dankort-systemet og NemID har ifølge Nets ikke været ramt af den alvorlige Heartbleed-sårbarhed.

Nets har været i fuld gang med at undersøge, hvorvidt virksomhedens systemer, der blandt andet involverer dankort-infrastrukturen - også den til online-betalinger - og ikke mindst NemID, har været berørt af den såkaldte Heartbleed-sårbarhed. Og det lader, heldigvis, ikke til at være tilfældet.

»Vi (Nets) har nu foretaget en sikkerhedsmæssig vurdering af vores systemer både hos os selv og hos vores underleverandører. Vores klare vurdering er, at vi ikke er eksponeret, og vi har heller ikke været det, over for den kendte OpenSSL-sårbarhed,« oplyser pressechef i Nets Søren Winge i en e-mail til Version2.

Han meddeler desuden, at virksomheden ikke påtænker at gå i nærmere detaljer omkring, hvorfor Hearbleed er gået uden om Nets systemer. Hvilket Version2 naturligvis har forsøgt at spørge ind til.

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

Heartbleed-sårbarheden relaterer sig til det udbredte OpenSSL-bibliotek, der skal skabe en sikker forbindelse til en server. Heartbleed blev offentligt kendt i april i år, men har eksisteret i OpenSSL til produktionsmiljøer siden 2012.

Sårbarheden gør det kort fortalt muligt for vilkårlige besøgende at sende en særlig datapakke til en server, hvorefter serveren returnerer dele af indholdet i sin hukommelse. Det kan i princippet være serverens private nøgler, andre besøgendes brugernavn og kodeord samt indholdet af eksempelvis e-mails, chat-beskeder etc.

Altså et eklatant it-sikkerhedshul, som har fået den anerkendte og nøgterne it-sikkerhedsmand Bruce Schneier til at kalde Heartbleed for katastrofal samt give sårbarheden 11 på en skala fra 1 til 10 målt på, hvad der må formodes at være alvorlighed.

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

Der er kun to mulige forklaringer. Enten bruger Nets ikke OpenSSL eller også bruger de er version der er for gammel til at inkluderer fejlen.

Det burde nok for en angriber være rimelig nemt at fingerprinte sig til hvilken situation vi er i. Så derfor giver jeg ikke meget for Nets betænkelighed ved at gå i detaljer.

Under alle omstændigheder kan ovenstående dog kun dække over Nets egne systemer. Det kan på ingen måde afvise at ens kort-oplysninger kan være kompromiteret hvis man har betale med kort over nettet.

  • 14
  • 1
Morten Hansen

Du glemmer den tredje mulighed: at heartbeat er slået fra på den version de bruger. Da det er en ligegyldig, ubrugt funktion i OpenSSL librariet så er det ekstremt overraskende at den er sat til by default og der bør være nogen med ekstremt røde ører der har truffet det valgt. Se evt: http://stackoverflow.com/questions/22992149/what-are-ssl-heartbeats

  • 6
  • 0
Peter Mogensen

Der er kun to mulige forklaringer.

Well... de er også den forklaring at de har vurderet at ingen af de steder hvor de faktisk bruger en ramt OpenSSL version er eksponeret imod angrebet eller håndterer nogen data, efterlader et varigt problem for brugerene og ikke kan fikses med en revokering og et nyt certifikat.

Jeg mener: Så vidt jeg har forstået, så kan man få tilfældig RAM indhold fra en server, der svarer på TLS heartbeat. Dvs... hvis jeg bare sætter en HTTPS-server op til at serve statisk indhold er det eneste, der reelt kan leake den private nøgle til serveren. (så andre kan udgive sig for at være min server). Det burde en revokering af certifikatet og et nyt løse. Bruger folk den derimod til at håndtere følsomt indhold. F.eks. sende HTTP Basic auth eller lader HTTP-server processen pille direkte i hemmelig data, så er der mere for en angriber at hente og så skal man ulejlige brugerne med at skifte password osv.

Måske har Nets bare vurderet at der ikke har været følsom data, der kunne leakes som følge af det.

  • 3
  • 0
Peter Makholm Blogger

Nets kan naturligvis ikke give nogen garantier for andres system opsætning. Ej, heller er det rimeligt at forlange de skal.

Jeg er enig i at Nets kun har et begrænset ansvar for andres systemer. Jeg mener dog at Nets som operatør for Dankortet er ansvarlig for ikke at give misvisende information om Dankort systemet som sådan og hvis Nets melder ud at Dankort-systemet som sådan ikek er i fare, så mener jeg lidt at deres udmelding let kan opfattes som misvisende.

Du glemmer den tredje mulighed: at heartbeat er slået fra på den version de bruger.

Det er korrekt, men jeg tror ikke på det. Den er lige så sandsynlig som den fjerde mulighed at Nets var bekendt med fejlen og selv har rettet fejlen uden at fortælle andre om det.

  • 3
  • 1
Kjeld Flarup Christensen

Selvom en sårbar version har været i brug, så er der flere grunde til at NemID næppe er ramt.

Nøglekortet eller det lokale certifikat gør, at det ikke er muligt at udnytte oplysninger man måtte hente ud fra serveren.

Nøgler og andet kritisk information ligger næppe i klar tekst på serveren.

Endelig så er protokollerne proprietære så man kan ikke umiddelbart bruge oplysninger selvom man havde fået nogle ud. For en gangs skyld en fordel med Java.

Der hvor man i stedet kan se en risiko er at det muligvis ville være muligt at dumpe andre brugeres fortrolige oplysninger som netop er sendt til disse. Altså på trafik efter NemID trinnet.

  • 1
  • 0
Log ind eller Opret konto for at kommentere