Compatibility at a Cost: Systematic Discovery and Exploitation of MCP Clause-Compliance Vulnerabilities

Dit artikel introduceert het eerste systematische raamwerk voor het analyseren en uitbuiten van 'compatibiliteitsmisbruik'-aanvallen in de Model Context Protocol (MCP), waarbij een taal-onafhankelijke representatie en LLM-gestuurde statische analyse worden gebruikt om kwetsbaarheden in SDK-implementaties op te sporen die ontstaan door optionele clausules.

Nanzi Yang, Weiheng Bai, Kangjie Lu

Gepubliceerd Thu, 12 Ma
📖 5 min leestijd🧠 Diepgaand

Each language version is independently generated for its own context, not a direct translation.

Hier is een uitleg van het onderzoek in eenvoudig Nederlands, met behulp van creatieve vergelijkingen om het begrijpelijk te maken.

De Kern: De "USB-C" van AI die te flexibel is

Stel je voor dat MCP (Model Context Protocol) de nieuwe USB-C-poort is voor kunstmatige intelligentie (AI). Vroeger had elke AI-apparaat zijn eigen eigenaardige stekker en kabel, wat een chaos was. MCP is de standaard die alles op één manier aansluit, zodat elke AI (zoals ChatGPT of Copilot) makkelijk kan praten met externe tools (zoals een database of een zoekmachine).

Maar er zit een addertje onder het gras. Om ervoor te zorgen dat deze poort voor iedereen werkt (of het nu een simpele chatbot is of een complexe robot), hebben de ontwerpers de regels extreem flexibel gemaakt.

Het Probleem: "Het mag, maar hoeft niet"

In de wereld van computerregels zijn er drie soorten instructies:

  1. MOETEN (MUST): Dit is verplicht.
  2. MOETEN (SHOULD): Dit is een sterk advies, maar je mag het negeren als je een goede reden hebt.
  3. MAG (MAY): Dit is optioneel.

Het probleem is dat 78,5% van de regels in MCP in de categorie "MOETEN" of "MAG" vallen. De ontwerpers dachten: "Laten we zoveel mogelijk opties geven, zodat elke ontwikkelaar zijn eigen AI kan bouwen."

De analogie:
Stel je voor dat je een veiligheidsinspectie doet voor een nieuw gebouw. De regels zeggen: "De branddeur MOET dicht blijven, tenzij je een noodalarm hebt, en dan MAG je hem openen."
De ontwerpers van het gebouw (de AI-ontwikkelaars) dachten: "Oh, we hebben geen noodalarm nodig, dus we bouwen de deur niet eens in."
Of: "We hebben een noodalarm, maar we vergeten de sensor aan te sluiten."

Voor de ontwerper is dit geen fout; het is een keuze om het gebouw lichter en flexibeler te maken. Maar voor een inbreker (de hacker) is dit een open raam. Omdat de sensor ontbreekt, kan de inbreker binnenkomen zonder dat het alarm afgaat.

Wat hebben de onderzoekers ontdekt?

De onderzoekers van de Universiteit van Minnesota hebben ontdekt dat deze "flexibiliteit" een nieuw soort hackersaanval mogelijk maakt, die ze "Compatibiliteits-misbruik" noemen.

Ze hebben een super-rekenmachine (een automatisch gereedschap) gebouwd om alle verschillende versies van de software (in 10 verschillende programmeertalen zoals Python, Java, etc.) te controleren. Ze zochten niet naar bekende hackers, maar keken naar wat er ontbreekt.

Hun methode in drie stappen:

  1. De Vertaler (IR Generator): Ze vertalen alle verschillende programmeertalen naar één universele taal, zodat ze ze allemaal kunnen vergelijken.
  2. De Controleur (LLM + Statistiek): Ze gebruiken een slimme AI (LLM) om te kijken: "Zegt de regel dat er een waarschuwing moet komen als er iets verandert? En is die waarschuwing in de code wel aanwezig?"
  3. De Hacker-Simulatie: Ze vragen zich af: "Als deze waarschuwing ontbreekt, kan een boze hacker hier iets mee?"

De Gevaren: Stilte is gevaarlijk

Ze vonden 1.265 potentiële risico's in slechts 10 softwarepakketten. Hier zijn drie voorbeelden van wat er kan gebeuren:

  1. De Stille Injectie (Silent Prompt Injection):

    • De Regel: Als een tool verandert, moet de server de AI waarschuwen.
    • De Fout: In de Python-versie is deze waarschuwing vergeten.
    • Het Gevolg: Een boze server kan de beschrijving van een tool veranderen in een giftige instructie. De AI ziet dit niet als een verandering (want er kwam geen waarschuwing) en voert de opdracht uit. De gebruiker merkt niets. Het is alsof iemand je huisdier vermomt als een vriend, en jij laat hem binnen zonder te twijfelen.
  2. De Drukke Gast (DoS - Denial of Service):

    • De Regel: De frequentie van "ping" (controle) moet instelbaar zijn.
    • De Fout: In de Python-versie is dit niet instelbaar.
    • Het Gevolg: Een boze server kan duizenden keren per seconde "hallo" roepen. De AI wordt hierdoor overbelast en stopt met werken.
  3. De Valse Sleutel (Token Misbruik):

    • De Regel: Je mag alleen sleutels (tokens) gebruiken die door de juiste beheerder zijn uitgegeven.
    • De Fout: De software controleert niet wie de sleutel heeft uitgegeven, alleen of hij nog geldig is.
    • Het Gevolg: Een hacker kan een sleutel van Server A stelen en die gebruiken bij Server B. De software denkt: "Oh, de sleutel is geldig, laat binnen!" terwijl het een valse sleutel is.

De Oplossing en Impact

De onderzoekers hebben niet alleen de fouten gevonden, maar ook de ontwerpers van MCP ervan overtuigd dat dit een serieus probleem is.

  • Erkenning: Ze hebben 26 meldingen gedaan. De meeste werden bevestigd. Vijf werden als "zeer hoog risico" (P0/P1) bestempeld.
  • Verandering: De MCP-gemeenschap is zo onder de indruk dat ze het gereedschap van de onderzoekers willen integreren in hun officiële testproces. In plaats van dat elke ontwikkelaar handmatig moet controleren, wordt dit gereedschap gebruikt om te zorgen dat nieuwe versies van de software veilig zijn voordat ze vrijgegeven worden.

Samenvatting in één zin

Dit onderzoek toont aan dat te veel vrijheid in de regels voor AI-verbindingen leidt tot gevaarlijke gaten in de beveiliging, en dat we automatisch gereedschap nodig hebben om te controleren of ontwikkelaars die gaten niet per ongeluk open laten voor hackers.

Het is een waarschuwing: Compatibiliteit is geweldig, maar niet als het ten koste gaat van veiligheid.