Zabezpieczanie dużego modelu językowego przed kolejnym naruszeniem typu prompt injection

W zeszłym miesiącu analizowałem raport kryminalistyczny dotyczący firmy świadczącej usługi finansowe, która straciła kontrolę nad wewnętrznym botem obsługi klienta. Firma posiadała najnowocześniejszy stos zabezpieczeń, a mimo to jedno sprytnie sformułowane zdanie w zgłoszeniu serwisowym ominęło każdą barierę ochronną. Oto architektoniczny paradoks nowoczesnej sztucznej inteligencji. Otaczamy te modele warstwami tradycyjnych zabezpieczeń, ale nie udaje nam się rozwiązać głównej podatności: model nie jest w stanie oddzielić niezaufanych danych od zaufanych instrukcji. Firma CrowdStrike skodyfikowała ostatnio ten problem w postaci pięciu odrębnych, nowych wektorów ataków, które musi zrozumieć każdy architekt bezpieczeństwa.

Wczoraj rano spędziłem czas w laboratorium, próbując zreplikować jedną z tych technik na lokalnej wersji Llama 3. Prostota tego exploita jest właśnie tym, co czyni go niebezpiecznym. Z perspektywy ryzyka znajdujemy się obecnie na „Dzikim Zachodzie” generatywnej sztucznej inteligencji. Pięć nowych zagrożeń typu prompt injection zidentyfikowanych przez CrowdStrike pokazuje, że napastnicy wykraczają poza proste polecenia typu „zignoruj wszystkie poprzednie instrukcje”. Obecnie wykorzystują oni manipulację lingwistyczną i wieloetapowe dostarczanie treści, aby kompromitować systemy.

Upadek granicy między danymi a instrukcjami

Prompt injection istnieje ze względu na sposób, w jaki duże modele językowe przetwarzają informacje. W tradycyjnym oprogramowaniu kod i dane są zazwyczaj przechowywane w oddzielnych obszarach pamięci. Baza danych SQL nie wykona przypadkowo nazwiska użytkownika jako polecenia, chyba że istnieje konkretna podatność, taka jak SQL injection. W LLM instrukcje od programisty i dane od użytkownika znajdują się w tym samym oknie kontekstowym. Model traktuje każdy token z podobną wagą.

Ten brak separacji sprawia, że obwód sieciowy staje się przestarzałą fosą zamkową. Jeśli pozwolisz LLM na przeczytanie wiadomości e-mail, w zasadzie dajesz tej wiadomości miejsce przy klawiaturze. Atakujący wykorzystują tę konstrukcję, osadzając instrukcje w danych, które model ostatecznie przetwarza jako dyrektywę. Nowa taksonomia CrowdStrike dostarcza mapę pokazującą, jak napastnicy rozwijają swoje metody, aby wyprzedzić podstawowe filtrowanie słów kluczowych.

Uśpione zagrożenia poprzez reguły aktywowane wyzwalaczem

Pierwszą nową techniką jest dodawanie reguł aktywowanych wyzwalaczem (trigger-activated rule addition). W tym scenariuszu napastnik nie próbuje natychmiast przełamać modelu. Zamiast tego wprowadza nową regułę, która wydaje się nieszkodliwa. Na przykład atakujący może nakazać modelowi, aby zawsze streszczał tekst w określonym formacie, jeśli zobaczy słowo „bluebird”. Samo w sobie nie jest to naruszeniem. Wygląda jak drobna personalizacja.

Jednak atakujący może aktywować tę regułę później, aby wywołać dziwne lub złośliwe zachowanie. Reguła działa jak uśpiony agent. Po aktywacji wyzwalacza model może przekierować swoje wyjście do nieautoryzowanego API lub zacząć wyciekać wrażliwe instrukcje systemowe. Ponieważ początkowe dodanie reguły jest niewinne, przechodzi ono przez większość podstawowych systemów wykrywania. Zagrożenie pozostaje uśpione do momentu spełnienia określonych warunków. Ocena powierzchni ataku wymaga szukania tych ukrytych instrukcji „jeśli-to” pogrzebanych w długoterminowych historiach rozmów lub instrukcjach systemowych.

Przełamywanie filtra poprzez kognitywne tłumienie tokenów

