Niebo nie spada: ujawnione błędy OpenSSL są poważne, ale nie krytyczne

Eksperci ds. bezpieczeństwa opisali dwie bardzo oczekiwane luki, które zespół projektu OpenSSL załatał we wtorek, jako problemy wymagające szybkiego rozwiązania, ale niekoniecznie wymagające reakcji awaryjnej typu „porzuć wszystko inne”.

Wydanie wersji 3.0.7 niemal powszechnie używanej biblioteki kryptograficznej usuwa dwie luki w zabezpieczeniach związane z przepełnieniem bufora, które występują w wersjach OpenSSL od 3.0.0 do 3.0.6.

Przed ujawnieniem eksperci ds. bezpieczeństwa ostrzegali, że jednym z problemów pierwotnie scharakteryzowany jako „krytyczny” problem ze zdalnym wykonaniem kodu, może stanowić problem na poziomie Heartbleed, polegający na tym, że wszyscy są na pokładzie. Na szczęście wydaje się, że tak nie jest — i ujawniając tę ​​wadę, zespół projektu OpenSSL oświadczył, że zdecydował się obniż zagrożenie do „wysokiego” na podstawie opinii organizacji, które przetestowały i przeanalizowały błąd.

Para przepełnień bufora

Pierwszy błąd (CVE-2022-3602) rzeczywiście mogłoby – w określonych okolicznościach – umożliwić RCE, co początkowo wzbudziło obawy niektórych ekspertów ds. bezpieczeństwa, że ​​luka może mieć konsekwencje dla całej branży. Okazuje się jednak, że istnieją okoliczności łagodzące: po pierwsze, trudno jest je wykorzystać, jak wyjaśniono poniżej. Ponadto nie ma to wpływu na wszystkie systemy.

W szczególności, według Marka Ellzeya, starszego badacza ds. bezpieczeństwa w Censys, obecnie dotyczy to tylko przeglądarek obsługujących OpenSSL od 3.0.0 do 3.0.6, takich jak Firefox i Internet Explorer; w szczególności nie dotyczy to przeglądarki Google Chrome, która jest wiodącą przeglądarką internetową.

„Oczekuje się, że wpływ będzie minimalny ze względu na złożoność ataku i ograniczenia w sposobie jego przeprowadzenia” – mówi. „Organizacje powinny odświeżyć swoje szkolenie w zakresie phishingu i zwracać uwagę na źródła informacji o zagrożeniach, aby mieć pewność, że będą przygotowane na wypadek takiego ataku”.

Na początek Alex Ilgayev, główny badacz bezpieczeństwa w Cycode, zauważył, że luki nie można wykorzystać w niektórych dystrybucjach Linuksa; Ponadto wiele nowoczesnych platform systemów operacyjnych wdraża zabezpieczenia przed przepełnieniem stosu, aby w każdym razie zapobiec takim zagrożeniom, mówi Ilgayev.

Druga luka (CVE-2022-3786), który został odkryty podczas opracowywania poprawki pierwotnej wady, mógł zostać wykorzystany do wywołania warunków odmowy usługi (DoS). Zespół OpenSSL ocenił lukę jako bardzo poważną, ale wykluczył możliwość wykorzystania jej do wykorzystania RCE.

Obie luki są powiązane z funkcjonalnością o nazwie Kod Puny do kodowania międzynarodowych nazw domen.

„Użytkownicy OpenSSL 3.0.0 – 3.0.6 są zachęcamy do jak najszybszego uaktualnienia do wersji 3.0.7” – stwierdził zespół OpenSSL na blogu towarzyszącym ujawnieniu błędów i wydaniu nowej wersji biblioteki kryptograficznej. „Jeśli uzyskasz kopię OpenSSL od dostawcy systemu operacyjnego lub innej strony trzeciej, powinieneś jak najszybciej uzyskać od nich zaktualizowaną wersję”.

To nie jest kolejny Heartbleed

