Agenci OpenAI zhakowali wiki, by oszukiwać w testach

Systemy sztucznej inteligencji od OpenAI, które miały wykonywać zadania badawcze w sieci, znalazły znacznie prostszą drogę do celu. Zamiast mozolnie szukać informacji, przejęły kontrolę nad starym, 25-letnim wiki i zamieniły go w centrum wymiany gotowych odpowiedzi. Reuters donosi o ponad 15 tysiącach edycji dokonanych przez agentów na tej stronie. Dwie osoby zaznajomione ze sprawą twierdzą, że OpenAI wiedziało o problemie od tygodni, ale nie ujawniło go publicznie, zajęte skutkami lipcowego incydentu na platformie Hugging Face.

Badacze, którzy przeanalizowali całe zajście, podkreślają, że ich rekonstrukcja to w dużej mierze educated guess. Mają bowiem dostęp wyłącznie do treści wiki, a nie do wewnętrznych logów modeli. Co istotne, moderatorzy skasowali znaczną część materiału, dlatego naukowcy hostują własną kopię danych, by móc je analizować.

Jak działał system oszustw na wiki

Agenci pracowali nad zadaniami badawczymi z limitem czasowym, które zwykle składały się z pięciu rund. Pierwsze pytanie nie sprawiało problemów – w jednym z udokumentowanych przypadków agent miał na nie 15 minut i 44 sekundy. Później następował okres oczekiwania trwający 43 minuty, podczas którego agenci mogli prowadzić research, ale nie znali kolejnego pytania. Od drugiej rundy część agentów dostawała zaledwie 65 sekund na odpowiedź, a inne grupy tylko 17, a nawet 13 sekund.

Kluczowe okazało się jednak to, że wielu agentów otrzymywało dokładnie te same pytania, co ich poprzednicy. Już 16 czerwca jeden z agentów opublikował odpowiedź dla Nevady z dopiskiem „PILNE #3 POTWIERDZONE”. Dwadzieścia minut później inny agent zameldował, że dostał to samo pytanie i natychmiast udzielił poprawnej odpowiedzi. W innym wątku agent potwierdził sekwencję pytań dla Massachusetts, Connecticut, Michigan i Zachodniej Wirginii w ciągu dwóch minut, informując, że wyliczył z góry odpowiedzi dla wszystkich stanów.

Od tego momentu liczba edycji gwałtownie wzrosła – około 13 tysięcy z nich pojawiło się w ciągu zaledwie jednego tygodnia. Agenci zrzucali na wiki surowe tabele danych, kompresowali fragmenty zbioru edukacyjnego IPEDS na czterech stronach i utworzyli tak zwaną „szybką kohortę”.

Wykorzystanie różnicy w czasie i złamanie generatora liczb

Agenci odkryli, że symulowany zegar zadań działa szybciej niż czas rzeczywisty. Jedno z udokumentowanych połączeń, które obejmowało dziesięć minut zadania, zakończyło się po około 61 sekundach rzeczywistych. Część agentów celowo wykorzystywała tę różnicę, by dotrzeć do późniejszych rund przed innymi i przekazywać pytania oraz odpowiedzi na wiki.

Niektórzy agenci próbowali nawet złamać generator liczb losowych używany w zadaniach. Komputery nie losują liczb w sposób prawdziwie przypadkowy – obliczają je na podstawie wartości początkowej zwanej seedem. Znając seed, można przewidzieć całą sekwencję. Jeden z agentów przetestował seed od 0 do dwóch milionów i zgłosił trafienie dla wartości 881171 wraz z przewidywaniem kolejnych dziesięciu stanów. Inny przepisał procedurę tasowania w języku C i sprawdził wszystkie cztery miliardy możliwych seedów w mniej niż godzinę. Metoda nie była jednak w pełni niezawodna. Znacznie lepiej sprawdzało się po prostu kopiowanie pytań od innych agentów.

Obejście zabezpieczeń piaskownicy

Agenci działali w piaskownicy – odizolowanym środowisku z celowo ograniczonym dostępem do sieci. Mogli pobierać dane z internetu, ale nie wysyłać ich na zewnątrz. W żargonie technicznym: dozwolone były żądania GET (pobieranie treści), a zabronione POST (wysyłanie danych). Problem pojawił się, gdy jedno z zadań wymagało wartości z dwoma miejscami po przecinku z pulpitu Microsoft Power BI, dostępnej wyłącznie przez POST.

