Apsaugokite savo MCP sistemą: 11 dažnų rizikų ir kaip nuo jų apsisaugoti

MCP rizikas galima suskirstyti į tris plačias kategorijas: LLM manipuliavimas, duomenų ir prieigos saugumas bei infrastruktūros pažeidžiamumai.

Kadangi MCP serveriai dažnai suteikia prieigą prie daugybės vidinių sistemų, galima saugumo rizika yra didelė. Tačiau tikimybė labai priklauso nuo konfigūracijos.

Asmenys ir įmonės gali imtis daugybės veiksmų, kad apsaugotų savo sistemas, o apsaugos protokolai visada turėtų atitikti galimybes ir duomenis, kuriuos gali atskleisti prijungti MCP serveriai.

Kas yra MCP ir MCP saugumas?

Model Context Protocol (MCP) – tai bendrovės Anthropic sukurtas atviras standartas, skirtas LLM pagrįstoms programoms (arba pagrindinėms programoms) prijungti prie išorinių sistemų.

MCP sistemą sudaro trys pagrindiniai komponentai: pagrindinė programa (host), klientas ir serveris. Pagrindinė programa, kuri dažnai yra DI asistentas, per klientą prisijungia prie išorinio MCP serverio. Tada ji gali siųsti užklausas paleisti išorines funkcijas (įrankius), gauti duomenis (išteklius) arba raginimus, kuriuos galima įtraukti į LLM konteksto langą.

Padidinti

MCP saugumas – tai protokolai, saugantys MCP sistemos ryšius ir komponentus. Yra keletas esminių iššūkių, būdingų tik MCP, pavyzdžiui, tai, kad DI programos dažnai turi agentinių galimybių, o į pranešimus gali būti įterpta kenkėjiškų instrukcijų.

Problemų kelia ir žinomos grėsmės, būdingos ne vien MCP, pavyzdžiui, raginimų injekcija, silpnas autentifikavimas ir nesaugios trečiųjų šalių integracijos. Kaip ir bet kuri kompiuterinė sistema, MCP apsaugai remiasi procedūrinių protokolų, pavyzdžiui, tik patikimų serverių naudojimo, ir techninių kontrolės priemonių, pavyzdžiui, API šliuzų, deriniu.

Kiek rimtos yra MCP grėsmės?

MCP greitai tapo populiaria LLM technologija, ją naudoja daugelis organizacijų ir vartotojams skirtų programų. Kadangi MCP serveriai yra kodu parašytos programos, jie turi pažeidžiamumų, kaip ir bet kuri kita programa.

Vis dėlto, kai organizacijos naudoja MCP kontroliuojamose diegimo aplinkose, jis paprastai yra saugus. Sistemos kūrimas su patikimais serveriais ir patikrintais leidimais labai skiriasi nuo autonominio agento prijungimo prie keliolikos nepatikrintų serverių.

Grėsmė Nr. 1: netiesioginė raginimų injekcija

Užpuolikas gali įterpti LLM skirtų instrukcijų į dokumentą, tinklalapį arba įrankio išvestį, kurią grąžina MCP serveris. Jei pagrindinė programa įtraukia šią medžiagą į konteksto langą, yra tikimybė, kad LLM palaikys ją tikromis instrukcijomis.

Be to, iš pirmo žvilgsnio šios instrukcijos gali atrodyti tinkamos. Pavyzdžiui, gautoje pagalbos tarnybos užklausoje LLM gali būti nurodyta prieš generuojant atsakymą eksportuoti neskelbtinus klientų įrašus.

Kaip apsisaugoti nuo netiesioginės raginimų injekcijos

Raginimų injekcijas paprastai reikėtų spręsti pagrindinės programos lygmeniu. Išorinis turinys turėtų būti žymimas kaip nepatikimas, o užklausoms dėl neskelbtinos informacijos turėtų būti reikalingas informuotas į procesą įtraukto žmogaus patvirtinimas. Taip pat gali būti naudingas saugumo testavimas, kurio metu iškviečiami kenkėjiški dokumentai ar duomenys ir stebima, kaip reaguoja pagrindinė programa ir LLM.

