Przygotuj się teraz na krytyczną lukę w OpenSSL, ostrzegają eksperci ds. bezpieczeństwa

Organizacje mają pięć dni na przygotowanie się na to, co projekt OpenSSL określił 26 października jako „krytyczną” lukę w zabezpieczeniach w wersjach 3.0 i nowszych niemal powszechnie używanej biblioteki kryptograficznej do szyfrowania komunikacji w Internecie.

We wtorek, 1 listopada, projekt udostępni nową wersję OpenSSL (wersja 3.0.7), która załata nieujawnioną jeszcze lukę w obecnych wersjach tej technologii. Charakterystyka luki i łatwość, z jaką można ją wykorzystać, określi szybkość, z jaką organizacje będą musiały zaradzić problemowi.

Potencjalnie ogromne implikacje

Główni dostawcy systemów operacyjnych, wydawcy oprogramowania, dostawcy poczty e-mail i firmy technologiczne, które zintegrowały OpenSSL ze swoimi produktami i usługami, prawdopodobnie udostępnią zaktualizowane wersje swoich technologii wraz z ujawnieniem luki przez projekt OpenSSL w przyszły wtorek. Jednak to wciąż pozostawia potencjalnie miliony innych osób – w tym agencje federalne, firmy prywatne, usługodawców, producentów urządzeń sieciowych i niezliczoną liczbę operatorów witryn internetowych – przed zbliżającym się terminem znalezienia i naprawienia luki, zanim ugrupowania zagrażające zaczną ją wykorzystywać.

Jeśli nowa luka okaże się kolejnym błędem Heartbleed — ostatnią krytyczną luką wpływającą na OpenSSL — organizacje, a nawet cała branża, będą miały okazję do jak najszybszego rozwiązania problemu.

Ujawniona w 2014 roku luka Heartbleed (CVE-0160-2014) w zasadzie umożliwiła atakującym podsłuchiwać komunikację internetową, kraść dane
od usług i użytkowników, do podszywania się pod usługi, a wszystko to bez śladu, że kiedykolwiek to zrobili. Błąd występował w wersjach OpenSSL od marca 2012 roku i wpływał na oszałamiającą gamę technologii, w tym na powszechnie używane serwery internetowe, takie jak Nginx, Apache i IIS; organizacje takie jak Google, Akamai, CloudFlare i Facebook; serwery poczty elektronicznej i czatów; urządzenia sieciowe takich firm jak Cisco; i VPN.

Ujawnienie błędu wywołało szaleństwo działań naprawczych w całej branży i wzbudziło obawy dotyczące poważnych kompromisów. Jak zauważyła witryna Heartbleed.com firmy Synopsys, w chwili ujawnienia Heartbleed same Apache i Nginx miały udział w rynku wynoszący ponad 66% aktywnych witryn w Internecie.

Nie wiadomo, przynajmniej do wtorku, czy nowa usterka będzie choć trochę podobna do Heartbleed. Biorąc jednak pod uwagę wykorzystanie OpenSSL do szyfrowania w Internecie niemal jak w infrastrukturze krytycznej, organizacje dobrze zrobią, jeśli nie lekceważą zagrożenia, stwierdzili w tym tygodniu eksperci ds. bezpieczeństwa.

Organy bezpieczeństwa powinny przygotować się na uderzenie

„Trudno spekulować na temat wpływu, ale dotychczasowe doświadczenia pokazały, że OpenSSL nie lekceważy określenia „krytyczny”” – mówi Johannes Ullrich, dziekan ds. badań w Instytucie SANS.

Sam OpenSSL definiuje krytyczną wadę jako taką, która umożliwia istotne ujawnienie zawartości pamięci serwera i potencjalne dane użytkownika, luki, które można łatwo i zdalnie wykorzystać w celu naruszenia bezpieczeństwa kluczy prywatnych serwera.

Wersja 3.0, aktualna wersja OpenSSL, jest używana w wielu obecnych systemach operacyjnych, takich jak Ubuntu 22.04 LTS oraz MacOS Mavericks i Ventura, zauważa Ullrich. Organizacje mogą spodziewać się szybkiego i prawdopodobnego otrzymania poprawek dla systemu Linux w tym samym czasie, co wtorkowy biuletyn OpenSSL. Jednak organizacje powinny przygotować się już teraz i dowiedzieć się, które systemy korzystają z OpenSSL 3.0, mówi Ullrich. „Po Heartbleed OpenSSL wprowadziło wstępne zapowiedzi poprawek bezpieczeństwa” – mówi. „Mają pomóc organizacjom się przygotować. Wykorzystaj więc ten czas, aby dowiedzieć się, co będzie wymagało łatania”.

