TensorFlow CI/CD-Schwachstelle macht Lieferkette anreifbar
In der Open-Source TensorFlow-Maschinenlernplattform wurden Fehlkonfigurationen bei der kontinuierlichen Integration und kontinuierlichen Bereitstellung (CI/CD) entdeckt. Diese Schwachstellen hätten ausgenutzt werden können, um Angriffe auf die Lieferkette zu koordinieren.
Die Fehlkonfigurationen könnten von einem Angreifer ausgenutzt werden, um „eine Kompromittierung der Lieferkette der TensorFlow-Veröffentlichungen auf GitHub und PyPi durchzuführen, indem die Build-Agenten von TensorFlow über einen bösartigen Pull Request kompromittiert werden“, berichteten Forscher von Praetorian in einem kürzlich veröffentlichten Bericht.
Die erfolgreiche Ausnutzung dieser Probleme könnte es einem externen Angreifer ermöglichen, bösartige Veröffentlichungen im GitHub-Repository hochzuladen, Remote-Code-Ausführung auf dem selbstgehosteten GitHub-Runner zu erlangen und sogar ein GitHub Personal Access Token (PAT) für den Benutzer tensorflow-jenkins abzurufen.
TensorFlow nutzt GitHub Actions, um den automatisierten Prozess für Software-Builds, Tests und Bereitstellung zu steuern. Dabei können Runner, die Aufgaben in einem GitHub Actions Workflow ausführen, entweder von GitHub oder von den Nutzern selbst gehostet werden.
Die GitHub-Dokumentation rät dazu, selbst gehostete Runner nur für private Repositories zu verwenden. Grund: „Forks Ihres öffentlichen Repositorys können potenziell gefährlichen Code auf Ihrem selbst gehosteten Runner-Rechner ausführen, indem sie einen Pull-Request absetzen, der den Code in einem Workflow ausführt.“
Kurz gesagt: Jede beteiligte Person hätte die Möglichkeit, beliebigen Code auf dem selbst gehosteten Runner auszuführen, indem sie einen bösartigen Pull-Request erzeugt.
Wenn GitHub die Runner hostet, gibt es kein Sicherheitsproblem, da jeder Runner nur für kurze Zeit existiert. Er stellt eine saubere, isolierte virtuelle Maschine dar, die nach Abschluss der Aufgaben gelöscht wird.
Praetorian war offensichtlich in der Lage, TensorFlow-Workflows zu identifizieren, die auf selbst gehosteten Runnern ausgeführt wurden, und anschließend Fork-Pull-Requests von früheren Mitwirkenden zu finden, die automatisch die entsprechenden CI/CD-Workflows auslösten, ohne dass eine Genehmigung erforderlich war.
Ein Angreifer, der ein Ziel-Repository trojanisieren möchte, bräuchte daher nur beispielsweise einen Tippfehler korrigieren oder eine kleine, aber legitime Codeänderung vornehmen, einen Pull-Request dafür zu erstellen und dann darauf zu warten, dass er genehmigt wird, um zu einem Mitwirkenden zu werden. Auf diese Weise könnte er den Code auf dem Runner ausführen, ohne Verdacht zu erregen, da er keinen auffälligen oder gar unzulässigen Pull-Request erstellen musste.
Eine weitere Überprüfung der Workflow-Protokolle ergab, dass der selbst gehostete Runner nicht nur länger existierte (und somit die Möglichkeit zur dauerhaften Einrichtung eröffnete), sondern auch, dass das GITHUB_TOKEN, das mit dem Workflow verbunden war, umfassende Schreibberechtigungen hatte.
Die Forscher erklären: „Da das GITHUB_TOKEN die Berechtigung contents:write hatte, konnte es Releases auf https://github[.]com/tensorflow/tensorflow/releases/ hochladen.“ Das bedeutet, dass ein Angreifer, der Zugriff auf eines dieser GITHUB_TOKENs hatte, in der Lage war, eigene Dateien zu den Release-Assets hinzuzufügen.
Zusätzlich könnten die contents:write-Berechtigungen als Mittel genutzt werden, um bösartigen Code direkt in das TensorFlow-Repository einzufügen. Dies könnte geschehen, indem der schädliche Code heimlich in einen Feature-Branch injiziert und dann in den Haupt-Branch integriert wird.
Und das ist jedoch nicht alles: Ein Angreifer könnte auch den AWS_PYPI_ACCOUNT_TOKEN stehlen, der im Freigabe-Workflow verwendet wird, um sich bei der Python Package Index (PyPI)-Registrierung zu authentifizieren. Durch diese Aktion könnte der Angreifer eine bösartige Python .whl-Datei hochladen und somit das gesamte Paket vergiften.
Die Forscher betonen, dass ein Angreifer auch die Berechtigungen des GITHUB_TOKEN nutzen könnte, um das Repository-Geheimnis JENKINS_TOKEN zu kompromittieren. Interessanterweise wurde dieses Geheimnis zwar nicht in Workflows auf den selbst gehosteten Runnern verwendet, jedoch könnte ein Angreifer es dennoch ausnutzen.
Die Schwachstellen wurden am 1. August 2023 entdeckt und von den Projektbetreuern am 20. Dezember 2023 behoben. Sie reagierten, indem sie eine Genehmigung für Workflows einführen, die von allen Fork-Pull-Requests, einschließlich derjenigen von früheren Mitwirkenden, eingereicht wurden. Außerdem änderten sie die GITHUB_TOKEN-Berechtigungen für Workflows, die auf selbst gehosteten Runnern liefen, auf schreibgeschützt.
Nach Angaben der Forscher nehmen ähnliche CI/CD-Angriffe derzeit zu, da immer mehr Unternehmen ihre Prozesse automatisieren. Besonders anfällig seien KI/ML-Unternehmen, da viele ihrer Workflows erhebliche Rechenleistung erfordern, die auf von GitHub gehosteten Runnern nicht verfügbar ist. Daher sei die Nutzung von selbst gehosteten Runnern weit verbreitet.
Die Forscher haben gleichzeitig herausgefunden, dass verschiedene öffentliche GitHub-Repositories, darunter solche von Chia Networks, Microsoft DeepSpeed und PyTorch anfällig dafür sind, dass Schadcode über selbst gehostete GitHub-Aktions-Runner eingeschleust werden kann. Das Thema bleibt also weiter spannend.