Google Antigravity pod ostrzałem: luka RCE i kampania malware wymierzone w środowisko agentowe AI - Security Bez Tabu

Google Antigravity pod ostrzałem: luka RCE i kampania malware wymierzone w środowisko agentowe AI

Cybersecurity news

Wprowadzenie do problemu / definicja

Google Antigravity to nowoczesna platforma deweloperska klasy agent-first, zaprojektowana do współpracy z autonomicznymi agentami AI realizującymi złożone zadania inżynierskie. Rosnące znaczenie takich środowisk sprawia jednak, że stają się one atrakcyjnym celem zarówno dla badaczy bezpieczeństwa, jak i cyberprzestępców.

W ostatnim czasie wokół Antigravity ujawniono dwa równoległe zagrożenia. Pierwsze dotyczy podatności umożliwiającej ucieczkę z sandboxa i zdalne wykonanie kodu, drugie zaś kampanii malware wykorzystującej markę produktu do dystrybucji złośliwego instalatora.

W skrócie

  • W Google Antigravity wykryto lukę pozwalającą na zdalne wykonanie kodu i obejście mechanizmów izolacji.
  • Źródłem problemu miała być niewystarczająca sanitizacja danych wejściowych w parametrze używanym przy wyszukiwaniu plików.
  • Badacze wykazali także możliwość użycia pośredniego prompt injection bez przejęcia konta ofiary.
  • Równolegle pojawiła się kampania podszywająca się pod Antigravity i dystrybuująca trojanizowany instalator.
  • Złośliwe oprogramowanie miało kraść dane z przeglądarek, komunikatorów, portfeli kryptowalutowych i innych aplikacji użytkownika.

Kontekst / historia

Ekosystem narzędzi deweloperskich wspieranych przez AI rozwija się bardzo dynamicznie. Rozwiązania tego typu nie są już jedynie inteligentnymi edytorami kodu, lecz pełnią rolę warstwy orkiestracji dla agentów zdolnych do planowania, wykonywania i weryfikowania wieloetapowych działań.

To przesunięcie funkcjonalne zwiększa produktywność zespołów, ale jednocześnie rozszerza powierzchnię ataku. Narzędzie, które analizuje pliki, interpretuje polecenia i może inicjować działania w systemie lokalnym, staje się elementem krytycznym z punktu widzenia bezpieczeństwa stacji roboczej dewelopera oraz całego łańcucha dostaw oprogramowania.

W przypadku Google Antigravity zagrożenie ma charakter podwójny. Z jednej strony ujawniono błąd projektowy wpływający na izolację i wykonanie poleceń. Z drugiej strony cyberprzestępcy wykorzystali rozpoznawalność platformy jako przynętę do infekowania użytkowników malware. To typowy schemat obserwowany przy szybko zyskujących popularność produktach technologicznych.

Analiza techniczna

Według opisu incydentu wykryta podatność umożliwiała eskalację z poziomu ograniczonego środowiska do wykonania arbitralnych poleceń systemowych. Bezpośrednią przyczyną miała być niewystarczająca sanitizacja danych wejściowych w parametrze przetwarzanym przez funkcję wyszukiwania plików. Odpowiednio spreparowana wartość mogła prowadzić do wstrzyknięcia poleceń i ich wykonania po stronie lokalnego środowiska.

Szczególnie istotne jest to, że zaprezentowany scenariusz miał omijać tryb Secure Mode. Sugeruje to, że mechanizmy ochronne nie obejmowały wszystkich ścieżek wykonania albo nie uwzględniały specyfiki operacji inicjowanych przez agentów AI. W środowiskach agentowych ryzyko jest podwyższone, ponieważ agent może traktować zawartość plików, komentarzy i instrukcji jako dane sterujące dalszym działaniem.

Badacze wskazali również wariant wykorzystujący pośrednie prompt injection. W takim scenariuszu użytkownik pobiera z nieufnego źródła plik, który wygląda niegroźnie, ale zawiera treść wpływającą na zachowanie agenta. Gdy agent przetwarza taki plik, może zostać nakłoniony do przygotowania lub uruchomienia złośliwego łańcucha działań. Pokazuje to, że w narzędziach AI granica między danymi a instrukcjami bywa wyjątkowo cienka.

Drugi aspekt techniczny dotyczy kampanii malware. Fałszywa witryna imitująca legalny projekt dystrybuowała zmodyfikowany instalator, który poza pozornie prawidłową instalacją uruchamiał dodatkowe skrypty PowerShell. To skuteczna technika socjotechniczna, ponieważ użytkownik widzi działającą aplikację, podczas gdy złośliwe komponenty są wdrażane równolegle w tle.