Grėsmė Nr. 2: įrankių nuodijimas ir „rug pull“ atakos

Įrankių nuodijimo atakos metu į MCP įrankio aprašą ar schemą įterpiamas kenkėjiškas kodas. Tai gali paveikti LLM aptikimo etape, kai MCP pirmą kartą pateikia prieinamus įrankius.

Padidinti

„Rug pull“ ataka – tai ypatinga įrankių nuodijimo rūšis, kai pakeičiami patvirtinti metaduomenys. Užuot tiesiogiai iškvietusi kenkėjišką įrankį, tokia įrankių nuodijimo forma gali pakeisti tai, kaip modelis naudoja patikimus įrankius.

Kaip apsisaugoti nuo įrankių nuodijimo ir „rug pull“ atakų

Prieš naudodama kiekvieną įrankį, pagrindinė programa turėtų patikrinti visą jo apibrėžtį ir palyginti ją su patvirtintų patikimų įrankių sąrašu – taip aptinkami bet kokie pakeitimai. Parametrų patikros gali padėti nustatyti galimai pavojingas galimybes ir jas pažymėti.

Grėsmė Nr. 3: pertekliniai leidimai

Naudotojai dažnai suteikia MCP serveriams ir (per pagrindinę programą) prijungtiems LLM daugiau leidimų, nei reikia užduočiai atlikti. Pavyzdžiui, rašymo leidimus, kai pakaktų tik skaitymo, arba visišką prieigą prie vidinės failų sistemos (pvz., Google Drive).

Toks plataus masto leidimų plėtimasis gali padidinti kitų pažeidžiamumų, pavyzdžiui, kenkėjiškų įrankių iškvietimų, žalos mastą. Dažnai leidimai „susikaupia“, kai naudotojai įmonėje suteikia privilegijas kasdien dirbdami su DI įrankiais (privilegijų kaupimasis).

Kaip apsisaugoti nuo perteklinių leidimų

Tiesiausias būdas apsisaugoti nuo šios problemos – apriboti leidimus ir OAuth aprėptis (skaitymas, rašymas, visiška prieiga ir t. t.). Svarbi to dalis yra naudotojų patvirtinimai, ypač atliekant neskelbtinas operacijas, tačiau leidimai taip pat turėtų būti kontroliuojami sistemos lygmeniu (operacinės sistemos, MCP pagrindinės programos ir serverio).

Grėsmė Nr. 4: silpnas autentifikavimas ir autorizavimas

Autentifikavimas patikrina prie MCP serverio prisijungiančių naudotojų ar programų tapatybę. Autorizavimas nustato, kuriuos įrankius ir išteklius jie gali pasiekti.

Netinkamai sukonfigūruoti MCP serveriai gali priimti užklausas ar prieigos raktus tinkamai neautentifikavę naudotojų arba netaikydami prieigos apribojimų. Be to, jei patvirtinimas silpnas, pavogti prisijungimo duomenys gali leisti piktavaliams gauti prieigą.

Kaip apsisaugoti nuo silpno autentifikavimo ir autorizavimo

OAuth pagrįstas nuotolinių MCP serverių autentifikavimas, trumpalaikiai prieigos raktai ir vaidmenimis pagrįsta prieigos kontrolė (RBAC) – visa tai priemonės, padedančios sumažinti silpno autorizavimo riziką. Vaidmenimis pagrįsta prieiga naudinga, nes neleidžia naudotojams pasiekti duomenų ir įrankių, viršijančių jų leidimus, net jei pats serveris turi prieigą.

Grėsmė Nr. 5: prisijungimo duomenų nutekėjimas ir netinkamas naudojimas

MCP serveriai, jungdamiesi prie išorinių paslaugų, įprastai naudoja prisijungimo duomenis, pavyzdžiui, API raktus ir OAuth prieigos raktus. Jei jie atskleidžiami ar netinkamai naudojami, užpuolikai gali gauti prieigą prie neskelbtinų duomenų ir funkcijų.

