Immagini container minimali

Cos’è Immagini container minimali?

Ogni strumento che distribuisci in un'immagine di produzione è uno strumento che un attaccante eredita. Un'immagine runtime che porta con sé un package manager, un compilatore, una shell e utility di rete trasforma una falla applicativa limitata in un kit di strumenti funzionante, perché l'attaccante non deve più portare nulla con sé. Questo esercizio copre questa escalation: osserva un attaccante fare pivot usando i contenuti stessi dell'immagine, poi riduci il runtime a uno stage minimale senza shell e senza strumenti di build.

Cosa imparerai in Immagini container minimali

• Permette a un attaccante con esecuzione di codice limitata di scaricare e installare tutto ciò di cui ha bisogno, così una piccola falla diventa un punto d'appoggio completo senza che debba portare alcuno strumento.
• Gli strumenti di build restano nello stage di build, e solo l'artefatto compilato e le sue dipendenze runtime vengono copiati nell'immagine finale.
• Molte tecniche comuni di exploitation e persistenza presuppongono una shell per eseguire comandi, quindi rimuoverla interrompe il percorso più semplice dall'esecuzione di codice al controllo.
• Uno riguarda ciò che i layer registrano ancora dalla build, e questo riguarda ciò che l'immagine finale consegna a un attaccante a runtime. Stesso strumento, fallimento diverso.

Immagini container minimali — Fasi della formazione

1. Un punto d'appoggio nel checkout

   Bob non parte con una shell. Il servizio di checkout costruisce etichette di spedizione in PDF ed esegue comandi esterni per farlo, e un campo di quella richiesta non è sanificato. Inietta una sonda per confermare di poter eseguire un comando, e per vedere chi è e dove si trova.

2. Tutto ciò che l'immagine distribuisce

   Bob ha l'esecuzione di un comando alla volta come l'app, ma non ancora una shell. Di solito è qui che un attaccante si blocca, a meno che il container non gli fornisca un kit di strumenti. Prima di fare qualcosa di rumoroso, controlla cosa è già installato.

3. Recupera le credenziali cloud con curl

   Il container gira nel cloud, e ogni istanza cloud espone un servizio di metadata a un indirizzo interno fisso che distribuisce le credenziali temporanee del ruolo della macchina. Raggiungerlo richiede un client HTTP. L'immagine ne aveva già uno.

4. Come un comando è diventato una violazione

   L'accesso di Bob all'app era strettamente limitato.

5. Una shell in un container runtime

   Skelwyn esegue endpoint detection sui suoi host container. Non sa a cosa serva ogni container; riporta comportamenti che non si addicono a un runtime.

6. Conferma cosa era presente

   Alice riproduce ciò che l'attaccante ha trovato: chiede al container in esecuzione quali di quegli strumenti effettivamente contiene.

7. Un runtime da 412MB

   Il kit di strumenti non è gratuito. È peso, ed è superficie d'attacco. Alice controlla la dimensione dell'immagine effettivamente eseguita dal servizio.

8. Da dove entra il kit di strumenti

   L'immagine è costruita a partire da un unico Dockerfile. Alice lo apre per vedere perché un container runtime finisce per portare con sé un compilatore.

9. Uno stage solo, tutto viene distribuito

   L'immagine viene costruita ed eseguita in un unico stage, quindi tutto ciò di cui la build ha bisogno, lo porta con sé anche il runtime.

10. Separa la build dal runtime

    La correzione è una build multi-stage: mantieni l'immagine completa e la sua toolchain come stage di build che compila l'app, poi copia solo l'app completata e le sue dipendenze in un'immagine runtime distroless che non ha shell, né package manager, né compilatore.