Brian Fox, współzałożyciel i dyrektor ds. technicznych w Sonatype, mówi, że zanim we wtorek projekt OpenSSL ujawni błąd, organizacje muszą określić, czy w swoim portfolio technologii korzystają z wersji podatnej na ataki, jakie aplikacje z niej korzystają i jak długo zajęłoby im naprawienie problemu. 

„Potencjalny zasięg jest zawsze najważniejszym elementem każdej poważnej wady” – zauważa Fox. „W tym przypadku największym wyzwaniem związanym z aktualizacją OpenSSL jest to, że często to użycie jest wbudowane w inne urządzenia”. W takich przypadkach ocena narażenia bez konsultacji z dostawcą technologii na wyższym szczeblu łańcucha dostaw może być trudna – dodaje.

Wszystko, co bezpiecznie komunikuje się z Internetem, może potencjalnie mieć wbudowany OpenSSL. Problem może dotyczyć nie tylko oprogramowania, ale także sprzętu. Powiadomienie z wyprzedzeniem dostarczone przez projekt OpenSSL powinno dać organizacjom czas na przygotowanie. „Pierwszym krokiem jest znalezienie oprogramowania lub urządzeń. Organizacje powinny to zrobić teraz, a następnie nastąpi wprowadzanie poprawek lub pozyskiwanie aktualizacji od dostawców wyższego szczebla” – mówi Fox. „W tej chwili jedyne, co możesz zrobić, to inwentaryzacja”.

Cały ekosystem może wymagać aktualizacji

Wiele będzie zależeć także od tego, jak dostawcy produktów z wbudowanymi wersjami OpenSSL zawierającymi luki w zabezpieczeniach zareagują na ujawnienie informacji. Publikacja nowej wersji projektu OpenSSL we wtorek to dopiero pierwszy krok. „Cały ekosystem aplikacji zbudowanych przy użyciu OpenSSL będzie musiał także zaktualizować swój kod, wydać własne aktualizacje, a organizacje będą musiały je zastosować” – mówi John Bambenek, główny łowca zagrożeń w Netenrich.

Idealnie byłoby, gdyby organizacje, które miały do ​​czynienia z Heartbleed, miały pojęcie, gdzie znajdują się ich instalacje OpenSSL i które produkty ich dostawców również będą wymagały aktualizacji. „Dlatego zestawienia materiałów oprogramowania mogą być ważne” – mówi Bambenek. „Mogą poświęcić ten czas na skontaktowanie się ze swoimi dostawcami i ich planami dotyczącymi aktualizacji i zrozumienie ich, aby mieć pewność, że te aktualizacje również zostaną zastosowane”. Dodaje, że jednym z prawdopodobnych problemów, na który organizacje muszą się przygotować, jest sposób postępowania z produktami wycofanymi z eksploatacji, dla których nie są dostępne aktualizacje.

Mike Parkin, starszy inżynier techniczny w Vulcan Cyber, twierdzi, że bez dowodów aktywności exploitów i powiązanych wskaźników naruszenia bezpieczeństwa najlepiej jest, aby organizacje postępowały zgodnie ze swoim normalnym procesem zarządzania zmianami na wypadek nadchodzącej znanej aktualizacji. „Jeśli chodzi o bezpieczeństwo, warto położyć większy nacisk na systemy, na które może mieć wpływ pojawienie się exploita przed publikacją nowej wersji” – radzi.

W ogłoszeniu OpenSSL Project nie ma wystarczających informacji, aby określić, ile pracy będzie wymagało uaktualnienie, „ale jeśli aktualizacja nie będzie wymagała aktualizacji certyfikatów, aktualizacja będzie prawdopodobnie prosta” – przewiduje Parkin.

Również 1 listopada projekt OpenSSL wyda wersję OpenSSL 1.1.1s, którą określił jako „wersję poprawiającą błędy”. Jak zauważyli uczestnicy projektu, wersja 1.1.1, którą zastępuje, nie jest podatna na CVE, które jest naprawiane w wersji 3.0.