Jeden człowiek, jeden dzień roboczy i mniej niż dwadzieścia poleceń wpisanych do ogólnodostępnych modeli. Tyle według firmy A Security wystarczyło, żeby znaleźć w Zoomie błąd pozwalający przejąć komputer innego uczestnika spotkania. W tym samym oknie czasowym powstał działający kod, który ten błąd wykorzystuje. Poprawka siedzi w kliencie od czerwca, a biuletyn producenta wyszedł 11 sierpnia, więc jako ostrzeżenie sprawa jest domknięta. Otwarty zostaje rachunek, bo według A Security znalezienie luk tej klasy wymagało dotąd elitarnych zespołów, miesięcy pracy i budżetów dostępnych głównie podmiotom państwowym.
Na czym polega luka zero-click w funkcji adnotacji Zooma
Adnotacje to rysowanie po udostępnionym ekranie. Ktoś zaznacza fragment tabelki, ktoś inny dopisuje strzałkę albo pole tekstowe. Rysunek nie podróżuje przez sieć jako obrazek. Klient buduje z niego opis obiektu i wysyła go w postaci ciągu bajtów. Klient po drugiej stronie odtwarza z tych bajtów ten sam kształt i pokazuje go na ekranie.
Błąd siedzi w odtwarzaniu. Format zapisu jest ciągiem wartości poprzedzonych licznikami. Parser czyta z sieci liczbę i na jej podstawie decyduje, ile bajtów wczytać dalej. Liczniki pochodzą od nadawcy, a w jednym miejscu nikt nie sprawdzał, czy podana wartość mieści się w przygotowanym buforze. Zamiast danych do wyświetlenia można było więc podstawić takie, które wyjadą poza bufor i nadpiszą pamięć obok. Ten sam kod źródłowy kompiluje się do klientów na Windows, macOS, iOS i Androida. Jeden błąd obejmuje więc całą linię produktu.
Określenie zero-click bierze się stąd, że klient odbiorcy sam przetwarza to, co przyjdzie. Ofiara nie musi kliknąć ani niczego otworzyć, wystarczy jej obecność na spotkaniu. Wzorzec jest bliski temu, który opisywaliśmy przy agencie wykonującym polecenie ukryte w dzienniku zdarzeń. Program dostaje dane z zewnątrz i traktuje je jako wiarygodne, bo przyszły kanałem uznanym za swój. A Security dorzuca, że funkcja adnotacji działa niezależnie od tego, czy ktokolwiek jej w danym spotkaniu używa.
Co mieści się w dwudziestu promptach, a co się w nich nie mieści
Liczba jest efektowna i dlatego obiegła prasę branżową bez pytania, co dokładnie obejmuje. Opis badania jest pod tym względem uczciwy, bo pokazuje także to, co nie zadziałało.
Zaczęło się od klienta na Androida i od problemu skali. Sto dwadzieścia jeden bibliotek natywnych to za dużo, żeby przeglądać je ręcznie. Agenty zbudowały więc statyczny ranking, oceniając każdą funkcję osiągalną z warstwy Javy pod kątem niebezpiecznych operacji na pamięci. Wyszła kolejka robocza licząca 3 762 funkcje w siedemdziesięciu bibliotekach. Czołówka tej kolejki okazała się ślepa. Prowadziła do ścieżek lokalnych, czyli do obsługi kamery samego urządzenia. Jedyny znaleziony tam błąd nie dawał się wywołać danymi, które pojawiają się w prawdziwym spotkaniu.
Przełom przyniosła zmiana pytania. Zamiast szukać miejsc, gdzie kod robi coś niebezpiecznego, badacze zaczęli szukać tego, co zdalny uczestnik w ogóle może dosięgnąć. Śledzenie działającego klienta w trakcie spotkania wskazało bibliotekę odpowiedzialną za adnotacje. W statycznym rankingu stała na czterdziestym piątym miejscu.
To jest najbardziej pouczający fragment całej historii. Maszyna wykonała robotę nieosiągalną dla człowieka w tej skali, ale jej własne uszeregowanie priorytetów prowadziło donikąd. Rozstrzygnęła decyzja o zmianie kryterium, a takich decyzji w rachunku “mniej niż dwadzieścia promptów” nie widać. Podobny rozjazd między tym, co narzędzie zrobiło, a tym, co mu przypisano, opisywaliśmy przy atrybucji luki wygenerowanej przez Copilot Autofix.
Pierwsza Misja AI · Kodożercy
AI bez technikaliów – kurs i certyfikat
Pierwsza Misja AI to kurs Kodożerców dla absolutnych początkujących. Fabuła w konwencji science fiction, gamifikacja, ćwiczenia na żywym modelu, certyfikat na koniec.
Zacznij Pierwszą Misję →
Kto właściwie mówi, ile taka luka kosztowała dawniej
Porównanie “kiedyś elitarne zespoły, dziś jeden dzień” pochodzi od A Security. W oryginale brzmi ono tak: model wymagający elitarnych zespołów, miesięcy pracy i budżetów regulowanych jak handel bronią właśnie się zawalił. To zdanie warto czytać razem z tym, czym ta firma jest. A Security opisuje się jako platforma do autonomicznych testów ofensywnych i naprawy. Wniosek jej wpisu brzmi, że jedyną trwałą odpowiedzią jest skierowanie tej samej zdolności do wewnątrz i ciągłe testowanie własnego środowiska.
Nie znaczy to, że liczby są nieprawdziwe. Znaczy tyle, że nikt ich niezależnie nie zweryfikował, a firma podająca koszt znalezienia luki sprzedaje usługę znajdowania luk. W relacjach z tej sprawy pojawiła się przy okazji konkretniejsza wersja porównania. Mówi ona o pięciu osobach pracujących pół roku. W materiale źródłowym takiej liczby nie ma i nie warto jej powtarzać.
Ostrożność nie odbiera sprawie wagi. Zoom jest oprogramowaniem zamkniętym, bez opublikowanej specyfikacji protokołu. Według opisu A Security podatny fragment udało się mimo to odtworzyć jednej osobie w ciągu jednego dnia, przy wsparciu ogólnodostępnych modeli. Opublikowana metoda pokazuje przebieg tej pracy, ale nie jest niezależnym potwierdzeniem czasu ani liczby badaczy.
Producent ocenia tę lukę inaczej niż badacze
Tu warto zestawić dwa dokumenty, bo mówią o tym samym błędzie różnym językiem. Biuletyn Zooma daje ocenę 8,3 na dziesięć i opisuje rzecz jako brak sprawdzenia granic bufora w funkcji adnotacji. W wektorze tej oceny producent zaznaczył jednak wymaganą interakcję użytkownika oraz wysoką złożoność ataku. Badacze piszą tymczasem wprost o ataku niewymagającym od ofiary żadnego działania. Rozbieżność zostawiamy jako rozbieżność, bo oba dokumenty są źródłami pierwszej ręki.
Kalendarium jest za to spójne i mówi więcej niż sama ocena. Błąd znaleziono 8 czerwca, zgłoszono 10 czerwca, a poprawka kliencka wyszła dwanaście dni później. W połowie lipca doszło do tego zabezpieczenie po stronie serwera, dla tych, którzy klienta jeszcze nie zaktualizowali. Publikacja czekała do 11 sierpnia, żeby użytkownicy zdążyli dostać zarówno poprawkę kliencką, jak i zabezpieczenie po stronie serwera.
Jest jeszcze praktyczny drobiazg, który w relacjach ginie. A Security zaznacza, że użytkownicy szyfrowania end-to-end potrzebują aktualizacji klienta, bo zabezpieczenie serwerowe im nie wystarcza. Podaje przy tym jako podatne wydania starsze niż 7.1.5 i 7.0.6, podczas gdy biuletyn Zooma dla tej luki wskazuje 7.1.0 i 7.0.6. Źródła są w tym punkcie rozbieżne, więc najbezpieczniej po prostu zaktualizować klienta do najnowszej dostępnej wersji. Żadne ze źródeł nie twierdzi, że ktokolwiek wykorzystał tę lukę w ataku, a kodu wykorzystującego ją nie opublikowano.
Co z tego wynika dla firmy, która nie pisze własnego oprogramowania
Zwykła polska firma nie ma tu nic do naprawienia w kodzie, bo kodu Zooma nie widzi i nigdy nie zobaczy. Zostają dwie dźwignie i obie leżą po stronie konfiguracji.
Pierwsza to tempo aktualizacji. Opublikowana łatka jest mapą do błędu, więc ryzyko dla niezaktualizowanej floty rośnie w momencie jej wydania. Zoom pozwala wymusić minimalną wersję klienta dla pracowników i dla gości, co jest ustawieniem wartym jednego popołudnia. Druga dźwignia to zmniejszanie powierzchni ataku. Skoro do tego ataku wystarczała obecność na spotkaniu, to reguły wejścia są elementem zabezpieczeń. Liczy się poczekalnia, hasło, wpuszczanie wyłącznie zalogowanych i brak publicznie wiszącego linku do pokoju osobistego. Do tego wyłączanie funkcji, z których zespół nie korzysta, bo każda opcjonalna funkcja to kolejny parser czytający cudze bajty.
Trzeci wniosek jest niewygodny i dotyczy planowania. Ekspozycja zaczyna się w chwili, gdy ktoś znajdzie błąd, a nie wtedy, gdy producent się o nim dowie. Jeśli koszt tego pierwszego zdarzenia spada, okno między znalezieniem a łatką robi się dla obrońcy ważniejsze niż dotąd. Zmierzyć go od środka i tak nie sposób. Zestaw pytań, jakie trzeba dziś zadawać narzędziom opartym na modelach, zbieraliśmy osobno przy analizie tego, co psuje się w agentach.
Podsumowanie
Sama luka jest już załatana i nic nie wskazuje na to, żeby ktokolwiek jej użył w ataku. Panika byłaby tu nie na miejscu. Warta uwagi jest cena znalezienia, choć trzeba ją czytać z dwoma zastrzeżeniami. Liczbę “mniej niż dwadzieścia promptów” podaje firma sprzedająca automatyczne testy ofensywne i nikt jej niezależnie nie sprawdził. Nie obejmuje też ona całej pracy. Poza nią zostaje statyczny ranking na kilku tysiącach funkcji, a drugą rzeczą jest moment, w którym człowiek uznał, że maszyna szuka w złym miejscu. Nawet po tych odjęciach zostaje wniosek, który warto wpisać we własny rachunek ryzyka. Ten przypadek pokazuje, że sama nieprzejrzystość zamkniętego oprogramowania nie wystarcza już jako ochrona.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
