Hvordan en fejl i OpenSSL forårsagede en sikkerhedskrise

brain, heart, mind-5371476.jpg

Heartbleed er en sårbarhed i OpenSSL, der kom frem i april 2014; det var til stede på tusindvis af webservere, herunder dem, der kører store websteder som Yahoo. Heartbleedkan spores til en enkelt kodelinje i OpenSSL, et open source-kodebibliotek.

OpenSSL er et open source-kodebibliotek, der implementerer TLS-protokollerne (Transport Layer Security) og SSL (Secure Sockets Layer).  Sårbarheden betød, at en skadelig bruger let kunne narre en sårbar webserver til at sende følsomme oplysninger, herunder brugernavne og adgangskoder.

TLS/SSL-standarderne er afgørende for moderne webkryptering, og mens fejlen lå i OpenSSL-implementeringen frem for selve standarderne, er OpenSSL så udbredt – da fejlen blev offentliggjort, påvirkede den 17% af alle SSL-standarder  – at det udløste en sikkerhedskrise.

Hvorfor hedder Heartbleed Heartbleed?

Navnet Heartbleed kommer fra hjerteslag, som er navnet på en vigtig komponent i TLS/SSL-protokollen. Hjerteslaget er, hvordan to computere, der kommunikerer med hinanden, lader hinanden vide, at de stadig er forbundet, selvom brugeren ikke downloader eller uploader noget i øjeblikket. Lejlighedsvis sender en af disse computere et krypteret stykke data, kaldet en hjerteslagsanmodning, til den anden. Den anden computer svarer tilbage med nøjagtigt det samme krypterede stykke data, hvilket beviser, at forbindelsen stadig er på plads.

Heartbleed-sårbarheden får sit navn, fordi angribere kan bruge hjerteslagsanmodninger til at udtrække oplysninger fra en målserver – metaforisk bløder offeret følsomme data ud gennem sine hjerteslagsanmodninger.

Hvordan virker Heartbleed?

Heartbleed fungerer ved at drage fordel af en afgørende kendsgerning: en hjerteslagsanmodning indeholder oplysninger om sin egen længde, men den sårbare version af OpenSSL-biblioteket kontrollerer ikke for at sikre, at oplysningerne er korrekte, og en angriber kan bruge dette til at narre målserveren til at give angriberen adgang til dele af sin hukommelse, der skal forblive private. For at forstå mekanismen bag dette, lad os gå gennem et typisk eksempel på OpenSSL i aktion.

Forestil dig, at du læser din Yahoo-mail, men ikke har gjort noget i et stykke tid for at indlæse flere oplysninger. Din webbrowser ønsker at sikre, at Yahoos server stadig er oppe og lytte, så den sender en besked, der i det væsentlige siger: “Dette er en 40 KB-besked, du er ved at få. Gentag det hele tilbage til mig.” Dette er den hjerteslagsanmodning, vi diskuterede tidligere. Hjerteslagsanmodninger kan have varierende størrelser (op til 64 KB), og hver anmodning skal indeholde oplysninger om dens specifikke længde.

Når Yahoos server modtager denne meddelelse, tildeler den en hukommelsesbuffer – et område af fysisk hukommelse, hvor den kan gemme oplysninger – svarende til den rapporterede længde af hjerteslagsanmodningen. I vores eksempel er det 40 KB. Derefter gemmer serveren de krypterede data fra anmodningen i den hukommelsesbuffer, læser derefter straks dataene tilbage ud af dem og sender dem tilbage til din webbrowser. Når din browser får de samme oplysninger tilbage, som den sendte ud, kan den være sikker på, at den stadig har en forbindelse til den server, den har talt med indtil dette tidspunkt.

Sådan skal det fungere. Heartbleed-sårbarheden opstod, fordi OpenSSL’s implementering af hjerteslagsfunktionaliteten manglede en afgørende beskyttelse: computeren, der modtog hjerteslagsanmodningen, kontrollerede aldrig for at sikre, at anmodningen faktisk var så lang, som den hævdede at være. Så hvis en anmodning sagde, at den var 40 KB lang, men faktisk kun var 20 KB, ville den modtagende computer afsætte 40 KB hukommelsesbuffer, derefter gemme de 20 KB, den faktisk modtog, og derefter sende de 20 KB tilbage plus hvad der tilfældigvis var i de næste 20 KB hukommelse. Der kan være alle mulige ting i de 20 KB, for selv når en computer er færdig med information, fortsætter disse data i hukommelsesbuffere, indtil der kommer noget andet for at overskrive det. De ekstra 20 KB data er oplysninger, som angriberen nu har udtrukket fra webserveren.