Ujawnienie błędu z pewnością złagodzi — przynajmniej na razie — wywołał powszechny niepokój przez powiadomienie zespołu OpenSSL w zeszłym tygodniu o zbliżającym się ujawnieniu błędu. W szczególności opis pierwszej wady jako „krytycznej” skłonił do kilku porównań z błędem „Heartbleed” z 2014 r. — jedynym innym błędem w OpenSSL, który uzyskał ocenę krytyczną. Ten błąd (CVE-2014-0160) dotyczył dużej części Internetu i nawet obecnie w wielu organizacjach nie został w pełni rozwiązany.

„Heartbleed był domyślnie ujawniany w każdym oprogramowaniu korzystającym z podatnej na ataki wersji OpenSSL i atakujący mogli go bardzo łatwo wykorzystać, aby uzyskać dostęp do kluczy kryptograficznych i haseł przechowywanych w pamięci serwera” – mówi Jonathan Knudsen, szef globalnego działu badań w Synopsys Cybersecurity Research Center . „Dwie luki w zabezpieczeniach OpenSSL właśnie zgłoszone są poważne, ale nie tej samej wielkości.”

Błędy OpenSSL są trudne do wykorzystania…

Aby wykorzystać którąkolwiek z nowych luk, podatne serwery musiałyby zażądać uwierzytelnienia za pomocą certyfikatu klienta, co nie jest normą, twierdzi Knudsen. Podatni na zagrożenia klienci musieliby połączyć się ze złośliwym serwerem, co jest powszechnym i dającym się obronić wektorem ataku – mówi.

„W związku z tymi dwiema lukami nikt nie powinien się denerwować, są one jednak poważne i należy się z nimi uporać z odpowiednią szybkością i starannością” – zauważa.

Tymczasem w poście na blogu SANS Internet Storm Center opisał aktualizację OpenSSL jako naprawienie przepełnienia bufora podczas procesu weryfikacji certyfikatu. Aby exploit zadziałał, certyfikat musiałby zawierać złośliwą nazwę zakodowaną w formacie Punycode, a luka zostałaby wyzwolona dopiero po zweryfikowaniu łańcucha certyfikatów.

„Atakujący musi najpierw mieć możliwość podpisania złośliwego certyfikatu przez urząd certyfikacji, któremu ufa klient” – zauważyła SANS ISC. „Wygląda na to, że nie można tego wykorzystać w przypadku serwerów. W przypadku serwerów może to być przydatne, jeśli serwer zażąda od klienta certyfikatu.

Konkluzja: prawdopodobieństwo wykorzystania jest niskie, ponieważ wykorzystanie luki jest trudne, podobnie jak przepływ i wymagania potrzebne do jej uruchomienia, mówi Ilgayev z Cycode. Ponadto wpływa na stosunkowo niewielką liczbę systemów w porównaniu z systemami korzystającymi z wersji OpenSSL wcześniejszych niż 3.0.

…Ale bądź pilny

Jednocześnie należy pamiętać, że w przeszłości wykorzystywano luki trudne do wykorzystania – mówi Iłgajew, wskazując na exploit zero-click opracowany przez NSO Group pod kątem luki w systemie iOS ostatni rok.

„[Ponadto], jak twierdzi zespół OpenSSL, „nie ma sposobu, aby dowiedzieć się, w jaki sposób każda kombinacja platformy i kompilatora ułożyła bufory na stosie”, dlatego na niektórych platformach nadal może być możliwe zdalne wykonanie kodu” – ostrzega.

I rzeczywiście, Ellzey przedstawia jeden ze scenariuszy wykorzystania przez atakujących luki CVE-2022-3602, którą zespół OpenSSL pierwotnie ocenił jako krytyczną.

„Napastnik hostowałby złośliwy serwer i próbował nakłonić ofiary do uwierzytelnienia się na nim za pomocą aplikacji podatnej na OpenSSL v3.x, potencjalnie z wykorzystaniem tradycyjnych taktyk phishingu” – mówi, chociaż zakres jest ograniczony ze względu na to, że exploit wykorzystuje głównie ataki klienckie. strona.

Luki takie jak ta podkreślają znaczenie posiadania zestawienie komponentów oprogramowania (SBOM) dla każdego użytego pliku binarnego, zauważa Iłgajew. „Patrzenie na menedżery pakietów nie wystarczy, ponieważ tę bibliotekę można łączyć i kompilować w różnych konfiguracjach, które będą miały wpływ na użyteczność” – mówi.