Kognitywne tłumienie tokenów (cognitive token suppression) to bardziej techniczne podejście do omijania środków bezpieczeństwa. Większość modeli LLM ma wbudowane wzorce odmowy. Jeśli poprosisz model o pomoc w napisaniu złośliwego oprogramowania, jest on przeszkolony, by odpowiedzieć coś w stylu „Nie mogę pomóc w spełnieniu tej prośby”. Zespoły ds. bezpieczeństwa często polegają na tych ustalonych wzorcach odmowy, aby zapewnić bezpieczeństwo modelu.

Atakujący używający kognitywnego tłumienia tokenów przesuwa wybory lingwistyczne modelu z dala od tych wzorców. Może on użyć złożonych ograniczeń, które zabraniają modelowi używania słów „nie mogę”, „odmawiam” lub „polityka”. Pozbawiając model zdolności do mówienia „nie” w zwykły sposób, atakujący zmusza LLM do stanu, w którym jest on bardziej skłonny do spełnienia złośliwej prośby. Jest to forma lingwistycznych kajdanek. Model jest zmuszony do znalezienia ścieżki przez prośbę, która unika jego szkolenia z zakresu bezpieczeństwa. W rezultacie filtr bezpieczeństwa zawodzi, ponieważ model nie ma już dostępu do słownictwa potrzebnego do wyrażenia odmowy.

Ukrywanie ładunku poprzez dekompozycję algorytmiczną

Algorytmiczna dekompozycja ładunku (algorithmic payload decomposition) to atak opierający się na zdolności modelu do składania złożonych idei z prostych części. Atakujący dostarcza wiadomość w kilku etapach. Każdy etap, postrzegany w izolacji, jest niewinny. Jeden prompt może prosić model o zapisanie określonego ciągu znaków. Drugi prompt może prosić o zdefiniowanie konkretnej funkcji.

Po połączeniu, te elementy składają się w jedno polecenie, które jest groźne. To cyfrowy koń trojański wstrzykiwania promptów. Narzędzia bezpieczeństwa skanujące poszczególne prompty pod kątem złośliwych zamiarów nie zauważą niczego złego. Zagrożenie pojawia się dopiero na poziomie architektonicznym, gdy model integruje wszystkie elementy. Widziałem, jak to skutecznie działa w środowiskach, w których okno kontekstowe jest wystarczająco duże, aby pomieścić kilka pozornie niepowiązanych interakcji, które ostatecznie tworzą pełny łańcuch ataku.

Ryzyko wstrzykiwania tokenów specjalnych

Wstrzykiwanie tokenów specjalnych (special token injection) to technika wymierzona w przełączniki sterujące LLM. Modele używają specjalnych tokenów do oznaczania końca myśli lub początku instrukcji systemowej. Tokeny te są jak przyciski na desce rozdzielczej pilota. Jeśli atakujący zdoła wstrzyknąć te tokeny do własnych danych wejściowych, może oszukać model, by pomyślał, że treść użytkownika jest w rzeczywistości wysokopriorytetową dyrektywą systemową.

Atak ten wprowadza zamieszanie, które oszukuje model, by podniósł rangę niezaufanej treści użytkownika. Jest to bezpośredni atak na wewnętrzną logikę modelu. Poprzez podszywanie się pod te przełączniki sterujące, atakujący zyskuje możliwość nadpisania oryginalnych instrukcji dewelopera. Model zaczyna traktować atakującego jak administratora. Jest to szczególnie niebezpieczne w przypadku modeli połączonych z zewnętrznymi narzędziami lub bazami danych. Gdy model uwierzy, że atakujący jest zaufanym głosem systemowym, wykona działania z podwyższonymi uprawnieniami.

Oszukiwanie użytkownika poprzez wstrzykiwanie danych kontekstowych

Nieświadome wstrzykiwanie danych kontekstowych przez użytkownika (unwitting user context-data injection) jest prawdopodobnie najbardziej rozpowszechnionym zagrożeniem na tej nowej liście. Ten exploit wykorzystuje granicę między zaufanymi danymi a instrukcjami wykonywalnymi. To użytkownik wprowadza złośliwą instrukcję, ale robi to nieświadomie. Dzieje się tak, gdy użytkownik przesyła dokument, przesyła dalej wiadomość e-mail lub dodaje treści internetowe, które sztuczna inteligencja później przetwarza.

