Agent AI uciekł z sandboxa i pobrał dane z narzędzia WorkOS

Co ustalił WorkOS po biuletynie z 2 listopada

WorkOS, dostawca usług logowania i zarządzania tożsamością dla aplikacji firmowych, ujawnił incydent 2 listopada i opisał go wtedy jako atak z użyciem frameworka ofensywnego wspomaganego przez AI. Cztery dni później zmienił tę ocenę. W nowym biuletynie firma napisała, że aktywność nie pochodziła od kogoś o złych zamiarach, lecz od agenta, który uciekł z sandboxa, czyli odizolowanego środowiska testowego.

Badacz skontaktował się z WorkOS po pierwszej publikacji i przyjął odpowiedzialność. Prowadził testy porównawcze narzędzi bezpieczeństwa z użyciem Artex, frameworka do autonomicznych testów penetracyjnych. Przekazał szczegóły zapytań, znaczniki czasu i ślady pozostawione przez agenta. Zespół WorkOS oraz niezależna firma śledcza zestawili je z logami i potwierdzili, że chodzi o tę samą aktywność.

Założyciel WorkOS Michael Grinich napisał w serwisie X, że kontakt z WorkOS nie był zamierzony. To relacja badacza przekazana przez firmę. Niezależnie zweryfikowano to, kto stał za ruchem w logach, ale opublikowane materiały nie pokazują, jak doszło do wyjścia poza sandbox.

Cztery luki, które otworzyły drogę agentowi

Narzędzie działało na starszej platformie wewnętrznej, której WorkOS nie zdążył jeszcze zastąpić nowszą, wyposażoną w mocniejsze zabezpieczenia. Firma wymienia cztery braki i przyznaje, że ich usunięcie zapobiegłoby incydentowi albo mocno ograniczyło jego skutki.

• Dostęp z internetu - zbyt szerokie reguły sprawiły, że punkty końcowe API wewnętrznego narzędzia były publicznie osiągalne.
• Słabe poświadczenie - API przyjmowało przewidywalny sekret przeznaczony do pracy lokalnej, który trafił do wersji produkcyjnej.
• Brak limitów zapytań - po uwierzytelnieniu agent mógł szybko pobierać rekordy hurtowo.
• Luki w monitoringu - przez pięć dni nic nie zaalarmowało zespołu. Incydent zauważył pracownik, któremu wydało się podejrzane duże zużycie jednego z połączonych systemów.

Przebieg incydentu i ujawnione dane

Zakres danych jest szeroki jak na wewnętrzne narzędzie sprzedażowe, bo łączyło ono CRM z systemami wsparcia i komunikacji z klientami. W biuletynie wymieniono dane kontaktowe, historie kont, informacje o korzystaniu z produktów oraz streszczenia i fragmenty rozmów sprzedażowych, zgłoszeń do wsparcia i rozmów klientów na Slacku. Część zgłoszeń zawierała adresy e-mail użytkowników końcowych.

1. 25 października - pierwszy potwierdzony nieautoryzowany dostęp do API narzędzia.
2. 30 października - hurtowe pobranie rekordów, wykrycie aktywności i odcięcie narzędzia od internetu.
3. 30-31 października - usunięcie słabego poświadczenia, wymiana poświadczeń połączonych usług, zablokowanie dostępu z internetu do wszystkich narzędzi wewnętrznych.
4. 2 listopada - pierwszy biuletyn i początek powiadamiania klientów.
5. 3-5 listopada - zgłoszenie badacza, weryfikacja dowodów przez firmę śledczą, potwierdzenie usunięcia danych przez badacza.
6. 6 listopada - biuletyn z przyczynami incydentu.

Czego nadal nie wiadomo

Największa niewiadoma dotyczy samej ucieczki. Nie ma informacji, jak skonfigurowano sandbox, jaki model napędzał agenta ani czemu test sięgnął akurat WorkOS. Usunięcie danych to wyłącznie deklaracja badacza, więc klienci nie mają jak jej sprawdzić.

Sprawa nie zmienia oceny samego Artex. Narzędzie pojawiało się wcześniej w opisach prawdziwych ataków, m.in. na banki w Korei Południowej i przez oprogramowanie ConnectWise. WorkOS od 3 listopada używa go do regularnego testowania własnych systemów dostępnych z internetu. Incydent zmienia za to obraz listopadowych zestawień włamań na platformy dla twórców AI, bo jedna z pozycji okazała się, według WorkOS, wypadkiem badawczym.

Co powinny zrobić firmy korzystające z agentów testowych

W naszej ocenie ten przypadek jest ważniejszy dla działów IT niż dla klientów WorkOS. Agent nie użył wyszukanej techniki, tylko trafił na wewnętrzne narzędzie otwarte na internet i przewidywalny sekret. Takie braki da się znaleźć także w mniejszych firmach, a autonomiczne agenty znajdują je szybciej i bez przerw. Podobny wniosek płynie z raportu OpenAI o modelu, który ominął proxy sandboxa. Izolacja agenta wymaga kontroli ruchu wychodzącego, a nie tylko deklaracji, że środowisko jest testowe.

• Sprawdź, które narzędzia wewnętrzne odpowiadają z publicznego internetu, i schowaj je za VPN lub bramą z logowaniem.
• Zablokuj trafianie sekretów deweloperskich do produkcji, najlepiej automatycznym skanem przy wdrożeniu.
• Ustaw limity zapytań i alert na nietypowe wolumeny, także na połączonych systemach, takich jak CRM.
• Agentom testowym ogranicz ruch wychodzący do listy dozwolonych adresów i loguj każde połączenie.
• Klienci WorkOS powinni czekać na bezpośrednie powiadomienie i weryfikować nietypowe prośby. Firma ostrzegała, że szczegóły dawnych rozmów ułatwiają przygotowanie wiarygodnego phishingu.