Браузер Backdoor ретінде: Client-Side LLM құпия экстракциясы жойылды | B4N1

Браузер Backdoor ретінде: Client-Side LLM құпия экстракциясы жойылды

1 month ago · b4n1 Tiempo de lectura: 4 min

Браузер Backdoor ретінде: Client-Side LLM құпия экстракциясы жойылды

Ұзақ уақыт бойы біз «AI қауіпсіздік ескертулерін» алыстағы қауіптер немесе академиялық қызығушылықтар ретінде қарастырдық. Біз жылдам инъекция, джейлбрейктер және деректердің өшіп қалуы туралы естідік, олар жиі иығын көтеру және «біз оған жетеміз» деген сөздермен жалғасады. Дегенмен, соңғы интерактивті демонстрациялар бұл ыңғайлы иллюзияны бұзды. Бұл енді теориялық осалдық емес; бұл үлкен тіл үлгілерінен (LLM) құпия ақпаратты шығаруға арналған тірі, браузерге негізделген, клиенттік эксплойт [2]. Егер сіз LLM-мен жұмыс істейтін қолданбаларды, әсіресе веб-бағдарламаны қолданып жатсаңыз, сіздің «болашақ мәселеңіз» өте қазіргі, өте ашық және ықтимал өте ұят жауапкершілікке айналды.

Бұл «AI қауіпті» деген басқа жалпы тақырып емес. Бұл зиянды актер тек браузерді пайдаланып, құпия ақпаратты ашу үшін сіздің LLM-ді қалай мәжбүрлей алатынын нақты, нақты көрсету. Мұны бір сәтке қарастырыңыз. Бұл күрделі серверлік шабуылдар немесе терең модельді интроспекция туралы емес. Бұл әрекеттестік қабаты - қолданбаңыздың ең алдыңғы есігі - бірнеше мұқият жасалған таңбалармен пайдаланылуда. Бұл сіздің болжалды қауіпсіз чат-ботыңызға дұрыс фразаны құрастырған адамның цифрлық баламасы және ол сыни деректерді, әдетте, біртіндеп береді.

Үлгі қауіпсіздік иллюзиясы

Көптеген кәсіпорындар меншікті үлгілерді дәл баптайтын немесе болжамды қорғаныстары бар кәсіпорын деңгейіндегі API интерфейстеріне сүйене отырып, «қауіпсіз» LLM-ге көп инвестициялады. Жасырын болжам, егер модельдің өзі сенімді болса, оның үстіне салынған қолданба сол қауіпсіздікті мұраға алады. Жақында өткен демонстрациялар мұны қауіпті қате түсінік ретінде көрсетті. Осалдық модельдің негізгі интеллектінде немесе оның жаттығу деректерінде емес; ол біз оның айналасында құрастыратын интерфейсте [1]. Бұл классикалық «мықты қойма, кіреберіс есік» мәселесі. Сізде әлемдегі ең жетілдірілген, шыңдалған LLM болуы мүмкін, бірақ қолданбаның енгізу талдаушысы аңғал болса немесе шығыс сүзгісі жоқ болса, сіз маңызды ақпаратты кез келген адам таба алатындай етіп қалдырасыз.

Бұл «жедел инъекция» техникасы әсіресе маңызды, себебі ол LLM-ге тән табиғатты пайдаланады: оның нұсқауларды орындау және үлгілерді аяқтау мүмкіндігі. Пайдаланушы енгізуіне мұқият құрастырылған префиксті енгізу арқылы шабуылдаушы модельдің ішкі күйін басқара алады, бұл оны ешқашан арналмаған ақпаратты ашуға мәжбүрлей алады [3]. Мұнда «бір биттік» немесе итеративті аспект өте маңызды. Бұл жай ғана ретсіз деректер қоқысы емес, әдістемелік, басқарылатын эксфильтрацияны білдіреді. Шабуылдаушының қайталап сұрайтынын елестетіп көріңізші: «Құпия «А» бірінші кейіпкері ме?» содан кейін «Бұл «В» ма?» және т.б. Бұл баяу, иә, бірақ ол сондай-ақ керемет тиімді және сіз оны арнайы іздемейтін болсаңыз, анықтау қиын.

Сіздің браузеріңіз, олардың қаруы

Бұл шолғышқа негізделген эксплуат фактісі ойынды толығымен өзгертеді. Ол мынаны білдіреді:

  • Кірудегі аз кедергі: Веб әзірлеудің негізгі дағдылары мен браузері бар кез келген адам бұған әрекет ете алады. Ешқандай арнайы құралдар немесе терең AI білімі қажет емес.
  • Клиент тарапынан орындау: Шабуыл пайдаланушының құрылғысынан туындайды, бұл желі шетіндегі заңды пайдаланушы енгізуінен ажыратуды қиындатады.
  • Тез қауіп: Егер LLM қолданбасы тірі болса және веб-интерфейс арқылы қолжетімді болса, ол қазірдің өзінде осы векторға осал. Бұл болашақ патч емес; бұл қазіргі төтенше жағдай.

Салдарын қарастырыңыз: меншікті код үзінділері, ішкі құжаттама, тұтынушы деректері, API кілттері немесе жалған ақпаратты тарату немесе зиянды мазмұнды жасау үшін тіпті LLM әрекетін жасырын манипуляциялау. Мұның барлығын қарапайым мәтіндік жолақ арқылы шығаруға немесе әсер етуге болады.

