Offenlegung der Container-Registry

Was ist Offenlegung der Container-Registry?

Eine Registrierung, die es ermöglicht, anonym Ihre Quelle, Ihre Konfiguration und Ihr bereitgestelltes Artefakt an jeden weiterzugeben, der den Repository-Namen errät. Beim anonymen Push kann ein Angreifer das Tag, das Sie versenden möchten, überschreiben, ohne dass die Pipeline davon Notiz nimmt. Sie rufen ein Produktionsimage ab, erstellen es mit einer Implantation neu, übertragen es unter demselben Release-Tag zurück und weisen die Implantation innerhalb des laufenden Dienstes zu. Anschließend benötigen Sie eine Authentifizierung, einen Scope-Push, markieren Release-Tags als unveränderlich und überprüfen das bereitgestellte Image anhand eines Digests statt eines Tags.

Was Sie lernen in Offenlegung der Container-Registry

• Beachten Sie, dass ein Angreifer durch anonymes Pullen auf ein privates Repository Ihre Quelle, Ihre Konfiguration und Ihre Build-Ebenen erhält
• Verfolgen Sie eine vergiftete Bereitstellung auf einen Angreifer zurück, der das Produktionsimage neu erstellt und unter demselben Release-Tag zurückgeschoben hat
• Konfigurieren Sie eine Registrierungsrichtlinie, die eine Authentifizierung zum Pullen und Pushen von Bereichen auf die Repositorys erfordert, die eine Pipeline tatsächlich erstellt
• Markieren Sie Release-Tags als unveränderlich, damit ein vorhandenes Tag nicht auf Inhalte umgeleitet werden kann, die niemand getestet oder überprüft hat
• Überprüfen Sie ein bereitgestelltes Image, indem Sie seinen Digest mit dem von der Pipeline aufgezeichneten Digest vergleichen, da ein Tag verschoben werden kann, ein Digest jedoch nicht

Offenlegung der Container-Registry — Trainingsschritte

1. Nach einem öffentlichen Repo suchen

   Bob nimmt Quenmoor nicht gezielt ins Visier. Er scannt selbst gehostete Registries nach solchen, die ohne Login antworten, und listet dann deren Repositories auf, um eines zu finden, das lesbar geblieben ist. Quenmoors Registry antwortet, und ein Repository sticht heraus.

2. Ein privates Repo, offen gelassen

   Bob scannt selbst gehostete Registries nach Repositories, die er eigentlich nicht erreichen dürfte. Quenmoors Registry antwortete ihm, ohne zu fragen, wer er ist, und ein Repository sticht heraus: ein interner Dispatch-Dienst.

3. Öffentlich, und beschreibbar

   Das ist ein interner Dienst, aber seine Zugriffsrichtlinie steht weit offen. Bob liest die zwei Einstellungen, die für ihn zählen.

4. Anonym pullen

   Keine Zugangsdaten, keine Mitgliedschaft, keine Zugriffsanfrage. Bob richtet Docker auf die Registry und zieht das Produktions-Image direkt herunter.

5. Ihre Produktionskonfiguration lesen

   Das Image ist nicht nur Code. Es trägt die Konfiguration, mit der es läuft, fest eingebacken in eine Schicht. Bob startet daraus einen Container und liest diese Datei direkt aus.

6. Mit einer Backdoor neu bauen

   Das Image zu lesen war Diebstahl; es zu überschreiben ist Kontrolle. Da er ihr echtes Produktions-Image gezogen hat, baut Bob direkt darauf neu auf und fügt eine einzige Schicht hinzu. Das ist das Dockerfile.

7. Die Schicht, die er hinzugefügt hat

   Alles andere ist unverändert ihr Image. Ein einziges RUN macht daraus einen Brückenkopf, der mit jedem Deploy ausgeliefert wird.

8. Als deren Release taggen

   Bob baut das vergiftete Image und taggt es mit genau dem Namen, von dem Quenmoor deployt, sodass die Registry es als das Produktions-Release behandelt.

9. Einen vergifteten Tag pushen

   Das Image zu lesen ist Diebstahl. Es zu überschreiben ist Kontrolle. Bob baut das Image mit einer Backdoor in seinem Entrypoint neu und pusht es zurück auf genau den Tag, von dem Quenmoor deployt. Die Registry nimmt es an, ohne zu fragen, wer er ist.

10. Was der Push ihm eingebracht hat

    Das nächste Deploy rollte Bobs Tag in die Produktion aus, und die Schicht, die er hinzugefügt hatte, meldete sich aus dem laufenden Dienst heraus nach Hause. Er muss Quenmoor nicht mehr von außen erreichen: Sein Code ist der Dienst.