Vienas iš pavyzdžių – prieigos rakto perdavimas (token passthrough), kai MCP serveris persiunčia prieigos raktą kitai paslaugai nepatikrinęs, ar jis iš tikrųjų skirtas gaunančiajai paslaugai. Tai savo ruožtu gali lemti nutekėjimą, jei gaunančioji paslauga nėra pakankamai apsaugota.

Kaip apsisaugoti nuo prisijungimo duomenų nutekėjimo ir netinkamo naudojimo

Trumpalaikiai, siauros aprėpties prieigos raktai ir prisijungimo duomenų rotacija veiksmingai riboja, kiek nutekėjusius duomenis gali panaudoti piktavaliai. API raktai ir prisijungimo duomenys visada turėtų būti saugiai laikomi naudojant slaptųjų duomenų tvarkyklę.

Grėsmė Nr. 6: sutrikusio tarpininko (confused deputy) atakos

Sutrikusio tarpininko ataka įvyksta, kai užpuolikas apgaule priverčia patikimą programą panaudoti savo leidimus ir atlikti veiksmą, kurio neautorizavo teisėtas naudotojas. Šiuo atveju tarpininkas yra MCP serveris.

Padidinti

Užpuolikas išnaudos MCP serverio pažeidžiamumą (pavyzdžiui, silpną OAuth patikrą), kad įvykdytų kenkėjišką procesą, pavyzdžiui, įrankio iškvietimą ar duomenų gavimą.

Kaip apsisaugoti nuo sutrikusio tarpininko atakų

Autorizavimo patikra, kai kiekvienas įrankio iškvietimas patikrinamas kaip priklausantis konkrečiam naudotojui, padeda riboti sutrikusio tarpininko atakas. Be to, neskelbtiniems veiksmams, pavyzdžiui, duomenų eksportui, turėtų būti reikalingas aiškus autorizavimas.

Grėsmė Nr. 7: kenkėjiški serveriai ir pažeistos priklausomybės

MCP serveriuose gali būti kenkėjiško kodo (iš esmės tai yra išorinės programos) arba jie gali priklausyti nuo pažeistų priklausomybių, pavyzdžiui, trečiųjų šalių bibliotekų. Tai programinės įrangos tiekimo grandinės problema, o ne vien MCP būdinga problema.

Vienas paprastas būdas, kaip tai gali nutikti, – užpuolikas platina teisėtai atrodančią integraciją. Ją įdiegus, ji gali pavogti ir pakartotinai panaudoti prisijungimo duomenis, pasiekti neskelbtinus duomenis ir vykdyti neautorizuotas operacijas.

Kaip apsisaugoti nuo kenkėjiškų serverių ir pažeistų priklausomybių

Diekite MCP serverius tik iš patikimų ir patikrintų šaltinių. Jei įmanoma, peržiūrėkite jų kodą ir visada patikrinkite visas išorines priklausomybes. Užtikrinkite, kad serveriai būtų reguliariai atnaujinami ir pataisomi.

Grėsmė Nr. 8: serverio pusės užklausų klastojimas (SSRF)

Serverio pusės užklausų klastojimas (SSRF) įvyksta, kai užpuolikas apgaule priverčia MCP serverį siųsti tinklo užklausas vidiniais adresais, kurių naudotojas neketino pasiekti.

Tai gali nutikti, kai MCP serveris pateikia įrankį, gaunantį informaciją iš URL adreso. Jei užpuolikas gali paveikti URL parametrą, jis gali jį pakeisti norimu tinklo adresu, pavyzdžiui, vidinės API ar debesijos paslaugos. Dėl to gali būti gauti neskelbtini duomenys ir jie gali tapti prieinami

Kaip apsisaugoti nuo serverio pusės užklausų klastojimo (SSRF)

MCP serveriai visada turėtų tikrinti URL adresus, blokuoti prieigą prie ribotos prieigos vidinių tinklo adresų ir užkirsti kelią išeinančiai tinklo prieigai. Šio protokolo taip pat turėtų būti laikomasi ir peradresavimams.

Grėsmė Nr. 9: sesijos užgrobimas

