Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Heartbleed – krytyczny błąd w OpenSSL
Wykryto krytyczny błąd w OpenSSL – jednej z najpopularniejszych bibliotek wykorzystywanych przy zestawianiu połączeń SSL/TLS. To kolejna podatność w infrastruktyrze SSL po choćby odkrytym w zeszłym roku Lucky Thirteen, niedawnym Applowym goto fail czy podobnych problemach w GnuTLS. Wracając do samego OpenSSL – sami autorzy biblioteki opisują problem dość lakonicznie:
A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
W zależności od sytuacji wspomniane 64k pamięci na serwerze (lub kliencie!) może zawierać wszystko – od haseł administratorów w plaintext – przez identyfikatory sesji / hasła użytkowników – aż po klucze prywatne naszych certyfikatów SSL. Wygląda groźnie? To popatrzmy na kolejne fakty związane z podatnością heartbleed:
- wykorzystanie podatności nie wymaga uwierzytelnienia (wystarczy zwykłe, anonimowe połączenie SSL)
- wykorzystanie podatności jest trudne do wykrycia po stronie serwerowej i klienckiej (nie wymagane jest wysłanie żadnego requestu HTTP – choć oczywiście warto pamiętać że SSL nie musi być stosowany jedynie do ochrony HTTP – inne przykłady to choćby poczta elektroniczna, FTP, SSL-VPN);
pewne próby wykrycia ataku mogą być jednak wykonane (trzeba mieć jednak w tym celu odpowiednio przygotowany system IDS, który można oczywiście uruchomić na archiwalnym ruchu – jeśli taki zapisujemy):
Due to encryption differentiating between legitimate use and attack can not be based on the content of the request, but the attack may be detected by comparing the size of the request against the size of the reply.
- w zależności od sytuacji możliwe jest odczytanie również wcześniej przechwyconej, zaszyfrowanej komunikacji SSL. Tutaj mogą pomóc mechanizmy klasy Forward Secrecy które stworzone są właśnie na tego typu okazje:
forward secrecy (also known as perfect forward secrecy or PFS) is a property of key-agreement protocols that ensures that a session key derived from a set of long-term keys will not be compromised if one of the long-term keys is compromised in the future.
- sam OpenSSL wspiera PFS od wersji 1.0 – jednak inną kwestią jest ile osób korzysta z tego mechanizmu. Za cytowaną powyżej Wikipedią:
As of April 2014, 6.3% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to web browsers
- 64kilobajty wycieku pamięci z serwera to niewiele… Owszem, ale atakujący może ponowić atak dowolną liczbę razy uzyskując różne fragmenty pamięci – potencjalnie może to realizować aż do momentu uzyskania dostępu do interesujących danych
- dostępne w sieci są już bardzo proste exploity czy moduły do skanerów podatności takich jak OpenVAS (do użycia oczywiście tylko na swoje serwery). Działają też serwisy umożliwiające sprawdzenie czy nasza usługa – np. webserwer – jest podatna
- szczęśliwie problem prawdopodobnie można w miarę prosto zablokować w systemach typu IPS czy application firewall – mimo że komunikacja jest oczywiście szyfrowana, to możliwe jest zablokowanie wszystkich rekordów SSL z typem hearbeat (bez wnikania w ich zawartość – do niej i tak nie mamy dostępu)
- podatne są wszystkie wersje z serii 1.0.1 oraz 1.0.2-beta, a problem łata wersja 1.0.1g (alternatywnie można przekompilować OpenSSL z opcją -DOPENSSL_NO_HEARTBEATS).
Pełna techniczna analiza błędu dostępna jest tutaj.
–michal.sajdak<at>securitum.pl
Świetne wyjaśnienie tego błędu w formie komiksu:
http://xkcd.com/1354/