Offengelegte Secrets in CI/CD

Was ist Offengelegte Secrets in CI/CD?

Build-Pipelines verarbeiten Geheimnisse und Build-Protokolle sind öffentlicher, als Workflow-Autoren annehmen. Ein Debugschritt, der ein Umgebungsgeheimnis widerspiegelt, gibt es im Klartext aus. Der gleiche Workflow birgt oft ein zweites Problem: Ein Pull-Request-Titel wird direkt in einen Ausführungsschritt interpoliert, wo er als Shell ausgeführt wird. Sie kopieren einen Bereitstellungsschlüssel aus öffentlichen Aktionsprotokollen und pushen ihn, entfernen dann das Echo, hören auf, nicht vertrauenswürdige Eingaben zu interpolieren, fixieren Aktionen von Drittanbietern durch Commit-SHA und drehen den Schlüssel, da das Maskieren zukünftiger Protokolle nichts rückgängig macht.

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 ist dieses Log für alle lesbar
• Workflow Script Injection verstehen: Nicht vertrauenswürdige Eingaben wie der Titel eines Pull Requests oder ein Branch-Name, die in einen run-Schritt interpoliert werden, können in der Pipeline als Shell-Befehle ausgeführt werden
• Die Gegenmaßnahme bei einem geleakten Secret anwenden: das echo entfernen, das Secret über eine Umgebungsvariable in Anführungszeichen übergeben, damit es benutzt statt ausgegeben wird, und den Key rotieren, weil er bereits in einem lesbaren Log stand
• Die Pipeline härten: nicht vertrauenswürdige Eingaben über Umgebungsvariablen in Anführungszeichen einbinden, statt sie in run-Schritte zu interpolieren, und einschränken, worauf durch Pull Requests ausgelöste Runs zugreifen dürfen
• Actions von Drittanbietern per Commit-SHA pinnen, damit ein verschobener 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 baut seinen Edge-Transcoder im Freien auf, daher ist die Pipeline des Repositorys öffentlich, ebenso wie alles, was es druckt. Bob benötigt kein Konto, keine Einladung oder einen einzigen Exploit, um zu starten. Er öffnet den Laufverlauf und liest.

2. Öffnen Sie einen Release-Lauf

   Die Integration führt nur Build und Test durch. Der Release-Workflow ist interessant, da ein Release die Produktion erreichen muss und für die Produktion eine Berechtigung erforderlich ist. Bob öffnet den neuesten Release-Lauf.

3. Erweitern Sie den Bereitstellungsschritt

   Der Lauf ist eine Liste von Schritten, von denen jeder einzelne reduziert ist. Auschecken und Aufbauen sind Routine. Der Schritt, den Bob möchte, ist derjenige, der mit der Produktion kommuniziert, denn dort muss ein Berechtigungsnachweis verwendet werden.

4. Das Token im Klartext

   Der Schritt öffnet sich und der Berechtigungsnachweis ist einfach da. Jemand hat eine Zeile zum Drucken des Tokens hinzugefügt, während er einem fehlerhaften Deploy nachjagte, der Deploy wurde repariert und die Zeile blieb bestehen. Bob muss nichts knacken. Er wählt den Wert aus und kopiert ihn.

5. Wie lange wird es schon gedruckt?

   Eine Protokollzeile ist eine Kopie. Bob geht zurück zum Laufverlauf und durchsucht die Ausgabe jedes Laufs nach dem Präfix des Tokens, um herauszufinden, wie lange das schon passiert. Die Antwort entscheidet darüber, wie viele Personen es bereits in den Händen halten könnten.

6. Was der Token erreichen kann

   Bevor er es verwendet, fragt Bob den Deploy-Service von Vellmoor, was dieser Berechtigungsnachweis tun darf. Er ruft den Umgebungsendpunkt mit dem Token in einem Autorisierungsheader auf. Die Antwort kommt ohne Herausforderung zurück und ist nicht auf eine Testumgebung beschränkt.

7. Versende seinen eigenen Build

   Bob muss das Repository nicht berühren, keine Pull-Anfrage öffnen oder auf eine Überprüfung warten. Dem Bereitstellungsdienst ist es egal, woher ein Bild kommt, sondern nur, ob der Aufrufer über ein gültiges Token verfügt. Er verweist auf ein Bild in seinem eigenen Register.

8. Wissenscheck

   Sie haben gerade zugesehen, wie Produktionsanmeldeinformationen aus einem Build-Protokoll entnommen wurden, ohne dass ein Exploit involviert war. Halten Sie fest, wie es dorthin gelangt ist.

9. Der Alarm trifft ein

   Sie besitzen die CI-Workflows von Vellmoor. Heute Morgen erlebte die Plattformsicherheit beide Hälften einer schlechten Nacht: ein Ausweis, der in der öffentlichen Ausgabe gefunden wurde, und ein Produktionseinsatz, den niemand geplant hatte.

10. Sehen Sie es in Ihrer eigenen Pipeline

    Berichte über ein Leck sind eine Sache. Sie öffnen die Option „Alarmpunkte ausführen“, um zu sehen, was Ihre Pipeline tatsächlich veröffentlicht hat.