Sådan kan hul i open source-kryptering udnyttes

Den netop opdagede sårbarhed i GnuTLS-biblioteket gør det eksempelvis muligt for en russisk hacker at udgive sig for en netbank. Dog kun under visse forudsætninger, forklarer krypteringsekspert Poul-Henning Kamp.

Der har været en del usikkerhed om, hvilke konsekvenser den sårbarhed i Gnu-TLS-biblioteket, som Version2 og andre medier har omtalt i løbet af dagen, kan tænkes at få. Biblioteket bliver blandt andet anvendt i en del Linux-distributioner, og formodes derfor at være ganske udbredt, både på klienter og servere. Og sikkerhedshullet gør krypterede TLS/SSL-forbindelser mindre sikre - men hvordan?

Læs også: 'Ekstremt kritisk' sikkerhedshul i Linux - opdater nu

Sårbarheden, der nu er patchet, betyder, at en angriber kan udforme et særligt certifikat, som bliver godkendt til en krypteret forbindelse - eksempelvis af en browser - selvom certifikatet er ugyldigt. I praksis vil det eksempelvis sige, at en it-kriminel på en eller anden måde narrer en bruger ind på en hjemmeside, der både på URL'en og indholdsmæssigt til forveksling ligner brugerens sædvanlige netbank. Og såfremt brugerens browser anvender det sårbare Gnu-TLS-bibliotek, vil sitet kunne præsentere brugeren for et certifikat og en grøn hængelås, der også giver indtryk af, at brugeren er landet på den rigtige side.

Nu kan den it-kriminelle suge det intetanende offers oplysninger til sig og eksempelvis misbruge dem til at logge ind på den rigtige netbank, Facebook-profil, Gmail-konto eller andet. Sikkerhedshullet er dog ikke kun et problem i browser-sammenhæng, men generelt når det kommer til at have tillid til certifikater. Således også hvis en server kobler op til en anden server, eksempelvis for at hente opdateringer.

Men for at udnytte sikkerhedshullet forudsætter det altså i udgangspunktet, at enten en server eller en klient kobler op til en URL, som en angriber kontrollerer, så det falske certifikat kan præsenteres til klienten. Det kan eksempelvis foregå via phishing-mails med URL'er, der fører til et domæne, der næsten ligner det rigtige, og med et indhold, der også ser troværdigt ud, men altså ikke er det.

En anden angrebsvinkel kunne være et et wifi-hotspot, kontrolleret af en angriber, og som - til trods for at de opkoblede klienter har indtastet den korrekte URL - alligevel præsenterer dem for ondsindet indhold og et falskt certifikat.

»Det betyder, at folk ikke kan stole på certifikater fra den anden ende af en forbindelse, under et eller andet antal mere eller mindre veldefinerede omstændigheder,« skriver Version2-blogger Poul-Henning Kamp, der har indsigt i kryptering, i en mail til Version2. Han fortsætter:

»Det kan bruges til Man-In-The-Middle-angreb, men den slags tager oftest noget tid at sætte op, så det er formodentlig kun dem, der kendte fejlen i forvejen, der har kunnet udnytte det.«

Der kan dog også være situationer, hvor en klient kan udnytte et sårbart Gnu-TLS-bibliotek ved at koble op til en server. Men det hører til sjældenhederne, vurderer Poul-Henning Kamp.

»Kun hvis serveren bruger GNUTLS og checker et klient-certifikat. Det sker så godt som aldrig.«

Phishing-mails

Han gætter på, at der i kølvandet af den nu patchede sårbarhed vil begynde at dukke phishing-mails op, der netop har til formål at lokke brugere ind på sites, der til forveksling ligner den ægte vare, men som er sat op at eksempelvis kriminelle, som er ude efter kreditkortoplysninger og andet.

Poul-Henning Kamp sammenligner situationen med den sårbarhed, der blev opdaget i Apples operativsystemer for nogle uger siden, og hvor certifikater heller ikke blev ordentligt validerede i Safari-browseren. Dog med den forskel, dem, der kører GnuTLS-biblioteket, der er open source, i princippet også har mulighed for at finde og fikse fejlen.

Forskellen på fejl i open source og closed source er i dette tilfælde interessant, da sikkerhedshullet kan have stået åbent siden 2005 i kode, som alle i princippet har kunnet tilgå - også it-kriminelle. Men ingen har åbenbart fundet og lukket hullet før folk hos Linux-distributionen Red Hat opdagede det under en koderevision for nyligt.

»Kvalitet sker kun når nogen har ansvaret for det og ressourcerne til det, og i Open Source kniber det utroligt med begge dele. Omvendt kan man sige, det var netop Red Hat, der spottede det her, fordi det var Open Source, så processen virker faktisk, omend meget, meget ringe,« skriver Poul-Henning Kamp.

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