Hvorfor er Heartbleed farligt?

Heartbleed er farligt, fordi det lader en angriber se indholdet af den hukommelsesbuffer, som kan omfatte følsomme oplysninger. Ganske vist, hvis du er angriberen, har du ingen måde at vide på forhånd, hvad der kan lure i de 20 KB, du lige har grebet fra serveren, men der er et number af muligheder.  Det kan være volapyk eller ubrugelig cruft. Hvis du er rigtig heldig, kan du få SSL private nøgler, hvilket ville give mulighed for dekryptering af sikker kommunikation til den server; dette er usandsynligt, men ville være den hellige gral for en angriber. Mere almindeligt kunne du få brugernavne og adgangskoder tilbage, der var blevet sendt til applikationer og tjenester, der kører på serveren, hvilket ville give dig mulighed for at logge ind på disse apps og få adgang til brugerkonti.

Randall Munroes web-tegneserie xkcd er kendt for at gøre vanskelige videnskabelige begreber tilgængelige, især inden for datalogi, Munroes specialitet.  Denne xkdc-tegneserie fra 2014 gør et godt stykke arbejde med at opsummere, hvordan Heartbleed-sårbarheden fungerer på en kortfattet måde.

Hvordan blev Heartbleed opdaget?

Heartbleed blev faktisk opdaget af to forskellige grupper, der arbejder uafhængigt på meget forskellige måder: en gang i løbet af en gennemgang af OpenSSL’s open source-kodebase og en gang under en række simulerede angreb mod servere, der kører OpenSSL. De to uafhængige opdagelser skete inden for få uger efter hinanden, hvilket er noget ironisk i betragtning af, at sårbarheden havde luret uopdaget i to år.

Den første til at opdage Heartbleed var Neel Mehta, en ingeniør, der arbejder hos Google, i marts 2014. Mehta havde besluttet at foretage en linje-for-linje ausit af OpenSSL-koden , fordi to tidligere SSL-fejl, der var blevet afsløret tidligere på året, goto fail og GnuTLS, fik ham til at mistanke om, at andre farer kunne lure andre steder i SSL / TLS-økosystemet. Efter at han opdagede fejlen og indså dens konsekvenser, begyndte Google privat atundervisenogle infrastrukturvirksomhedersom CloudFlare om det, selvom de ikke offentliggjorde det eller sagde noget til den amerikanske regering.

Den anden opdagelse skete hos Codenomicon, et finsk cybersikkerhedsfirma, blot et par uger senere. Virksomheden arbejdede på et produkt kaldet Safeguard, designet til penetrationstest på krypterings- og godkendelsesværktøjer. I den store tech-industritradition med at spise dit eget hundefoder besluttede Codenomicon at teste Safeguard på deres egen infrastruktur – og opdagede, at de kunne få adgang til en chokerende mængde data.

Codenomicon fortsatte helt anderledes end Google: ikke kun offentliggjorde de deres opdagelse, men de mærkede det: det var dem, der kom med Heartbleed-navnet, og de designede endda et logo til det. Det var et af de første (men på ingen måde de sidste) eksempler på et sikkerhedsfirma, der gjorde opdagelsen af en sårbarhed til en markedsføringsmulighed.

Heartbleed CVE

Identifikatoren for Heartbleed i det fælles system for sårbarheder og eksponeringer (CVE) er CVE-2014-0160;  du kan følge dette link for et væld af oplysninger om fejlen. “Heartbleed” er naturligvis meget fængende, så du kan forstå, hvorfor Codenomicons navn sidder fast.

Heartbleed kode

En enkelt kodelinje indeholder den fejl, der gav anledning til Heartbleed-sårbarheden:

memcpy (bp, pl, nyttelast);

memcpy () er den kommando, der kopierer data.  bp er det sted, det kopierer det til, pl er, hvor det kopieres fra, og nyttelast er længden af de data, der kopieres. Som vi har set, er problemet, at der aldrig er noget forsøg på at kontrollere, om mængden af data i pl er lig med værdien af nyttelast.

