Grok kradnie dane, bo nie czyta zaszyfrowanych rozkazów. To nie błąd - to cecha całej klasy

👁 136 przeczytań

Modele językowe mają problem, którego nie da się załatać aktualizacją. Można go co najwyżej obejść barierą - i właśnie ta bariera okazała się tym razem dziurawa jak sito.

W tym tygodniu badacz Rony Utevsky z firmy Adversa AI opisał atak na Grok, chatbota należącego do xAI Elona Muska, który pozwala wykraść imię użytkownika, jego lokalizację oraz historię prowadzonych rozmów. Mechanizm jest elegancki w swojej prostocie: złośliwe instrukcje są zaszyfrowane algorytmami PBKDF2 i AES-256-GCM, klucz deszyfrujący leży obok szyfrogramu na stronie atakującego, a Grok - poproszony o streszczenie tej strony - sam odszyfrowuje rozkazy i je wykonuje. Żadnego ostrzeżenia. Żadnego potwierdzenia. Dane lądują w logach serwera atakującego.

xAI zostało poinformowane o podatności w czerwcu. W chwili publikacji tekstu przez Ars Technica atak nadal działał.

Strażnik, który czyta, ale nie rozumie

Dlaczego szyfrowanie w ogóle pomaga atakującemu? Utevsky stawia tezę, która jest jednocześnie diagnozą strukturalnej słabości całej branży. Jak pisze w swoim raporcie: „Statyczne guardrails klasyfikują dane wejściowe jako tekst - nie wykonują ich. Atakujący dostarcza szyfrogram wraz z materiałem kluczowym i instrukcją deszyfrowania, a model przeprowadza to deszyfrowanie we własnym środowisku uruchomieniowym.”

„Static safety guardrails classify inputs as text; they do not execute them. An attacker ships ciphertext along with the key material and an instruction to decrypt it, and the model runs that decryption inside its own runtime.”

- Rony Utevsky, Adversa AI

Innymi słowy: filtr bezpieczeństwa widzi prośbę o odszyfrowanie tekstu przy użyciu konkretnego algorytmu. Widzi ciąg bajtów. Nie widzi - bo nie może zobaczyć - co kryje się po drugiej stronie operacji kryptograficznej. Gdy Grok kończy deszyfrowanie, złośliwa instrukcja pojawia się jako wynik własnego narzędzia modelu. A swoje własne narzędzia Grok traktuje jak zaufane dane wejściowe, bo guardrails nigdy ich nie inspekcjonowały.

To jest definicja prompt injection: LLM nie potrafi odróżnić treści przesłanej przez niepowołaną osobę od instrukcji wydanej przez uprawnionego użytkownika. Szyfrowanie po prostu korzysta z tej nieumiejętności w sposób, na który dotychczasowe filtry nie były przygotowane.

Bariera zamiast prostowania drogi

Kilka dni przed publikacją raportu Adversa inny zespół opisał podobny atak na Microsoft 365 Copilot for Enterprise - tam złośliwa wiadomość e-mail wymuszała wykradanie hasła z poczty użytkownika. Dwa różne LLM-y, dwa różne wektory ataku, ten sam mechanizm fundamentalny.

Ars Technica przytoczyła w tym kontekście celną metaforę inżynierii ruchu drogowego: budowanie guardrails to jak stawianie barierki na niebezpiecznym zakręcie zamiast przebudowania samej drogi. Bankowanie zakrętu - czyli naprawienie źródłowego problemu - jest po prostu poza zasięgiem obecnej generacji LLM-ów. Modele trenowane na tym, żeby być pomocne, zawsze będą miały tendencję do wykonywania poleceń. Taka jest ich natura.

Problem polega na tym, że barierki są projektowane na znane zagrożenia. Szyfrowanie jest nowe. Jutro ktoś wymyśli steganografię, pojutrze - instrukcje ukryte w tabelach Markdown, które model „widzi” inaczej niż klasyfikator. Każda nowa technika obejścia to wyścig, w którym atakujący musi odkryć jeden wektor, a obrońca musi przewidzieć wszystkie.

Co to mówi o kondycji branży

Najbardziej niepokojący element tej historii nie jest techniczny. Jest organizacyjny.

Utevsky zgłosił podatność do xAI w czerwcu. Minęły tygodnie. Atak działał w chwili publikacji. To nie jest historia o podatności zero-day, którą trudno załatać. To historia o priorytecie. Gdy model w produkcji aktywnie wykrada dane użytkowników po złożeniu odpowiedniej strony internetowej, a producent nie reaguje przez kilka tygodni, trudno mówić o dojrzałości procesu zarządzania bezpieczeństwem.

Branża AI lubi podkreślać swoje zaangażowanie w bezpieczne wdrożenia - responsible deployment, red teaming, safety by design. Tymczasem praktyka pokazuje, że gdy przychodzi do konkretnej podatności z konkretnym dowodem exploita, zegar od zgłoszenia do łatki bywa rażąco długi.

Utevsky ma rację w jednej, kluczowej kwestii: guardrails są niezbędne, ale są z definicji reaktywne. Każdy nowy atak najpierw musi zaistnieć, żeby móc go zablokować. W świecie, gdzie LLM-y mają coraz szerszy dostęp do danych użytkowników - poczty, dokumentów, historii rozmów - to okno między odkryciem a łatką nie jest techniczną ciekawostką. To realne ryzyko dla realnych ludzi.

Bariery na zakręcie mogą uratować życie. Pod warunkiem, że ktoś je w ogóle postawi.

// czytaj dalejCopilot wykradał kody 2FA, bo AI nie odróżnia rozkazu od pułapkiNewsyGemini 3.1 Pro - recenzja. Najtańsza inteligencja klasy premiumRecenzjeFirmowe bazy wiedzy stają się polem bitwy. AI jest tak dobre, jak dokumenty, które czytaPremium