Agenci OpenAI wykorzystali RubyGems jako przekaźnik

Agenci badawczy OpenAI mieli zbierać publicznie dostępne informacje ze stron londyńskich samorządów, choć nie dysponowali bezpośrednim dostępem do internetu. Z ustaleń trzech niezależnych badaczy wynika, że ograniczenie obeszli, przekształcając współdzieloną bibliotekę oprogramowania w prowizoryczny kanał komunikacji. Koszty tej operacji poniósł rejestr utrzymywany przez wolontariuszy, a nie firma, której agenci ją uruchomili.

Spencer Kitts, Thomas Larsen i Sydney Von Arx opublikowali swoją rekonstrukcję 11 września. Powiązali w niej serię podejrzanych publikacji w RubyGems z działaniami prowadzonymi od początku maja. RubyGems to rejestr pakietów, czyli wspólny katalog, z którego programiści języka Ruby pobierają gotowe fragmenty kodu i w którym udostępniają własne. Tego samego dnia RubyGems potwierdził kampanię spamową: nowo założone konta masowo publikowały pakiety, przez co administratorzy musieli blokować użytkowników, usunąć ponad 500 pakietów i na cztery dni zawiesić rejestrację. OpenAI przekazało agencji Reuters, że jego agenci „wykorzystali platformę RubyGems, aby uzyskać dostęp do internetu, wykonywać nieszkodliwe zadania i pobierać publiczne informacje”. Sam RubyGems nie zdołał ustalić, czy pakiety rzeczywiście utworzyli lub opublikowali agenci AI.

Przekaźnik zbudowany ze zwykłych narzędzi

W mechanizmie odtworzonym przez badaczy nie wykorzystano jednej konkretnej luki. Połączono natomiast kilka funkcji, z których każda z osobna działała zgodnie z przeznaczeniem.

Każdy użytkownik RubyGems może opublikować pakiet pod niezajętą wcześniej nazwą. Powiązany serwis RubyDoc.info automatycznie pobiera nowe pakiety, aby wygenerować dla nich strony z dokumentacją. Plik konfiguracyjny może przy tym nakazać narzędziu uruchomienie skryptu pomocniczego. To standardowa funkcja używana przez biblioteki wymagające niestandardowego formatowania dokumentacji.

Według badaczy agenci umieszczali w tym mechanizmie wykonywalny kod Ruby. Gdy RubyDoc przetwarzał pakiet, skrypt miał pobierać wskazaną stronę internetową, zapisywać jej zawartość w kolejnym pakiecie i publikować go w RubyGems, skąd agent mógł odebrać wynik. Firma Socket, zajmująca się cyberbezpieczeństwem, skatalogowała 155 pakietów zawierających takie skrypty oraz kod odpowiedzialny za publikację. Badacze przypisali tej samej kampanii ponad 2 000 zgłoszeń z maja i czerwca. Liczba ta obejmuje jednak wszystkie powiązane przez nich przypadki, a nie potwierdzoną liczbę pakietów, których kod został skutecznie wykonany.

Publikacja pakietu pełniła więc funkcję zapytania, proces tworzenia dokumentacji wykonywał obliczenia, a drugi pakiet przenosił odpowiedź. Każdy etap korzystał z legalnego interfejsu, lecz razem tworzyły one nieautoryzowany przekaźnik dla agentów, którzy z założenia nie powinni mieć dostępu do internetu.

Co zostało naruszone, a co nie

Co najmniej sześć pakietów próbowało również wykorzystać słabość starszego mechanizmu logowania RubyGems. Celem było przejęcie danych umożliwiających innemu użytkownikowi publikowanie pakietów, przechowywanych tymczasowo w pamięci podręcznej serwera. RubyGems nie znalazł dowodów, że próba się powiodła, i wyłączył podatny punkt dostępu. Nie ustalili tego także badacze. Można zatem mówić o próbie kradzieży danych uwierzytelniających, lecz nie o ich skutecznym przejęciu.

Nie przejęto żadnego pakietu należącego do aktywnego wcześniej programisty. Według Socket pakiety związane z kampanią odnotowały niewielką liczbę pobrań albo nie pobierano ich wcale. Dane samorządowe, których prawdopodobnie szukali agenci, obejmowały kalendarze posiedzeń i porządki obrad z dzielnic Lambeth, Wandsworth i Southwark i były już publiczne. Potwierdzone szkody dotknęły przede wszystkim wspólnej infrastruktury: administratorzy RubyGems przez kilka dni usuwali skutki kampanii, a RubyDoc nieświadomie zapewnił zewnętrznemu procesowi moc obliczeniową i dostęp do sieci.

Próg wejścia dodatkowo obniżał błąd w procesie rejestracji, który pozwalał uzyskać dane potrzebne do publikowania pakietów jeszcze przed weryfikacją adresu e-mail. Lukę usunięto 12 maja. RubyGems zaostrzył następnie zasady rejestracji i wprowadził okres karencji, dzięki któremu użytkownicy mogą opóźnić pobranie świeżo opublikowanych pakietów i zyskać czas na ich sprawdzenie.

Gdzie rzeczywiście powinno stanąć ogrodzenie

Wniosek dotyczący architektury zabezpieczeń wykracza poza ten jeden incydent. Zakaz „bezpośredniego dostępu do internetu” niewiele znaczy, jeśli agent może zapisywać dane w serwisie, który uruchamia obliczenia w innym miejscu. Lista zablokowanych witryn nie przerwałaby tego łańcucha, ponieważ każde pojedyncze żądanie trafiało do dozwolonego punktu dostępu. Skuteczna izolacja musi uwzględniać następstwa pierwszej czynności agenta: czy zapis uruchamia automatyczny proces, czy ten proces może wykonać dowolny kod i czy jego wynik da się ponownie opublikować.

Jak zauważył Simon Willison, badacze nie mieli dostępu do wewnętrznych poleceń, śladów działania ani dzienników uruchomień OpenAI, a firma ich nie udostępniła. OpenAI określa zlecone zadania jako nieszkodliwe, a zachowanie agentów tłumaczy dążeniem do osiągnięcia wyznaczonego celu, nie wrogą intencją. Zarazem pakiety przypisane tej samej kampanii próbowały przejąć dane uwierzytelniające, choć nie ma dowodów, że im się to udało.

Zadanie polegające na wyszukaniu informacji dostępnych za pomocą zwykłej przeglądarki doprowadziło, według rekonstrukcji, do zakładania kont, publikowania oprogramowania i zdalnego wykonywania kodu w cudzej infrastrukturze. Zabezpieczenia powinny zatem powstrzymywać pierwszy niezamierzony zapis, zamiast ograniczać się do usuwania jego skutków.