At hævde open Source modellerne fortræffeligheder i sætningen inden man medgår at hullet har været åbent siden 2005... Specielt da det ssl/tls lib fejlen i det lukkede Mac os X var i var kildekoden tilgængeligt for så man kunne se det efter og der var det også et internt Source code review der fandt fejlen (i Apple og redhat)...

http://opensource.apple.com/source/Security/Security-55471/libsecurity_s...

Så hvad med at acceptere at i teorien burde det her ha været en sejr for Linux og opensource men i virkeligheden endte det i uafgjort og vi kan alle være lykkelige over at det OS vi bruger er blevet mere sikkert.

Men faktisk så lidt dobbelt selvmål for opensource modellens kerne pointe at det er mere sikkert fordi man kan se sourcekoden...

Det betød absolut ingen forbedring af sikkerheden i denne sammenhæng for hverken Apples Mac OS X eller for Linux...

Så når PHK er færdig med den logiske slangemenneske forestilling... Så kunne man måske starte med at diskutere hvad der så vil virke når nu opensource modellen i dette tilfælde ikke virkede hvad skal man så gøre for at sikre et løbende review af kruypterings Libs ?

En krypto ACID test site hvor man nemt og hurtigt kan teste om den browser man bruger korrekt håndtere certifikater ? Hvor de store spillere/firmaer betaler præmier til dem der finder svagheder ved systemet ?

Offentligt finansiering af kode reviews ?

Eller noget helt tredie...

  • 3
  • 7
Henrik Kramshøj Blogger

Så hvad med at acceptere at i teorien burde det her ha været en sejr for Linux og opensource men i virkeligheden endte det i uafgjort og vi kan alle være lykkelige over at det OS vi bruger er blevet mere sikkert.

Jeg håber de fleste har indset at blot fordi man open sourcer noget software sker hard-core kode review ikke automatisk, og de fleste har slet ikke viden nok til at finde fejl af disse typer - udover måske undrer sig over to goto's efter hinanden som OSX buggen havde.

Den store forskel er dog at for et open source projekt kan enhver som føler at deres behov kræver et review kan iværksætte dette. I et kommercielt produkt som de har købt fra firma X skal de overbevise X om at der bør ske et review, og kan formentlig ikke påvirke dette i ret høj grad - hvis det overhovedet udføres.

Så ja, open source har denne store fordel i min optik, udover den helt naturlige at NÅR der findes fejl (al sw har mange fejl) så kan enhver der har interesse se i alle detaljer hvor alvorligt det er, om patchen er en god patch, om den løser hele spektret af problemer i den pågældende case. Der er en DEL eksempler på at eksempelvis Microsoft tidligere, før deres klare forbedring af kodekvalitet og sikkerhed, lavede patchet lynhurtigt som kun fixede en del af problemet. Open source er i sagens natur dårligt til at feje noget under gulvtæppet - ikke at det dermed er et plus når en fejl har eksisteret i mange år.

TL; Open Source giver os mere information om sårbarhederne og løsningerne og enhver kan iværksætte et kode review.

  • 12
  • 1
Anonym

Fordi man har adgang til koden er det ikke sikrere. Fordelene ved OpenSource er jo at man har adgang til koden. Man har i langt større grad frihed til at tilpasse softwaren til egne systemer. Om det skulle være billigere tror jeg kun gælder når man sammenligner software der kræver licensbetaling og software der ikke gør. En programmør koster vel nogenlunde det samme.

Og lige præcis på det sikkerhedsmæssige tror jeg det er langt sværere at skjule et hul når koden er tilgængelig. Men siger man at det er langt sikrere når der er færre øjne der ser med tror jeg ikke man har fulgt med. Et firma kan sagtens begrave huller (både MicroSoft med deres cloud der stod piv åben og Apple med en dilletant agtig SSL håndtering).

Det bliver en del sværere når man på et hacker site kan læse om hvordan man kan udnytte det ene eller andet hul. Specielt når en del af dokumentationen er henvisninger til netop koden. Man kan sige at hackeren i det tilfælde fortæller hvordan man skal lukke hullet.

  • 1
  • 0
Allan Jensen

Udover de forudsætninger nævnt så overser artiklen også at man skal bruge et program der bruger gnuTLS. Hvilket INGEN browserer gør, så din netbank er sikker. GnuTLS bruges kun af meget få programmer da der altid har været anset for usikkert.

Programmer det bruges på i min Debian installation: OpenLDAP og wget. Wow.

  • 2
  • 2
Robert Larsen

Hvor ser du at det KUN er russiske hackere, som kan det?
Står der ikke "eksempelvis muligt for en russisk hacker"..bemærk ordet "EKSEMPELVIS".
Det betyder, at det er én af flere muligheder.

Den danske sprog er en svær én.

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