Zaštitite svoj MCP sustav: 11 čestih rizika i kako se zaštititi od njih

Rizici MCP-a uglavnom se dijele u tri kategorije: manipulacija LLM-om, sigurnost podataka i pristupa te ranjivosti infrastrukture.

Budući da MCP poslužitelji često omogućuju pristup velikom broju internih sustava, potencijalni sigurnosni rizik je visok. Međutim, vjerojatnost uvelike ovisi o postavljanju.

Pojedinci i tvrtke mogu poduzeti mnogo koraka kako bi osigurali zaštitu svojih sustava, a protokoli uvijek trebaju biti razmjerni mogućnostima i podacima koje povezani MCP poslužitelji mogu izložiti.

Što je MCP i što je MCP sigurnost?

Model Context Protocol (MCP) otvoreni je standard koji je stvorio Anthropic za povezivanje aplikacija temeljenih na LLM-ovima (ili domaćina) s vanjskim sustavima.

MCP sustav čine tri ključne komponente: domaćin, klijent i poslužitelj. Domaćin, koji je često AI asistent, povezuje se s vanjskim MCP poslužiteljem putem klijenta. Zatim može slati zahtjeve za pokretanje vanjskih funkcionalnosti (alata) ili dohvaćanje podataka (resursa) ili upita koje dodaje u kontekstni prozor LLM-a.

Povećaj

MCP sigurnost odnosi se na protokole koji štite veze i komponente u MCP sustavu. Postoji nekoliko ključnih izazova jedinstvenih za MCP, uključujući činjenicu da AI aplikacije često imaju agentske mogućnosti, a zlonamjerne upute mogu biti ugrađene u poruke.

Probleme uzrokuju i dobro poznate slabosti koje nisu specifične za MCP, poput ubacivanja upita, slabe autentifikacije i nesigurnih integracija trećih strana. Kao i svaki računalni sustav, MCP se za zaštitu oslanja na kombinaciju proceduralnih protokola, poput korištenja isključivo pouzdanih poslužitelja, i tehničkih kontrola, poput API pristupnika.

Koliko su ozbiljne MCP prijetnje?

MCP je brzo postao popularna LLM tehnologija, a koriste ga mnoge organizacije i aplikacije namijenjene potrošačima. Budući da su MCP poslužitelji programi napisani u kodu, imaju ranjivosti kao i svaka druga aplikacija.

Međutim, kada organizacije koriste MCP u kontroliranim implementacijama, on je općenito siguran. Postoji velika razlika između izgradnje sustava s pouzdanim poslužiteljima i provjerenim dopuštenjima i povezivanja autonomnog agenta s desetak neprovjerenih poslužitelja.

Prijetnja br. 1: neizravno ubacivanje upita

Napadač može postaviti upute namijenjene LLM-u unutar dokumenta, web-stranice ili izlaza alata koji vraća MCP poslužitelj. Ako domaćin doda taj sadržaj u kontekstni prozor, postoji mogućnost da ga LLM zamijeni za stvarne upute.

Štoviše, te se upute na prvi pogled mogu činiti primjerenima. Na primjer, dohvaćena prijava za podršku mogla bi LLM-u naložiti da izveze osjetljive zapise o klijentima prije generiranja odgovora.

Kako se zaštititi od neizravnog ubacivanja upita

Ubacivanje upita obično treba rješavati na razini domaćina. Vanjski sadržaj treba označiti kao nepouzdan, a zahtjevi za osjetljivim informacijama trebaju zahtijevati informirano odobrenje čovjeka uključenog u proces. Korisno može biti i sigurnosno testiranje koje uključuje pozivanje zlonamjernih dokumenata ili podataka kako bi se vidjelo kako domaćin i LLM reagiraju.

Prijetnja br. 2: trovanje alata i rug pull napadi

U napadu trovanjem alata zlonamjerni kod dodaje se u opis ili shemu MCP alata. To može utjecati na LLM u fazi otkrivanja, kada MCP prvi put izlaže dostupne alate.

Povećaj

Rug pull poseban je oblik trovanja alata u kojem se mijenjaju odobreni metapodaci. Ovaj oblik trovanja alata može promijeniti način na koji model koristi pouzdane alate umjesto da izravno pokrene zlonamjerni alat.

Kako se zaštititi od trovanja alata i rug pull napada

Domaćin bi prije korištenja svakog alata trebao pregledati njegovu potpunu definiciju i usporediti je s popisom odobrenih pouzdanih alata te tako otkriti sve promjene. Provjere parametara mogu pomoći u prepoznavanju potencijalno opasnih mogućnosti i njihovu označavanju.

Prijetnja br. 3: prekomjerna dopuštenja

Korisnici često MCP poslužiteljima i povezanim LLM-ovima (putem domaćina) dodjeljuju više dopuštenja nego što je potrebno za zadatak. Na primjer, dopuštenja za pisanje kada bi bilo dovoljno samo čitanje ili potpun pristup internom sustavu datoteka (kao što je Google Drive).

