Immagini Base Vulnerabili
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.
Cos’è Immagini Base Vulnerabili?
Le dipendenze di un'applicazione vengono esaminate. Il sistema operativo sottostante spesso no. Un tag dell'immagine di base variabile significa che il livello sotto il tuo codice cambia senza che nessuno abbia deciso che dovesse farlo, e uno obsoleto significa che vulnerabilità note vengono spedite in produzione a ogni deploy. Questo esercizio tratta una falla sfruttabile nel livello del sistema operativo: osserva un attaccante sfruttarla, poi blocca l'immagine di base tramite digest, passa a un'immagine di base slim e subordina la pipeline a una scansione.
Cosa imparerai in Immagini Base Vulnerabili
- Il livello sotto la tua applicazione cambia senza che nessuno abbia deciso che dovesse farlo, quindi non puoi sapere quali pacchetti del sistema operativo sono in produzione né quando sono stati modificati l'ultima volta.
- Che ogni build scarica esattamente gli stessi byte, quindi una modifica alla base è un commit deliberato e verificabile, non un evento silenzioso.
- Una cadenza di rebuild deliberata, perché una base bloccata (pinned) smette di ricevere patch finché qualcuno non sposta il pin.
- La falla si trova nel livello del sistema operativo sotto l'applicazione, quindi nessun file delle dipendenze la menziona e la correzione è un cambio dell'immagine di base, non l'aggiornamento di un pacchetto.
Immagini Base Vulnerabili — Fasi della formazione
-
L'immagine dello scheduler nel registry
Bob ha accesso in lettura al registry dei container di Bremhollow grazie a un token robot trapelato. Non sta guardando il codice — sta guardando quanto sono recenti le immagini, perché un servizio che non è stato ricostruito da un po' è un servizio la cui immagine base è invecchiata silenziosamente. Lo scheduler elabora immagini caricate dagli utenti, il che rende ciò su cui è costruito molto interessante per lui. Apri la sua pagina e guarda cosa dice il registry.
-
Un'immagine che ha smesso di muoversi
Il registry non deve essere sbagliato per aiutare Bob. Una sola riga gli dice che l'immagine distribuita è vecchia e costruita su una base mobile.
-
Scansiona la base alla ricerca di un varco
Bob esegue il pull dell'immagine e ci passa sopra uno scanner di vulnerabilità, lo stesso strumento che userebbe un difensore. Non è interessato al codice dell'applicazione. Vuole una vulnerabilità nota e pubblicata nei pacchetti del sistema operativo che l'immagine base ha trascinato con sé, perché quelle vengono con exploit funzionanti.
-
Trasforma il CVE in una shell
Un risultato dello scanner non è un exploit finché qualcuno non lo esegue. CVE-2023-4863 ha una proof-of-concept pubblica: un WebP creato ad arte che manda in overflow libwebp nel momento in cui viene decodificato. Lo scheduler decodifica ogni immagine caricata, quindi Bob monta il file PoC in un'esecuzione usa e getta dell'immagine vulnerabile e lo decodifica — dimostrando che il risultato è un percorso funzionante di remote-code-execution prima ancora di toccare la produzione.
-
Dove si trova la vulnerabilità
Un momento di riflessione sul meccanismo prima che inizi la risposta.
-
Lo scanner segnala la flotta
Bremhollow ha aggiunto la scansione delle immagini alla propria pipeline, e la prima verifica completa di ciò che è già in esecuzione in produzione ha restituito qualcosa che non può aspettare.
-
Verificalo di persona
Prima di cambiare qualsiasi cosa, Alice esegue la stessa scansione sull'immagine distribuita. Vuole vedere il risultato, dove si trova, e qual è effettivamente la base.
-
Aprire il Dockerfile
L'immagine base viene scelta in una riga del Dockerfile. Tutto ciò che lo scanner ha trovato è arrivato tramite quella riga.
-
Trova la base mobile
Non c'è nulla di scritto male o malformato qui. Il problema è una singola riga che dice meno di quanto dovrebbe.
-
Blocca la base tramite digest
Un tag è un'etichetta che qualcuno può spostare; un digest è l'impronta di contenuto dell'immagine e non può mai puntare a nient'altro. Alice blocca la base su un node:18 slim esatto e aggiornato tramite il suo digest, così ogni build d'ora in poi recupera gli stessi byte verificati, e spostare quel blocco diventa una modifica deliberata e revisionabile.