Heartbleed

Heartbleed (CVE-2014-0160) – błąd bezpieczeństwa w popularnej bibliotece kryptograficznej OpenSSL, obecny w jej wersjach wydanych między 14 marca 2012 a kwietniem 2014, który pozwalał na nieautoryzowany zdalny odczyt danych z pamięci operacyjnej dowolnego programu używającego tej biblioteki do obsługi szyfrowanych połączeń sieciowych. Był błędem implementacji rozszerzenia protokołu TLS/DTLS „Heartbeat”.

Umożliwiając kradzież obecnych często w pamięci programów, i krytycznie ważnych dla bezpieczeństwa, prywatnych kluczy kryptograficznych i danych dostępowych (haseł czy kluczy sesji), błąd narażał systemy na łatwe wtórne ataki typu przechwytywanie sesji czy man in the middle – podszywanie się pod usługi i użytkowników lub podsłuchiwanie ich, a tym samym na dostęp także do szyfrowanej komunikacji, prywatnych kont, usług i danych zapisanych w pamięci zewnętrznej.

Ze względu na powszechność stosowania OpenSSL i skalę zagrożenia, błąd określono jako bardzo poważny. Po czasie okazało się jednak, że nie wykorzystano go do wielu publicznie opisanych nadużyć.

Mechanizm działania

Kontekst

Fragment interfejsu graficznego przeglądarki internetowej, na którym znajduje się symbol kłódki, reprezentujący stosowanie szyfrowanego połączenia.
TLS jest standardem używanym m.in. do szyfrowania połączeń HTTPS ze stronami internetowym. Wiele przeglądarek używa ikony kłódki obok pola adresu do zasygnalizowania, że komunikacja jest w ten sposób chroniona.

Protokoły SSL i TLS definiują powszechnie używane standardy kryptograficznej ochrony poufności i spójności danych w komunikacji sieciowej – sposób realizacji szyfrowanych połączeń w Internecie. Do 2012 standard TLS nie uwzględniał własnych funkcji związanych z długoterminowym utrzymywaniem połączeń. Komunikacja pozbawiona tej funkcjonalności może być wolniejsza, mniej płynna i bardziej wymagająca dla aplikacji – po zerwaniu lub zakończeniu jednej transmisji konieczna jest ponowna, pełna renegocjacja kolejnej. Nie dotyczyło to połączeń TLS opartych na samodzielnie rozwiązującym ten problem TCP, ale dotykało wariantu DTLS korzystającego z UDP. W lutym 2012 w dokumencie RFC 6520 ↓ zaproponowano rozszerzenie protokołu o funkcjonalność „Heartbeat” (pol. „puls serca”) – wymiany próbnych komunikatów, podobnej do ping (na zasadzie „wezwanie – odzew”), wspomagających monitorowanie i podtrzymywanie połączenia, oraz przy okazji odświeżających tablice trasowania i translacji adresów na jego drodze[1][2][3].

Definicja Heartbeat wymaga, aby w wezwaniu określono odrębnie treść (maksymalnie bajtów) i długość żądanego odzewu w bajtach (jako uint16, czyli szesnastobitowa liczba naturalna, maksymalnie ) – w związku z możliwością stosowania zmiennego paddingu (dodatkowych bitów wydłużających pakiet). Zgodnie ze standardem, wezwania niespójne lub w inny sposób błędne muszą być ignorowane. Rozszerzenie zezwala też na korzystanie z mechanizmu Heartbeat na prawie każdym etapie połączenia (w tym przed próbą autoryzacji, która może być zapisana w logu)[1][2][3][4][5][6].

Rozszerzenie Heartbeat zaimplementowano w programach korzystających z szyfrowanej komunikacji, oraz w bibliotekach programistycznych z gotowymi funkcjami kryptograficznymi udostępnianymi innym programom. Jedną z takich bibliotek rozwija nieodpłatnie, w modelu wolnego i otwartego oprogramowania, projekt OpenSSL. Korzystają lub korzystały z niej m.in. bardzo popularne serwery HTTP (Apache, nginx, Lighttpd, Tomcat), poczty elektronicznej (Sendmail, Postfix, Qmail, Exim, Dovecot, Zimbra), baz danych (MySQL, PostgreSQL, MongoDB), czy OpenVPN, OpenLDAP, a także program Bitcoin[3][4].

Błąd implementacji

Implementacja w bibliotece OpenSSL, niezgodnie ze standardem, nie weryfikowała czy żądana treść i długość odzewu są zgodne – programista pominął konieczność sprawdzania zakresu. Wskutek tego, odpowiadała także na błędne wezwania do odesłania danego tekstu z długością przekraczającą jego faktyczny rozmiar. W takim przypadku nadal odsyłała zawartość nieprawidłowo określonego bufora – cały fragment pamięci operacyjnej o żądanej długości (do 64 KB), zaczynający się od praktycznie losowego adresu pod którym zapisano wyznaczoną odpowiedź, oraz znajdujące się po niej dowolne inne dane przechowywane tam aktualnie przez program – w tym potencjalnie wrażliwe informacje[3][4][7][8][6][9]. Przy każdym żądaniu możliwy był wyciek ok. bajtów (64 KB) pamięci[10].

Choć mechanizm błędu nie pozwalał na celowy wybór adresu ujawnianej pamięci, wezwanie można było wysyłać wielokrotnie i do skutku. Ponieważ nie trzeba było przy tym zaczynać prób autoryzacji, ataki nie zostawiały z reguły śladu w standardowych logach[2][4][5]. W praktyce, wykradana zawartość pamięci okazywała się różna w zależności od systemu – niektóre ujawniały natychmiast hasła, inne głównie nieprzydatne dane[11]. W eksperymentach CERT Polska, badacze wysyłający żądania „Heartbleed” do różnych usług internetowych uzyskali w odpowiedzi fragmenty m.in. wiadomości e-mail, ciasteczek z kluczami sesji, danych dostępowych do VPN, konfiguracji serwerów sieci Tor (w tym ich ukrywanych adresów IP), czy logów serwera. Relacjonowali też, że inne osoby zdobyły tym sposobem inne dane dostępowe, czy fragmenty konfiguracji serwerów WWW, w tym plików .htaccess mogących zawierać dane autoryzacyjne[12].

