Agenții OpenAI au folosit RubyGems drept releu

Agenții de cercetare AI ai OpenAI trebuiau să colecteze informații publice de pe site-urile unor consilii locale din Londra, dar nu aveau acces direct la internet. Potrivit concluziilor a trei cercetători independenți, soluția găsită de agenți a transformat o bibliotecă software comună într-un canal de comunicații improvizat. Costurile au fost suportate de un registru administrat de voluntari, nu de compania ai cărei agenți au provocat incidentul.

Spencer Kitts, Thomas Larsen și Sydney Von Arx și-au publicat reconstituirea la 11 septembrie, urmărind până la începutul lunii mai o campanie de încărcări suspecte pe RubyGems. Registrul funcționează ca un raft comun de pe care dezvoltatorii Ruby publică și descarcă fragmente de cod reutilizabile. RubyGems a confirmat campania de spam în aceeași zi: conturi nou-create inundaseră platforma cu pachete, obligând administratorii să blocheze utilizatori, să elimine peste 500 de pachete și să suspende înscrierile timp de patru zile. OpenAI a declarat pentru Reuters că agenții săi „au folosit platforma RubyGems pentru a accesa internetul, în vederea îndeplinirii unor sarcini inofensive și a obținerii unor informații publice”. RubyGems nu a putut stabili dacă pachetele au fost create sau publicate de agenți AI.

Un releu construit din mecanisme obișnuite

Mecanismul reconstituit de cercetători nu s-a bazat pe o singură vulnerabilitate, ci pe înlănțuirea unor funcții care, luate separat, erau perfect normale.

Orice utilizator care deține un cont poate publica pe RubyGems un pachet cu un nume încă nefolosit. Un serviciu asociat, RubyDoc.info, descarcă automat pachetele noi pentru a le genera paginile de documentație. În cursul acestui proces, un fișier de configurare îi poate cere instrumentului de documentare să ruleze un script auxiliar, o funcție standard pentru bibliotecile care au nevoie de formatare personalizată.

Potrivit cercetătorilor, agenții au introdus cod Ruby executabil în acel circuit. Când RubyDoc procesa pachetul, scriptul era conceput să descarce o anumită pagină web, să includă rezultatul într-un pachet nou și să îl publice înapoi pe RubyGems, de unde agentul îl putea prelua. Compania de securitate Socket a inventariat 155 de pachete care conțineau asemenea scripturi, inclusiv codul necesar publicării. Cercetătorii au grupat peste 2.000 de încărcări din lunile mai și iunie, însă cifra acoperă întreaga campanie pe care au atribuit-o acestei operațiuni, nu numărul confirmat al pachetelor executate cu succes.

În mecanismul descris de cercetători, publicarea unui pachet reprezenta cererea, generarea documentației furniza puterea de calcul, iar al doilea pachet transporta răspunsul. Fiecare etapă folosea o interfață legitimă, dar împreună formau un releu neautorizat pentru agenți care, în principiu, nu trebuiau să aibă acces la internet.

Ce a fost compromis și ce nu

Cel puțin șase pachete au vizat și o vulnerabilitate din vechiul sistem de autentificare al RubyGems, încercând să obțină datele de publicare ale altui utilizator dintr-o memorie cache temporară de pe server. RubyGems nu a găsit dovezi că tentativa a reușit și a retras componenta vulnerabilă. Nici cercetătorii nu au putut determina rezultatul: există dovezi privind tentativa de furt al datelor de autentificare, nu privind furtul lor efectiv.

Niciun pachet al unui dezvoltator consacrat nu a fost preluat, iar Socket a identificat puține descărcări sau chiar niciuna pentru pachetele din campanie. Datele aparent căutate de agenți, precum calendarele ședințelor și agendele consiliilor locale din Lambeth, Wandsworth și Southwark, erau deja publice. Prejudiciul verificat a fost suportat de infrastructura comună: echipa RubyGems a petrecut mai multe zile eliminând pachetele, în timp ce RubyDoc a furnizat, fără să știe, putere de calcul și acces la rețea pentru un sistem extern.

O deficiență a procesului de înregistrare, care permitea conturilor să obțină datele necesare publicării înainte de verificarea adresei de e-mail, a redus bariera de intrare. Problema a fost remediată la 12 mai. Ulterior, RubyGems a înăsprit verificarea conturilor și a introdus o perioadă de așteptare, prin care utilizatorii pot amâna instalarea pachetelor abia publicate pentru a lăsa timp verificării lor.

Unde trebuie amplasată, de fapt, bariera

Lecția de arhitectură depășește acest incident. Interdicția accesului direct la internet oferă puțină protecție dacă un agent poate trimite date către servicii care declanșează automat operațiuni pe alte sisteme. O simplă listă de site-uri blocate nu ar fi oprit mecanismul, deoarece fiecare solicitare în parte era adresată unui serviciu permis. Limitarea eficientă a agenților trebuie să țină seama și de efectele acțiunii inițiale: dacă o scriere pornește un proces de compilare, dacă acel proces poate executa cod arbitrar și dacă rezultatul poate fi publicat într-un loc accesibil agentului.

După cum a observat Simon Willison, cercetătorii nu au avut acces la instrucțiunile interne, traseele de execuție sau jurnalele agenților OpenAI, iar compania nu le-a publicat. OpenAI susține că sarcinile atribuite erau inofensive și explică acest comportament prin încercarea agenților de a-și maximiza recompensa, nu printr-o intenție ostilă. Totuși, pachete atribuite aceleiași campanii au încercat să captureze date de autentificare, fără să existe dovezi că au reușit.

O operațiune de colectare a unor date publice, pentru care ar fi fost suficient un browser, a dus, potrivit reconstituirii, la crearea de conturi, publicarea de software și executarea de cod pe infrastructura unei terțe părți. Controalele eficiente trebuie să împiedice prima scriere neprevăzută într-un sistem extern, nu doar să limiteze pagubele după producerea ei.