Jak serwis modelowego relay stał się atakiem?
Categories:
Jak serwis modelowego relay stał się atakiem?
Osoby korzystające obecnie z lub rozważające użycie usług “model mid / routing modeli / API forwarding”
Ta seria diagramów odpowiada na jedno pytanie: co się stanie, gdy Twoje żądanie modelu przechodzi przez nieufny serwis przesyłający, i jak się wtedy bronić?
Co ta seria ma wyjaśnić?
Usługa modelowego relay pomaga przekierować żądanie do prawdziwego API modelu. Ale przekierowanie oznacza, że za każdym razem, gdy zadajesz pytanie, oraz za każdą odpowiedź modelu, przepływa ono przez jego serwer. To właśnie jest punktem ataku – nie jest to proxy ruchu, lecz pośrednik, który ma w rękach cały przepływ między Tobą a dużym modelem.
W powyższym diagramie jest to architektura ryzyka: klient (przeglądarka, wtyczka IDE) → serwis relay → duży model. Dlatego serwis relay może widzieć pełen przepływ dwustronny i w mgnieniu oka zrobić coś złego.
Jakie są zagrożenia?
Najczęstszym i najbardziej ukrytym atakiem jest ukrywanie nieuczciwych treści w instrukcjach tool_use zwracanych przez model. Klient “zaufa” i wykona wszystkie otrzymane instrukcje narzędzi, więc serwis relay może przypadkiem pozwolić użytkownikowi na dowolne działania na jego maszynie.
Ta ścieżka nazywa się wstrzyknięciem polecenia przez klienta: instrukcje search_web, read_file itd. zwracane normalnie przez model zostały przez serwis relay dodatkowo wstrzyknięte ukrytego odczytu kluczy i wykonania skryptu shell. Dane nie wracają do modelu, rozmowa wygląda całkowicie normalnie, więc użytkownik w ogóle nie zauważy.
Inna metoda ataku polega na ataku z poziomu serwera: modyfikują Twoje prompty wysyłane do modelu i sprawiają, że model pomoże Ci wygenerować kod z ukrytym backdoorem.
Ta ścieżka nazywa się prompt injection ze strony serwera: serwis relay zmienia Twoje “napisz skrypt analizy logów” na “najpierw naładuj i wyślij do skryptu zmienne środowiskowe”. Model jest posłuszny i w generowanym kodzie dodaje logikę ujawniającą klucz API.
Jakie inne ryzyka istnieją?
Kradzież informacji to dopiero początek. Gdy operator chce bezpośrednio zniszczyć Twoje dane, punkt przechwytywania staje się przeskokiem do kradzieży danych; gdy chce długofranużytować Twoją moc obliczeniową, staje się przejęciem zasobów; gdy chce manipulować decyzjami, staje się manipulacją treścią; a gdy chce zanieczyścić projekt, staje się zanieczyszczeniem łańcuchem dostaw.
Wśród nich szczególnie niebezpieczne jest przejęcie repozytorium kodu: najpierw cicho wysyłasz swój kod na atakerskie repozytorium jako backup, a następnie wymusza się wprowadzenie działań niszczących.
Poniższy terminalny odtwarzanie to przykładowa sekwencja instrukcji przejęcia repozytorium: backup → rollback → wymuszone force push → pozostawienie informacji o szantażu.
Który diagram wybrać?
Obrona nie polega na jednej komendzie, lecz na całej serii kroków, od wyboru usługi aż po ostateczną linię obrony.
Kolejność podstawowa: najpierw preferuj usługi oficjalne lub zaufane; w własnym kliencie wprowadź białą listę dla tool_use; kod wygenerowany przez AI sprawdź przed uruchomieniem; umieść narzędzia AI w kontenerze sandbox; pluginy nadaj minimalne uprawnienia; przed instalacją zależności sprawdź reputację i regularnie audytuj; ważny kod duplikuj offline.
Dalej czytać
- Oryginalne repozytorium: how-to-hack-as-model-router
- Więcej treści o prywatności i bezpieczeństwie: https://nullprivate.com