Offengelegte Secrets in CI/CD

Was ist Offengelegte Secrets in CI/CD?

Build-Logs sind öffentlicher, als die Autoren der Workflows annehmen. Eine Debug-Zeile mit echo kann ein Secret im Klartext ausgeben. Im selben Workflow kann ein Pull-Request-Titel direkt in einen run-Schritt eingesetzt werden und dort als Shell-Befehl laufen. Sie kopieren ein Deployment-Token aus öffentlichen Actions-Logs und deployen damit Ihr eigenes Image. Danach entfernen Sie echo, binden fremde Eingaben sicher ein, legen Drittanbieter-Actions per Commit-SHA fest und rotieren das offengelegte Token. Das Maskieren künftiger Logs beseitigt die bisherige Offenlegung nicht.

Was Sie lernen in Offengelegte Secrets in CI/CD

• Offengelegte Secrets in CI/CD erkennen: Ein Workflow-Schritt, der ein Secret per echo oder auf anderem Weg ausgibt, schreibt es ins Build-Log – und bei einem öffentlichen Run kann es jeder lesen
• Workflow-Script-Injection verstehen: Nicht vertrauenswürdige Eingaben wie ein Pull-Request-Titel oder Branch-Name können, wenn sie in einen Run-Schritt interpoliert werden, in der Pipeline als Shell-Befehle ausgeführt werden
• Die Gegenmaßnahme bei einem geleakten Secret anwenden: das echo entfernen, das Secret über eine quotierte Umgebungsvariable übergeben, damit es verwendet statt ausgegeben wird, und den Schlüssel rotieren, weil er bereits in einem lesbaren Log stand
• Die Pipeline härten: Nicht vertrauenswürdige Eingaben über quotierte Umgebungsvariablen einbinden, statt sie in Run-Schritte zu interpolieren, und einschränken, worauf durch Pull Requests ausgelöste Runs zugreifen dürfen
• Drittanbieter-Actions auf einen Commit-SHA pinnen, damit ein verschobenes Tag nicht klammheimlich bösartigen Code einschleusen kann, und Workflow-Dateien auf dieselben echo- und Interpolationsmuster prüfen

Offengelegte Secrets in CI/CD — Trainingsschritte

1. Öffentliche Build-Logs

   Vellmoor entwickelt seinen Edge-Transcoder öffentlich. Deshalb sind sowohl die Pipeline des Repositorys als auch alles, was sie ausgibt, öffentlich. Bob braucht weder ein Konto noch eine Einladung oder einen einzigen Exploit. Er öffnet den Ausführungsverlauf und liest.

2. Einen Release-Lauf öffnen

   Die Integrationsläufe bauen und testen nur. Der Release-Workflow ist interessant, weil ein Release in die Produktion gelangen muss und dafür Zugangsdaten nötig sind. Bob öffnet den neuesten Release-Lauf.

3. Den Bereitstellungsschritt aufklappen

   Der Lauf besteht aus eingeklappten Schritten. Checkout und Build sind Routine. Bob interessiert sich für den Schritt, der mit der Produktion kommuniziert, denn dort müssen Zugangsdaten verwendet werden.

4. Das Token im Klartext

   Der Schritt öffnet sich, und das Token steht dort im Klartext. Jemand hatte bei der Fehlersuche für ein fehlgeschlagenes Deployment eine Zeile hinzugefügt, die das Token ausgibt. Das Deployment wurde repariert, die Zeile blieb. Bob muss nichts knacken. Er wählt den Wert aus und kopiert ihn.

5. Wie lange wird es schon ausgegeben?

   Jede Log-Zeile enthält eine weitere Kopie des Tokens. Bob durchsucht die Ausgaben aller Läufe nach dem Präfix, um herauszufinden, seit wann es erscheint. Je länger es öffentlich ist, desto mehr Menschen könnten bereits eine Kopie besitzen.

6. Was das Token erreichen kann

   Bevor Bob das Token nutzt, fragt er beim Deployment-Service von Vellmoor ab, wozu es berechtigt ist. Er ruft den Endpunkt für Umgebungen mit dem Token im Authorization-Header auf. Die Antwort kommt ohne weitere Prüfung. Das Token gilt nicht nur für eine Testumgebung.

7. Eigenen Build ausrollen

   Bob muss nicht auf das Repository zugreifen, keinen Pull Request öffnen und nicht auf ein Review warten. Für den Deployment-Service zählt nur, ob der Aufrufer ein gültiges Token hat – nicht, woher das Image stammt. Er lässt ein Image aus seiner eigenen Registry in Produktion bereitstellen.

8. Wissenscheck

9. Der Alarm trifft ein

   Sie verantworten Vellmoors CI-Workflows. Heute Morgen meldet das Plattformsicherheitsteam zwei Teile desselben Vorfalls: Zugangsdaten in einer öffentlichen Build-Ausgabe und ein ungeplantes Deployment in Produktion.

10. Es in der eigenen Pipeline sehen

    Berichte über ein Leck sind eine Sache. Sie öffnen den Lauf, auf den die Warnung verweist, um zu sehen, was Ihre Pipeline tatsächlich veröffentlicht hat.