Naršyklė kaip užpakalinės durys: iš kliento pusės slaptas LLM ištraukimas demistifikuotas | B4N1

Naršyklė kaip užpakalinės durys: iš kliento pusės slaptas LLM ištraukimas demistifikuotas

1 month ago · b4n1 Read time: 4 min

Naršyklė kaip užpakalinės durys: iš kliento pusės slaptas LLM ištraukimas demistifikuotas

Per ilgai „AI saugumo įspėjimus“ traktavome kaip tolimas grėsmes ar akademinius įdomybes. Girdėjome apie greitą injekciją, įsilaužimus į kalėjimą ir duomenų nutekėjimą tyliais tonais, po kurių dažnai gūžtelime pečiais ir „susitvarkysime“. Tačiau pastarosios interaktyvios demonstracijos sugriovė tą patogią iliuziją. Tai nebėra teorinis pažeidžiamumas; tai tiesioginis, naršyklėje pagrįstas, kliento pusės išnaudojimas jautriai informacijai išgauti iš didelių kalbų modelių (LLM) [2]. Jei diegiate LLM pagrįstas programas, ypač bet kokias žiniatinklyje esančias programas, jūsų „ateities problema“ tiesiog tapo labai aktuali, labai vieša ir galbūt labai gėdinga atsakomybė.

Tai nėra dar viena bendra antraštė „AI yra rizikinga“. Tai konkretus, apčiuopiamas demonstravimas, kaip kenkėjiškas veikėjas, naudodamas tik savo naršyklę, gali priversti jūsų LLM atskleisti neskelbtiną informaciją. Apsvarstykite tai akimirką. Tai ne apie sudėtingas serverio atakas ar gilų modelio savistabą. Kalbama apie sąveikos sluoksnį – pačias priekines jūsų programos duris – naudojant kelis kruopščiai sukurtus simbolius. Tai skaitmeninis atitikmuo, kai kas nors sukuria tinkamą frazę jūsų tariamai saugiam pokalbių robotui, ir jis pareigingai perduoda svarbius duomenis, dažnai po truputį.

Modelio saugumo iliuzija

Daugelis įmonių daug investavo į „saugias“ LLM, tobulindamos patentuotus modelius arba pasikliaudamos įmonės lygio API su tariamais apsauginiais turėklais. Netiesiogiai daroma prielaida, kad jei pats modelis yra tvirtas, ant jo sukurta programa paveldės tą saugumą. Naujausios demonstracijos atskleidžia tai kaip pavojingą klaidingą nuomonę. Pažeidžiamumas nėra pagrindiniame modelio intelekte ar jo mokymo duomenyse; tai yra sąsaja, kurią sukuriame aplink ją [1]. Tai klasikinė „tvirtas skliautas, silpnos priekinės durys“ problema. Galbūt turite pažangiausią, sugriežtintą LLM pasaulyje, bet jei jūsų programos įvesties analizatorius yra naivus arba jūsų išvesties filtro nėra, iš esmės paliekate svarbią informaciją, kurią gali rasti visi.

Šis „greito įpurškimo“ metodas yra ypač susirūpinęs, nes jis išnaudoja būdingą LLM prigimtį: jos gebėjimą sekti instrukcijas ir užbaigti šablonus. Įvesdamas kruopščiai sukurtą priešdėlį į vartotojo įvestį, užpuolikas gali manipuliuoti vidine modelio būsena, priversdamas jį atskleisti informaciją, kurios jam niekada nebuvo numatyta [3]. „Vieno bito“ arba kartotinis aspektas čia yra labai svarbus. Tai reiškia metodišką, kontroliuojamą išfiltravimą, o ne tik chaotišką duomenų sąvartyną. Įsivaizduokite, kad užpuolikas kartojasi klausia: „Ar pirmasis paslapties simbolis „A“? tada "Ar tai "B"?" ir taip toliau. Jis lėtas, taip, bet taip pat neįtikėtinai efektyvus ir sunku aptikti, jei specialiai jo neieškote.

Jūsų naršyklė, jų ginklas

Tai, kad tai yra naršyklės išnaudojimas, visiškai pakeičia žaidimą. Tai reiškia:

  • Žemas įėjimo barjeras: kiekvienas, turintis pagrindinių žiniatinklio kūrimo įgūdžių ir turintis naršyklę, gali tai pabandyti. Nereikia jokių specialių įrankių ar gilių dirbtinio intelekto žinių.
  • Vykdymas kliento pusėje: ataka kyla iš vartotojo kompiuterio, todėl ją sunkiau atskirti nuo teisėtos vartotojo įvesties tinklo pakraštyje.
  • Neatidėliotina grėsmė: jei jūsų LLM programa veikia ir pasiekiama per žiniatinklio sąsają, ji jau yra pažeidžiama šio vektoriaus. Tai nėra būsimas pataisas; tai dabartinė ekstremali situacija.

