Supply-Chain-Angriffe – Bedrohungen und Schutzmechanismen (Teil 2)

Im ersten Teil Supply-Chain-Angriffe – Bedrohungen und Schutzmechanismen haben wir Abhängigkeiten zu Frameworks und Bibliotheken beschrieben und entsprechende Angriffsvektoren und Schutzmassnahmen aufgezeigt. Im zweiten und vorerst letzten Teil beleuchten wir zwei weitere Aspekte der Supply Chain hinsichtlich Sicherheit:

1. Managed Services, also von Drittanbietern verwaltete und gewartete Dienste. Dazu gehören Dienste von Cloudanbietern – sowohl Low-Level-Dienste wie Queuing-Technologien als auch High-Level-Dienste wie Benutzerauthentifizierung und -autorisierung – und Dienste von spezialisierten Anbietern wie Bezahldiensten.
2. Coding-Assistenten, also auf LLMs zurückgreifende Dienste, die Entwickler zur Code-Generierung verwenden. Einige Beispiele dieser erst in jüngster Zeit entstandene Tool-Kategorie sind Cursor, Bolt und GitHub Copilot.

Managed Services sind in der Entwicklung und im Anwendungsbetrieb omnipräsent. Die Idee, Managed Services einzusetzen, ist verlockend: Man kauft Funktionalität, der Anbieter kümmert sich um Wartung, Weiterentwicklung, Performance – und um die Sicherheit.

Als Nutzer von Managed Services müssen wir uns jedoch bewusst sein, dass wir damit Kontrolle und Einfluss abgeben. Insbesondere bei der Sicherheit schenken wir den Anbietern von Managed Services einen beträchtlichen Vertrauensvorschuss. Zwei Beispiele aus den letzten Jahren zeigen, dass Entscheider bei der Frage, ob ein Managed Service in einem bestimmten Anwendungsfall eingesetzt werden soll, den Sicherheitsaspekt bewusst einbeziehen müssen. Die genannten Unternehmen sollen nicht an den Pranger gestellt werden, die Vorfälle sind lediglich passende Beispiele für diesen Beitrag. Es gibt Dutzende erfolgreiche Supply-Chain-Angriffe auf grosse und kleine bzw. spezialisierte Unternehmen [1].
 

Im Juli 2023 wurde bekannt, dass es einer Angreifergruppe gelungen ist, einen Private Key innerhalb des Microsoft-Ökosystems abzugreifen, der zur Signierung von Daten verwendet wurde. Dieser Key ermöglichte es den Angreifern, gültige Zugangsschlüssel für Outlook Web Access (OWA) und outlook.com zu erstellen – und damit auf beliebige Benutzerkonten und -daten dieser Dienste zuzugreifen [2].

Forschende der Cloud-Security-Plattform Wiz kamen zum Schluss, dass die Angreifer noch mehr Zugänge erlangen konnten: Auf Basis des Private Keys und unter Ausnutzung weiterer Schwachstellen konnten die Angreifer Schlüssel für jede Anwendung erzeugen, die die Authentifizierung mit einem persönlichen Microsoft-Konto erlaubt. Damit waren unter anderem SharePoint, Teams, Azure DevOps und Kundenanwendungen, die ein Microsoft-Login erlauben, zumindest theoretisch betroffen [3]. Insbesondere Azure DevOps ist hier aus Supply-Chain-Sicht hochkritisch!

Insgesamt kann dieser Vorfall als eine Worst-Case-Kompromittierung der Azure Cloud angesehen werden.

Ebenfalls im Juli 2023 wurde ein Supply-Chain-Angriff auf die Firma JumpCloud bekannt. JumpCloud bietet eine Plattform, um Zugriffe auf Dienste und Anwendungen zu managen. Mit dem Ziel, sich Zugang zu Kundensystemen zu verschaffen, haben Angreifer mittels eines gezielten Phishing-Angriffs – dem sogenannten Spear-Phishing – Zugang zum internen JumpCloud-Netz erlangt und konnten schadhaften Code in JumpClouds Commands Framework einschleusen [4]. Wie JumpCloud berichtete, ist dies den Angreifern in «weniger als fünf Fällen» auch gelungen [5].

