whoc

Ein Container-Image, das die zugrunde liegende Container-Runtime extrahiert und an einen entfernten Server sendet. Testen Sie die zugrunde liegende Container-Runtime Ihrer bevorzugten CSP-Container-Plattform!

• WhoC at Defcon 29 Cloud Village
• Azurescape – whoc-gestützte Forschung, die erste Cross-Account-Container-Übernahme in der Public Cloud (70.000$ Prämie)

Wie funktioniert es?

Wie durch runc CVE-2019-5736 gezeigt, legen sich traditionelle Linux-Container-Runtimes gegenüber den Containern, die sie ausführen, über /proc/self/exe offen. whoc nutzt diese Verknüpfung, um die Container-Runtime auszulesen, die es ausführt.

Dynamischer Modus

Dies ist der Standardmodus von whoc, der mit dynamisch gelinkten Container-Runtimes funktioniert.

1. Der Einstiegspunkt des whoc-Images wird auf /proc/self/exe gesetzt, und der dynamische Linker (ld.so) des Images wird durch upload_runtime ersetzt.
2. Sobald das Image ausgeführt wird, führt sich die Container-Runtime innerhalb des Containers erneut aus.
3. Da die Runtime dynamisch gelinkt ist, lädt der Kernel unseren gefälschten dynamischen Linker (upload_runtime) in den Runtime-Prozess und übergibt die Ausführung an ihn.
4. upload_runtime liest das Runtime-Binary über /proc/self/exe und sendet es an den konfigurierten entfernten Server.

Wait-For-Exec-Modus

Für statisch gelinkte Container-Runtimes gibt es whoc in einer weiteren Variante: whoc:waitforexec.

1. upload_runtime ist der Einstiegspunkt des Images und läuft als PID 1 des whoc-Containers.
2. Der Benutzer wird erwartet, in den whoc-Container zu execen und eine Datei aufzurufen, die auf /proc/self/exe verweist (z. B. docker exec whoc_ctr /proc/self/exe).
3. Sobald der Exec erfolgt, führt sich die Container-Runtime innerhalb des Containers erneut aus.
4. upload_runtime liest das Runtime-Binary über /proc/$runtime-pid/exe und sendet es an den konfigurierten entfernten Server.

Lokal testen

Sie benötigen docker und python3. Klonen Sie das Repository:

git clone [email protected]:twistlock/whoc.git && cd whoc

Richten Sie einen Dateiserver ein, um die extrahierte Container-Runtime zu empfangen:

mkdir -p stash && cd stash
ln -s ../util/fileserver.py fileserver 
./fileserver

Führen Sie von einer anderen Shell das whoc-Image in Ihrer bevorzugten Container-Umgebung aus, zum Beispiel Docker:

cd whoc
docker build -f Dockerfile_dynamic -t whoc:latest src  # or ./util/build.sh
docker run --rm -it --net=host whoc:latest 127.0.0.1  # or ./util/run_local.sh

Stellen Sie fest, dass der Dateiserver die Container-Runtime empfangen hat. Wenn Sie whoc unter normalem Docker ausführen, sollte die empfangene Container-Runtime runc sein.

--net=host wird nur in lokalen Tests verwendet, damit der whoc-Container den Dateiserver auf dem Host einfach über 127.0.0.1 erreichen kann.

Andere Plattformen

Standardmäßig wird whoc für linux/amd64 gebaut, unterstützt aber auch andere CPU-Architekturen. Der Wait-for-Exec-Modus kann wie gewohnt gebaut werden. Um whoc im dynamischen Modus für andere CPU-Architekturen zu bauen, müssen Sie das Build-Argument PLATFORM_LD_PATH_ARG mit dem Pfad des dynamischen Linkers auf der Zielarchitektur füllen.

Ein Beispiel-Build-Skript für arm64 ist unter util/build_arm64.sh verfügbar.

Hilfe

Hilfe für das Hauptbinary von whoc, upload_runtime:

Usage: upload_runtime [options] <server_ip>

Options:
 -p, --port                 Port of remote server, defaults to 8080
 -e, --exec                 Wait-for-exec mode for static container runtimes, waits until an exec to the container occurred
 -b, --exec-bin             In exec mode, overrides the default binary created for the exec, default is /bin/enter
 -a, --exec-extra-argument  In exec mode, pass an additional argument to the runtime so it won't exit quickly
 -r, --exec-readdir-proc    In exec mode, instead of guessing the runtime pid (which gives whoc one shot of catching the runtime),
                            find the runtime by searching for new processes under '/proc'