Tegye biztonságossá MCP-rendszerét: 11 gyakori kockázat és a védekezés módjai

Az MCP-kockázatok nagyjából három kategóriába sorolhatók: az LLM manipulálása, az adat- és hozzáférés-biztonság, valamint az infrastruktúra sebezhetőségei.

Mivel az MCP-szerverek gyakran a belső rendszerek széles köréhez biztosítanak hozzáférést, a lehetséges biztonsági kockázat magas. A bekövetkezés valószínűsége azonban nagymértékben a konfigurációtól függ.

Magánszemélyek és vállalatok egyaránt számos lépést tehetnek rendszereik védelméért, a protokolloknak pedig mindig arányban kell állniuk azokkal a képességekkel és adatokkal, amelyeket a csatlakoztatott MCP-szerverek elérhetővé tehetnek.

Mi az MCP és az MCP-biztonság?

A Model Context Protocol (MCP) az Anthropic által létrehozott nyílt szabvány, amely LLM-alapú alkalmazásokat (más néven hostokat) kapcsol külső rendszerekhez.

Egy MCP-rendszer három fő összetevőből áll: a hostból, a kliensből és a szerverből. A host – amely gyakran egy AI-asszisztens – egy kliensen keresztül csatlakozik egy külső MCP-szerverhez. Ezután kéréseket küldhet külső funkciók (eszközök) futtatására, illetve adatok (erőforrások) vagy promptok lekérésére, hogy azokat az LLM kontextusablakához adja.

Nagyítás

Az MCP-biztonság azokat a protokollokat jelenti, amelyek egy MCP-rendszer kapcsolatait és összetevőit védik. Számos kulcsfontosságú kihívás kifejezetten az MCP-re jellemző, például az, hogy az AI-alkalmazások gyakran ügynöki képességekkel rendelkeznek, és az üzenetekbe rosszindulatú utasítások ágyazhatók be.

Az olyan ismert problémák is gondot okoznak, amelyek nem kifejezetten az MCP-re jellemzők, mint a promptinjektálás, a gyenge hitelesítés és a nem biztonságos külső integrációk. Mint minden számítógépes rendszer, az MCP is eljárási protokollok – például kizárólag megbízható szerverek használata – és technikai kontrollok – például API-átjárók – kombinációjára támaszkodik a védelem érdekében.

Mennyire súlyosak az MCP-fenyegetések?

Az MCP gyorsan népszerű LLM-technológiává vált, és számos szervezet, valamint fogyasztóknak szóló alkalmazás használja. Mivel az MCP-szerverek kódban megírt programok, ugyanúgy vannak sebezhetőségeik, mint bármely más alkalmazásnak.

Ha azonban a szervezetek ellenőrzött környezetben telepítik az MCP-t, az általában biztonságos. Óriási különbség van aközött, hogy valaki megbízható szerverekkel és ellenőrzött jogosultságokkal épít rendszert, vagy egy autonóm ügynököt kapcsol rá egy tucat ellenőrizetlen szerverre.

1. fenyegetés: Közvetett promptinjektálás

A támadó az LLM-nek szánt utasításokat helyezhet el egy olyan dokumentumban, weboldalon vagy eszközkimenetben, amelyet egy MCP-szerver visszaad. Ha a host ezt a tartalmat hozzáadja a kontextusablakhoz, fennáll a lehetősége, hogy az LLM valódi utasításnak tekinti.

Ráadásul ezek az utasítások első ránézésre helyénvalónak tűnhetnek. Egy lekért ügyfélszolgálati jegy például arra utasíthatja az LLM-et, hogy a válasz létrehozása előtt exportáljon érzékeny ügyféladatokat.

Védekezés a közvetett promptinjektálás ellen

A promptinjektálást jellemzően a host szintjén kell kezelni. A külső tartalmat nem megbízhatóként kell megjelölni, az érzékeny információkra irányuló kérésekhez pedig a folyamatba bevont ember tájékozott jóváhagyását kell megkövetelni. Hasznos lehet az olyan biztonsági tesztelés is, amely rosszindulatú dokumentumok vagy adatok meghívásával vizsgálja, hogyan reagál a host és az LLM.

