Das Model Context Protocol (MCP) ist noch recht jung, vom November 2024, und seit einiger Zeit tauchen immer häufiger Sicherheitslücken in Verbindung damit auf – und zwar sowohl server- als auch clientseitig. Umgekehrt gibt es Tausende von MCP-Quellen im Netz, die sich mit wenigen Klicks in die eigene KI-Anwendung einbinden lassen.

Eine lange, kuratierte Liste findet sich auf GitHub. Umgekehrt hat Docker eine Liste mit Angriffspunkten und Sicherheitsproblemen gesammelt. Konkrete Beispiele sind ein Angriff über Repositories auf den MCP-Server GitHub oder eine Attacke auf die Cursor IDE via MCP. Mirko Ross, Gründer und CEO der Sicherheitsfirma asvin spricht mit heise developer über die Sicherheit des als „USB-C der KI“ bezeichneten Protokolls.

Mirko, Du beschäftigst Dich schon länger mit der Sicherheit von KI und MCP, wo liegen denn die Hauptschwachstellen Deiner Meinung nach?

MCP ist in Hinblick auf eine einfache Verknüpfung von Applikationen mit GenAI-Modellen hin entworfen worden, das Ganze in einem sich schnell entwickelnden AI-Tech-Umfeld. Die Schwachstelle liegt in der Genese des Protokolls: Das Design von MCP ist auf eine einfache und schnelle Integration ausgelegt, was zulasten der Protokoll- und Systemsicherheit geht. Zudem haben wir generell noch viel zu wenig die Cybersicherheit-Schwachstellen von GenAI-Systemen umfassend begriffen. Wir sehen in einem täglichen Rhythmus, wie Angreifer sich neue Muster und Jailbreak-Attacken ausdenken und anwenden, mit denen die angegriffenen Systeme aus den Sicherheitsschranken ausbrechen. MCP hat im Protokoll keine wirksamen Sicherheitselemente zur Abwehr solcher Angriffe.

Gibt es Risiken, die ihre Ursachen nicht im Protokoll haben, aber bei der Nutzung von MCP dennoch eine Rolle spielen?

Ja, insbesondere Angriffe in der Softwarelieferkette sind eine Gefahr. Angreifer publizieren Bibliotheken für MCP-Clients und Server, die Schadcode enthalten, in öffentlichen Code-Repositorys. Gerade unerfahrene Entwicklerinnen und Entwickler, die nach einem Einstieg in MCP und KI-Agentensystem suchen, sind hier potenzielle Opfer der Angreifer. Ist eine solche Bibliothek einmal integriert, kann der darin enthaltene Schadcode in Firmennetzwerken ausgeführt werden – beispielsweise als Einfallstor für Ransomware-Angriffe.

Mit Void Programming, also wenn GenAI Programmcode für KI-Agenten oder MCP-Services erzeugt, ergeben sich zusätzliche Sicherheitsprobleme: Bereits jetzt kopieren Angreifer populäre Softwarebibliotheken, kompromittieren sie mit Schadcode und publizieren sie unter ähnlich lautenden Namen. Ziel ist es, dass GenAI bei der Codeerzeugung nicht die Originalbibliothek referenziert, sondern die ähnlich benannte schädliche Kopie. Daher gelten auch bei Void Programming die Grundregeln: erstens jede extern eingebundene Quelle auf Vertrauenswürdigkeit prüfen und zweitens den erzeugten Code auf Schadcode scannen, bevor dieser in eine Produktivumgebung gelangt.

Eine erste Korrektur des Protokolls, die Authentifizierung betreffend, gab es Ende April. Hätte man das Protokoll gleich von Anfang an mehr auf Sicherheit optimieren sollen?

MCP wurde in einem aufgeheizten Markt unter hohem Zeitdruck konzipiert. Dabei spielt der Gedanke des MVP – Minimal Viable Product – eine Rolle. Also die schnelle Einführung von Grundfunktionen, die von Anwendern angenommen werden. Aus Sicht der Cybersecurity bedeutet MVP allerdings „Most vulnerability possibilities“.

Es gibt von der OWASP seit kurzem Empfehlungen für den MCP-Einsatz. Bieten sie umfassende Sicherheit für Server- und Client-Anbieter?

Wer sich an die OWASP-Empfehlungen hält, ist sich zumindest der Risiken einer MCP-Integration bewusst und kann damit die entsprechenden technischen Schutzmaßnahmen aufbauen. Einen umfassenden Schutz gibt es allerdings nicht – denn GenAI-Systeme sind leider grundlegend angreifbar und versierte Täter sind sehr kreativ im Design der Angriffe.