Bemerkenswert: JumpClouds Zero-Trust-Ansatz konnte diesen Angriff an keiner Stelle aufhalten.

Auf Basis dieser beiden Beispiele möchten wir einige Erkenntnisse und Konsequenzen in Hinblick auf Sicherheit ableiten:

1. Die Grösse eines Managed-Service-Anbieters sagt nichts über die Sicherheit der angebotenen Dienste aus. Weder grosse noch spezialisierte Cloud-Anbieter sind per se als sicher anzusehen.
2. Als Kunde eines Managed Services erhöht man seine potenziellen Angriffsvektoren. Als Kunde eines kompromittierten Managed-Service-Anbieters besteht mindestens das theoretische Risiko, dass man ebenfalls kompromittiert wurde. Die beiden Vorfälle sind gute Beispiele dafür, dass es für Angreifer oft ein Leichtes ist, Angriffe gezielt auf Kunden von Managed Services auszuweiten.
3. Zweifellos haben Managed Services ihre Berechtigung und ihre Vorteile. Als verantwortungsbewusste Software Engineers müssen wir Stakeholdern und Entscheidern potenzielle (Sicherheits-)Risiken darlegen. Insbesondere für das Abschätzen der Sicherheitsrisiken bietet sich Threat Modeling an [6]. Aus Platzgründen gehen wir nicht weiter auf diesen Ansatz ein.
4. Zudem sollte man den Aspekt der Anbieterunabhängigkeit berücksichtigen. Wird ein Dienst genutzt, der von sehr wenigen Anbietern angeboten wird, ist ein kurz- oder ggf. auch mittelfristiger Anbieterwechsel, z. B. aus Security-Gründen, nicht möglich. Compliance-Vorgaben können hier die Alternativen weiter einschränken.

Mit dem Versprechen, das Entwickeln von Anwendungsteilen oder ganzen Anwendungen massiv zu beschleunigen, haben Coding-Assistenten enorme Aufmerksamkeit auf sich gezogen – auch von Personen, die wenig bis keine Erfahrung im Programmieren haben. Unternehmen müssen wissen, dass Coding-Assistenten neue Supply-Chain-Angriffsvektoren eröffnen und wie man sich dagegen schützen kann.

Ein Coding-Assistent ist grundsätzlich eine interaktive Client-Software, die auf Entwicklerrechnern läuft, mit LLMs kommuniziert und auszuführende Befehle vorschlägt und selbstständig ausführen kann. Diese Entwickler-Assistent-Schleife kann durch Model-Context-Protocol-Server (MCP-Server) und Rules-Dateien erweitert respektive individualisiert werden. Sowohl MCP-Server als auch Rules können für Supply-Chain-Angriffe ausgenutzt werden.
 

MCP-Server bieten die Möglichkeit, für bestimmte Anfragen nicht auf ein LLM zurückzugreifen, sondern die Dienste eines MCP-Servers zu nutzen, da dieser Anfragen oft präziser oder zuverlässiger beantworten kann. Typische Anwendungsfälle sind z. B. das Abrufen von Echtzeitdaten oder arithmetische Operationen. Aber: MCP-Server sind inhärent unsicher [7]! Sicherheit wurde für dieses Protokoll nicht von Anfang an vorgesehen, stattdessen wurde und wird Sicherheit wie ein Flickenteppich behandelt. Erfolgreiche Angriffe auf MCP-Server mit dem Ziel, diese zu übernehmen, sind daher nicht verwunderlich [8]. Auch MCP-Server bekannter Hersteller bilden dabei keine Ausnahme [9].

Hat ein Angreifer einen MCP-Server übernommen, kann er die Antworten, die ein Coding-Assistent von diesem MCP-Server erhält, beliebig anpassen und mit böswilligen Anweisungen versehen. Besonders kritisch: Coding-Assistenten laufen in der Regel mit den Rechten des angemeldeten Benutzers – und das sind bei Entwicklern häufig Admin-Rechte! – und führen Aktionen wie das Installieren von Abhängigkeiten häufig ohne kritisches Hinterfragen der Entwickler aus.