Apsvarstykite pasekmes: patentuotus kodo fragmentus, vidinius dokumentus, klientų duomenis, API raktus ar net subtilų manipuliavimą jūsų LLM elgesiu, siekiant skleisti dezinformaciją arba generuoti žalingą turinį. Visa tai galima išgauti arba paveikti, po truputį, naudojant paprastą teksto laukelį.

Atsakomybė yra jūsų

Modelių tiekėjams, tokiems kaip „OpenAI“ ar „Google“, tai nėra problema, kurią gali išspręsti kitame modelio atnaujinime. Tai yra programos saugumo problema, o atsakomybė už mažinimą tenka kūrėjams, saugos komandoms ir CTO, diegiančių šias sistemas, pečius. Jūsų LLM yra galingas, bet galiausiai naivus variklis. Jis atliks tai, kas jai nurodyta, net jei tos instrukcijos yra paslėptos iš pažiūros nekenksmingos vartotojo įvesties.

Taigi, ką tu darai dabar?

Neatidėliotinos atsakomosios priemonės:

  1. Agresyvus įvesties valymas: tai neapsiriboja SQL įterpimo ar XSS prevencija. Turite atidžiai išnagrinėti kiekvieną veikėją, įvedantį į LLM. Ieškokite modelių, rodančių greitą injekciją, neįprastas simbolių sekas arba bandymus išsiveržti iš laukiamų pokalbių srautų [4]. Tai ne apie „blogų žodžių“ blokavimą; kalbama apie priešiškų raginimų nustatymą. Be pagrindinės reguliariosios ir euristinės analizės, įgyvendinkite semantinę analizę, kad aptiktumėte kenkėjiškus ketinimus. Norėdami nustatyti anomalius įvesties modelius, naudokite atpažinimo ir įterpimo analizę. Apsvarstykite galimybę naudoti antrinį, mažesnį LLM arba taisyklėmis pagrįstą sistemą, specialiai paruoštą aptikti greitus injekcijos bandymus. Ieškokite modelių, pvz., vaidmenų žaidimo instrukcijų, aiškių duomenų išgavimo užklausų arba bandymų apeiti ankstesnes instrukcijas.
  2. Tvirtas išvesties filtravimas ir patvirtinimas: Niekada netiesiogiai nepasitikėkite LLM išvestimi. Prieš bet kokį LLM sugeneruotą tekstą rodant vartotojui arba naudojant kitą sistemą, jis turi praeiti griežtą patvirtinimo sluoksnį. Ar jame yra jautrių raktinių žodžių? Ar jis atitinka numatytus formatus? Ar bandoma vykdyti kodą arba atskleisti vidinius sistemos raginimus? Jei jūsų LLM turėtų apibendrinti dokumentą, bet jis pradeda išvardyti failų kelius, turite problemų.
  3. Sluoksniuota raginimo inžinerija: nors tai nėra išsamus sprendimas, gerai suplanuoti sistemos raginimai ir kelių kadrų pavyzdžiai gali padėti sustiprinti norimą elgesį ir apsunkinti užpuoliko užgrobimą modelį. Tačiau supraskite, kad vien operatyvios inžinerijos nepakanka; tai giluminė gynyba, o ne pagrindinis skydas.
  4. Mažiausia privilegija LLM sąveikai: Ar jūsų LLM tikrai reikia prieigos prie visų duomenų, kuriuos jis gali būti paragintas atskleisti? Įdiekite griežtą prieigos kontrolę. Jei LLM turėtų atsakyti tik į klausimus apie viešąją dokumentaciją, įsitikinkite, kad jis neturi programinės prieigos prie vidinių duomenų bazių arba jautrių API.
  5. Stebėjimas ir anomalijų aptikimas: turite aktyviai ieškoti neįprasto LLM elgesio. Konkrečių tipų užklausų šuolis, išvesties, kurios skiriasi nuo įprastų modelių, arba pakartotiniai bandymai išgauti informaciją turėtų nedelsiant suaktyvinti įspėjimus.

Tai jau ne apie platų „AI saugumą“. Tai yra jūsų LLM programų sąveikos sluoksnio apsauga nuo konkretaus, parodyto ir nedelsiant išnaudojamo atakos vektoriaus. Mes sukūrėme šias neįtikėtinas, galingas sistemas, dažnai su netinkamomis sąsajos saugumo priemonėmis. Naujausios demonstracijos mums tiksliai parodė, kaip lengva išnaudoti šias spragas. Teorinių diskusijų laikas praėjo. Norint apsaugoti LLM programas, reikia nedelsiant imtis veiksmų.

Šaltiniai

[1] OWASP 10 geriausių didelių kalbų modelių taikomųjų programų – https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] „Lakera Gandalf: Interactive Prompt Injection Challenge“ – https://gandalf.lakera.ai/ [3] Greitos injekcijos atakos | Žiniatinklio saugumo akademija – https://portswigger.net/web-security/llm-attacks/prompt-injection [4] Kas yra greitas švirkštimas ir kaip to išvengti? - https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it


Have Questions?

Let's Talk

Contact me on LinkedIn