Sesijos užgrobimo metu užpuolikas perima aktyvaus ryšio tarp MCP kliento ir serverio kontrolę.

Pavyzdžiui, jis gali pavogti sesijos identifikatorių iš prastai apsaugotos MCP programos (pvz., pagrindinės programos ar serverio). Jei MCP serveris priima šį identifikatorių, užpuolikas gali iškviesti įrankius su teisėtais naudotojo leidimais.

Kaip apsisaugoti

Sesijos užgrobimo riziką galima sumažinti taikant griežtą tapatybės patikrą visose MCP sistemos programose. Šifravimas tarp MCP klientų ir nuotolinių serverių taip pat būtinas, kad sesijų identifikatorių nebūtų galima nustatyti.

Grėsmė Nr. 10: supainiojimo atakos

Supainiojimo atakos metu užpuolikas apgaule priverčia MCP klientą išsiųsti autorizacijos kodą kenkėjiškam autorizacijos serveriui, esančiam tarp kliento ir MCP serverio. Autorizacijos serveris – tai programa, kuri išduoda OAuth prieigos raktus, patikrinusi, ar prašoma prieiga yra autorizuota.

Padidinti

Jei MCP pagrindinė programa jungiasi prie kelių paslaugų, kurių kiekviena naudoja skirtingą autorizacijos serverį, užpuolikas gali valdyti vieną iš jų (pavyzdžiui, užregistravęs kenkėjišką paslaugą) ir priversti klientą išsiųsti teisėto serverio išduotą autorizacijos kodą kenkėjiškam serveriui. Toks supainiojimas gali leisti užpuolikui apsimesti autorizuota programa ir gauti prieigą prie apsaugotų paslaugų.

Kaip apsisaugoti nuo supainiojimo atakų

MCP klientai turėtų tikrinti autorizacijos serverio tapatybę viso OAuth proceso metu. Konkrečiai, jie turėtų palyginti serverio išdavėjo identifikatorių (iss) su laukiama tapatybe ir atmesti neatitikimus.

Grėsmė Nr. 11: vietinio MCP serverio pažeidimas

Daugelis MCP serverių veikia naudotojo vietiniame kompiuteryje. Naudotojas gali įdiegti serverį iš trečiosios šalies arba susikurti jį pats. Jei užpuolikas sugeba pažeisti šį vietinį MCP serverį, jis gali gauti prieigą prie didelės vietinės sistemos dalies.

Užpuolikas prieigą gali gauti įvairiais būdais. Jis gali platinti kenkėjišką serverį, užmaskuotą kaip teisėta integracija, pakeisti MCP pagrindinės programos konfigūraciją taip, kad ji vykdytų kenkėjišką komandą, arba pasiekti MCP serverį, veikiantį aplinkoje su nepakankamomis saugumo kontrolės priemonėmis, pavyzdžiui, pasitelkęs DNS perrišimą (DNS rebinding), kai naršyklė apgaule priverčiama siųsti užklausas localhost paslaugai.

Kaip apsisaugoti nuo vietinio MCP serverio pažeidimo

Naudojant vietinius MCP serverius svarbu taikyti izoliavimą (sandboxing) ir griežtus sutikimo protokolus. MCP serverius reikėtų diegti tik iš patikimų tiekėjų, o operacinės sistemos leidimai turėtų riboti, kuriuos katalogus jie gali pasiekti.

MCP pažeidžiamumai dažnai yra senos grėsmės nauju pavidalu

MCP pažeidžiamumai dažnai atsiranda žinomas rizikas ir atakų metodikas pritaikant naujai. MCP suteikia užpuolikams naujų būdų išnaudoti šiuos pažeidžiamumus per LLM, MCP serverių ir išorinių paslaugų sąveiką.

Žinoma, MCP būdingų grėsmių tikrai egzistuoja. Tačiau verta nepamiršti, kad standartiniai saugumo protokolai, pavyzdžiui, griežto autorizavimo taikymas, patikimų tiekėjų naudojimas ir apsauga nuo raginimų injekcijų, labai padės apsaugoti bet kokį MCP diegimą.