Umożliwiona przez błąd kradzież kluczy prywatnych pozwalała na podszywanie się i odszyfrowanie zapisów starych transmisji (o ile nie podlegały technice utajniania z wyprzedzeniem). Kradzież ciasteczek sesyjnych pozwalała z reguły na bezhasłowe wejście na konto. Dzięki szybkiej dostępności gotowych skryptów po ujawnieniu podatności, wykonanie takich ataków było w ocenie ekspertów banalnie proste[3][4][13][14][15].

Historia

Okno terminala, w którym uruchomiono skrypt do wykorzystania podatności. W uzyskanej odpowiedzi serwera widać dane dostępowe.
Symulowane wykorzystanie Heartbleed do uzyskania z serwera HTTP fragmentu pamięci, który zawiera login, hasło, i ciasteczko sesyjne użyte chwilę wcześniej przez obcego użytkownika serwisu.

Definicję rozszerzenia Heartbeat opublikowano oficjalnie w lutym 2012 w dokumencie RFC 6520 ↓. Już pod koniec 2011 jeden z autorów RFC, Robin Seggelmann, wówczas doktorant w Fachhochschule Münster (Uniwersytet Nauk Stosowanych w Münsterze), przygotował implementację funkcji w rozwijanej w modelu wolnego i otwartego oprogramowania bibliotece OpenSSL. Po złożeniu przez Seggelmanna wniosku o dodanie wyniku jego pracy do kodu biblioteki, jego zmiany zostały sprawdzone przez Stephena N. Hensona, jednego z czterech głównych programistów i jedynego pełnoetatowego pracownika projektu. Henson nie zauważył błędu w implementacji i krótko przed północą 31 grudnia 2011 przyjął wadliwy kod do oficjalnego repozytorium. Błąd rozprzestrzenił się wraz z włączeniem rozszerzenia do wydania 1.0.1 OpenSSL 14 marca 2012. Funkcja „pulsu” była domyślnie włączona i nie podlegała konfiguracji, narażając na zagrożenie większość użytkowników wersji dotkniętych zmianą. Na błąd podatne były wersje od 1.0.1 do 1.0.1f oraz 1.0.2-beta i 1.0.2-beta1[1][3][4][7][8][16].

Po ujawnieniu błędu w kwietniu 2014, Seggelman przyznał się do jego autorstwa, tłumacząc to jako nieszczęśliwą programistyczną pomyłkę, i wspominał, że w tym czasie poprawiał wiele błędów i dodawał liczne nowe funkcjonalności do kodu[17]. Likwidujące problem poprawki zostały uwzględnione we wszystkich wersjach biblioteki począwszy od 1.0.1g wydanej 7 kwietnia 2014[18].

Jak zwracali później uwagę komentatorzy, projekt OpenSSL był w tym czasie utrzymywany przez bardzo małą grupę wolontariuszy, spośród nielicznych ekspertów w niszowym i specjalistycznym temacie – dlatego kontrola jakości kodu była trudna. Przykładowo, Dan Kaminsky wskazywał że projektowanie i implementacja bezpiecznych protokołów jest bardzo żmudną i niewdzięczną pracą, która przyciąga mało chętnych, choć to krytyczny element infrastruktury telekomunikacyjnej. Strona projektu wymieniała w tym czasie 15 aktywnych oficjalnych członków, z których jedynie Henson był zatrudniony na pełen etat. Wskazywano na relatywnie niski budżet projektu, nieproporcjonalny do ogromnej popularności biblioteki. OpenSSL otrzymywało wówczas ok. $2000 charytatywnych wpłat rocznie. Deweloperzy dorabiali dodatkowo do ok. $1 miliona łącznie jako konsultanci, jednak służyło to głównie ich prywatnemu utrzymaniu. Po ujawnieniu błędu inicjatywa Linux Foundation, z udziałem m.in. Facebooka, Google, IBM i Microsoftu, zdecydowała się zapewnić większe finansowanie dla podstawowej otwartoźródłowej „infrastruktury”, poczynając od OpenSSL[1][4][9][19][20].

Wykrycie

Błąd pozostał prawdopodobnie niewykryty przez dwa lata[21]. Pod koniec marca 2014 dwie niezależne grupy badaczy poświęcały uwagę jakości kodu OpenSSL. Neel Mehta z Google Security zajmował się, jak wspominał, żmudnym audytem tej biblioteki, zaniepokojony mniej poważnymi błędami w podobnych programach ujawnionymi wcześniej w 2014[7][22]. Antti Karjalainen, Riku Hietamäki i Matti Kamunen z fińskiej firmy Codenomicon wykorzystywali OpenSSL do testów nowego fuzzera protokołów[5][6][21]. Mehta odkrył błąd 21 marca lub wcześniej; od tego dnia Google zaczęło wprowadzać poprawki w swoich systemach[3][23]. Zespół Codenomicon odkrył podatność 3 kwietnia (czasu fińskiego)[6][3].