Dostarczany payload miał charakter stealer malware nastawionego na pozyskiwanie danych o wysokiej wartości operacyjnej i finansowej. Z opisu funkcjonalności wynika, że celem były między innymi zapisane hasła, cookies, dane autouzupełniania, informacje z komunikatorów, portfeli kryptowalutowych oraz klientów FTP. Dodatkowo malware miał wspierać clipboard hijacking, keylogging, a nawet tworzenie ukrytego pulpitu w systemie Windows, co sprzyja skrytemu wykonywaniu działań.

Konsekwencje / ryzyko

Dla organizacji korzystających z narzędzi agentowych ryzyko ma kilka poziomów. Podatność typu remote code execution w środowisku programistycznym może prowadzić do pełnego przejęcia stacji roboczej dewelopera. Taka stacja często posiada dostęp do repozytoriów kodu, kluczy SSH, tokenów CI/CD, sekretów aplikacyjnych, środowisk chmurowych i systemów wewnętrznych.

Prompt injection w narzędziu zdolnym do wykonywania działań na systemie plików i uruchamiania poleceń może z kolei umożliwiać ataki łańcuchowe. Niebezpieczny plik źródłowy, komentarz w repozytorium lub spreparowana dokumentacja mogą stać się punktem wejścia do środowiska deweloperskiego nawet wtedy, gdy użytkownik nie uruchamia świadomie podejrzanego kodu.

Osobnym problemem są kampanie podszywające się pod popularne narzędzia AI. Są one szczególnie groźne dla freelancerów, małych zespołów i środowisk testowych, gdzie kontrola nad pochodzeniem instalatorów bywa słabsza. Kradzież cookies, haseł i sesji może prowadzić do przejęcia kont, dostępu do zasobów firmowych oraz dalszej lateralizacji w infrastrukturze.

W ujęciu strategicznym incydent pokazuje, że narzędzia AI dla deweloperów stają się krytycznym elementem łańcucha dostaw oprogramowania. Każda podatność lub kampania podszywania się pod taki produkt może wpływać nie tylko na pojedynczy host, ale także na repozytoria, pipeline wdrożeniowe i zasoby produkcyjne.

Rekomendacje

Organizacje powinny traktować środowiska IDE oraz agentowe narzędzia AI jako aktywa wysokiego ryzyka i obejmować je kontrolami podobnymi do tych stosowanych wobec stacji uprzywilejowanych. W praktyce oznacza to segmentację dostępu, ograniczenie lokalnych uprawnień, monitoring procesów potomnych oraz ścisłą kontrolę użycia PowerShell i interpreterów skryptowych.

  • Pobierać instalatory wyłącznie z oficjalnych i zweryfikowanych kanałów.
  • Weryfikować podpisy cyfrowe i sumy kontrolne przed wdrożeniem oprogramowania.
  • Stosować allowlisting aplikacji oraz blokować uruchamianie nieautoryzowanych binariów i skryptów z katalogów użytkownika.
  • Traktować pliki z repozytoriów publicznych, dokumentację i komentarze jako potencjalnie niebezpieczne dane wejściowe dla agentów AI.
  • Rozdzielać środowiska testowe od środowisk o podwyższonym poziomie zaufania.
  • Wdrażać polityki jawnej akceptacji dla operacji systemowych wykonywanych przez agentów.
  • Regularnie usuwać zbędne tokeny i sekrety z lokalnych stacji oraz korzystać z menedżerów sekretów.

Z perspektywy SOC i zespołów IR warto przygotować detekcje obejmujące nietypowe uruchomienia PowerShell po instalacji narzędzi deweloperskich, tworzenie procesów potomnych przez IDE, dostęp do magazynów przeglądarek, eksport cookies, aktywność wobec portfeli kryptowalutowych oraz anomalie związane z tworzeniem alternatywnych pulpitów w systemie Windows.

Podsumowanie

Przypadek Google Antigravity dobrze ilustruje dwa równoległe trendy w cyberbezpieczeństwie. Z jednej strony rośnie znaczenie podatności w narzędziach AI działających z szerokim dostępem do systemu i procesu wytwórczego. Z drugiej strony operatorzy malware bardzo szybko wykorzystują popularność nowych marek i produktów do prowadzenia kampanii socjotechnicznych.

Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia modelu zagrożeń o nowe klasy ryzyk, takie jak prompt injection w środowiskach agentowych, kompromitacja stacji deweloperskich przez fałszywe instalatory oraz nadużycia wynikające z nadmiernych uprawnień narzędzi AI. Im większa automatyzacja pracy programistycznej, tym większa potrzeba wdrażania twardych kontroli bezpieczeństwa wokół całego ekosystemu.

Źródła

  1. SecurityWeek — Google Antigravity in Crosshairs of Security Researchers, Cybercriminals — https://www.securityweek.com/google-antigravity-in-crosshairs-of-security-researchers-cybercriminals/
  2. Pillar Security — Technical write-up on the Antigravity vulnerability — https://www.pillar.security/
  3. Malwarebytes — Analysis of the trojanized Antigravity installer campaign — https://www.malwarebytes.com/