Takvo opsežno širenje dopuštenja može povećati opseg štete drugih ranjivosti, poput zlonamjernih poziva alata. Uobičajeno je da se dopuštenja „zbrajaju“ dok korisnici dodjeljuju privilegije tijekom svakodnevnog rada s AI alatima u tvrtki (gomilanje privilegija).

Kako se zaštititi od prekomjernih dopuštenja

Najizravniji način zaštite od ovog problema jest ograničavanje dopuštenja i OAuth opsega (čitanje, pisanje, potpuni pristup itd.). Odobrenja korisnika, osobito za osjetljive operacije, važan su dio toga, ali dopuštenja treba kontrolirati i na razini sustava (operacijski sustav, MCP domaćin i poslužitelj).

Prijetnja br. 4: slaba autentifikacija i autorizacija

Autentifikacija provjerava identitet korisnika ili aplikacija koje se povezuju s MCP poslužiteljem. Autorizacija određuje kojim alatima i resursima mogu pristupiti.

Loše konfigurirani MCP poslužitelji mogu prihvaćati zahtjeve ili tokene bez ispravne autentifikacije korisnika ili provođenja ograničenja pristupa. Osim toga, ako je provjera valjanosti slaba, ukradene vjerodajnice mogu zlonamjernim akterima omogućiti pristup.

Kako se zaštititi od slabe autentifikacije i autorizacije

Autentifikacija temeljena na OAuthu za udaljene MCP poslužitelje, kratkotrajni tokeni i kontrola pristupa temeljena na ulogama (RBAS) mjere su koje pomažu u ublažavanju slabe autorizacije. Pristup temeljen na ulogama koristan je jer korisnicima onemogućuje pristup podacima i alatima izvan njihovih dopuštenja, čak i ako sam poslužitelj ima pristup.

Prijetnja br. 5: curenje i zlouporaba vjerodajnica

MCP poslužitelji redovito koriste vjerodajnice poput API ključeva i OAuth pristupnih tokena za povezivanje s vanjskim uslugama. Ako su one izložene ili zloupotrijebljene, napadači mogu dobiti pristup osjetljivim podacima i funkcionalnostima.

Jedan je primjer prosljeđivanje tokena (token passthrough), pri čemu MCP poslužitelj prosljeđuje pristupni token drugoj usluzi bez provjere je li on doista namijenjen usluzi koja ga prima. To pak može dovesti do curenja podataka ako usluga primateljica nema odgovarajuću zaštitu.

Kako se zaštititi od curenja i zlouporabe vjerodajnica

Kratkotrajni tokeni uskog opsega i rotacija vjerodajnica učinkovito ograničavaju mjeru u kojoj zlonamjerni akteri mogu iskoristiti procurjele podatke. API ključeve i vjerodajnice uvijek treba sigurno pohranjivati pomoću upravitelja tajni.

Prijetnja br. 6: napadi zbunjenog zamjenika (confused deputy)

Napad zbunjenog zamjenika (confused deputy) događa se kada napadač navede pouzdanu aplikaciju da iskoristi svoja dopuštenja za izvođenje radnje koju legitimni korisnik nije odobrio. U ovom slučaju MCP poslužitelj je zamjenik.

Povećaj

Napadač će iskoristiti ranjivost MCP poslužitelja (kao što su slabe OAuth provjere) kako bi izveo zlonamjerni proces, poput poziva alata ili dohvaćanja podataka.

Kako se zaštititi od napada zbunjenog zamjenika

Provjera autorizacije, pri kojoj se za svaki poziv alata potvrđuje da pripada određenom korisniku, pomaže ograničiti napade zbunjenog zamjenika. Osim toga, osjetljive radnje, poput izvoza podataka, trebaju zahtijevati izričitu autorizaciju.

Prijetnja br. 7: zlonamjerni poslužitelji i kompromitirane ovisnosti

MCP poslužitelji mogu sadržavati zlonamjerni kod (u osnovi su vanjski programi) ili se oslanjati na kompromitirane ovisnosti, poput biblioteka trećih strana. To je problem lanca opskrbe softvera, a ne problem jedinstven za MCP.

Jedan jednostavan način na koji se to može dogoditi jest da napadač distribuira integraciju koja se čini legitimnom. Nakon postavljanja ona može ukrasti i ponovno upotrijebiti vjerodajnice, pristupiti osjetljivim podacima i izvoditi neovlaštene operacije.

Kako se zaštititi od zlonamjernih poslužitelja i kompromitiranih ovisnosti

Instalirajte MCP poslužitelje samo iz pouzdanih i provjerenih izvora. Ako je moguće, pregledajte njihov kod i uvijek provjerite sve vanjske ovisnosti. Pobrinite se da se poslužitelji redovito ažuriraju i zakrpaju.