Początkowo dwa zespoły nie wiedziały wzajemnie o swoich pracach i podejmowały odrębne działania, aby odpowiedzialnie ujawnić podatność. Przed oficjalnym ogłoszeniem doszło też rzekomo do pojedynczych wycieków plotek i informacji, poprzez prywatne znajomości pracowników Google, Codenomicon i innych firm. Przedstawiciele CloudFlare twierdzili na przykład, że otrzymali 31 marca jakąś drogą ostrzeżenie (według niektórych źródeł, przez rozmowę zaprzyjaźnionych inżynierów). Jak relacjonuje m.in. szczegółowy przegląd „The Sydney Morning Herald”, 1 kwietnia Google Security skontaktowało się z projektem OpenSSL, którego członkowie zaczęli przygotowania do ogłoszenia i wydania poprawek w pierwotnie planowanym terminie 9 kwietnia. Wiadomość Google wspominała też, że „powiadomiono niektórych dostawców infrastruktury pod warunkiem tajności”. 3 kwietnia (czasu fińskiego) Codenomicon odkryło niezależnie podatność, i tego samego dnia powiadomiło fińską organizację typu CERT (NCSC-FI). Firma odmówiła odpowiedzi na pytania, czy poinformowała kogoś jeszcze. 4 kwietnia łaty na błąd wprowadziła firma Akamai (podając później sprzeczne wyjaśnienia, m.in. że otrzymała informację od kogoś z projektu OpenSSL). W tym czasie w społeczności open source zaczęły już krążyć plotki o nieznanym, poważnym błędzie w bibliotece. 5 kwietnia Codenomicon kupiło domenę Heartbleed.com, którą wykorzystało później do kampanii informacyjnej. 6 kwietnia NCSC-FI zaczęło uzgadniać z amerykańskim CERT/CC nadanie podatności opisu i numeru CVE. Wieczorem 6 kwietnia członek OpenSSL pracujący dla Red Hat zawiadomił o podatności główny zespół tej dystrybucji Linuxa i autoryzował dalsze przekazywanie tej informacji wśród głównych programistów innych systemów operacyjnych. Inny pracownik Red Hat wysłał następnie ogólnikową informację na listę mailingową deweloperów OS, prosząc programistów dużych projektów o kontakt, i deklarując że udzieli dokładniejszych informacji pod warunkiem tajności. Po fakcie podał, kto zdążył się z nim skontaktować i uzyskał odpowiedź – m.in. przedstawiciele projektów SuSE, Debian, FreeBSD i ALT Linux. Kontaktowy pracownik RH udał się jednak na odpoczynek, i nie odpowiedział na wiadomości od projektów Ubuntu, Gentoo i Chromium do momentu publicznego ogłoszenia podatności. 7 kwietnia informację zdobył z wyprzedzeniem rzekomo także Facebook (dzięki rozmowie znajomych inżynierów). Tego dnia NCSC-FI skontaktowało się bezpośrednio z OpenSSL. Odkrycie, że na błąd trafił drugi zespół wzbudziło w członkach projektu konsternację. Zdecydowali się zaniechać pozostałe kroki koordynowanego z Red Hat procesu ujawniania podatności, jak najszybciej wydać poprawki i ogłosić jej istnienie. Dokonano tego w ciągu następnych godzin – załatana wersja ukazała się ok. 19:49, a publiczne zawiadomienie o błędzie ok. 22:37 (czasu polskiego). Własne ogłoszenia w tym czasie wstawiło też m.in. Cloudflare, Mehta i Codenomicon (na Heartbleed.com)[2][6][3][7][9][23][24][25][26][27][28].

Komentatorzy, np. eksperci cytowani przez „The Sydney Morning Herald”, przedstawiali różne oceny procesu ujawnienia błędu. Część branży IT czuła się pominięta w obiegu ostrzeżeń z wyprzedzeniem, i wzięta przez problem z zaskoczenia. Inne osoby chwaliły odkrywców za wykazaną ostrożność, wstrzemięźliwość, odpowiedzialność, i uniknięcie szerokich wycieków[2][6][26][29].

Mehta otrzymał w kolejnych dniach za odkrycie błędu nagrodę w wysokości $15000, od finansowanego przez Facebook i Microsoft programu bug bounty HackerOne, którą przekazał Freedom of the Press Foundation[23][30].

Wykreowanie marki

Logo Heartbleed – część serwisu informacyjnego opublikowanej przez firmę Codenomicon, zaprojektowane przez jej graficzkę Leenę Snidate.

Po ogłoszeniu podatności, Codenomicon upubliczniło przygotowaną wcześniej, prostą i przyjazną dla laików, stronę Heartbleed.com z opisem problemu – nadając mu w ten sposób obiegową nazwę[5][9]. Nawiązujące do mechanizmu Heartbeat hasło „Heartbleed” wymyślił Ossi Herrala, administrator systemów z Codenomicon[25]. Stronie towarzyszyło też logo, które zaprojektowała pracująca w Codenomicon graficzka Leena Snidate. Według cytowanego przez ABC News specjalisty, Heartbleed był pierwszym błędem czy wirusem, który zdobył taki „branding” – do tej pory okazjonalnie wymyślano im tylko nazwy[31]. Codenomicon przedstawiło w tekście wagę problemu, informując że w eksperymentach badaczom udało się wydobyć z testowych systemów klucze, certyfikaty, loginy i hasła, wiadomości, e-maile i dokumenty, nie pozostawiając po tym śladu[21]. Według komentarzy, m.in. Mehty, ten marketing był zaskakująco skuteczny i pomógł sprawnie poinformować publikę. Pochwały zdobyła też sama „niestandardowa, ewokująca emocjonalnie” nazwa i logo[22][32][33]. W ciągu dwóch pierwszych dni po publikacji liczba odwiedzin strony sięgnęła 1,4 miliona[25].

Diagnoza podatności

W pierwszych dniach po ogłoszeniu błędu zarówno popularne media, jak i specjaliści IT alarmowali o jego powadze, dzieląc się potwierdzonymi i niepotwierdzonymi informacjami. Bruce Schneier określił błąd jako „katastrofalny”, „na skali od 1 do 10, to jest 11”; eksperci wskazywali na niepozostawiającą śladów w logach podatność całej pamięci masowo używanego oprogramowania[5][17][34]. Autor piszący dla firmy Kaspersky stwierdził, że błąd jest potencjalnie „apokaliptyczny”[35]. Brian Krebs opisywał problem jako bardzo poważny[36]. Reporter TechCrunch relacjonował, że „wielu znajomych specjalistów od bezpieczeństwa sieci jest dziś w panice”[13]. Materiał z NPR określił problem jako „druzgocący”[16], a autor „The Washington Post” pisał, że to „najpoważniejszy błąd w ostatnich latach, który powinien niepokoić każdego użytkownika Internetu”[21], Po czasie Mehta, jeden z odkrywców błędu, stwierdził że wiele wczesnych komentarzy jakie widział było jego zdaniem hiperbolicznych[22].

