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.
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.
- Nets vurderer, at Heartbleed er gået uden om NemID og dankortet
- Canada lukker offentlig selvbetjening efter SSL-sårbarhed
- Digitaliseringsstyrelsen: Heartbleed-sårbarhed kan have alvorlige og omfattende konsekvenser
- Denne artikel
- Hul i OpenSSL: En halv million hjemmesider er sikkerhedsudsat
- Ekspert om omfattende SSL-sårbarhed: Derfor skal du skifte alle dine kodeord
- Alvorligt sikkerhedshul i openSSL opdaget efter to år
- emailE-mail
- linkKopier link

...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.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Åbenbart er exploit i OpenSSL 1.0.1 og netscalerne kører vist 0.9.x.
De nyere Citrix Netscalere kører denne version: OpenSSL 0.9.7e-p1 25 Oct 2004
Dropbox har dog ikke opdateret deres certifikat, selv om de også benyttede OpenSSL. Certifikatet er i skrivende stund fra 10. december 2013.
Dropbox har skiftet certifikat, og datoen står nu til 10/4 2014.
http://toolbar.netcraft.com/site_report?url=http://www.nemid.nu
Citrix netscaler info:
http://support.citrix.com/article/CTX140605
Åbenbart er exploit i OpenSSL 1.0.1 og netscalerne kører vist 0.9.x.
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>. 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 må 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.
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.
Dropbox har dog ikke opdateret deres certifikat, selv om de også benyttede OpenSSL. Certifikatet er i skrivende stund fra 10. december 2013.
Jeg har set et sted (men kan naturligvis ikke genfinde det), at man kan udskifte certifikatet uden at skifte datoen, hvilken grund der så end kan være til det.
Jeg har set et sted (men kan naturligvis ikke genfinde det), at man kan udskifte certifikatet uden at skifte datoen, hvilken grund der så end kan være til det.
Det vil jeg se dokumenteret før jeg tror på det.
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.
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 ;)
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.
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...
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?
Afsnittet er taget ud, men ifølge Google er flere af deres services blevet patched og er dermed ikke længere sårbare. Herunder Gmail. http://googleonlinesecurity.blogspot.dk/2014/04/google-services-updated-to-address.htmlIfølge de rapporter jeg har læst har Gmail aldrig været udsat. Hvor får i det fra?
»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...
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?
Sårbarheden har eksisteret siden 2012, men er først blevet opdaget og lukket i april i år
Det er ikke sandt at sårbarheden først blev opdaget i april i år. Nogle angribere kendte til sårbarheden i november 2013 (og selvfølgelig muligvis lang tid før det): http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/
Det var et - kluntet - forsøg på at skrive officielt kendt. Det er rettet. Send gerne en mail en anden gang. Jakob - Version2
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.
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.
"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.
EFF har også bedrevet en artikel om emnet.
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>
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>
Mon, 7 Apr 2014 16:53:31 +0000 (17:53 +0100)