2. fenyegetés: Eszközmérgezés és rug pull támadások

Az eszközmérgezéses támadás során rosszindulatú kódot adnak hozzá egy MCP-eszköz leírásához vagy sémájához. Ez befolyásolhatja az LLM-et a felderítési fázisban, amikor az MCP először elérhetővé teszi a rendelkezésre álló eszközöket.

Nagyítás

A rug pull az eszközmérgezés egy speciális típusa, amelynek során a jóváhagyott metaadatokat módosítják. Az eszközmérgezés e formája ahelyett, hogy közvetlenül egy rosszindulatú eszközt hívna meg, azt változtathatja meg, ahogyan a modell a megbízható eszközöket használja.

Védekezés az eszközmérgezés és a rug pull támadások ellen

A hostnak használat előtt meg kell vizsgálnia minden eszköz teljes definícióját, és össze kell vetnie azt a jóváhagyott, megbízható eszközök listájával, így észlelve az esetleges változásokat. A paraméter-ellenőrzések segíthetnek azonosítani és megjelölni a potenciálisan veszélyes képességeket.

3. fenyegetés: Túlzott jogosultságok

Gyakori, hogy a felhasználók több jogosultságot adnak az MCP-szervereknek és a (hoston keresztül) csatlakoztatott LLM-eknek, mint amennyi egy feladathoz szükséges. Például írási jogosultságot, amikor a csak olvasási hozzáférés is elegendő lenne, vagy teljes hozzáférést egy belső fájlrendszerhez (például a Google Drive-hoz).

A jogosultságok ilyen mértékű burjánzása megnövelheti más sebezhetőségek, például a rosszindulatú eszközhívások hatósugarát. Gyakori, hogy a jogosultságok „összeadódnak”, ahogy a felhasználók egy vállalatnál az AI-eszközökkel végzett mindennapi munkájuk során újabb és újabb jogosultságokat adnak meg (jogosultság-felhalmozás).

Védekezés a túlzott jogosultságok ellen

A probléma elleni védekezés legközvetlenebb módja a jogosultságok és az OAuth-hatókörök (olvasás, írás, teljes hozzáférés stb.) korlátozása. Ennek fontos része a felhasználói jóváhagyás, különösen az érzékeny műveleteknél, de a jogosultságokat rendszerszinten (az operációs rendszer, az MCP-host és a szerver szintjén) is szabályozni kell.

4. fenyegetés: Gyenge hitelesítés és engedélyezés

A hitelesítés az MCP-szerverhez csatlakozó felhasználók vagy alkalmazások identitását ellenőrzi. Az engedélyezés azt határozza meg, hogy mely eszközökhöz és erőforrásokhoz férhetnek hozzá.

A rosszul konfigurált MCP-szerverek a felhasználók megfelelő hitelesítése vagy a hozzáférési korlátozások érvényesítése nélkül is elfogadhatnak kéréseket vagy tokeneket. Emellett gyenge ellenőrzés esetén a rosszindulatú szereplők ellopott hitelesítő adatokkal is hozzáférést szerezhetnek.

Védekezés a gyenge hitelesítés és engedélyezés ellen

A távoli MCP-szerverek OAuth-alapú hitelesítése, a rövid élettartamú tokenek és a szerepköralapú hozzáférés-vezérlés (RBAC) mind olyan intézkedések, amelyek segítenek mérsékelni a gyenge engedélyezés kockázatát. A szerepköralapú hozzáférés azért hasznos, mert megakadályozza, hogy a felhasználók a jogosultságaikon túli adatokhoz és eszközökhöz férjenek hozzá, még akkor is, ha maga a szerver rendelkezik hozzáféréssel.

5. fenyegetés: Hitelesítő adatok kiszivárgása és visszaélés velük

Az MCP-szerverek rendszeresen használnak hitelesítő adatokat, például API-kulcsokat és OAuth hozzáférési tokeneket a külső szolgáltatásokhoz való csatlakozáshoz. Ha ezek nyilvánosságra kerülnek, vagy visszaélnek velük, a támadók érzékeny adatokhoz és funkciókhoz férhetnek hozzá.