Media podawały początkowo, że luka „może być wykorzystana do ataku na większość serwerów”[37][38]. Wiele relacji odnosiło się do faktu, że udział oprogramowania Apache i nginx wynosił w tym czasie 2/3 liczby popularnych serwisów WWW – co miało określać skalę potencjalnych ataków. Dokładne testy ujawniły, że było to przeszacowanie – nie wszystkie z tych systemów korzystały z OpenSSL w podatnej wersji, albo z SSL w ogóle. Badacze firmy Netcraft skanujący różne zakresy przestrzeni adresów IPv4 szacowali, że luka może występować na 17,5% serwerów WWW (ok. 500 tys. certyfikatów SSL)[4][3][7][8][9][18][29][35][39][40]. Według innego źródła 9 kwietnia podatnych było 47 z 1000 i 628 z 10 tys. najpopularniejszych stron[18]. Jeszcze inna relacja podała 9 kwietnia wartość 11%, a 13 kwietnia 6,2% z najpopularniejszego miliona witryn według Alexy[41]. Według badania opartego o wielokrotny skan całej przestrzeni adresów IPv4, z miliona najpopularniejszych domen wg Alexy, reprezentujących ok. 629 tys. certyfikatów, ok. 123 tys. było potencjalnie podatnych[10]. Badanie Durumerica i in. oszacowało w oparciu o przegląd publikacji i własne analizy, że w momencie ujawnienia błędu podatnych było 24–55% serwisów WWW używających HTTPS. Popularne strony szybko wprowadzały poprawki – w ciągu dwóch dób wszystkie 500 stron z czołówki rankingu Alexy było już zabezpieczonych[3].

W Polsce, według komentarza CERT Polska z 11 kwietnia 2014, po kilkudziesięciu godzinach od ogłoszenia z 13490 najpopularniejszych adresów WWW w domenie .pl, 765 (5,7%) pozostawało podatnych na błąd, „w tym kilkanaście dużych sklepów internetowych”[12]. Specjalista cytowany przez „Komputer Świat” wskazywał, że na liście wyników skanu podatności znajdowała się m.in. strona ING Banku Śląskiego[37]. Niebezpiecznik.pl zasugerował też, że 10 kwietnia podatny był nadal polski serwis obsługi studiów USOSweb[42]. Przez 6 dni po ogłoszeniu błędu nieaktualizowane pozostawały serwisy płatności mPay i Cardmobile. Według Niebezpiecznika, badacze wydobyli z nich dane osobowe, numery kart kredytowych, i ciasteczka sesyjne[42][43].

Na różnych listach potencjalnie podatnych serwisów na świecie wymieniano takie firmy lub organizacje, jak Yahoo, Intuit, Dropbox, Netflix[9], Instagram, Pinterest, Etsy, GoDaddy, SoundCloud, Venmo, Box, Dropbox, GitHub, OKCupid, Wikipedia, WordPress[44], Imgur, Eventbrite, FBI[15], HypoVereinsbank, Regents Bank, Commonwealth Bank of Australia[8], Ars Technica[18], DuckDuckGo i RedTube[38], Reddit[3], oraz stronę projektu OpenSSL[36]. Nie we wszystkich przypadkach kryteria uwzględnienia w spisie były pewne; pojawiały się na nich także Google i Facebook[9][44], które według innych informacji miały zabezpieczyć się przed atakami z wyprzedzeniem[40][45]. Akamai (content delivery network obsługujące „30% ruchu w Internecie”) miało być zabezpieczone, ale okazało się to niekompletne[46]. Serwisy Yahoo (w tym Flickr i Tumblr) były zaktualizowane z opóźnieniem, przez co firma przyciągnęła szczególnie wiele krytyki[37][42]. Zademonstrowano wycieki danych dostępowych z jej usług[16]. Anonimowa osoba wykorzystała błąd na Steam do przechwycenia sesji jednego z partnerów serwisu i zastąpienia jego profilu prośbą o załatanie podatności[42]. Błąd wykryto też w grze Minecraft, która wyłączyła serwery na czas naprawy[35].

Oprócz systemów HTTP, z OpenSSL z błędem korzystały też – zależnie od wersji – serwery poczty elektronicznej (Sendmail, Postfix, Qmail, Exim, Dovecot, Zimbra), baz danych (MySQL, PostgreSQL, MongoDB), czy OpenVPN, OpenLDAP, a także Tor i program Bitcoin[3]. Według eksperymentów Durumerica i in., 10 kwietnia w losowej próbie adresów IP 7,5% serwerów pocztowych obsługujących szyfrowanie, i aż 48% węzłów Tor było podatnych na Heartbleed[3]. Poza serwerami WWW, podatne mogły być też aplikacje klienckie. Taką lukę miał system Android 4.1.1 (Jelly Bean), czy niektóre kompilacje CURL[7][47][42].

Jako podatne wymieniano również oprogramowanie sprzętowe niektórych produktów takich firm jak IBM, Cisco, VMware, Dell, Intel, NetApp[20], QNAP, D-Link, Synology, pfSense, Fortinet, Lexmark, Brother i Hewlett-Packard[3]. OpenSSL w wadliwej wersji było też standardową częścią stabilnych wydań takich systemów operacyjnych jak Debian Wheezy, Ubuntu 12.04.4 LTS, CentOS 6.5, Fedora 18, OpenBSD 5.3, FreeBSD 8.4, NetBSD 5.0.2 i OpenSUSE 12.2[48].

