Luka zero-day to błąd bezpieczeństwa wykorzystywany, zanim producent ma na niego poprawkę; nazwa bierze się stąd, że obrońcy mieli zero dni na reakcję. To najbardziej niepokojąca kategoria zagrożeń, bo zwykła rada, „aktualizuj oprogramowanie”, jeszcze nie ma zastosowania: nie ma do czego aktualizować. Ten artykuł przygląda się temu, jak takie luki naprawdę wyglądały na platformach Apple, opierając się na własnych informacjach Apple o wydaniach zabezpieczeń, na Google Project Zero i na Citizen Lab, a następnie tej jednej rzeczy, którą nieznany exploit wciąż musi zrobić po tym, jak się powiedzie.
Jedną kwestię trzeba postawić na wstępie, bo marketing wokół tego tematu bywa mylący: żadna zapora sieciowa nie zatrzymuje exploita. Ani FireAI, ani żadna inna. Zapora nie widzi zniekształconego obrazu parsowanego w iMessage ani błędu jądra wyzwalanego ze strony internetowej. To, co zapora może zrobić, to obserwować, co dzieje się dalej, a to okazuje się ważniejsze, niż się na pierwszy rzut oka wydaje.
Co naprawdę pokazują zapisy
Apple dokumentuje każdą poprawkę bezpieczeństwa na swojej stronie Apple security releases, a gdy luka była już wykorzystywana przeciwko prawdziwym ludziom, mówi o tym standardową formułą: „Apple wie o doniesieniu, że ten problem mógł być aktywnie wykorzystywany”. Czytanie tej strony przez kilka lat daje bardziej ugruntowany obraz niż jakikolwiek nagłówek. Google Project Zero prowadzi uzupełniający, publiczny rejestr, swój tracker 0-day „In the Wild”, który wymienia exploity wykryte w prawdziwych atakach, zanim istniała łatka. Project Zero starannie zaznacza, że tracker zawiera wyłącznie przypadki, które zostały wykryte, a więc z definicji porażki atakujących, dlatego nie da się go użyć do policzenia, ile wykorzystywania luk naprawdę ma miejsce, ani do porównywania platform.
Trzy udokumentowane przypadki pokazują kształt problemu.
FORCEDENTRY, 2021
W marcu 2021 roku Citizen Lab na Uniwersytecie w Toronto przeanalizowało telefon saudyjskiego aktywisty i odzyskało exploit, który nazwało FORCEDENTRY. Był to atak zero-click: specjalnie spreparowany plik, dostarczony przez iMessage, który nie wymagał od ofiary żadnego dotknięcia i instalował oprogramowanie szpiegujące Pegasus firmy NSO Group. Citizen Lab znalazło dowody, że był w użyciu co najmniej od lutego 2021 roku. Apple załatało lukę, CVE-2021-30860 w parserze obrazów CoreGraphics, 13 września 2021 roku w iOS 14.8, macOS Big Sur 11.6 i aktualizacji zabezpieczeń dla Cataliny; własne uwagi do wydania Big Sur 11.6 potwierdzają, że luka „mogła być aktywnie wykorzystywana”.
Google Project Zero opublikowało później analizę techniczną, która wyjaśnia, dlaczego coś takiego jest tak trudne do złapania. Błąd tkwił w kodzie kompresji obrazów JBIG2 używanym wewnątrz plików PDF. Exploit NSO wykorzystał własne operatory logiczne tego formatu, by z ponad 70 000 poleceń segmentów obrazu zbudować mały, działający komputer wewnątrz dekodera obrazów, i na nim uruchomił resztę ataku. Z zewnątrz nic w tym nie wygląda jak program. To obraz, otwierany przez legalny, podpisany proces systemowy.
Hongkoński watering hole, 2021
Pod koniec sierpnia 2021 roku Threat Analysis Group Google znalazła kampanię typu watering hole wymierzoną w osoby odwiedzające strony hongkońskiego medium oraz ugrupowania prodemokratycznego. Przeciwko Macom łączyła ona lukę w WebKit, załataną już w styczniu, z błędem eskalacji uprawnień w jądrze, CVE-2021-30869, który na macOS Catalina wciąż nie był załatany; Apple naprawiło go 23 września 2021 roku. Ładunek, backdoor nazwany przez Google MACMA, potrafił pobrać odcisk maszyny, przechwytywać ekran, nagrywać dźwięk, rejestrować naciśnięcia klawiszy, wysyłać i pobierać pliki oraz uruchamiać polecenia terminala.
Ten przykład jest pouczający, bo exploit i ładunek to dwie osobne rzeczy. Exploit był niewidzialny: strona internetowa. Ładunek był zwykłym wszczepionym programem, który, by w ogóle przydać się operatorom, musiał ustanowić kanał dowodzenia i kontroli oraz wyprowadzić dane z Maca. Opis Google przedstawia dokładnie tę infrastrukturę.
BLASTPASS, 2023
We wrześniu 2023 roku Citizen Lab opisało BLASTPASS, kolejny łańcuch zero-click w iMessage dostarczający Pegasusa, tym razem przez załączniki PassKit zawierające szkodliwe obrazy. Apple nadało numery CVE-2023-41064 i CVE-2023-41061 i wydało poprawki dla iPhone’a, iPada, Maca i Apple Watch. Co istotne, zarówno inżynierowie bezpieczeństwa Apple, jak i Citizen Lab powiedzieli, że ich zdaniem tryb blokady (Lockdown Mode) zablokował ten konkretny łańcuch, co jest najmocniejszym publicznym dowodem na to, że przeciwko tej klasie zagrożeń działa ograniczanie powierzchni ataku, a nie wykrywanie ataku.
Dlaczego wykrycie samego exploita jest tak trudne
Zestaw te trzy przypadki obok siebie, a wzorzec staje się jasny. Exploit przychodzi jako dane (obraz, PDF, strona internetowa), a nie jako aplikacja. Przetwarza go legalny kod podpisany przez Apple. Nie ma pliku, który XProtect mógłby dopasować, nie ma niepodpisanego pliku binarnego, który Gatekeeper mógłby odrzucić, i często nie ma nowego procesu, który narzędzie endpoint security mogłoby oznaczyć, bo wrogi kod działa wewnątrz procesu, który już był zaufany. Wykrycie, jeśli w ogóle następuje, jest zwykle śledcze: Citizen Lab znalazło FORCEDENTRY, badając ślady na urządzeniu po fakcie, a nie dzięki skanerowi, który złapał go na żywo.
Dlatego rada Apple dla osób, które sądzą, że mogą być celem, nie brzmi „zainstaluj detektor”, lecz tryb blokady, który na macOS Ventura i nowszych blokuje większość typów załączników w wiadomościach, wyłącza złożone technologie internetowe, odrzuca nieznanych rozmówców FaceTime i uniemożliwia instalowanie profili konfiguracji. Działa przez usunięcie ścieżek kodu, których exploit potrzebuje, kosztem wygody, o którym Apple mówi wprost.
Dlaczego krok sieciowy jest inny
Exploit to początek ataku, a nie jego cel. Pegasus istnieje po to, by wysyłać wiadomości, zdjęcia i dźwięk z mikrofonu do swojego operatora. Zrzuty ekranu i naciśnięcia klawiszy zebrane przez MACMA były bezwartościowe na dysku ofiary. W każdym udokumentowanym przypadku wartość realizowała się przez ruch opuszczający maszynę, a w macierzy MITRE ATT&CK dla macOS ta faza ma dwie własne kolumny, dowodzenie i kontrolę oraz eksfiltrację, bo jest odrębnym, obserwowalnym krokiem, którego atakujący nie mogą pominąć.
Ten krok ma właściwości, których exploit nie miał. Pochodzi z identyfikowalnego procesu z podpisem kodu (albo, co wymowne, bez niego). Zmierza do celu, który ma adres IP, nazwę hosta i historię. Często używa nietypowego portu, surowego adresu IP zamiast nazwy albo dostawcy hostingu niemającego związku z żadną aplikacją na Macu. Nic z tego nie wymaga znajomości luki, która została użyta. Wymaga jedynie zobaczenia połączenia i możliwości powiedzenia „nie”.
To jest ta część, dla której FireAI zostało zbudowane. Jego reguły per aplikacja są powiązane z podpisem kodu procesu nawiązującego połączenie, więc wszczepiony plik binarny, który nie jest zatwierdzoną przez Ciebie aplikacją, dostaje prośbę o zgodę zamiast wolnego przejścia, wraz z uzasadnieniem modelu działającego na urządzeniu pokazanym w zwykłym języku. Jego źródła informacji o zagrożeniach (abuse.ch, Spamhaus, FireHOL, OpenPhish, Phishing Army i aktualna lista węzłów wyjściowych Tora) są stosowane lokalnie, więc znany adres dowodzenia i kontroli zostaje odrzucony niezależnie od tego, czy cokolwiek innego na Macu rozpoznało ładunek. Tryby Under attack i Paranoid zaostrzają ustawienie domyślne do bezwarunkowego blokowania niepodpisanych aplikacji i nieznanych celów, a wyłącznik awaryjny odcina internet, zachowując sieć lokalną, co jest właściwym pierwszym ruchem, gdy podejrzewasz włamanie i chcesz zachować dowody.
Czego to nie obejmuje
Uczciwość wymaga drugiej połowy listy. Jeśli ładunek działa w całości wewnątrz dozwolonej aplikacji, na przykład w przeglądarce, na którą już wyraziłeś zgodę, jego ruch dziedziczy uprawnienia tej aplikacji i FireAI go nie odróżni. Szyfrowany ruch do celu o czystej reputacji wygląda jak każde inne połączenie. Źródło zawiera tylko adresy, które ktoś już zgłosił; świeżego serwera dowodzenia i kontroli jeszcze na nim nie ma. A FireAI nie wykrywa, nie usuwa ani nie analizuje exploita czy implantu: nie skanuje plików ani pamięci i nie jest antywirusem. Na Macu, który Twoim zdaniem został przejęty przez aktora na poziomie państwowym, właściwa droga to wytyczne Apple dotyczące powiadomień o zagrożeniach i specjalista śledczy, a nie ustawienie zapory.
Praktyczna obrona przed nieznanymi lukami jest więc warstwowa i mało efektowna: instaluj aktualizacje Apple w dniu ich wydania, bo większość ataków wykorzystuje luki, które mają już poprawkę; włącz tryb blokady, jeśli Twoja praca czyni z Ciebie prawdopodobny cel; utrzymuj małą powierzchnię ataku; i kontroluj, które aplikacje na Twoim Macu w ogóle mogą rozmawiać z internetem, tak by, gdy coś nieznanego jednak się dostanie, krok, którego nie może pominąć, był krokiem, który obserwujesz.
Jaką rolę odgrywają FireAI i HisnLabs
FireAI cannot stop an exploit and does not claim to; what it does is sit on the one step every documented case above could not skip, the connection out, and ask, for each unknown process, whether that connection should be allowed at all.
FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.
Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.