Erre példa a tokenátadás (token passthrough), amikor egy MCP-szerver úgy továbbít egy hozzáférési tokent egy másik szolgáltatásnak, hogy nem ellenőrzi, valóban a fogadó szolgáltatásnak szánták-e. Ez pedig kiszivárgáshoz vezethet, ha a fogadó szolgáltatás védelme nem megfelelő.

Védekezés a hitelesítő adatok kiszivárgása és a velük való visszaélés ellen

A rövid élettartamú, szűk hatókörű tokenek és a hitelesítő adatok rendszeres cseréje hatékonyan korlátozza, hogy a rosszindulatú szereplők milyen mértékben használhatják fel a kiszivárgott adatokat. Az API-kulcsokat és a hitelesítő adatokat mindig biztonságosan, titokkezelő segítségével kell tárolni.

6. fenyegetés: Megtévesztett megbízott (confused deputy) típusú támadások

Megtévesztett megbízott (confused deputy) típusú támadásról akkor beszélünk, ha a támadó ráveszi egy megbízható alkalmazást, hogy a jogosultságait egy olyan művelet végrehajtására használja, amelyet a jogos felhasználó nem engedélyezett. Ebben az esetben az MCP-szerver a megbízott.

Nagyítás

A támadó kihasználja az MCP-szerver valamely sebezhetőségét (például a gyenge OAuth-ellenőrzést), hogy rosszindulatú folyamatot – például eszközhívást vagy adatlekérést – hajtson végre.

Védekezés a megtévesztett megbízott típusú támadások ellen

Az engedélyezés validálása – amelynek során minden eszközhívásról ellenőrzik, hogy egy adott felhasználóhoz tartozik-e – segít korlátozni a megtévesztett megbízott típusú támadásokat. Emellett az érzékeny műveletekhez, például az adatexportáláshoz, kifejezett engedélyt kell megkövetelni.

7. fenyegetés: Rosszindulatú szerverek és kompromittált függőségek

Az MCP-szerverek tartalmazhatnak rosszindulatú kódot (lényegében külső programokról van szó), vagy kompromittált függőségekre, például harmadik féltől származó könyvtárakra támaszkodhatnak. Ez a szoftverellátási lánc problémája, nem pedig kizárólag az MCP-re jellemző probléma.

Ez egyszerűen megtörténhet például úgy, hogy a támadó egy legitimnek tűnő integrációt terjeszt. A beállítás után az képes ellopni és újrafelhasználni a hitelesítő adatokat, hozzáférni érzékeny adatokhoz, és jogosulatlan műveleteket végrehajtani.

Védekezés a rosszindulatú szerverek és a kompromittált függőségek ellen

Csak megbízható és ellenőrzött forrásokból telepítsen MCP-szervereket. Ha lehetséges, tekintse át a kódjukat, és mindig ellenőrizze a külső függőségeket. Gondoskodjon arról, hogy a szerverek rendszeresen frissítéseket és javításokat kapjanak.

8. fenyegetés: Szerveroldali kéréshamisítás (SSRF)

Szerveroldali kéréshamisításról (SSRF) akkor beszélünk, ha a támadó ráveszi az MCP-szervert, hogy hálózati kéréseket küldjön olyan belső címekre, amelyekhez a felhasználó nem kívánt hozzáférni.

Ez akkor fordulhat elő, ha egy MCP-szerver olyan eszközt tesz elérhetővé, amely egy URL-ről kér le információkat. Ha a támadó befolyásolni tudja az URL-paramétert, a kívánt hálózati címre módosíthatja, például egy belső API-ra vagy felhőszolgáltatásra. Ennek következtében érzékeny adatokat kérhetnek le, amelyek akár hozzáférhetővé is válhatnak

Védekezés a szerveroldali kéréshamisítás (SSRF) ellen

Az MCP-szervereknek mindig validálniuk kell az URL-eket, blokkolniuk kell a korlátozott belső hálózati címekhez való hozzáférést, és meg kell akadályozniuk a kimenő hálózati hozzáférést. Az átirányításokra is ugyanezt a protokollt kell alkalmazni.

9. fenyegetés: Munkamenet-eltérítés

Munkamenet-eltérítés során a támadó átveszi az irányítást egy MCP-kliens és egy szerver közötti aktív kapcsolat felett.