Ein Entwicklerrechner gilt als kompromittiert, wenn ein Coding-Assistent auf diesem Rechner eine Aktion ausführt, die er von einem kompromittierten MCP-Server erhalten und die der Entwickler im Vorfeld nicht gründlich geprüft hat.

Rules sind System-Level-Regeln, die das Verhalten von Coding-Assistenten beeinflussen. Diese Regeln werden in sogenannten Rules-Dateien erfasst. Z. B. kann eine Regel in einer Rules-Datei besagen, dass beim Erstellen von Services ein bestimmtes Entwicklungsmuster zu befolgen ist. Für Angreifer sind Rules-Dateien ein interessantes Angriffsziel, da Angreifer z. B. eine Regel einschleusen können, die besagt, dass Datenbankabfragen so geschrieben werden sollen, dass sie für SQL-Injections verwundbar sind.

Eine solche Angriffstechnik ist die Rules File Backdoor [10]. Bei dieser Technik gelingt es dem Angreifer, nicht sichtbare Unicode-Zeichen in die Rules-Datei einzuschleusen, die für den Coding-Assistenten jedoch die vom Angreifer gewollte bösartige Bedeutung haben. Hier ist ein Beispiel, das SQL-Injections einschleusen würde:

Ein Angreifer kann versuchen, entweder die Rules-Datei eines Projektes selbst zu manipulieren, z. B. wenn es sich um ein Open-Source-Projekt handelt, oder eine online abrufbare Vorlage für Rules-Dateien zu manipulieren und mittels Social Engineering Entwickler dazu zu bringen, diese bösartige Vorlage zu verwenden.

Für den sicheren Einsatz von Coding-Assistenten gibt es einige Schutzmassnahmen, die Entwicklungsteams beachten sollten:

1. Entwickler sind auch hier die erste Verteidigungslinie! Entwickler müssen aufmerksam sein und von Coding-Assistenten generierten Code und insbesondere die auszuführenden Aktionen vorher genau prüfen.
2. Rules-Dateien, die ganz oder in Teilen übernommen werden, sind sehr kritisch zu überprüfen.
3. Man sollte sich bewusst entscheiden, welchem MCP-Server man wie viel vertraut. Hier macht es z. B. einen Unterschied, ob man einen öffentlichen MCP-Server verwendet oder einen hinter einem VPN selbst betriebenen. Threat Modeling kann helfen, die Sicherheitsimplikationen einzuschätzen.
4. Der allgemeine Grundsatz «Privilegien sollten auf das notwendige Minimum beschränkt werden» gilt auch beim Betrieb eines MCP-Servers. Für Entwickler mit Admin-Rechten kann Sandboxing eine Möglichkeit sein, um bei einem Angriff die Auswirkungen so weit wie möglich einzudämmen.

Supply-Chain-Angriffe nehmen stetig zu, sowohl in ihrem Volumen als auch in ihrer Finesse. Unternehmen sind in der Pflicht, ihre Softwareentwickler für diese Gefahren zu sensibilisieren. Entwickler wiederum sind die erste Verteidigungslinie gegen solche Angriffe, müssen wachsam sein und Angriffe erkennen, bevor sie Schaden anrichten.

[1] https://www.encryptionconsulting.com/top-10-supply-chain-attacks-that-shook-the-world/
[2] https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/
[3] https://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr
[4] https://cloud.google.com/blog/topics/threat-intelligence/north-korea-supply-chain/
[5] https://jumpcloud.com/blog/security-update-incident-details
[6] https://martinfowler.com/articles/agile-threat-modelling.html
[7] https://scribe.rip/%EF%B8%8F-the-s-in-mcp-stands-for-security-91407b33ed6b
[8] https://blog.jaisal.dev/articles/mcp
[9] https://thehackernews.com/2025/07/critical-vulnerability-in-anthropics.html
[10] https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents