Heartbleed 2014: błąd, który obnażył kruchość internetu

Sylwester 2011: commit, który nikogo nie zaniepokoił

31 grudnia 2011 roku, na kilka godzin przed północą, do repozytorium OpenSSL trafiła poprawka implementująca rozszerzenie TLS Heartbeat (opisane później w RFC 6520). Jej autorem był Robin Seggelmann, niemiecki doktorant, który współtworzył samą specyfikację. Zmianę przejrzał jeden z głównych opiekunów projektu, Stephen Henson. Nikt nie zauważył problemu.

Idea mechanizmu Heartbeat była prosta i rozsądna: klient wysyła do serwera krótką wiadomość w rodzaju jesteś tam? odeślij mi to słowo, ma 4 litery, a serwer odpowiada tym samym, potwierdzając, że połączenie wciąż żyje. Pozwalało to utrzymywać sesje szyfrowane bez kosztownego ponownego negocjowania kluczy.

W marcu 2012 roku kod trafił do wydania OpenSSL 1.0.1 i rozpoczął wędrówkę po serwerach całego świata – do Apache, nginx, routerów, urządzeń VPN, systemów pocztowych i niezliczonych dystrybucji Linuksa.

Jak działał Heartbleed – wyjaśnienie bez kodu

Błąd polegał na tym, że serwer wierzył klientowi na słowo w kwestii długości wiadomości. Wystarczyło wysłać zapytanie: odeślij mi słowo KOT, ma ono 64 000 liter. Serwer nie sprawdzał, czy otrzymał faktycznie tyle danych – kopiował po prostu 3 litery słowa KOT, a następnie kolejne tysiące bajtów, które akurat leżały w pamięci obok.

Co mogło się tam znaleźć? Praktycznie wszystko, co serwer przetwarzał w ostatnim czasie:

• loginy i hasła innych zalogowanych użytkowników,
• ciasteczka sesyjne pozwalające przejąć cudze konto,
• treść e-maili i formularzy,
• w najgorszym przypadku – prywatny klucz certyfikatu SSL, czyli fundament całego szyfrowania.

Każde zapytanie zwracało do 64 KB pamięci, a atak można było powtarzać w nieskończoność. Co gorsza, typowe logi serwera w ogóle nie rejestrowały takich żądań, więc administratorzy nie mieli jak sprawdzić, czy ktoś ich już okradł. Cała poprawka sprowadzała się do kilku linijek sprawdzających długość – klasyczny przykład tego, jak drobny błąd w niskopoziomowym kodzie C może mieć globalne skutki.

Kwiecień 2014: pierwsza luka z logo i własną stroną

Błąd odkryli niezależnie od siebie dwa zespoły: Neel Mehta z Google Security oraz inżynierowie fińskiej firmy Codenomicon. 7 kwietnia 2014 roku opublikowano poprawkę (OpenSSL 1.0.1g) i oficjalny identyfikator CVE-2014-0160.

To jednak Codenomicon zrobił coś, czego wcześniej w świecie bezpieczeństwa nie praktykowano: nadał luce chwytliwą nazwę Heartbleed, zaprojektował logo z krwawiącym sercem i uruchomił stronę heartbleed.com z przystępnym wyjaśnieniem. Efekt? O błędzie w bibliotece kryptograficznej mówiły serwisy informacyjne na całym świecie, a nawet popularny komiks xkcd poświęcił mu odcinek tłumaczący mechanizm ataku.

Od tamtej pory markowe podatności stały się normą – Shellshock, POODLE, Spectre, Meltdown czy Log4Shell miały już swoje nazwy i grafiki. Heartbleed zapoczątkował tę modę.

Skala katastrofy w liczbach

Według szacunków firmy Netcraft podatnych było około 17% bezpiecznych serwerów WWW na świecie, czyli mniej więcej pół miliona witryn. Wśród nich znalazły się serwisy takie jak Yahoo, Imgur czy Stack Overflow. Konsekwencje nie ograniczały się do teorii:

• Kanadyjska agencja podatkowa straciła numery ubezpieczenia społecznego około 900 obywateli – za atak aresztowano 19-letniego studenta.
• Amerykańska sieć szpitali Community Health Systems poinformowała o wycieku danych 4,5 miliona pacjentów; jako wektor wskazywano podatne urządzenie VPN.
• Miliony użytkowników na całym świecie musiały zmienić hasła, a administratorzy – unieważnić i wydać na nowo certyfikaty SSL.

Ta ostatnia operacja okazała się bolesna. Wiele firm nie miało pojęcia, ile certyfikatów posiada i gdzie są zainstalowane. Lekcja wciąż aktualna – o tym, jak zapanować nad tym procesem, piszemy w artykule Certyfikaty SSL w firmie – jak nie przegapić wygaśnięcia.

2000 dolarów rocznie na fundament internetu

Najbardziej szokujący fakt wyszedł na jaw po fakcie. Biblioteka, na której opierało się szyfrowanie dużej części internetu, była utrzymywana przez garstkę wolontariuszy. OpenSSL Software Foundation otrzymywała w darowiznach około 2000 dolarów rocznie, a na pełen etat pracował przy projekcie właściwie jeden człowiek. Korporacje warte miliardy korzystały z kodu za darmo, nie dokładając się do jego audytu.

Heartbleed wywołał lawinę zmian:

1. Linux Foundation powołała Core Infrastructure Initiative, do której dołączyły m.in. Google, Microsoft, Amazon i Facebook, finansując krytyczne projekty open source.
2. Zespół OpenBSD stworzył fork LibreSSL, usuwając w pierwszych tygodniach dziesiątki tysięcy linii przestarzałego kodu.
3. Google rozpoczął prace nad własnym forkiem BoringSSL.
4. Sam OpenSSL dostał stałe finansowanie, regularne audyty i bardziej rygorystyczny proces przeglądu kodu.

Dziś ta lekcja powraca przy każdej dużej podatności w bibliotekach open source – od Log4Shell po incydent z XZ Utils w 2024 roku.

Czego Heartbleed uczy małe i średnie firmy

Choć minęło ponad dziesięć lat, Heartbleed wciąż bywa wykrywany podczas skanów – na zapomnianych routerach, starych urządzeniach NAS czy serwerach, których nikt nie aktualizował od lat. Dla MŚP płyną z tej historii bardzo praktyczne wnioski:

• Inwentaryzacja to podstawa – nie załatasz serwera, o którego istnieniu nie wiesz.
• Szybkie aktualizacje mają znaczenie – firmy, które wdrożyły poprawkę w ciągu doby, ograniczyły ryzyko do minimum. Jak to zorganizować, opisujemy w poradniku Aktualizacje systemów w firmie – jak nimi zarządzać.
• Po załataniu trzeba posprzątać – zmiana haseł i wymiana certyfikatów była równie ważna jak sama aktualizacja.
• Wybór infrastruktury to decyzja o bezpieczeństwie – profesjonalny hosting z aktywnym zarządzaniem poprawkami sprawia, że krytyczne łatki trafiają na serwer w ciągu godzin, a nie miesięcy.

Heartbleed pokazał, że bezpieczeństwo internetu bywa tak mocne, jak najsłabsza linijka kodu w bibliotece, o której większość z nas nigdy nie słyszała.