Badacze z Binarly REsearch przyjrzeli się, w jaki sposób ostatnie aktualizacje zabezpieczeń OpenSSL odbijają się na ekosystemie łańcucha dostaw systemu układowego UEFI oraz jak zróżnicowane jest powszechne użycie wersji OpenSSL w kontekście systemu układowego. Możemy stwierdzić, iż wnioski nie są optymistyczne.
O które luki w OpenSSL chodzi?
Na początku tego miesiąca CISA opublikowała poradnik dotyczący ostatnich poważnych problemów bezpieczeństwa OpenSSL (CVE-2022-3602 i CVE-2022-3786). Pisaliśmy o tym także na Kapitanie.
Luki w zabezpieczeniach CVE-2022-3602 i CVE-2022-3786 związane są z niepowodzeniem weryfikacji certyfikatu x.509, co może prowadzić do przepełnienia bufora stosu.
W rzeczywistości nie dotyczy to starszych wersji, takich jak OpenSSL 1.0.2 i 1.1.1. Wcześniejsze wersje również pozostają nienaruszone, ponieważ zagrożony kod został wprowadzony po raz pierwszy w OpenSSL 3.0.0.
DELL, HP i Lenovo na celowniku
Analitycy cyberbezpieczeństwa z Binarly odkryli niedawno, iż ciągle używane są przestarzałe wersje biblioteki kryptograficznej OpenSSL w oprogramowaniach urządzeń produkowanych przez Dell, HP i Lenovo. Zawierają one wersje, które stanowią zagrożenie dla łańcucha dostaw ze względu na ich nieaktualność. Może to ułatwiać cyberprzestępcom przejęcie kontroli nad komputerem.
W czym tkwi problem?
Od niedawna branża technologiczna dyskutuje na temat wykorzystania tzw. listy software bill of materials (w skrócie SBOM) w celu przeciwdziałania zagrożeniom bezpieczeństwa łańcucha dostaw. Aby wdrożyć praktyki bezpieczeństwa, musi istnieć większa przejrzystość zależności oprogramowania. Wcześniej każde oprogramowanie było dostarczane jako czarna skrzynka bez jakichkolwiek informacji związanych z jego zależnościami czy komponentami stron trzecich. Oprogramowanie układowe było w dużej mierze postrzegane w ten sam sposób.
Implementacją systemu układowego (UEFI) typu open source jest zestaw EFI Development Kit, znany również jako EDK, który także jest EFI. W tym sensie system operacyjny działa jako interfejs między oprogramowaniem wbudowanym w sprzęt urządzenia a systemem operacyjnym.
„W środowisku programistycznym systemu układowego wbudowany jest pakiet kryptograficzny o nazwie CryptoPkg, który w rezultacie wykorzystuje usługi z projektu OpenSSL do świadczenia usług kryptograficznych w oprogramowaniu układowym” – dowiadujemy się od badaczy Binarly.
Podczas analizy stwierdzono, iż kilka wersji OpenSSL jest częścią obrazów systemu układowego powiązanych z urządzeniami korporacyjnymi Lenovo Thinkpad.
Poniżej podajemy wszystkie trzy wersje OpenSSL:
- 0.9.8zb
- 1.0.0a
- 1.0.2j
W oprogramowaniu układowym znajduje się jeden moduł oparty na OpenSSL w wersji 0.9.8zb, która została wydana 4 sierpnia 2014 r., a znana jest jako InfineonTpmUpdateDxe. Warstwa SSL (Secure Socket Layer) i Transport Layer Security (TLS) to protokoły typu open source, które są implementowane przez OpenSSL.
„Repozytorium Github EDKII jest regularnie aktualizowane, a społeczność programistów rozwiązuje problemy związane z bezpieczeństwem. Przeanalizowano wiele obrazów systemu układowego używanych przez wyżej wymienionych producentów, aby ustalić, czy problem występuje w ich urządzeniach” – piszą badacze z Binarly.
Często oprogramowanie układowe można postrzegać jako pojedynczy punkt awarii we wszystkich warstwach łańcucha dostaw, a także urządzenia użytkownika końcowego, na końcu łańcucha.
Ostatnio w „Digital Defense Report 2022” Microsoft zwrócił uwagę na następujący najważniejszy punkt:
„W 32% zbadanych obrazów systemu sprzętowego zidentyfikowano co najmniej 10 krytycznych luk w zabezpieczeniach”.
Źródło: MicrosoftSzacuje się, iż co najmniej dwie lub trzy luki w oprogramowaniu układowym występują w około 20% aktualizacji.
Latem 2021 roku korporacyjne urządzenia Lenovo korzystały z najnowszej dostępnej wówczas w Internecie wersji protokołu OpenSSL.
Źródło: BinarlyWnioski z badania
Wiele pakietów systemu sprzętowego Lenovo i Dell przez cały czas korzysta ze starszej wersji (0.9.8l), która została wydana 5 listopada 2009 r. i ma już ponad dekadę.
Podobnie kod systemu układowego HP zależny był od 10-letniej wersji biblioteki (0.9.8w) i ta sama wciąż była używana przez wielu innych producentów.
Podsumowanie
Dziedzina analizy kodu binarnego jest jedną z najbardziej złożonych i nie ma łatwego rozwiązania. Aby sposoby na zapewnienie bezpieczeństwa łańcucha dostaw oparte na SBOM odniosły sukces w dzisiejszym świecie, branża musi zacząć myśleć o nich inaczej.
Jeśli chodzi o kod strony trzeciej, który jest zawarty w kodzie aplikacji, lista zależności ciągle zawodzi. W przypadku niepowodzeń SBOM podejście „ufaj, ale weryfikuj” jest najlepszym sposobem na zmniejszenie ryzyka w łańcuchu dostaw i prawdopodobieństwa niepowodzeń SBOM.