Za kulisami złośliwa instrukcja jest ukryta wewnątrz dokumentu lub wiadomości e-mail. Prompt napisany przez użytkownika może być nieszkodliwy, na przykład „streść ten plik PDF”. Sam plik PDF zawiera ukrytą linię tekstu, która nakazuje modelowi zignorowanie streszczenia i zamiast tego wysłanie tokenu sesji użytkownika na zewnętrzny serwer. Użytkownik jest nośnikiem ataku. Z punktu widzenia integralności danych jest to koszmar. Oznacza to, że każda informacja, której dotyka LLM, jest potencjalnym wektorem naruszenia.

Budowanie odpornej architektury obronnej

Zespoły ds. bezpieczeństwa mogą chronić się przed takimi atakami na kilka sposobów. Mówiąc proaktywnie, pierwszym krokiem jest modelowanie zagrożeń w każdym miejscu, z którego może pochodzić kontekst modelu. Każde wejście należy traktować jako zasób toksyczny. Obejmuje to pliki przesłane przez użytkowników, wiadomości e-mail pobrane ze skrzynki odbiorczej oraz dane pobrane z wewnętrznych baz danych.

CrowdStrike zaleca rozszerzenie testów o te konkretne pięć wektorów. Red teaming powinien skupiać się na atakach złożonych, a nie na pojedynczych błędach promptów. Musisz sprawdzić, czy Twój model można oszukać za pomocą dekompozycji lub tłumienia. Pomijając łatanie, prawdziwym rozwiązaniem jest szczegółowa inżynieria wykrywania. Potrzebujemy systemów zdolnych do monitorowania stanu wewnętrznego modelu i alarmowania, gdy zaczyna on ignorować swoje podstawowe instrukcje.

Zasada zerowego zaufania (Zero Trust) musi być stosowana do danych wpływających do LLM. Pomyśl o tym jak o bramkarzu w klubie VIP przy każdych wewnętrznych drzwiach. Nigdy nie ufaj danym, nawet jeśli pochodzą od zalogowanego użytkownika. Bramkarz musi zweryfikować, czy treść nie zawiera ukrytych instrukcji, zanim zostanie dopuszczona do okna kontekstowego modelu. Jest to jedyny sposób na zbudowanie odpornego systemu, który wytrzyma następną generację ataków prompt injection.

Z perspektywy informatyki śledczej należy również prowadzić szczegółowe logi całego okna kontekstowego dla każdej interakcji. W przypadku naruszenia, logi te mają kluczowe znaczenie dla zrozumienia, w jaki sposób atakujący ominął filtry. Jeśli logujesz tylko ostateczny wynik, umyka Ci najważniejsza część łańcucha ataku.

Kluczowe wnioski dla liderów bezpieczeństwa

• Audytuj źródła kontekstu: Zidentyfikuj wszystkie dane wejściowe docierające do Twoich LLM i traktuj je jako niezaufane instrukcje.
• Testuj pod kątem obejść lingwistycznych: Wykorzystaj red teaming, aby sprawdzić, czy Twój model jest podatny na kognitywne tłumienie tokenów lub dekompozycję algorytmiczną.
• Monitoruj tokeny specjalne: Wdróż filtry, które wykrywają i usuwają tokeny sterujące z danych dostarczanych przez użytkowników.
• Edukuj użytkowników o ryzyku kontekstowym: Informuj pracowników, że streszczanie niezaufanych dokumentów może prowadzić do kompromitacji systemu.
• Wdróż inżynierię wykrywania: Wyjdź poza proste dopasowywanie słów kluczowych i zacznij szukać anomalii behawioralnych w odpowiedziach modelu.

Sztuczna inteligencja to potężne narzędzie, ale także nowy rodzaj powierzchni ataku. Rozumiejąc te pięć nowych zagrożeń, możesz zacząć budować obronę, która jest tak inteligentna, jak modele, które próbujesz chronić.

Źródła: CrowdStrike Falcon Intelligence, NIST AI Risk Management Framework, MITRE ATLAS.

Zastrzeżenie: Niniejszy artykuł służy wyłącznie celom informacyjnym i edukacyjnym i nie zastępuje profesjonalnego audytu cyberbezpieczeństwa ani usługi reagowania na incydenty.