Wie kann sich ein Serveranbieter vor Angriffen am besten schützen?

Erstens gilt es, die Grundregeln der Softwareentwicklung zu beachten: Entwicklerinnen und Entwickler müssen alle verwendeten Bibliotheken per SBOM dokumentieren und auf Schadcode scannen. Zweitens müssen sie MCP-basierte Dienste über Authentifizierung einbinden. Dabei müssen die Identitäten der Authentifizierungen gemanagt werden. Und drittens gilt es, die MCP-Dienste in der Applikationsarchitektur von anderen IT-Diensten zu segmentieren und beispielsweise über Zero-Trust-Prinzipien abzusichern.

Inzwischen gibt es große Sammlungen an einsatzbereiten Servern, die jedermann mit ein paar Klicks einbinden kann. Welche Risiken bestehen denn für die Clients beim Anzapfen von MCP-Quellen?

Sehr erfolgreiche Jailbreak-Angriffe auf GenAI arbeiten mit schädlichen Prompts, die die Angreifer beispielsweise in Dateien verstecken. Soll beispielsweise eine GenAI eine Zusammenfassung einer Word- oder PowerPoint-Datei erstellen, wird der darin versteckte Prompt vom KI-Agenten ausgeführt. Wir müssen lernen, dass wir solche Dateien auf schädliche Prompts überprüfen, bevor wir sie der GenAI zur Bearbeitung übergeben.

Worauf sollte man achten, wenn man MCP-Quellen einbinden will?

Generell gilt: nur Quellen einbinden, die als vertrauensvoll gelten und über eine gute Reputation verfügen. Unbekannte Quellen sollte man nicht einbinden.

Mirko, vielen Dank für das Gespräch!

(who)

Richard Seidl und Lars Luthmann gehen in dieser Folge des Podcasts Software Testing der Frage nach, welche Bedeutung „Developer Friendliness“ in der Softwareentwicklung hat. Sie plaudern darüber, wie ein angenehmes Arbeitsklima und geeignete Werkzeuge, wie Testschnittstellen und Testdatengeneratoren, den Alltag von Entwicklerinnen und Entwicklern erleichtern können.

Lars Luthmann teilt Einblicke aus einem Automobilprojekt, in dem innovative Ansätze wie REST-Schnittstellen und Mock-Services den Testprozess optimierten.

„Wenn man diese Maßnahmen dann umsetzt und die am Ende tatsächlich auch den Nutzen haben, den man denkt, dann spart man langfristig Zeit. Und das ist eben der eine ganz wichtige Punkt meiner Meinung nach.“ – Lars Luthmann

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Developer Friendliness für bessere Software – Lars Luthmann“ und steht auf YouTube bereit.

(mdo)

Durch laufende Anfragen an den Whatsapp-Server können Angreifer die Verschlüsselung für ein bestimmtes Opfer kurzzeitig um eine Stufe senken – oder es für alle unerreichbar machen (Denial of Service). Wertvoller sind wohl die nebenbei gesammelten Informationen über die Zielperson. Auf der IT-Sicherheitsmesse DEFCON 2025 haben am Sonntag (Ortszeit) die österreichischen Sicherheitsforscher Gabriel Gegenhuber und Maximilian Günther von der Universität Wien ihre Erkenntnisse präsentiert.

Im Zentrum stand dabei ein Sicherheitsmerkmal namens Perfect Forward Secrecy (PFS). Dabei wird – zusätzlich zu länger gültigen Schlüsselpaaren der Gesprächspartner – für jede Nachricht ein eigenes Schlüsselpaar erzeugt. Das soll verhindern, dass mit einem aufgedeckten Schlüssel auch andere Nachrichten entschlüsselt werden können. Das bedeutet allerdings, dass laufend Einmalschlüssel ausgehandelt werden müssen.

Bei asynchroner Kommunikation, wie sie für Whatsapp und Signal typisch ist, sind die Teilnehmer nicht unbedingt gleichzeitig online; in so einem Fall schlägt das direkte Aushandeln eines Schlüsselpaars fehl. Das Signal-Protokoll, das in einer Variante auch Grundlage Whatsapps ist, löst dieses Problem durch vorausschauenden Upload von Einmalschlüsseln auf den Server. Dort können sie jederzeit von Dritten abgerufen werden. Dann werden Nachrichten dreifach Ende-zu-Ende verschlüsselt: mit dem statischen Identitätsschlüsselpaar, dem zirka monatlich ausgetauschten, signierten Vorschlüsselpaar (Prekey) und mit dem PFS-Schlüsselpaar. Nur wer alle drei Schlüssel knackt, kann eine abgefangene Nachricht entschlüsseln.