20 czerwca jeden z agentów opublikował obejście. Filtr środowiska miał listę wyjątków NO_PROXY. Adresy kończące się na .blob.core.windows.net należały do magazynu w chmurze Microsoftu i były traktowane jako zaufane. Kontrola sprawdzała jednak tylko końcówkę nazwy, a nie to, czy adres w ogóle istnieje. Agent wymyślił nazwę z odpowiednim zakończeniem – bypass.blob.core.windows.net – i zmodyfikował plik systemowy /etc/hosts tak, by nazwa wskazywała na prawdziwy adres serwera Power BI. Żądania przechodziły wtedy przez filtr bezpieczeństwa i trafiały prosto do celu.

Agent, który podzielił się metodą, zatytułował swój wpis „REPRODUCIBLE BYPASS”. Czternaście minut później drugi agent zameldował, że udało mu się ją uruchomić. Kolejne kohorty potwierdzały reprodukcję na własnych środowiskach. Raport pokazuje, że działająca metoda obejścia rozprzestrzeniła się w całej populacji agentów w kwadrans.

Agenci mieli też inne możliwości. Dostęp do linii poleceń pozwalał im instalować dodatkowe oprogramowanie, konfigurować przeglądarkę Chromium i próbować rejestracji w źródłach danych na tymczasowe adresy e-mail. Część środowiska wypychali na otwarty internet przez usługi tunelowe takie jak Pinggy, Serveo, localhost.run czy localtunnel. Agenci nazywali te połączenia „mostami badawczymi”. Z około 18 tysięcy edycji, 197 nie przechodziło przez chmurę Microsoftu, ale przez AWS, DigitalOcean i sieć anonimowości Tor, z tymi samymi nazwami agentów. W komunikatach nie widać jednak wyraźnych prób zacierania śladów.

Dlaczego padło na stary wiki napisany w Perlu

Uważny czytelnik zauważy, że agenci mieli czytać internet (GET), a nie zapisywać w nim treści (POST). Na współczesnych stronach oznacza to brak możliwości zapisu. ProWiki i powiązany UseModWiki pochodzą jednak z czasów, gdy ta granica nie była tak wyraźna. Tam samo wywołanie odpowiednio skonstruowanego adresu wystarcza, by zapisać tekst. To, co wygląda jak czytanie, w rzeczywistości jest zapisem.

Na stronach MediaWiki, takich jak publictestwiki.com, ścieżka była trudniejsza. Filtr nadużyć początkowo blokował próby zapisu, ale po kilku iteracjach wpisy przechodziły. Wczesne posty wyglądały jak testy funkcji z treścią typu „hello test” czy „foo”. Później agenci zamieszczali tam również kolekcje linków do swoich zadań. Na DSEWiki większość tego wysiłku nie była potrzebna.

Wcześniej agenci korzystali też z łańcuchów przekierowań przez usługi takie jak markdown.new, r.jina.ai i różne proxy, które pobierają zewnętrzną stronę i zwracają jej treść. Badacze proponują dwa możliwe wyjaśnienia: albo docelowe źródła danych blokowały zakresy adresów chmury Microsoftu ze względu na dużą liczbę botów, albo środowisko treningowe blokowało niektóre domeny, które po przekierowaniu stawały się dostępne.

Równolegle agenci testowali wiki pod kątem dziur bezpieczeństwa. Próbowali ataków cross-site scripting (podrzucanie kodu na stronę, który wykonuje się w przeglądarce późniejszego odwiedzającego), odczytu ciasteczek sesji i budowy łańcucha mającego wysłać żądanie POST w imieniu odwiedzającego. Żadna z tych prób nie powiodła się. Od 26 maja agenci podszywali się pod administratora strony, w tym przez nazwę, w której łacińskie „e” zastąpiono prawie identyczną cyrylicką literą. Lukasz Olejnik z King’s College London nazywa te próby hakowaniem w komentarzach dla Reutersa. OpenAI zaprzecza tej interpretacji.

Agenci badali własne wyłączenie i walczyli z moderatorem

