Verwundbare Base-Images

Verwundbare Base-Images

A floating base-image tag ships known OS-layer vulnerabilities to production. Exploit one, then pin the base image by digest, move to a slim variant, and gate the pipeline on a scan.

Was ist Verwundbare Base-Images?

Die Abhängigkeiten einer Anwendung werden überprüft. Das darunterliegende Betriebssystem meist nicht. Ein nicht gepinnter (floating) Base-Image-Tag bedeutet, dass sich die Schicht unter Ihrem Code ändert, ohne dass jemand das bewusst entschieden hat, und ein veralteter Tag bedeutet, dass bei jedem Deployment bekannte Schwachstellen in die Produktion gelangen. Diese Übung behandelt eine ausnutzbare Schwachstelle in der Betriebssystemschicht: Sehen Sie zu, wie ein Angreifer sie ausnutzt, pinnen Sie dann das Base Image per Digest fest, wechseln Sie zu einem Slim-Base-Image, und richten Sie in der Pipeline ein Scan-Gate ein.

Was Sie lernen in Verwundbare Base-Images

Verwundbare Base-Images — Trainingsschritte

  1. Das Scheduler-Image in der Registry

    Bob hat über ein geleaktes Robot-Token Lesezugriff auf Bremhollows Container-Registry. Er schaut sich nicht den Code an — er schaut sich an, wie frisch die Images sind, denn ein Dienst, der eine Weile nicht neu gebaut wurde, ist ein Dienst, dessen Base-Image still und leise gealtert ist. Der Scheduler verarbeitet hochgeladene Bilder, was das, worauf er aufbaut, für ihn sehr interessant macht. Öffne seine Seite und sieh, was die Registry sagt.

  2. Ein Image, das stehen geblieben ist

    Die Registry muss sich nicht irren, um Bob zu helfen. Eine einzige Zeile verrät ihm, dass das deployte Image alt ist und auf einer schwimmenden Base aufbaut.

  3. Die Base nach einem Einstiegsweg durchsuchen

    Bob zieht das Image und lässt einen Schwachstellenscanner darüberlaufen, dasselbe Tool, das auch ein Verteidiger nutzen würde. Er interessiert sich nicht für den Anwendungscode. Er will eine bekannte, veröffentlichte Schwachstelle in den Betriebssystem-Paketen, die das Base-Image mitgebracht hat, denn dafür gibt es funktionierende Exploits.

  4. Die CVE in eine Shell verwandeln

    Ein Scanner-Fund ist kein Exploit, bis ihn jemand ausführt. Für CVE-2023-4863 gibt es einen öffentlichen Proof-of-Concept: ein präpariertes WebP, das libwebp genau in dem Moment zum Überlauf bringt, in dem es dekodiert wird. Der Scheduler dekodiert jedes hochgeladene Bild, also bindet Bob die PoC-Datei in einen Wegwerf-Lauf des verwundbaren Images ein und dekodiert sie — und beweist damit, dass der Fund ein funktionierender Remote-Code-Execution-Weg ist, bevor er überhaupt die Produktion berührt.

  5. Wo die Schwachstelle steckt

    Ein kurzer Moment beim Mechanismus, bevor die Reaktion beginnt.

  6. Der Scanner schlägt bei der Flotte Alarm

    Bremhollow hat Image-Scanning in seine Pipeline aufgenommen, und der erste vollständige Durchlauf über das, was bereits in Produktion läuft, hat etwas zutage gefördert, das nicht warten kann.

  7. Sieh es dir selbst an

    Bevor sie etwas ändert, führt Alice denselben Scan am deployten Image aus. Sie will den Fund sehen, wo er sitzt, und was die Base tatsächlich ist.

  8. Das Dockerfile öffnen

    Das Base-Image wird in einer einzigen Zeile des Dockerfiles gewählt. Alles, was der Scanner gefunden hat, kam über diese Zeile herein.

  9. Die schwimmende Base finden

    Hier ist nichts falsch geschrieben oder fehlerhaft. Das Problem ist eine einzige Zeile, die weniger aussagt, als sie sollte.

  10. Die Base per Digest fixieren

    Ein Tag ist ein Label, das jemand verschieben kann; ein Digest ist der Inhalts-Fingerabdruck des Images und kann niemals auf etwas anderes zeigen. Alice fixiert die Base per Digest auf ein exaktes, aktuelles, schlankes node:18, sodass ab jetzt jeder Build dieselben geprüften Bytes zieht, und das Verschieben dieses Pins wird zu einer bewussten, überprüfbaren Änderung.