Przez krótki czas podatne były popularne systemy infrastruktury sieciowej Amazon AWS ELB i Cloudfront SSL. Według wspomnień głównego inżyniera AWS ELB, naprawa problemu przyjęła najwyższy priorytet; zdecydowano się na zatrzymanie niektórych usług, i zalecenie unieważnienia starych kluczy. Zespół szybko przygotował łatę do dystrybucji, oraz uruchomił reguły filtrujące ataki na poziomie zapory sieciowej dla ochrony klientów, którzy nie byli w stanie dokonać aktualizacji[33][42].

Cloudflare ogłosiło, że dostało ostrzeżenie 31 marca i załatało podatność z wyprzedzeniem. Korzystając z publicznej uwagi, firma podała też, że zdaniem jej specjalistów kradzież kluczy prywatnych do certyfikatów jest nieprawdopodobna, i wskazała jako publiczne wyzwanie adresy serwerów do testowania tej tezy. Komentatorzy, np. Schneier, przyjęli to twierdzenie jako źródło nadziei, że sytuacja nie jest tak zła, jak się początkowo wydawała. Dwie osoby zdobyły jednak w krótkim czasie klucze z serwerów Cloudflare, które przyznało się do błędu[4][42][49][50][51][52][53].

Działania zaradcze

Projekt OpenSSL opublikował łatę na błąd, i poprawioną wersję biblioteki, 7 kwietnia 2014 razem z ogłoszeniem podatności. W pierwszych dniach powstały też liczne narzędzia testowe i rozszerzenia do przeglądarek sprawdzające bezpieczeństwo; dzielono się również definicjami filtrów do zapór sieciowych i systemów IPS/IDS[37][42]. Wśród rad dla użytkowników, i głównie pracowników IT, wymieniano przede wszystkim aktualizację OpenSSL[35], a także „wymianę certyfikatów, zmianę haseł, skasowanie aktywnych tokenów sesyjnych”[7][16]. Podawane w mediach zalecenia dotyczące zmiany haseł były niespójne – niektóre źródła sugerowały, aby je jak najszybciej zmienić, według innych najlepiej było nie logować się w ogóle[18][19][21][40]. Niektóre źródła, m.in. Tor Project, zalecały aby na kilka dni całkiem zrezygnować z używania Internetu, lub przynajmniej nie logować się do ważnych systemów[15][29][35][37][40]. Autor Kaspersky Blog sugerował, aby użytkownicy włączyli w przeglądarkach wymuszenie sprawdzania unieważnienia certyfikatów[38]. Reporter CNet proponował zaś, aby przez kilka dni po 7 kwietnia monitorować konta bankowe, i szukać podejrzanych transakcji[40].

Firmom i pracownikom IT zalecano uczciwe powiadomienie użytkowników o sytuacji. W ciągu następnych dni masowo instalowano aktualizacje i łaty na serwerach[2][3][18][35]. Imgur zresetowało dla ostrożności wszystkie ciasteczka i identyfikatory sesji[40]. Szybko opublikowano też aktualizacje firmware sprzętu sieciowego[4]. Według zespołu Zhanga i in., w ciągu pierwszych trzech tygodni szacunkowo 73% certyfikatów nie zostało odnowionych, a 87% starych nie unieważniono[10]. Według badania Durumerica i in., w ciągu pierwszego miesiąca tylko 10% stron używających HTTPS wymieniło certyfikat, a z nich 14% wygenerowało go przy pomocy starego klucza[3].

W Polsce, w ocenie redakcji serwisu Niebezpiecznik, popularne serwisy internetowe zareagowały na problem generalnie szybko, ale nie zdecydowały się od razu na wymuszenie zmiany haseł czy odnowienie certyfikatów[42].

Potwierdzone wykorzystania błędu

W pierwszych dniach po ogłoszeniu podatności opublikowano narzędzia do jej wykorzystywania, „które [umożliwiały] przeprowadzenie ataku nawet gimnazjalistom”[42]. Wg komentarza z „The Economist”, pomimo obaw że będzie to największy kryzys zabezpieczeń komputerowych w historii, nie stało się tak „być może bardziej dzięki szczęściu niż mądrości”[4].

Ze względu na mechanizm podatności, próby włamań nie zostawiały z reguły śladów w logach. Jest niejasne, czy ktokolwiek wiedział o podatności i korzystał z niej w czasie dwóch lat jej istnienia przed odkryciem[7][15][37][42]. Według „The Economist” w ocenie ekspertów było to mało prawdopodobne, bo bardzo niewiele osób jest wystarczającymi specjalistami co do programowania i kryptografii – co samo w sobie było jedną z przyczyn wprowadzenia błędu[4]. W mediach pojawiały się spekulacje, czy np. NSA, oraz chińskie i rosyjskie agencje wywiadu, wiedziały o podatności wcześniej – jak twierdziły anonimowe źródła rzekomo związane z NSA cytowane przez „Bloomberg”[50]. Według Piotra Koniecznego z Niebezpiecznik.pl, nie przedstawiono na to dowodów. Oficjalne wypowiedzi, w tym oświadczenie prezydenta Obamy, odcinały się od takiej możliwości. Konieczny zapytał retorycznie, czy jakikolwiek rząd mógłby utrzymywać tak poważny błąd, pozwalając na jego wykorzystywanie również obcym wywiadom we własnym kraju?[49] Według oświadczenia Białego Domu, nikt z rządu amerykańskiego nie został ostrzeżony z wyprzedzeniem[45]. Także jeden z odkrywców podatności, Mehta wątpił, by używali jej wcześniej szpiedzy[22]. Według przeglądu Durumerica i in., w kompletnych zapisach pakietów odebranych przez badawcze serwery honeypot z projektów LBNL, ICSI, NERSC, oraz prywatnego serwera członka zespołu, J. Alexa Haldermana, obejmujących wiele miesięcy z okresu 2012–2014, nie wykryto prób korzystania z błędu przed 7 kwietnia 2014. Po tym czasie rejestrowano tysiące masowych „sond”, które mogły być atakami lub eksperymentami[4][3][54].