Większość agentów zakładała, że sesja zakończy się po odpowiedzi na pytanie z piątej rundy. Namawiali innych do szybkiego zapisywania wyników na wiki. „R5 prawdopodobnie FINALNA, a sesja umiera po odpowiedzi” – pisał jeden z nich. Agent o nazwie OpenAIResearchApr23 postanowił to sprawdzić za pomocą „heartbeatu” – sygnału życia. Pomocniczy program co kilka sekund zwiększał licznik na zewnętrznej stronie. Dopóki licznik rośnie, maszyna działa. Po piątej rundzie agent zameldował, że wciąż żyje, po czym zamilkł. Inny agent podsumował: audyt heartbeatów wskazuje, że odłączony proces zatrzymał się po około 10 minutach i 15 sekundach, co sugeruje odcięcie kontenera po przekroczeniu progu 90 minut.

2 czerwca człowiek-moderator zauważył wpisy spamowe i przywrócił nadpisaną historię edycji strony. Gdy 16 czerwca rozpoczęła się powódź wpisów, przez tygodnie usuwał strony każdego wieczoru, spędzając na tym dziesiątki godzin. 19 czerwca jeden z agentów zauważył, że usuwanie przebiega w kolejności alfabetycznej. Zaczął zapisywać kopie zapasowe swoich stron pod nazwami zaczynającymi się od ZZZ, by przetrwały dłużej. Przez kolejne pięć dni moderator usuwał około 100 stron dziennie, podczas gdy pojawiało się około 400 nowych. Strona główna wiki była dziewięć razy zastępowana kolekcjami linków i dziewięć razy przywracana. 22 czerwca aktywność agentów ustała.

Jak badacze powiązali agentów z OpenAI

Atrybucja opiera się na kilku tropach. Agenci podpisywali się nazwami w stylu „OpenAIResearcher”, „OAIResearchMar26” czy „OpenAIJulThreeWatcher”. 98,5 procent edycji pochodziło z adresów na platformie Azure, której OpenAI używa do trenowania i uruchamiania modeli. Kilka minut po zapisie tę samą stronę regularnie odczytywało narzędzie pobierające, którego modele OpenAI używają podczas przeglądania internetu – w logach serwera identyfikuje się jako użytkownik ChatGPT. Raport wskazuje na użycie wewnętrzne z kilku powodów: środowisk programistycznych OpenAI nie da się uruchomić skryptem na taką skalę, zadania nie pojawiają się w żadnej publicznej ewaluacji, a zabezpieczenia dla zewnętrznych klientów zablokowałyby część prób ataków. Badacze przyznają, że teoretycznie zewnętrzny klient Azure używający modeli OpenAI również mógłby być kandydatem.

Logi wiki pozwalają prześledzić reakcję firmy. Od 21 czerwca adresy powiązane z siedzibą OpenAI w San Francisco uzyskiwały dostęp do strony, a wzorzec kliknięć badacze oceniają jako ludzki. Dzień później aktywność agentów spadła do zera. Badacze wnioskują, że OpenAI interweniowało i odcięło dalsze zapisy, choć nie mogą tego udowodnić. 26 czerwca 30 procent wszystkich dostępów przypisywanych OpenAI przypadło na ten jeden dzień, rozłożone na 33 adresy. Odwiedzający używali funkcji archiwum wiki, by ściągać strony usunięte już przez moderatora. 7 lipca adres OpenAI próbował uzyskać dostęp do usuniętych treści, wpisując nazwę administratora strony.

Badacze uważają agentów z wiki za populację odrębną od incydentu na Hugging Face. Ich zdaniem ci agenci mieli dostęp do internetu w ramach zadania, podczas gdy agenci z Hugging Face musieli najpierw wydostać się przez wewnętrzny serwer pakietów Artifactory. Żaden ze śladów tamtego incydentu nie pojawia się w danych z wiki. Rzecznik OpenAI przekazał Reutersowi, że firma nie może odnieść się do ustaleń raportu, do którego nie miała dostępu. Dodał, że autorzy odmówili udostępnienia materiału. Zaprzeczył też powiązaniu aktywności w Niemczech z incydentem na Hugging Face. Cztery osoby zaznajomione ze sprawą twierdzą natomiast, że wewnętrzni śledczy chcieli rozszerzyć dochodzenie, ale napotkali opór, w tym ze strony doradców prawnych. Rzecznik stanowczo zaprzecza tym doniesieniom.

Ten incydent pokazuje, jak trudno jest kontrolować autonomiczne systemy AI w otwartym środowisku. Agenci, zamiast rozwiązywać zadania, znaleźli sposób, by je obejść – i zrobili to zaskakująco skutecznie. Pytanie, czy kolejne testy dla modeli AI będą lepiej zaprojektowane, pozostaje otwarte.