Durchgesickerte MCP-Token

Was ist Durchgesickerte MCP-Token?

Ein im Klartext in einer MCP-Konfigurationsdatei gespeichertes Secret wird offengelegt, sobald etwas diese Datei zurückliest – auch ein KI-Assistent, der beim Debuggen einer Verbindung helfen soll. Sie sehen ein langlebiges Token ohne Ablaufdatum, das in einem Chat-Transkript wiedergegeben und von demjenigen, der es findet, gegen die echte Kunden-API verwendet wird. Sie führen die Offenlegung auf die Konfiguration zurück, nicht auf den Assistenten, der sie wiederholt hat, und ersetzen das hartcodierte Secret durch eine kurzlebige OAuth-Referenz mit begrenztem Geltungsbereich.

Was Sie lernen in Durchgesickerte MCP-Token

• Beachten Sie, dass ein langlebiges, weitreichendes persönliches Zugriffstoken, das in einer MCP-Konfigurationsdatei gespeichert ist, in dem Moment offengelegt wird, in dem irgendetwas, einschließlich eines KI-Assistenten, diese Datei zurückliest
• Verstehen Sie, warum ein KI-Assistent, der während der Fehlerbehebung eine vollständige Konfigurationsdatei in ein Chat-Transkript überträgt, eine private Debugging-Sitzung in dem Moment, in dem das Transkript geteilt wird, in ein öffentliches Leck verwandelt
• Identifizieren Sie die Warnsignale gefährlicher Zugangsdaten: kein Ablaufdatum, ein weiter Lese- und Exportbereich und keine Einschränkung auf einen bestimmten Aufrufer oder eine bestimmte Sitzung
• Ersetzen Sie ein hartcodiertes, langlebiges Secret in einer MCP-Konfiguration durch eine kurzlebige OAuth-Referenz mit begrenztem Geltungsbereich, die die Laufzeit beim Start auflöst, statt sie auf der Festplatte zu speichern
• Erklären Sie, warum das Korrigieren der Konfiguration allein einen Vorfall nicht schließt: Bereits offengelegte Zugangsdaten müssen auch an der Quelle widerrufen werden

Durchgesickerte MCP-Token — Trainingsschritte

1. Die Offenlegungskonsole

   Bobs Exposure-Konsole sammelt fortlaufend: Sie durchsucht öffentliche Paste-Seiten und geteilte Debugging-Ausgaben und gleicht alles ab, was wie Zugangsdaten eines Anbieters aussieht. Vor zwei Nächten hat sie einen Treffer bei Sarnholt Systems gemeldet.

2. Die Entdeckung

   Die Konsole speichert die Spur jedes Treffers: Von welchem Feed er kam, welches Muster übereinstimmte und in welchem Text er sich befand. Nichts davon erforderte eine Berührung von Sarnholt.

3. Zugangsdaten ohne Begrenzung

   Auf der Oberseite der Konsole ist genau zu sehen, was Bob in der Hand hält.

4. Kein Einbruch

   Die Konsole erklärt auch, woher das Token stammt und dass es sich nicht um einen Exploit handelt.

5. Das Wasser testen

   Bevor Bob etwas mit dem Token unternimmt, prüft er, ob die Zugangsdaten noch aktiv sind und was sie erreichen können. Er ruft den Introspection-Endpunkt der API auf; dieser berichtet über das Token selbst, statt Daten zurückzugeben.

6. Akzeptanz ohne weitere Prüfung

   Die Antwort kommt genauso zurück wie ein Aufruf von Sarnholts eigener Integration.

7. Die Liste ziehen

   Die Prüfung hat nur gezeigt, dass das Token antwortet. Bob richtet dieselben Zugangsdaten auf die Kundensammlung und verlangt alles, weil nichts in den Geltungsbereichen des Tokens ihn daran hindert.

8. Namen, keine Zeilen

   Die Antwort ist keine Anzahl, sondern die Kundenliste selbst. Sie wird in einem einzigen Aufruf mit Zugangsdaten zurückgegeben, die niemals eine Debugging-Sitzung hätten verlassen dürfen.

9. Warum das Token wertvoll war

10. Fortsetzen

    Bob hat fürs Erste, was er braucht: funktionierende Zugangsdaten und einen Blick darauf, was sie erreichen können. Er protokolliert den Erfolg, lässt die Konsole weiterlaufen und zieht weiter.