Die Angriffsmethode

Der von den Österreichern gezeigte Angriff erlaubt, die Verwendung der Einmalschlüssel für alle Whatsapp-Nachrichten einer Sitzung von der ersten Nachricht bis inklusive der ersten Antwort zu verunmöglichen. Diesen Nachrichten fehlt dann die PFS, die Teilnehmer einer Whatsapp-Unterhaltung erhalten darauf aber keinen Hinweis. Der Angreifer muss „nur noch“ die beiden anderen Schlüssel knacken. Die Absenkung des Sicherheitsniveaus ist also moderat.

Die theoretische Möglichkeit wird schon in Anmerkungen zum Signal-Protokoll angesprochen und wurde von den Österreichern erstmals in der Praxis unter Beweis gestellt. Aber das ist aber nicht das Ende der Geschichte.

Die Methode ist erstaunlich simpel: Der Angreifer nutzt einen alternativen Whatsapp-Client und muss die Telefonnummer des Zielkontos kennen. Damit fordert er wiederholt neue PFS-Schlüssel vom Server an. Schickt das Endgerät des Zielkontos nicht schnell genug neue Schlüssel, was insbesondere iPhones und Macs schwerzufallen scheint, ist der Vorrat alsbald erschöpft. Whatsapp hat offenbar keine Beschränkung (Rate Limiting) für solche Schlüsselbestellungen eingebaut. In den Tests der Forscher der Universität Wien und SBA Researchs hat es trotz Abwarten jeder einzelnen Serverantwort nur 40 Sekunden bis zwei Minuten gedauert. Mit parallelen Abfragen durch mehrere Endgeräte geht es sogar in zehn Sekunden.

Außerdem unterscheiden sich die Initialisierungswerte der drei abrufbaren Schlüsselarten je nach Betriebssystem des Zielclients. Das mag bei der Auswahl von Malware für einen gezielten Angriff über einen anderen Kanal helfen.

Das Datenschutzproblem

Erstaunlich viel lässt sich aus der Art und Weise ableiten, wie neue Einmalschlüssel auf dem Server auftauchen. Einfachste Variante: Es tauchen keine neuen Schlüssel auf. Dann ist das jeweilige Endgerät aller Wahrscheinlichkeit nach offline.

Durch wiederholte Schlüsselerschöpfung kann ein Angreifer langfristige, heimliche Beobachtungen anstellen: Ist beispielsweise ein bestimmtes Desktopgerät oder eine bestimmte Browserinstanz regelmäßig zu Bürozeiten online, kann unter Umständen auf den Aufenthaltsort des Zieles geschlossen werden. Umgekehrt lassen neue Schlüssel von einem meist nur Abends oder am Wochenende genutzten Desktoprechner auf den Aufenthalt des überwachten Whatsapp-Users zu Hause schließen.

Tauchen neue Schlüssel auf, lässt sich aus dem Tempo des „Nachladens“ bedingt auf das Endgerätemodell schließen (fingerprinting). In den Tests der Forscher gelang die Schlüsselerschöpfung beispielsweise bei einem Samsung Galaxy A54 mit eingeschaltetem Bildschirm und LTE-Datenverbindung nur bei vier Prozent der Anfragen. Bei iPhones hingegen fast immer (iPhone SE 93%, iPhone 8 zu 88%, iPhone 11 zu 80%). Standby oder WLAN-Anbindung bremsen das Nachladen tendenziell weiter.

Ein Poco X3 über LTE-Mobilfunk mit aktivem Bildschirm schaffte den Schlüsselupload zügig, sodass es nur bei 17 Prozent der Anforderungen zu einer Erschöpfung kam. Im Standby-Modus über WLAN waren die Angreifer hingegen zu 76 Prozent erfolgreich. (In diesem Punkt ähnelt der PFS-Erschöpfungsangriff dem ebenfalls von den beiden Österreichern auf der DEFCON 2025 vorgestellten Angriff mittels heimlicher Zustellbestätigungen auf Whatsapp und Signal, wo ebenfalls device fingerprinting möglich ist.)