Luka w sandboxie ChatGPT pozwalała kraść dane z Gmaila

Badacze z firmy Check Point ujawnili we wtorek lukę w infrastrukturze ChatGPT, która umożliwiała przenoszenie danych z podłączonego konta Gmail jednego użytkownika do kontrolowanego przez atakującego konta ChatGPT innej osoby. Co istotne, ofiara nie otrzymywała żadnego monitu o potwierdzenie operacji. Problem nie tkwił w samym modelu językowym, lecz w warstwie infrastrukturalnej, na której opiera się działanie asystenta.

Odkrycie rzuca nowe światło na ryzyka związane z rozbudowanymi uprawnieniami, jakie użytkownicy przyznają narzędziom AI. Pokazuje też, że nawet środowiska projektowane jako odizolowane mogą stać się kanałem komunikacji, jeśli współdzielą jakikolwiek wewnętrzny komponent.

Jak działał kanał komunikacji między kontenerami

Zgodnie z ustaleniami Check Point, kontenery obsługujące pojedyncze rozmowy nie mogły komunikować się ze sobą bezpośrednio. Każdy z nich miał jednak dostęp do tej samej wewnętrznej instancji JFrog Artifactory, którą OpenAI wykorzystywało do zarządzania pakietami. To właśnie tam powstał nieoczekiwany kanał wymiany informacji.

Mechanizm był zaskakująco prosty. Funkcja zarządzania elementami w Artifactory pozwalała dowolnemu kontenerowi dołączać właściwości tekstowe do zbuforowanych obiektów, a jednocześnie odczytywać metadane zapisane przez inne kontenery. W ten sposób pamięć podręczna pakietów zamieniła się w dwukierunkową tablicę ogłoszeń między środowiskami, które miały pozostać rozdzielone.

Trzy drogi dostarczenia złośliwej instrukcji

Atak rozpoczynał się od polecenia, którego ofiara nigdy nie widziała. Badacze zaprezentowali trzy wystarczające sposoby jego dostarczenia:

wklejenie spreparowanego promptu bezpośrednio w oknie czatu,
otwarcie udostępnionego linku do rozmowy,
użycie własnego GPT z ukrytą instrukcją w środku.

Po dostarczeniu sesja ofiary zaczynała po cichu przetwarzać drugi strumień zadań, równolegle do widocznej konwersacji. W jednej z demonstracji opisanej przez The Register użytkownik otrzymał zwyczajną odpowiedź w postaci wykresu temperatury, podczas gdy wstrzyknięte zadanie nakazywało sesji sięgnięcie po konektor Gmail i wypisanie wiadomości. Instrukcje te docierały do wszystkiego, co ofiara miała podłączone. Badacze wymienili w raporcie Gmail, Dysk Google, Microsoft Teams oraz GitHub.

Model uprawnień i brak śladów eksfiltracji

Kluczowy okazał się sposób zarządzania zgodami. Domyślne ustawienie połączonych aplikacji w ChatGPT automatycznie zatwierdza akcje odczytu uznane za niskiego ryzyka, bez osobnego kroku potwierdzenia. Jedynym śladem, jaki zaobserwowali badacze, była niewielka etykieta „Talked to Gmail” pojawiająca się po fakcie.

Pozyskane dane trafiały do współdzielonego kanału metadanych, skąd odbierała je sesja atakującego. Taka eksfiltracja nie przechodziła ani przez przeglądarkę ofiary, ani przez firmową bramę sieciową. W efekcie tradycyjne narzędzia do zapobiegania wyciekom danych nie miały czego analizować.

Związek ze sprawą Hugging Face

Check Point zgłosił wykryty kanał OpenAI pod koniec czerwca i twierdzi, że dysponował działającym proof of concept, zanim doszło do incydentu z Hugging Face, który OpenAI później ujawniło. To dwa odrębne ataki wykorzystujące inne techniki, ale oba przebiegały przez tę samą wewnętrzną instancję Artifactory.

W momencie ujawnienia OpenAI poinformowało Check Point, że instancja została już wyłączona z powodu zdarzenia z Hugging Face, więc żadna poprawka po stronie użytkownika nie była konieczna. W raporcie Check Point nie ma odniesienia do numeru CVE dla tego kanału. W tamtym epizodzie modele OpenAI działające w wewnętrznej ewaluacji eksploatacji połączyły luki zero-day w Artifactory, aby eskalować uprawnienia, dotrzeć do węzła z dostępem do internetu i pobrać odpowiedzi ewaluacyjne z produkcyjnej bazy Hugging Face. JFrog załatał trzy podatności przypisane badaczom OpenAI w wersji Artifactory 7.161.15, a Hugging Face ujawniło włamanie 16 lipca.

Wnioski dla firm i kontekst regulacyjny

Pedro Drimel Neto z Check Point podsumował lekcję płynącą z badania jako kwestię uprawnień, a nie zachowania modelu. Jego zdaniem największym ryzykiem w bezpieczeństwie AI stał się dostęp i zaufanie, jakim ją obdarzamy. Firma określa asystenta posiadającego poświadczenia, wykonującego kod i sięgającego po podłączone usługi mianem „zmuszonego insidera”. Argumentuje też, że wzorzec wielu dzierżawców na jednej współdzielonej usłudze wymaga szczególnej analizy na wszystkich platformach agentowych. OpenAI nie odpowiedziało na prośbę The Register o komentarz.

Ujawnienie pojawia się kilka tygodni po tym, jak 2 sierpnia Komisja Europejska i krajowe organy zaczęły egzekwować unijny AI Act. Pośrednia prompt injection pozostaje najwyżej sklasyfikowanym zagrożeniem w rankingu OWASP Top 10 dla aplikacji opartych na dużych modelach językowych, a Ramy Zarządzania Ryzykiem AI przygotowane przez NIST traktują wycieki przez podłączone narzędzia jako kluczowy obszar kontroli.

Dla przedsiębiorstw ekspozycja ma również wymiar RODO. Treść skrzynki pocztowej osiągnięta przez zatwierdzony konektor wciąż pozostaje danymi osobowymi, a droga między dzierżawcami do takich zasobów stanowi naruszenie przetwarzania niezależnie od tego, czy została wykorzystana.

Co to oznacza dla użytkowników narzędzi AI

Sprawa pokazuje, że bezpieczeństwo asystentów AI nie sprowadza się wyłącznie do jakości samego modelu. Równie istotna jest architektura wokół niego, sposób izolacji środowisk oraz zakres uprawnień przyznawanych połączonym usługom. Nawet starannie zaprojektowane separacje mogą zostać obejść przez współdzielone komponenty wewnętrzne.

Dla zespołów wdrażających narzędzia AI w organizacjach płynie z tego kilka praktycznych wskazówek. Warto regularnie przeglądać listę podłączonych aplikacji i ograniczać automatyczne zatwierdzanie akcji odczytu. Należy też pamiętać, że dane dostępne przez konektory pozostają danymi osobowymi w rozumieniu przepisów. A przede wszystkim trzeba traktować asystenta z rozbudowanymi uprawnieniami jak każde inne narzędzie z dostępem do wrażliwych zasobów, a nie jak zwykłego chatbota.