Vi hører regelmessig om sårbarheter som blir oppdaget og fikset. Noen store, mange små. Det er imidlertid få (om noen) som kommer opp i samme klasse som the Heartbleed bug i OpenSSL.

For sikre nettsider er OpenSSL det aller mest brukte kryptobiblioteket. Det er brukt i anslagsvis to tredjedeler av alle servere i verden. Men hva er egentlig denne sårbarheten? Hva blir konsekvensen? Og ikke minst: er det noe du kan gjøre?

Litt bakgrunn om TLS og heartbeat

TLS (Transport Layer Security) er den vanlige protokollen brukt for å sikre innhold som sendes mellom datamaskiner på internett (f.eks gjennom HTTPS på web, VPN, eller sikker e-post). TLS fungerer vanligvis slik at man setter opp en sikker forbindelse, sender og mottar data, og tar ned/avslutter forbindelsen når det ikke er mer data å sende. Så har det senere blitt laget et tillegg til TLS, kalt Heartbeat-utvidelsen, for å kunne opprettholde TLS forbindelser i perioder hvor data ikke sendes. I korte trekk er det slik at hvis én av partene ønsker å opprettholde en forbindelse kan denne sende en heartbeat-pakke som inneholder tilfeldige data. Hvis mottakeren aksepterer heartbeat-pakker svarer den med å sende tilbake den samme tilfeldige dataen som den mottok. Slik vet både sender og mottaker at begge ønsker å fortsette forbindelsen selv om de ikke har noe nyttig data å sende akkurat nå.

Hva er Heartbleed-feilen?

Feilen oppstår i hvordan Heartbeat-utvidelsen er implementert i OpenSSL (derav navnet “heartbleed”). En Heartbeat-pakke inneholder et felt som beskriver lengden på de tilfeldige dataene som sendes (maksimalt 64kB) i tillegg til de faktiske dataene. Noe forenklet, kan man si at feilen i OpenSSL er at man ikke sjekker om disse to samsvarer. Altså, om den oppgitte lengden på den tilfeldige dataen er den samme som den faktiske lengden på dataen. Dette gjør at en potensiell angriper i lengdefeltet kan si at den sender 64kB med tilfeldige data, mens den i realiteten bare sender 1 Byte. Uten å gå inn på detaljer om minnehåndtering i C og OpenSSL er det likevel slik at når OpenSSL svarer på en slik melding sender den ikke tilbake den ene byten med data, men istedet 64kB data (eller tilsvarerende lengdefeltet i den mottatte heartbeat-pakken). Og den ekstra datamengden hentes fra minnet. Voila, så har angriperen fått tak i 64kB av minnet OpenSSL bruker. Og hvis 64kB ikke er nok kan angrepet gjentas i det kjedsommelige…

Det kan imidlertid være greit å påpeke at angriperen ikke kan spesifisere hvilken del av minnet som skal leses, slik at man må ha litt flaks og/eller utholdenhet for å få tak i det en vil ha. Minnet kan inneholde kryptografiske nøkler, passord, cookies, osv. Men i følge Neel Mehta (én av de som oppdaget feilen) så er det lite sannsynlig at nøkler kan leses.  Problemet er uansett at det er umulig å vite om angrepet har vært brukt og i tilfelle hvilke data angriperne fikk med seg. Man kan derfor ikke avskrive muligheten for at nettopp private nøkler er på avveie.

Hvilke konsekvenser får dette?

Siden det er umulig å vite om sårbarheten har vært utnyttet og i tilfelle hvilke data som ble stjålet er det selvsagt også umulig å si noe sikkert om konsekvensen av dette. I tradisjonell sikkerhetstankegang må man anta at angrepet har vært utført og at alle data som noen gang i løpet av de to siste årene har vært lagret i minnet av OpenSSL  er på avveie. Brukere må altså anta at passord, e-poster, personinformasjon, bankinformasjon, kortinformasjon – alt – er på avveie. Tjenesteleverandører må også anta det samme, og i tillegg at sesjonsnøkler, delte nøkler og til og med private nøkler er på avveie (med mindre man har brukt en sikker maskinvare til oppbevaring/bruk av nøkler).

Det som skiller Heartbleed fra en hvilken som helst annen sikkkerhetsfeil (hull) er at OpenSSL er så vanvittig mye brukt, at sårbarheten har vært der i over to år og at angrepet er så enkelt at det lar seg utføre uten noen spesiell sikkerhetskompetanse eller bruk av avanserte programmer.

Hva skal vi gjøre?

For brukere er det igrunn bare å gjøre som NorSIS og Norsk Sikkerhetsmyndighet (NSM) anbefaler: bytt alle passord. Men, vær obs på at hvis det skal ha noen effekt å bytte passord må tjenestene der en skifter passord ha blitt oppgradert først. Ellers vil det nye passordet bli offer for akkurat den samme sårbarheten… (la oss håpe tjenstetilbyderne er raske med å oppdatere).

Edit: NorSIS anbefaler at man venter med passordbytte til tjenesten er oppdatert. NRK har laget  en kort liste med status for noen av de mest brukte tjenestene.

For tjenesteleverandører som kan ha sine private nøkler på avveie er det litt mer komplisert. I prinsippet må man be sertifikatutstederen (f.eks VeriSign) om å trekke tilbake det aktuelle sertifikatet, lage nye nøkler og få utstedt et nytt sertifikat fra utstederen. I og med at så mange kan være rammet av Heartbleed kan det imidlertid bli et problem at listen over ugyldige sertifikater (Certificate Revocation List) blir fryktelig lang og dermed tidkrevende å sjekke hver gang et sertifikat skal verifiseres. Og da kan det tenkes at f.eks VeriSign istedet velger å trekke tilbake sitt eget  sertifikat (intermediate CA) og utstede et nytt. Da må i så fall alle sertifikater lages på nytt, også de som ikke har vært utsatt for sårbarheten. Det er antakelig ikke veldig sannsynlig, siden det finnes måter å løse dette på som ikke innebærer bruk av CRL. Imidlertid synes det åpenbart at vi vil merke ettervirkningene av Heartbleed i en god stund fremover…

PS: Det har selvsagt dukket opp tjenester som avslører om tjenere er sårbare. Og hvis du synes det er litt ubehagelig å rette et potensielt angrep mot din egen tjener (“tjenesten” kan jo faktisk være ondsinnet), så finnes det også skript du kan verifisere og kjøre på din maskin.