A támadók például ellophatnak egy munkamenet-azonosítót egy gyengén védett MCP-alkalmazásból (pl. egy hostból vagy szerverből). Ha az MCP-szerver elfogadja ezt az azonosítót, a támadó a felhasználó legitim jogosultságaival hívhat meg eszközöket.

Védekezés ellene

A munkamenet-eltérítés kockázata csökkenthető az MCP-rendszer összes alkalmazására kiterjedő szigorú identitás-ellenőrzéssel. Az MCP-kliensek és a távoli szerverek közötti titkosítás is elengedhetetlen ahhoz, hogy a munkamenet-azonosítókat ne lehessen kifürkészni.

10. fenyegetés: Összekeveréses (mix-up) támadások

Összekeveréses támadás során a támadó ráveszi az MCP-klienst, hogy egy engedélyezési kódot egy rosszindulatú engedélyezési szervernek küldjön, amely a kliens és az MCP-szerver között helyezkedik el. Az engedélyezési szerver olyan alkalmazás, amely OAuth hozzáférési tokeneket bocsát ki, miután ellenőrizte, hogy a kért hozzáférés engedélyezett-e.

Nagyítás

Ha egy MCP-host több szolgáltatáshoz csatlakozik, amelyek mindegyike más engedélyezési szervert használ, a támadó potenciálisan átveheti az irányítást az egyik felett (például egy rosszindulatú szolgáltatás regisztrálásával), és elérheti, hogy a kliens egy legitim szerver által kibocsátott engedélyezési kódot a rosszindulatú szervernek küldjön el. Ez az összekeverés lehetővé teheti a támadó számára, hogy megszemélyesítse az engedélyezett alkalmazást, és hozzáférjen a védett szolgáltatásokhoz.

Védekezés az összekeveréses támadások ellen

Az MCP-klienseknek az OAuth-folyamat során végig ellenőrizniük kell az engedélyezési szerver identitását. Konkrétan össze kell vetniük a szerver kibocsátóazonosítóját (iss) a várt identitással, és el kell utasítaniuk az eltéréseket.

11. fenyegetés: Helyi MCP-szerver kompromittálása

Számos MCP-szerver a felhasználó helyi gépén fut. A felhasználó telepítheti a szervert egy külső féltől, vagy maga is létrehozhatja. Ha egy támadó kompromittálni tudja ezt a helyi MCP-szervert, potenciálisan a helyi rendszer nagy részéhez hozzáférhet.

A támadók többféleképpen is hozzáférést szerezhetnek. Terjeszthetnek legitim integrációnak álcázott rosszindulatú szervert, módosíthatják egy MCP-host konfigurációját úgy, hogy az rosszindulatú parancsot adjon ki, vagy hozzáférhetnek egy elégtelen biztonsági kontrollokkal rendelkező környezetben futó MCP-szerverhez, például DNS-rebinding révén, amely ráveszi a böngészőt, hogy kéréseket küldjön egy localhoston futó szolgáltatásnak.

Védekezés a helyi MCP-szerver kompromittálása ellen

A helyi MCP-szerverek használatakor fontos a sandbox alkalmazása és a szigorú hozzájárulási protokollok betartása. MCP-szervereket kizárólag megbízható szolgáltatóktól szabad telepíteni, az operációs rendszer jogosultságainak pedig korlátozniuk kell, hogy mely mappákhoz férhetnek hozzá.

Az MCP-sebezhetőségek gyakran régi fenyegetések új köntösben

Az MCP-sebezhetőségek gyakran ismert kockázatok és támadási módszerek új alkalmazásaiból erednek. Az MCP az LLM-ek, az MCP-szerverek és a külső szolgáltatások interakciói révén új lehetőségeket kínál a támadóknak e sebezhetőségek kihasználására.

Természetesen léteznek kifejezetten az MCP-re jellemző fenyegetések is. Érdemes azonban szem előtt tartani, hogy a szokásos biztonsági protokollok – például a szigorú engedélyezés érvényesítése, a megbízható szolgáltatók használata és a promptinjektálás elleni védekezés – sokat segítenek bármely MCP-implementáció védelmében.