Krytyczny bug w kryptografii Javy. Eksperci wzywają do aktualizacji!
Eksperci ds. cyberbezpieczeństwa w całym Internecie ostrzegają i wzywają do aktualizacji przed podatnością CVE-2022-21449. Jest to luka w zabezpieczeniach dotycząca aplikacji korzystających z sygnatur algorytmu podpisu cyfrowego krzywej eliptycznej (ang. ECDSA) w Java 15, Java 16, Java 17 i Java 18. Bug otrzymał ocenę 7,5 na 10 w skali CVSS, a eksperci zastanawiają się dlaczego tak mało.
Nowa podatność pochodzi z niewłaściwej implementacji algorytmu weryfikacji podpisów ECDSA i zasadniczo umożliwia atakującemu potencjalne przechwycenie komunikacji i wiadomości, które w innym przypadku powinny zostać zaszyfrowane. Chodzi tu o taką komunikacje jak komunikacja SSL, procesy uwierzytelniania i inne.
Oracle opublikował tydzień temu łatę dla luki po tym, jak firma ForgeRock poinformowała zespół OpenJDK o problemie.
Błąd jest poważny, ponieważ umożliwia atakującemu łatwe sfałszowanie niektórych typów certyfikatów SSL, „uścisków dłoni”, podpisanych JWT, asercji SAML lub tokenów OIDC id oraz nawet, wiadomości uwierzytelniających WebAuth. Standard ECDSA jest szeroko stosowanym mechanizmem podpisywania wszelkiego rodzaju dokumentów cyfrowych, a luka w zabezpieczeniach umożliwia atakującym użycie cyfrowego odpowiednika pustego dowodu osobistego. Mówi się, że jest to eksploit „białej kartki papieru”.
Podobno błąd został wykryty przez Neil’a Madden’a, blogera i eksperta kryptograficznego, już w listopadzie ubiegłego roku, ale Oracle przyznało się do tego dopiero niedawno.
Warto zastanowić się w ogóle, dlaczego podatność wychodzi na jaw teraz, kiedy Java od dawna obsługuje ECDSA. Czy zawsze ten mechanizm był wrażliwy?
Oczywiście nie. Jest to stosunkowo nowy błąd wprowadzony przez przepisanie kodu EC z natywnego kodu C++ na Javę, co miało miejsce w wydaniu Java 15. Chociaż reimplementacja ma zalety pod względem bezpieczeństwa pamięci i łatwości utrzymania, wydaje się, że doświadczeni inżynierowie kryptografowie nie byli zaangażowani ten proces. Oryginalna implementacja C++ nie jest podatna na te błędy, ale Java już tak. Wydaje się, że żadna z implementacji nie zapewnia bardzo dobrego pokrycia testami, a nawet najbardziej pobieżny odczyt specyfikacji ECDSA z pewnością sugerowałby testowanie podstawowych założeń.
Jeśli chodzi o techniczny aspekt podatności, to oczywiście na poziomie szczegółowym jest bardzo złożony, ale na poziomie ogólnym już bardzo prosty. Błąd implementacji polega na tym, że dwie zmienne „r” oraz „s” nie są weryfikowane w funkcji pod kątem wartości zero, która później powoduje, że podpis cyfrowy też ma wartość zero…, czyli po prostu jest pusty.
Brian Moussalli z JFrog Security Research nazwał lukę “Java Psychic Signatures” oraz oświadczył, że powoduje unieważnienie integralności każdej treści, która jest gwarantowana przez podpisy elektroniczne. Może to mieć poważne konsekwencje dla kilku transakcji finansowych we wszystkich branżach przy użyciu handshakes SSL, podpisów elektronicznych, SOA itp. Powiedział też, że brak bezpiecznego uzgadniania między systemami umożliwia atakującemu dostęp do treści, które powinny być chronione, co może mieć krytyczne konsekwencje zarówno dla konsumentów, jak i przedsiębiorstw.
Mike Parkin z Vulcan Cyber nazwał CVE-2022-21449 luką „załataj teraz” i powiedział, że jest to przykład dobrego systemu kryptograficznego, który stał się bezużyteczny z powodu błędu implementacji.
Co powinniśmy zrobić?
Przede wszystkim, jeśli używasz Java 15 lub nowszej, zaktualizuj ją do najnowszej wersji, aby uzyskać poprawkę.
Ogólnie rzecz biorąc, kod kryptograficzny jest bardzo trudny do poprawnej implementacji, a algorytmy podpisu klucza publicznego są jednymi z najtrudniejszych. ECDSA jest samo w sobie jednym z najbardziej delikatnych algorytmów, w którym nawet niewielka ilość błędu w jednej losowej wartości może umożliwić całkowite odzyskanie klucza prywatnego.
Jeśli jesteś programistą i projektujesz protokół lub aplikację, które Twoim zdaniem muszą korzystać z podpisów cyfrowych, zastanów się, czy naprawdę musisz to zrobić – czy zamiast tego zadziałałby prostszy mechanizm? Proste algorytmy MAC, takie jak HMAC, są niezwykle trudne do zepsucia w porównaniu ze schematami podpisów.
Popularne
YellowKey: koniec mitu o bezpieczeństwie BitLockera? Nowy zero-day pozwala ominąć szyfrowanie przy użyciu zwykłego pendrive’a
Jak zmienić nieznane/zapomniane hasło Administratora na Windows?
Kolejny poważny zero-day. Nowe luki omijają BitLockera i pozwalają przejąć uprawnienia SYSTEM
PowerShell bez powershell.exe. Dlaczego klasyczne detekcje coraz częściej zawodzą
Jeszcze o Mythos!
