Esposizione del registro dei container
A registry that allows anonymous pull leaks your source, and one that allows anonymous push lets an attacker replace the tag you deploy. Do both, then fix it with authentication, scoped push, and immutable tags.
Cos’è Esposizione del registro dei container?
Un registro di container contiene il tuo codice sorgente, la tua configurazione e l'artefatto che distribuisci. Uno che consente il pull anonimo consegna tutto questo a chiunque indovini il nome di un repository, e uno che consente il push anonimo permette a un attaccante di sostituire un tag che stai per pubblicare. Questo esercizio copre entrambi gli aspetti: osserva un attaccante leggere un'immagine privata e poi avvelenare un tag, quindi correggi il problema con autenticazione, permessi di push con ambito limitato e tag immutabili.
Cosa imparerai in Esposizione del registro dei container
- L'immagine contiene il codice sorgente dell'applicazione, la sua configurazione e i suoi layer di build, quindi un pull è di fatto una copia del codice e del suo ambiente.
- Un tag esistente ripuntato su un contenuto diverso, così l'artefatto che hai testato è l'artefatto che distribuisci.
- Il push sui repository specifici che costruisce, e nient'altro. Una credenziale di push valida per l'intero registro trasforma un runner compromesso nel controllo di ogni immagine.
- Confronta il digest dell'immagine distribuita con il digest registrato dalla pipeline, poiché il tag può cambiare ma il digest no.
Esposizione del registro dei container — Fasi della formazione
-
Cerca un repository pubblico
Bob non prende di mira Quenmoor per nome. Sonda i registri self-hosted alla ricerca di quelli che rispondono senza un login, poi enumera i loro repository per trovarne uno lasciato leggibile. Il registro di Quenmoor risponde, e un repository spicca.
-
Un repository privato lasciato aperto
Bob sonda i registri self-hosted alla ricerca di repository a cui non dovrebbe poter accedere. Il registro di Quenmoor gli ha risposto senza chiedergli chi fosse, e un repository spicca: un servizio interno di dispacciamento.
-
Pubblico, e scrivibile
Questo è un servizio interno, ma la sua policy di accesso è completamente aperta. Bob legge le due impostazioni che gli interessano.
-
Scaricalo in modo anonimo
Nessuna credenziale, nessuna appartenenza, nessuna richiesta di accesso. Bob punta Docker verso il registro e scarica direttamente l'immagine di produzione.
-
Leggi la loro configurazione di produzione
L'immagine non è solo codice. Porta con sé la configurazione con cui viene eseguita, incorporata in un livello. Bob avvia un container da essa e legge quel file direttamente.
-
Ricostruiscila con una backdoor
Leggere l'immagine era un furto; sovrascriverla è controllo. Poiché ha scaricato la loro vera immagine di produzione, Bob la ricostruisce direttamente a partire da essa e aggiunge un singolo livello. Questo è il Dockerfile.
-
Il livello che ha aggiunto
Tutto il resto è la loro immagine, invariata. Un solo RUN la trasforma in un punto d'appoggio che viene distribuito a ogni deploy.
-
Taggala come la loro release
Bob costruisce l'immagine avvelenata e la tagga con il nome esatto da cui Quenmoor distribuisce, così il registro la tratterà come la release di produzione.
-
Pubblica un tag avvelenato
Leggere l'immagine è un furto. Sovrascriverla è controllo. Bob ricostruisce l'immagine con una backdoor nel suo entrypoint e la ripubblica sull'esatto tag da cui Quenmoor distribuisce. Il registro la accetta senza chiedergli chi sia.
-
Cosa gli ha fruttato il push
Il deploy successivo ha portato il tag di Bob in produzione, e il livello che ha aggiunto ha telefonato a casa dall'interno del servizio in esecuzione. Non deve più raggiungere Quenmoor dall'esterno: il suo codice è il servizio.