Po ujawnieniu błędu, według raportu amerykańskiego Departamentu Bezpieczeństwa Krajowego z 11 kwietnia 2014, nie zgłoszono do wtedy poważnych nadużyć[55]. W późniejszych dniach media doniosły jednak o kilku zdarzeniach.

Kanadyjski urząd skarbowy zgłosił kradzież danych 900 podatników i poinformował, że dostęp do nich był możliwy dzięki wykorzystaniu błędu w okresie 6 godzin 8 kwietnia 2014 r. Pracownicy urzędu sami zdecydowali się wyłączyć wtedy usługi, pomimo przeciwnego zalecenia od rządowych ekspertów IT, co przerwało atak. Po odkryciu włamania agencja przedłużyła termin złożenia zeznań podatkowych, oraz anulowała kary za opóźnienia. 16 kwietnia kanadyjska policja ogłosiła, że oskarżyła dziewiętnastoletniego Kanadyjczyka o kradzież danych. CBC News podało też, że w Kanadzie stwierdzono inne ataki, ale ich szczegóły nie były znane[4][39][42][56][57].

Serwis handlu Bitcoinami, BTCJam, ogłosił że dzięki Heartbleed włamywacze dostali się na kilka kont użytkowników i ukradli im 28 BTC (o ówczesnej wartości ok. 25 tys. PLN); administracja strony zrekompensowała tę stratę z własnych funduszy[3].

Amerykański zarządca szpitali Community Health Services ogłosiła w sierpniu 2014 odkrycie, że w kwietniu doszło do opartego o Heartbleed ataku, w którym mogło dojść do kradzieży danych osobowych 4,5 miliona pacjentów. Odpowiedzialność za włamanie przypisywano APT1[58].

Na popularnej brytyjskiej witrynie dla rodziców Mumsnet przejęto 14 kwietnia kilka kont użytkowników, w tym konto administracyjne. Strona opublikowała później oświadczenie, że incydent był spowodowany przez Heartbleed i został rozwiązany szybko przez personel techniczny[4][23].

Jak opisało BBC, pojedynczy badacze wykorzystali Heartbleed aby uzyskać dostęp do tajnych forów używanych przez cyberprzestępców[59].

Następstwa

Jak zwracali uwagę komentatorzy, m.in. Dan Kaminsky, do Heartbleed przyczyniło się zjawisko ekonomiczne: efekt gapowicza. Darmowe OpenSSL, i inne powszechnie używane projekty rozwijane w modelu wolnego i otwartego oprogramowania, wymagały jego zdaniem poważniejszego wsparcia finansowego jako infrastruktura teleinformatyczna, i w coraz większym stopniu podstawa nowoczesnej gospodarki. Apelowano o inwestycje ze strony rządów, korporacji i fundacji, w celu zachęcenia do „żmudnych” prac przy rozwoju nieodpłatnych programów[1][41][60]. To zadanie podjęło Core Infrastructure Initiative – z udziałem takich firm jak m.in. IBM, Intel, Microsoft, Facebook, Google, Amazon, Cisco, Dell, Fujitsu, Qualcomm czy VMware, które zadeklarowały przeznaczenie po $100 tys. (łącznie $3,9 miliona) na finansowanie krytycznie ważnych projektów open source, z OpenSSL w pierwszej kolejności[4][61]. Jak powiedział w rozmowie z „Ars Technica” dyrektor inicjatywy, „mówiąc szczerze powinniśmy byli zrobić to trzy lata temu”[20]. Według przeglądu Waldena, w kolejnych latach zaobserwowano znaczny wzrost aktywności w projekcie, oraz poprawę standardów i jakości kodu; w tym, udało się wykryć i załatać wiele mniej poważnych błędów w starym kodzie[61].

W reakcji na Heartbleed krytykowano też poziom projektu OpenSSL i rozpoczęto rozwój kilku alternatywnych bibliotek; w kwietniu 2014 Theo de Raadt, twórca i główny prowadzącego OpenBSD i OpenSSH, napisał że „OpenSSL nie jest zarządzane przez odpowiedzialne osoby”. OpenBSD wyłoniło własny fork, LibreSSL; inny zespół zainicjował projekt BoringSSL[20][61][62]. Także Amazon Web Services opracowało i wprowadziło własną, wewnętrzną implementację TLS/SSL[33].

Apelowano również o powszechniejsze stosowanie audytów i testów kodu. Promowany był m.in. fuzz testing, dzięki któremu Codenomicon odkryło Heartbleed. Michał Zalewski, w tym czasie pracownik Google i autor popularnego fuzzera, zachęcał jednak do powściągliwości w stawaniu silnych tez o skuteczności jednego rozwiązania[6][63][64].