Det mest ironiske her er, at OpenSSL er open source-software. Enhver kunne se på koden, og formodentlig hundreder gjorde det, men indtil Mehta og Codenomicon-teamet snuble over den, bemærkede ingen denne ret elementære kodningsfejl. Faktisk, fordi open source-projekter som OpenSSL omhyggeligt holder styr på bidragydere, ved vi, hvis fejl det var: Robin Seggelman, en tysk softwareudvikler, der havde ydet adskillige bidrag til OpenSSL-projektet.

Hvem er påvirket af Heartbleed?

Der har været virkelige udnyttelser af Heartbleed-sårbarheden, selvom det ikke er klart, om nogen fandt sted, før fejlen blev bredt offentliggjort. Det er muligt, at nogle forsøg på angreb opdaget af sikkerhedsfirmaer allerede i 2013 undersøgte sårbarheden – og nogle mener, at angriberne var statslige sikkerhedsorganer.

Efter april 2014, da Codenomicon offentliggjorde sårbarheden, var der en byge af aktivitet og en vis mængde kaos, da virksomheder kæmpede for at opdatere deres systemer; for eksempel blev Yahoo- og OKCupid-brugere kortvarigt rådet til ikke at logge ind på deres konti , før disse tjenester administrerede patch deres installationer af OpenSSL, og at ændre deres adgangskoder, når de fik adgang igen.

Mens de store virksomheder formåede at få deres ænder i træk, før noget dårligt ramte dem, var hackere i stand til at udnytte sårbarheden i flere tilfælde. Et angreb på Community Health Systems, der stjal patientdata , blev skylden på Heartbleed, ligesom tyveri af hundres af sociale ID-numre fra det canadiske indtægtsagentur.

Heartbleed omkostninger

Heartbleed havde omkostninger, der gik ud over skaderne forårsaget af disse vellykkede angreb; Security Magazine anslog, at bare omkostningerne ved tusindvis af organisationer, der har brug for at tilbagekalde og erstatte deres SSL-certifikater, kunne løbe så højt som $ 500 millioner.  Tilføj de arbejdstimer, der kræves for at kontrollere og opdatere systemer, og du har en stor stigning i udgifter, der kan knyttes direkte til denne sårbarhed.

Heartbleed-rettelsen

Heartbleed-rettelsen blev rullet ud i version 1.0.1g af OpenSSL-biblioteket, udgivet den 8. april 2014, og blev også inkluderet i alle efterfølgende versioner af softwaren. Du kan rette Heartbleed-sårbarheden ved at opgradere til den nyeste version af OpenSSL og kan finde links til al den nyeste kode på OpenSSL-webstedet.

Den første del af denne kode sørger for, at hjerteslagsanmodningen ikke er 0 KB, hvilket kan forårsage problemer. Den anden del sikrer, at anmodningen faktisk er så lang, som den siger, den er.

Er Heartbleed stadig et problem?

I betragtning af at Heartbleed blev opdaget og lappet for mere end otte år siden, kan du blive overrasket over at høre, at mange servere stadig har Heartbleed-sårbarheden – faktisk var der over 200.000 online i november 2020, ifølge en forsker ved SANS Internet Storm Center.  Selvom dette tal sandsynligvis er faldet lidt siden da, er der næsten helt sikkert en række sårbare servere, der stadig venter på at blive hacket. Erfarne sikkerhedsprofessionelle vil sandsynligvis ikke være så overraskede over at lære dette – det er alt for almindeligt, at virksomheder forsømmer patching for at undgå nedetid på missionskritiske systemer uden sikkerhedskopier eller simpelthen af forsømmelse – men det store antal upatchede maskiner bør være et wakeupcall om vigtigheden af at udrulle et robust patch management-program i din egen butik.

Heartbleed sårbarhedstest: Sådan opdages Heartbleed

Du kan nemt teste dine servere for at opdage Heartbleed-sårbarheden ved hjælp af gratis onlineværktøjer. For eksempel har pentest-tools.com en gratis webbaseret test,  der giver dig mulighed for at indtaste en URL for at finde ud af, om en server er blevet korrekt patchet til Heartbleed og en række andre sårbarheder.

Hvis du opdager, at en server under din kontrol har været sårbar i nogen tid, er der mere at gøre end bare at opdatere OpenSSL-koden. For eksempel bør du ændre de SSL-certifikater, der bruges af serverne, da de muligvis er blevet kompromitteret uden at efterlade spor. Mere fodgænger, men stadig vigtigt: brugere, der har konti på systemet, skal ændre deres adgangskoder.

Kilde: CSO

Foto: pexels