Menu dostępności

Większość systemów Linux narażona na całkowite przejęcie z powodu luki w zabezpieczeniach Shim

Uwaga! Większość systemów Linux narażona na całkowite przejęcie z powodu luki w zabezpieczeniach Shim

Krytyczna luka w zabezpieczeniach Shim może pozwolić osobie atakującej sieci na ominięcie zabezpieczeń i przejęcie podatnego na ataki systemu Linux. O problemach z Linuksem nie piszemy tak często jak o tych z Windowsem, ale parę publikacji na ten temat powstało 😉

Tym razem na tapet bierzemy Shim. To mała aplikacja zawierająca certyfikaty i kod służący do weryfikacji programu ładującego. Jest używana w większości dystrybucji Linuksa jako zabezpieczenie początkowego etapu procesu rozruchu.

Luka, zidentyfikowana w obsłudze protokołu HTTP Shima, prowadzi do zapisu poza zakresem, który może zostać wykorzystany do zdalnego wykonania kodu.

Podatność została oznaczona jako CVE-2023-40547 i według zalecenia NIST otrzymała wynik CVSS na poziomie 9,8. Red Hat ocenia jednak błąd jako mający „wysoki poziom ważności” z wynikiem CVSS na poziomie 8,3.

„Obsługa rozruchu Shim ufa wartościom kontrolowanym przez atakującego podczas analizowania odpowiedzi HTTP. Ta wada umożliwia osobie atakującej spreparowanie określonego złośliwego żądania HTTP, co prowadzi do całkowicie kontrolowanego, prymitywnego zapisu poza zakresem i całkowitego naruszenia systemu” – czytamy w poradniku firmy Red Hat.

Osoba atakująca może przechwycić ruch HTTP między systemem ofiary a serwerem dostarczającym pliki obsługujące rozruch http – twierdzi z kolei Eclypsium – firma zajmująca się zarządzaniem ryzykiem w łańcuchu dostaw – i wyjaśnia: „napastnik może znajdować się w dowolnym segmencie sieci pomiędzy ofiarą a legalnym serwerem”.

Lokalny atakujący z uprawnieniami wystarczającymi do modyfikowania zmiennych EFI lub danych partycji EFI, na przykład przy użyciu działającego dysku USB z systemem Linux, może zmienić kolejność rozruchu, aby załadować podatną na ataki podkładkę i wykonać uprzywilejowany kod bez wyłączania bezpiecznego rozruchu.

Według Eclypsium atakujący znajdujący się w tej samej sieci, co system docelowy, może manipulować środowiskiem PXE w celu załadowania podatnego na ataki programu Shim.

„Osoba atakująca wykorzystująca tę lukę uzyskuje kontrolę nad systemem przed załadowaniem jądra, co oznacza, że ma uprzywilejowany dostęp i możliwość obejścia wszelkich kontroli wdrażanych przez jądro i system operacyjny” – zauważa Eclypsium.

Firma wyjaśnia, że usunięcie luki wymaga nie tylko aktualizacji podkładki Shim do poprawionej wersji, ale także aktualizacji łańcucha zaufania bezpiecznego rozruchu poprzez odświeżenie bazy danych UEFI Secure Boot DBX (listy odwołań).

Niedawno odkryto pięć innych luk w zabezpieczeniach Shim o wysokim i średnim poziomie ważności, prowadzących do awarii, odmowy usługi (DoS) lub wycieku wrażliwych danych podczas uruchamiania systemu.

Popularne

Jak zmienić nieznane/zapomniane hasło Administratora na Windows?

Jak zmienić nieznane/zapomniane hasło Administratora na Windows?

W tym artykule pokażemy, jak możemy zmienić hasło administratora na komputerze posiadając do niego fizyczny dostęp. Artykuł ten można potraktować także jako przestrogę dla firm, które nie zaimplementowały jeszcze odpo...
Kolejny poważny zero-day. Nowe luki omijają BitLockera i pozwalają przejąć uprawnienia SYSTEM

Kolejny poważny zero-day. Nowe luki omijają BitLockera i pozwalają przejąć uprawnienia SYSTEM

Eksperci ds. cyberbezpieczeństwa alarmują o dwóch nowych lukach typu zero-day w systemie Windows, mogących mieć poważne konsekwencje dla bezpieczeństwa użytkowników i firm. Podatności, którym nadano naz...
Jeszcze o Mythos!

Jeszcze o Mythos!

W bardzo dobrym artykule autorstwa mojego redakcyjnego kolegi możemy znaleźć kompendium wiedzy o Mythos – niedawno ogłoszonym modelu AI od Anthropic. Produkt ten wywołał panikę w branży ze względu na zdolno...
Czym jest Microsoft Entra Backup and Recovery?

Czym jest Microsoft Entra Backup and Recovery?

Przez długi czas odzyskiwanie zmian w Microsoft Entra opierało się głównie na kilku osobnych mechanizmach: soft-delete dla części obiektów, logach audytowych, eksportach konfiguracji i ręcznym odtwarza...
PowerShell bez powershell.exe. Dlaczego klasyczne detekcje coraz częściej zawodzą

PowerShell bez powershell.exe. Dlaczego klasyczne detekcje coraz częściej zawodzą

Przez lata wykrywanie aktywności PowerShella było stosunkowo proste. Wystarczyło monitorować powershell.exe, analizować command line i szukać charakterystycznych parametrów, typu -enc, bypass albo hidden...