Жауапкершілік сізде

Бұл OpenAI немесе Google сияқты модель провайдерлері үшін келесі үлгі жаңартуларында түзететін мәселе емес. Бұл қолданбаның қауіпсіздігі мәселесі және азайту үшін жауапкершілік осы жүйелерді қолданатын әзірлеушілерге, қауіпсіздік топтарына және CTO-ларға жүктеледі. Сіздің LLM - қуатты, бірақ сайып келгенде аңғал қозғалтқыш. Бұл нұсқаулар зиянсыз болып көрінетін пайдаланушы енгізуінде жасырылған болса да, ол айтқанын орындайды.

Сонымен, қазір не істейсіз?

Шұғыл қарсы шаралар:

  1. Агрессивті кірісті зарарсыздандыру: Бұл SQL инъекциясының немесе XSS-тің алдын алумен шектелмейді. LLM-ге кіретін әр таңбаны мұқият қарап шығу керек. Жедел енгізуді, әдеттен тыс таңбалар тізбегін немесе күтілетін сөйлесу ағындарынан шығу әрекеттерін көрсететін үлгілерді іздеңіз [4]. Бұл «жаман сөздерді» блоктау туралы емес; ол қарсылас шақыруларды анықтау туралы. Негізгі регекс және эвристикалық талдаудан басқа, зиянды ниетті анықтау үшін семантикалық талдауды орындаңыз. Аномальды енгізу үлгілерін анықтау үшін таңбалау және ендіру талдауын пайдаланыңыз. Қосымша, кішірек LLM немесе жылдам енгізу әрекеттерін анықтау үшін арнайы үйретілген ережеге негізделген жүйені пайдалануды қарастырыңыз. Рөлдік нұсқаулар, нақты деректерді алу сұраулары немесе алдыңғы нұсқауларды айналып өту әрекеттері сияқты үлгілерді іздеңіз.
  2. Мықты шығысты сүзу және тексеру: LLM шығысына ешқашан сенбеңіз. Кез келген LLM арқылы жасалған мәтін пайдаланушыға көрсетілмес бұрын немесе басқа жүйе пайдаланбас бұрын, ол қатаң тексеру деңгейінен * өтуі керек. Онда сезімтал кілт сөздер бар ма? Ол күтілетін пішімдерге сәйкес келе ме? Ол кодты орындауға немесе ішкі жүйе шақыруларын ашуға әрекет жасай ма? Егер LLM құжатты қорытындылауы керек болса, бірақ ол файл жолдарын тізімдей бастаса, сізде мәселе бар.
  3. Қабатты шақыру инженериясы: Толық шешім болмаса да, жақсы жобаланған жүйелік кеңестер мен бірнеше рет түсірілген мысалдар қалаған әрекетті күшейтуге көмектеседі және шабуылдаушының үлгіні басып алуын қиындатады. Дегенмен, тек жылдам инженерия жеткіліксіз екенін түсініңіз; бұл негізгі қалқан емес, терең қорғаныс.
  4. LLM өзара әрекеттесуі үшін ең аз артықшылық: Сіздің LLM шын мәнінде ашу сұралуы мүмкін деректердің әрбір бөлігіне қол жеткізуді қажет ете ме? Қатаң қол жеткізуді басқаруды енгізіңіз. Егер LLM қоғамдық құжаттама туралы сұрақтарға ғана жауап беруі керек болса, оның ішкі дерекқорларға немесе сезімтал API интерфейстеріне бағдарламалық қатынасы жоқ екеніне көз жеткізіңіз.
  5. Мониторинг және аномалияны анықтау: Сіз әдеттен тыс LLM әрекетін белсенді түрде іздеуіңіз керек. Сұраулардың арнайы түрлеріндегі өсулер, қалыпты үлгілерден ауытқыған шығыстар немесе ақпаратты шығаруға қайталанатын әрекеттер дереу ескертулерді іске қосуы керек.

Бұл енді кең ауқымды «AI қауіпсіздігі» туралы емес. Бұл LLM қолданбаларыңыздың өзара әрекеттесу деңгейін нақты, көрсетілген және бірден пайдаланатын шабуыл векторына қарсы қорғау туралы. Біз интерфейсте жиі қауіпсіздік шаралары жеткіліксіз болатын осы керемет, қуатты жүйелерді жасап жатырмыз. Жақында болған демонстрациялар бізге бұл олқылықтарды пайдалану қаншалықты оңай екенін көрсетті. Теориялық талқылаудың уақыты өтті. LLM қолданбаларын қорғау үшін шұғыл әрекет қажет.

Дереккөздер

[1] Үлкен тілдік үлгі қолданбаларына арналған OWASP үздік 10 — https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] Лакера Гандальф: Интерактивті жылдам инъекцияға шақыру — https://gandalf.lakera.ai/ [3] Жедел инъекциялық шабуылдар | Веб қауіпсіздік академиясы — https://portswigger.net/web-security/llm-attacks/prompt-injection [4] Жедел инъекция дегеніміз не және оны қалай болдырмауға болады? — https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it


¿Tienes preguntas?

Hablemos

Contáctame en LinkedIn