Jakie dwa zero-daye załatało ostatnio Apple?
W ostatnich dniach Apple gorąco namawia użytkowników macOS, iPhone’a i iPada do natychmiastowego zainstalowania aktualizacji, które zawierają poprawki dla dwóch podatności typu zero-day, będących pod aktywnymi atakami. Łatki dotyczą luk umożliwiających atakującym wykonanie dowolnego kodu i ostatecznie przejęcie urządzeń.
Poprawki są dostępne dla urządzeń z systemem iOS 15.6.1 i macOS Monterey 12.5.1. Zgodnie z aktualizacjami zabezpieczeń wydanymi przez Apple Wednesday usuwają one dwie luki, mające wpływ zasadniczo na każde urządzenie Apple, na którym można uruchomić system iOS 15 lub wersję Monterey na komputerze Mac. Warto od razu zaznaczyć, że każdy, kto ostatnio zaktualizował swój iPhone do systemu w wersji 16, jest bezpieczny i nie musi podejmować żadnych dodatkowych działań.
Jedną z podatności jest błąd jądra (CVE-2022-32894), występujący zarówno w iOS, jak i macOS. Według Apple to problem z zapisem out-of-band (poza zakresem), który został rozwiązany przez ulepszone sprawdzanie dostępnego podczas zapisu zakresu danych. Luka umożliwia aplikacji wykonanie dowolnego kodu z uprawnieniami jądra. Apple jak zwykle w niejasny sposób zakomunikował o istnieniu raportu mówiącego, że dziura ta jest aktywnie wykorzystywana w cyberatakach. Dlatego natychmiastowa aktualizacja jest tak ważna. Wynik CVSS to 7.8.
Druga zidentyfikowana usterka to błąd WebKit (śledzony jako CVE-2022-32893), czyli również błąd zapisu poza zakresem, rozwiązany przez Apple oczywiście za pomocą ulepszonego mechanizmu weryfikacji zapisywanych danych. Ogólnie wygląda to jak typowy błąd programisty, który nie wprowadził po prostu podstawowych metod weryfikacji typów zmiennych i ich wartości przy alokowaniu pamięci na dane. Jak podaje Apple, podatność umożliwia przetwarzanie spreparowanej zawartości internetowej, która może prowadzić do wykonania kodu. WebKit to silnik przeglądarki obsługujący Safari i wszystkie inne przeglądarki firm trzecich działające w systemie iOS. Tutaj z koleji wskaźnik zagrożenia to 8.8/10.
Odkrycie obu podatności, o których niestety niewiele wiadomo od technicznej strony, przypisuje się anonimowemu badaczowi.
Według tego, co wiemy, najnowsze błędy Apple mogą zapewnić atakującym pełny dostęp do urządzenia, a więc może powtórzyć się scenariusz niesławnego Pegasusa, gdzie państwowe APT atakowały cele za pomocą oprogramowania szpiegującego stworzonego przez izraelską grupę NSO.
Błędy Apple zostały ujawnione równolegle z innymi informacjami o zero-dayach w tym tygodniu. Google na przykład załatało swoją piątą już w tym roku lukę zero-day przeglądarki Chrome. Był to błąd wykonania dowolnego kodu podczas aktywnego ataku, a więc również podatność krytyczna.
Wiadomości o kolejnych lukach w zabezpieczeniach ze strony wiodących dostawców technologii nie napawają optymizmem. Pokazuje to, że pomimo najlepszych wysiłków czołowych firm, mających na celu rozwiązanie odwiecznych problemów z bezpieczeństwem w ich oprogramowaniu, jest to trudna bitwa, która będzie napędzana przez coraz nowsze ataki oraz coraz lepsze zabezpieczenia.
Wady systemu iOS są szczególnie niepokojące, biorąc pod uwagę wszechobecność iPhone’ów i całkowitą zależność użytkowników od urządzeń mobilnych w codziennym życiu. Jednak obowiązek ochrony smartfonów spoczywa nie tylko na dostawcach, lecz także na ich operatorach. Użytkownicy muszą być bardziej świadomi istniejących zagrożeń, a nie traktować możliwość włamania do swojego telefonu jak film science fiction.
Jednocześnie twórcy aplikacji na iPhone’y i inne urządzenia mobilne powinni dodać dodatkową warstwę kontroli bezpieczeństwa swojej technologii, aby byli mniej zależni od bezpieczeństwa systemu operacyjnego, biorąc pod uwagę często pojawiające się wady.
Popularne
Nowe podatności w architekturze sieci 5G
Pięć prognoz cyberbezpieczeństwa na 2026 rok
Polowanie na eskalację uprawnień w Windows: sterowniki jądra i Named Pipe pod lupą
Czym są non-human identities (NHI)? Jak możemy je chronić i jakie zagrożenia stwarzają dla organizacji?
Sekrety, które powinny pozostać sekretami – czyli jak chronić poświadczenia (credentials) NHI – część 2
