Container privilegiati
A container runs as root with the host filesystem mounted, so code execution inside it becomes control of the host. Perform the escape, then fix it with a non-root user, dropped capabilities, and no privileged flag.
Cos’è Container privilegiati?
Un container non è un confine di sicurezza per impostazione predefinita. Un processo in esecuzione come root all'interno di un container è root sul kernel dell'host, e un container privilegiato con un mount dell'host può scrivere ovunque sulla macchina su cui è in esecuzione. Questo esercizio riguarda una fuga dal container (container escape): osserva un attaccante trasformare l'esecuzione di codice all'interno di un container nel controllo dell'host, poi lavora sulla vera correzione con un utente non root, capacità rimosse e un filesystem root di sola lettura.
Cosa imparerai in Container privilegiati
- L'isolamento dei container è un insieme di funzionalità del kernel, non un confine. Root nel container è root sul kernel dell'host, quindi qualsiasi falla in quell'isolamento è immediatamente sfruttabile.
- Praticamente tutte le capabilities e l'accesso ai dispositivi dell'host, il che elimina gran parte di ciò che separa il container dall'host.
- Esegui come utente non root, elimina le capabilities e smetti di passare --privileged e il mount dell'host.
- Un attaccante che ottiene l'esecuzione di codice non può scrivere strumenti o persistenza nel container, quindi è molto più difficile consolidare il foothold.
Container privilegiati — Fasi della formazione
-
Una shell nel container
Bob prende di mira Vosswark, una piattaforma logistica il cui servizio media ridimensiona e transcodifica i caricamenti dei clienti. Una libreria di immagini non aggiornata in quel servizio gli ha dato l'esecuzione di codice remoto, e ora ha una shell in esecuzione al suo interno. Come sia entrato non è la parte interessante. Lo è ciò che il container gli permette di fare in seguito.
-
Chi sono e cosa posso fare
Due domande decidono se questo punto d'appoggio è un vicolo cieco o una porta d'accesso: con quale utente viene eseguito il processo, e cosa il kernel permetterà a quell'utente di fare. Un solo file risponde a entrambe.
-
Cosa ha effettivamente comprato la modalità privilegiata
Privilegiato significa che le restrizioni abituali non vengono applicate. Bob verifica la cosa più preziosa che può derivarne: se qualcosa dell'host è stato consegnato direttamente al container.
-
Prendere la chiave dell'host
Il container era un mezzo per un fine. Ciò che Bob vuole si trova sulla macchina sottostante, nell'unica directory che trasforma un singolo host compromesso in un punto d'appoggio sull'intera flotta.
-
Cosa ha reso possibile la fuga
Un momento sul meccanismo prima di contare i danni.
-
Lasciare una via di rientro
Leggere la chiave è furto. Scrivere sull'host è persistenza. Poiché il mount non è di sola lettura, Bob può aggiungere la propria chiave pubblica all'authorized_keys dell'host, e da quel momento in poi non ha più bisogno della chiave rubata. L'aggiunta non stampa nulla, esattamente come accadrebbe in una shell reale. Quel silenzio è il punto: nulla in questo sembra un attacco.
-
Contare cosa ha raggiunto un solo container
Bob ora possiede la stessa chiave dell'host e ne ha piantata una propria accanto ad essa. Il worker media era un servizio a basso valore che gestiva i caricamenti dei clienti. Era anche, così come configurato, una via d'accesso a ogni macchina che si fida di quella chiave, e una porta che Bob può riaprire a piacimento.
-
L'host segnala una lettura di file
Vosswark esegue il monitoraggio dell'integrità dei file sui propri host. Non gli importa quale container abbia fatto qualcosa; segnala che il materiale della chiave dell'host stesso è stato letto.
-
Osservare come è stato avviato
Il Dockerfile descrive cosa c'è dentro un'immagine. Non dice nulla sui flag con cui un container è stato avviato, ed è proprio in quei flag che risiede questo incidente. Solo l'host può rispondere a questo.
-
Aprire il Dockerfile
Ci sono due metà da correggere e vivono in file diversi. L'immagine decide con quale utente viene eseguito il processo; il deployment decide cosa quel processo è autorizzato a toccare. Inizia dall'immagine.