Prijetnja br. 8: krivotvorenje zahtjeva na strani poslužitelja (SSRF)

Krivotvorenje zahtjeva na strani poslužitelja (SSRF) događa se kada napadač navede MCP poslužitelj da šalje mrežne zahtjeve na interne adrese kojima korisnik nije namjeravao pristupiti.

To se može dogoditi kada MCP poslužitelj izlaže alat koji dohvaća informacije s URL-a. Ako napadač može utjecati na parametar URL-a, može ga promijeniti u željenu mrežnu adresu, poput internog API-ja ili usluge u oblaku. To može dovesti do dohvaćanja osjetljivih podataka i njihove moguće dostupnosti

Kako se zaštititi od krivotvorenja zahtjeva na strani poslužitelja (SSRF)

MCP poslužitelji uvijek trebaju provjeravati URL-ove, blokirati pristup ograničenim internim mrežnim adresama i sprječavati odlazni mrežni pristup. Preusmjeravanja također trebaju slijediti ovaj protokol.

Prijetnja br. 9: otmica sesije

Pri otmici sesije napadač preuzima kontrolu nad aktivnom vezom između MCP klijenta i poslužitelja.

Na primjer, napadač bi mogao ukrasti identifikator sesije iz slabo zaštićene MCP aplikacije (npr. domaćina ili poslužitelja). Ako MCP poslužitelj prihvati taj identifikator, napadač potencijalno može pozivati alate s legitimnim dopuštenjima korisnika.

Kako se zaštititi

Rizik od otmice sesije može se smanjiti strogom provjerom identiteta u svim aplikacijama MCP sustava. Šifriranje između MCP klijenata i udaljenih poslužitelja također je ključno kako bi se spriječilo otkrivanje identifikatora sesije.

Prijetnja br. 10: napadi zamjenom (mix-up)

U napadu zamjenom (mix-up) napadač navodi MCP klijent da pošalje autorizacijski kod zlonamjernom autorizacijskom poslužitelju koji se nalazi između klijenta i MCP poslužitelja. Autorizacijski poslužitelj je aplikacija koja izdaje OAuth pristupne tokene nakon što provjeri je li zatraženi pristup autoriziran.

Povećaj

Ako se MCP domaćin povezuje s više usluga od kojih svaka koristi drugi autorizacijski poslužitelj, napadač potencijalno može preuzeti kontrolu nad jednim od njih (primjerice registriranjem zlonamjerne usluge) i navesti klijent da autorizacijski kod koji je izdao legitimni poslužitelj pošalje zlonamjernom poslužitelju. Ta zamjena napadaču može omogućiti da se lažno predstavi kao autorizirana aplikacija i dobije pristup zaštićenim uslugama.

Kako se zaštititi od napada zamjenom

MCP klijenti trebaju provjeravati identitet autorizacijskog poslužitelja tijekom cijelog OAuth procesa. Konkretno, trebaju usporediti identifikator izdavatelja poslužitelja (iss) s očekivanim identitetom i odbiti nepodudaranja.

Prijetnja br. 11: kompromitiranje lokalnog MCP poslužitelja

Mnogi MCP poslužitelji rade na korisnikovu lokalnom računalu. Korisnik može instalirati poslužitelj od treće strane ili ga sam izgraditi. Ako napadač uspije kompromitirati taj lokalni MCP poslužitelj, potencijalno može dobiti pristup velikim dijelovima lokalnog sustava.

Napadač može dobiti pristup na različite načine. Može distribuirati zlonamjerni poslužitelj prerušen u legitimnu integraciju, izmijeniti konfiguraciju MCP domaćina tako da izdaje zlonamjernu naredbu ili pristupiti MCP poslužitelju koji radi u okruženju s nedostatnim sigurnosnim kontrolama, primjerice putem DNS rebindinga, koji navodi preglednik da šalje zahtjeve usluzi na localhostu.

Kako se zaštititi od kompromitiranja lokalnog MCP poslužitelja

Pri korištenju lokalnih MCP poslužitelja važni su izolacija u Sandbox okruženju i strogi protokoli pristanka. MCP poslužitelje treba instalirati isključivo od pouzdanih pružatelja, a dopuštenja operacijskog sustava trebaju ograničiti kojim direktorijima mogu pristupiti.

Ranjivosti MCP-a često su stare prijetnje u novom ruhu

Ranjivosti MCP-a često proizlaze iz nove primjene poznatih rizika i metodologija napada. MCP napadačima donosi nove načine iskorištavanja tih ranjivosti kroz interakcije LLM-ova, MCP poslužitelja i vanjskih usluga.

Naravno, prijetnje specifične za MCP postoje. Ipak, vrijedi imati na umu da će standardni sigurnosni protokoli, poput provođenja stroge autorizacije, korištenja pouzdanih pružatelja i zaštite od ubacivanja upita, uvelike pomoći u zaštiti svake MCP implementacije.