Heartbleed är sannolikt den värsta sårbarheten som upptäckts hittills. Från en webbserver kan det vara möjligt att hämta ut information såsom:
Heartbleed har fått sitt namn från den funktion i OpenSSL som är sårbar, heartbeat. Funktionen har lagts till i senare versioner av OpenSSL (1.0.1) och är till för att hålla en förbindelse vid liv för att minimera onödiga omförhandlingar av sessionen. OpenSSL är dels en applikation, som kan användas för att skapa och hantera nycklar med tillhörande certifikat, dels ett bibliotek som kan användas av utvecklare som vill implementera stöd för SSL/TLS i en applikation, lastbalanserare, virtualiseringsplattformar, VPN-lösningar med mera. Den kanske vanligaste användningen av detta bibliotek är som insticksmodul till webservern Apache (mod_ssl).
Sårbarheten möjliggör för en angripare att använda heartbeat-funktionen för att läsa 64KB minne från den process som OpenSSL körs under, exempelvis webbservern Apache. Angriparen kan inte välja vilken del av minnet som skall läsas utan får godta det som heartbeat-funktionen lämnar ifrån sig. Dock kan angriparen ställa denna fråga hur många gånger som helst och på så vis skaffa sig en ganska bra bild över vad som finns i minnet för den aktuella processen. Vi kunde tidigt visa att det går att plocka ut den privata nyckeln från en FreeBSD-server (https://www.youtube.com/watch?v=4fX-unvgMVU), något som sedan visade sig även vara möjligt på Linux-system (http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge).
Rekommendationen är att patcha sårbara versioner av OpenSSL, generera nya nyckelpar med tillhörande certifikat och byta alla lösenord som kan ha exponerats. Självklart bör fler åtgärder vidtas med tanke på vilken information en angripare kan misstänkas ha kommit över från minnet för en process som använder sig av en sårbar version av OpenSSL.
Vi fick mycket tidigt vetskap om denna sårbarhet och trots detta så hittade vi ganska snabbt programkod som lagts ut på Internet för att utnyttja denna sårbarhet, dvs. exponera det som finns lagrat i minnet på en server. Vi kunde snabbt se att många känsliga system var sårbara, däribland stora företag, banker, certifikatsutfärdare (!), VPN-koncentratorer, lastbalanserare med flera. Det vi också noterade var att efter två dagar, efter det att sårbarheten var känd, var fortfarande närmare 5% av de mest besökta .se och .nu-adresserna (enligt Alexa) fortfarande sårbara! Det finns vissa belägg för att någon eller några känt till sårbarheten som funnits i OpenSSL sedan 2011 (https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013).
Slutledningsvis kan vi konstatera att bara för att koden är öppen betyder det inte att någon granskar den, i alla fall inte djupare än att en bugg hittas då och då. Det här är med all säkerhet inte sista gången vi ser en sårbarhet av detta slag. Vi måste med gemensam kraft se till att i detalj granska de system och systemkomponenter som har stor spridning och därmed kan utgöra ett hot mot vår säkerhet på exempelvis Internet. Vi kan inte ställa de stackars OpenSSL-utvecklarna till ansvar, vilka utvecklar OpenSSL på sin fritid. Däremot borde alla företag som drar nytta av deras teknik, inte minst de som bygger kommersiella produkter med detta som grundsten, kunna hjälpa dem med monetära insatser för att dels granska koden, men även förbättra koden och göra koden betydligt mer strukturerad. Detta gäller inte bara OpenSSL utan alla större projekt för öppen källkod.
Thomas Nilsson och Tomas Rzepka