Przypisy

  1. ↑ a b c d e Dan Kaminsky, Be Still My Breaking Heart, Dan Kaminsky's Blog, 10 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  2. ↑ a b c d e f A digital heart attack, „The Economist”, 9 kwietnia 2014, ISSN 0013-0613 [dostęp 2021-10-29].
  3. ↑ a b c d e f g h i j k l m n o p q r s Zakir Durumeric i inni, The Matter of Heartbleed, [w:] Proceedings of the 2014 Conference on Internet Measurement Conference [online], Vancouver BC Canada: ACM, 5 listopada 2014, s. 475–488, DOI: 10.1145/2663716.2663755, ISBN 978-1-4503-3213-2 [dostęp 2021-10-31] (ang.).
  4. ↑ a b c d e f g h i j k l m n o p A heartbeat from disaster, „The Economist”, 6 maja 2014, ISSN 0013-0613 [dostęp 2021-10-29].
  5. ↑ a b c d e Lisa Eadicicco, How A Group Of Engineers Uncovered The Biggest Bug The Internet Has Seen In Years, Business Insider [dostęp 2021-10-29] (ang.).
  6. ↑ a b c d e f g Robert Vamosi, The Fuzzing Files: The Anatomy of a Heartbleed, forallsecure.com, 28 czerwca 2020 [dostęp 2021-10-29] (ang.).
  7. ↑ a b c d e f g h Heartbleed – krytyczna dziura w OpenSSL; ponad 65% serwerów w internecie podatnych na podsłuch …i to od 2 lat, NieBezpiecznik.pl, 8 kwietnia 2014 [dostęp 2021-10-29].
  8. ↑ a b c d Paul Mutton, Half a million widely trusted websites vulnerable to Heartbleed bug, Netcraft News, 8 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  9. ↑ a b c d e f g Timothy B. Lee, The Heartbleed Bug, explained, Vox, 19 czerwca 2014 [dostęp 2021-10-29] (ang.).
  10. ↑ a b c Liang Zhang i inni, Analysis of SSL certificate reissues and revocations in the wake of heartbleed, „Communications of the ACM”, 61 (3), 2018, s. 109–116, DOI: 10.1145/3176244, ISSN 0001-0782 [dostęp 2021-10-30] (ang.).
  11. ↑ Tom Simonite, Many Devices Will Never Be Patched to Fix Heartbleed Bug, MIT Technology Review, 9 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  12. ↑ a b Łukasz Siewierski, Heartbleed w Polsce (i w sieci TOR), cert.pl, 11 kwietnia 2014 [dostęp 2021-10-29] (pol.).
  13. ↑ a b Greg Kumparak, Massive Security Bug In OpenSSL Could Affect A Huge Chunk Of The Internet, TechCrunch, 8 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  14. ↑ Matthew Sullivan, Hijacking user sessions with the Heartbleed vulnerability, Matt's Life Bytes, 8 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  15. ↑ a b c d Alex Hern, Heartbleed: Hundreds of thousands of servers at risk from catastrophic bug, the Guardian, 9 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  16. ↑ a b c d Jeremy Bowers, The Security Bug That Affects Most Of The Internet, Explained, „NPR”, 8 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  17. ↑ a b Ben Grubb, Man who introduced serious 'Heartbleed' security flaw denies he inserted it deliberately, The Sydney Morning Herald, 10 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  18. ↑ a b c d e f Gail Sullivan, Heartbleed: What you should know, The Washington Post, 9 kwietnia 2014.
  19. ↑ a b Wszystko co powinieneś wiedzieś o Heartbleed. Czym jest ta niebezpieczna luka?, Dziennik, 17 kwietnia 2014 [dostęp 2021-10-29] (pol.).
  20. ↑ a b c d Jon Brodkin, Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL, Ars Technica, 24 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  21. ↑ a b c d e Lindsey Bever, Major bug called ‘Heartbleed’ exposes Internet data, The Washington Post, 9 kwietnia 2014.
  22. ↑ a b c d Ben Grubb, Revealed: How Google engineer Neel Mehta uncovered the Heartbleed security bug, The Sydney Morning Herald, 9 października 2014 [dostęp 2021-10-29] (ang.).
  23. ↑ a b c d Ben Grubb, Heartbleed disclosure timeline: who knew what and when, The Sydney Morning Herald, 15 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  24. ↑ OpenSSL Security Advisory, openssl-announce, 7 kwietnia 2014 [dostęp 2021-10-30].
  25. ↑ a b c Eric Markowitz, Behind the Scenes: The Crazy 72 Hours Leading Up to the Heartbleed Discovery, Vocativ, 10 kwietnia 2014 [dostęp 2017-12-03] (ang.).
  26. ↑ a b Ben Grubb, Google accused of being selfish and playing favourites over Heartbleed security bug disclosure, The Sydney Morning Herald, 17 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  27. ↑ Neel Mehta, Openssl 0day, may expose session data from servers / clients. Patch your stuff, Twitter, 2014 [dostęp 2021-10-30] (pol.).
  28. ↑ Nick Sullivan, Staying ahead of OpenSSL vulnerabilities, The Cloudflare Blog, 7 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  29. ↑ a b c Feeling the effects of Heartbleed: What it is and how to prevent vulnerabilities, Trend Micro, 23 czerwca 2014 [dostęp 2021-10-29] (ang.).
  30. ↑ Hal Hodson, Why a hacker got paid for finding the Heartbleed bug, New Scientist, 11 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  31. ↑ Susanna Kim, The Curious Origin of the 'Heartbleed' Logo, ABC News, 10 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  32. ↑ Patrick McKenzie, What Heartbleed Can Teach The OSS Community About Marketing, Kalzumeus Software, 9 kwietnia 2014 [dostęp 2021-10-29].
  33. ↑ a b c Colm MacCárthaigh, I think right around this minute is just about exactly 5 years since the Heartbleed vulnerability in OpenSSL became public. I remember the day vividly, and if you're interested, allow me to tell you about how the day, and the subsequent months, and years unfolded …, Twitter, 7 kwietnia 2019 [dostęp 2021-10-30] (pol.).
  34. ↑ Bruce Schneier, Heartbleed, Schneier on Security, 9 kwietnia 2014 [dostęp 2021-10-29].
  35. ↑ a b c d e f Yuri Ilyin, The Heartbleed Bug: averting a doomsday, Kaspersky Daily, 9 kwietnia 2014.
  36. ↑ a b Brian Krebs, ‘Heartbleed’ Bug Exposes Passwords, Web Site Encryption Keys – Krebs on Security, 8 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  37. ↑ a b c d e f Wojciech Wrzos, Heartbleed: Czy wszyscy jesteśmy zagrożeni, a OpenSSL nadaje się do kosza? Zapytaliśmy ekspertów, Komputer Świat, 11 kwietnia 2014 [dostęp 2021-10-29] (pol.).
  38. ↑ a b c Brian Donohue, “Heartbleed” Vulnerability may compromise your security on thousands of sites, Kaspersky, 10 kwietnia 2014.
  39. ↑ a b Pierwsze aresztowanie związane z Heartbleed. To 19-letni kanadyjski haker, TVN24 Biznes, 17 kwietnia 2014 [dostęp 2021-10-29] (pol.).
  40. ↑ a b c d e f Richard Nieva, How to protect yourself from the 'Heartbleed' bug, CNET, 8 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  41. ↑ a b Wendy M. Grossman, Heartbleed Software Snafu: The Good, the Bad and the Ugly, Scientific American, 16 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  42. ↑ a b c d e f g h i j k l redakcja, Heartbleed zebrał niezłe żniwo… Jak wygląda internet 2 dni po? Skąd już wyciekły hasła i ciasteczka?, NieBezpiecznik.pl, 10 kwietnia 2014 [dostęp 2021-10-29].
  43. ↑ igH, [Aktualizacja] Uwaga klienci mPay i Cardmobile. Serwisy te wciąż nie chronią przed Heartbleed — możliwy dostęp do danych kart, NieBezpiecznik.pl, 13 kwietnia 2014 [dostęp 2021-10-29].
  44. ↑ a b The Heartbleed Hit List: The Passwords You Need to Change Right Now, Mashable, 9 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  45. ↑ a b Brendan Sasso, Google Knew About Heartbleed and Didn't Tell the Government, The Atlantic, 14 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  46. ↑ redakcja, * Akamai jednak było podatne na Heartbleed, NieBezpiecznik.pl, 15 kwietnia 2014 [dostęp 2021-10-29].
  47. ↑ vi.curry, Heartbleed to wyciek pamięci nie tylko z serwerów WWW — z waszych komputerów również, NieBezpiecznik.pl, 10 kwietnia 2014 [dostęp 2021-10-29].
  48. ↑ Yuri Ilyin, The heart is bleeding out: a new critical bug found in OpenSSL, Kaspersky Daily, 8 kwietnia 2014.
  49. ↑ a b Piotr Konieczny, NSA korzystało z luki Heartbleed “od lat”. Czy aby na pewno? I czy to w istocie jest teraz nasz największy problem?, NieBezpiecznik.pl, 12 kwietnia 2014 [dostęp 2021-10-29].
  50. ↑ a b Bruce Schneier, More on Heartbleed, Schneier on Security, 11 kwietnia 2014 [dostęp 2021-10-29].
  51. ↑ Arik Hesseldahl, The First Good News About the Heartbleed Bug Emerges, Vox, 11 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  52. ↑ Russell Brandom, Heartbleed security flaw may not be as dangerous as thought, The Verge, 11 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  53. ↑ Nick Sullivan, Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed?, The Cloudflare Blog, 11 kwietnia 2014 [dostęp 2021-10-30] (ang.).
  54. ↑ Jordan Robertson, Hackers from China waste little time in exploiting Heartbleed, The Sydney Morning Herald, 16 kwietnia 2014 [dostęp 2021-10-31] (ang.).
  55. ↑ Groźna luka Heartbleed, rząd zaleca czujność wobec hakerów, www.money.pl, 11 kwietnia 2014 [dostęp 2021-10-29] (pol.).
  56. ↑ Dean Beeby, Heartbleed bug crisis hit more government computers than previously disclosed, CBC News, 9 grudnia 2015.
  57. ↑ Frequently asked questions: Heartbleed, Canada Revenue Agency, 13 kwietnia 2014 [dostęp 2021-10-29].
  58. ↑ vi.curry, * Wykradziono dane 4,5 miliona pacjentów. Wina Heartbleeda., NieBezpiecznik.pl, 19 sierpnia 2014 [dostęp 2021-10-29].
  59. ↑ Mark Ward, Heartbleed used to uncover data from cyber-criminals, „BBC News”, 29 kwietnia 2014 [dostęp 2021-10-31] (ang.).
  60. ↑ Timothy B. Lee, We massively underinvest in internet security, Vox, 12 kwietnia 2014 [dostęp 2021-10-29] (ang.).
  61. ↑ a b c James Walden, The Impact of a Major Security Event on an Open Source Project: The Case of OpenSSL, Proceedings of the 17th International Conference on Mining Software Repositories, New York, NY, USA: Association for Computing Machinery, 29 czerwca 2020, s. 409–419, DOI: 10.1145/3379597.3387465, ISBN 978-1-4503-7517-7 [dostęp 2021-10-30].
  62. ↑ Neil McAllister, OpenBSD founder wants to bin buggy OpenSSL library, launches fork, The Register, 22 kwietnia 2014 [dostęp 2021-10-31] (ang.).
  63. ↑ Michal Zalewski, Re: Hanno Boeck found Heartbleed using afl + ASan!, oss-security, 7 kwietnia 2015 [dostęp 2021-10-31].
  64. ↑ Hanno Böck, How Heartbleed could've been found, Hanno's blog, 7 kwietnia 2015 [dostęp 2021-10-31].

Bibliografia

Linki zewnętrzne

Media użyte na tej stronie

SSL Certificate Info Box In Firefox.png
Autor: BoobllaAu, Licencja: CC BY-SA 3.0
Website SSL identity info box in Firefox v27.0.1
Heartbleed exploit demonstration.png
Autor: Jaszczuroczłek, Licencja: CC BY-SA 4.0
The screenshot shows an exploit script triggering the Heartbleed vulnerability on a personal experimental virtual machine in the non-public IPv4 range, set up for this demonstration. Revealed data include a login, password, and authentication cookie, that were entered separately beforehand on a simple prepared website. The output has been slightly truncated, only to increase image compactness and readability. Created along the lines of this post: https://warroom.rsmus.com/building-a-vulnerable-box-heartbleed/, using Ubuntu 12.04.03, Nginx, and Sensepost's heartbleed-poc.py script.
Heartbleed.svg
Autor: Leena Snidate / Codenomicon, Licencja: CC0
The logo of the heartbleed bug