{"uuid": "62d9530a-fd1a-4fc2-a543-d7de67a6a7da", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2019-5736", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/39302", "content": "Kali Linux Tutorials\nWhoc : A Container Image That Extracts The Underlying Container Runtime\n\nWhoc is a container image that extracts the underlying container runtime and sends it to a remote server. Poke at the underlying container runtime of your favorite CSP container platform!\n\n* WhoC at Defcon 29 Cloud Village\n* Azurescape\u00a0\u2013 whoc-powered research, the first cross-account container takeover in the public cloud (70,000$ bounty) How does it work?\n\nAs shown by runc\u00a0CVE-2019-5736, traditional Linux container runtimes expose themselves to the containers they\u2019re running through /proc/self/exe. whocuses this link to read the container runtime executing it. Dynamic Mode\n\nThis is whocdefault mode that works against dynamically linked container runtimes.\n\n* The whocimage entrypoint is set to /proc/self/exe, and the image\u2019s dynamic linker (ld.so) is replaced with upload_runtime.\n* Once the image is run, the container runtime re-executes itself inside the container.\n* Given the runtime is dynamically linked, the kernel loads our fake dynamic linker (upload_runtime) to the runtime process and passes execution to it.\n* upload_runtimereads the runtime binary through /proc/self/exeand sends it to the configured remote server.\nhttps://blogger.googleusercontent.com/img/a/AVvXsEjocHBrqL-1DeWdgr84G9KTBwDuhOUH7iRkxmcMXWsXQnjtpQlcRlxf25x_Xv96NyR2T3Bd9jzEQBjtNFLfqZKx1FwIjPPzTasqAwRcH0_J60IuHDX9nGeMR_v9yUdB7BghvzW5znr5b3PjSrDk-KZ9DEuFMWend1XtmXY4oyh11Mfgtoc-YgLbHCYN=s571 \nWait-For-Exec Mode\n\nFor statically linked container runtimes, whoccomes in another flavor: whoc:waitforexec.\n\n* upload_runtimeis the image entrypoint, and runs as the whoccontainer PID 1.\n* The user is expected to exec into the whoccontainer and invoke a file pointing to /proc/self/exe(e.g. docker exec whoc_ctr /proc/self/exe).\n* Once the exec occurs, the container runtime re-executes itself inside the container.\n* upload_runtimereads the runtime binary through /proc/$runtime-pid/exeand sends it to the configured remote server.\nhttps://blogger.googleusercontent.com/img/a/AVvXsEjYUPEISvlrTOOIHWJ2ekop9nHLKToBwpf54UfVgSVe-QYm7Fj6wmq1Ms7EqHTr0Ii86_41fgPuwX59E2lcVgVUXUVo2PbVwAPFS4oy-mts1mfmuUURo3c8VgHmgmW2ijLhyoVkkwH0Z3AEREI_zx5YKSeTWNUytVlP7xmSLU7pie5C8gNV3pxFZr92=s571 \nTry Locally\n\nYou\u2019ll need dockerand python3installed. Clone the repository:\n\n$ git clone git@github.com:twistlock/whoc.git\n\nSet up a file server to receive the extracted container runtime:\n\n$ cd whoc\n$ mkdir -p stash && cd stash\n$ ln -s ../util/fileserver.py fileserver\n$ ./fileserver\n\nFrom another shell, run the whocimage in your container environment of choice, for example Docker:\n\n$ cd whoc\n$ docker build -f Dockerfile_dynamic -t whoc:latest src # or ./util/build.sh\n$ docker run \u2013rm -it \u2013net=host whoc:latest 127.0.0.1 # or ./util/run_local.sh\n\nSee that the file server received the container runtime. If you run whocunder vanilla Docker, the received container runtime should be\u00a0runc. --net=hostis only used in local tests so that the whoccontainer could easily reach the fileserver on the host via 127.0.0.1. Other Platforms\n\nBy default whocis built for linux/amd64, but it also supports other CPU architectures. Wait-for-exec mode can be built as usual. To build whocin dynamic mode for other CPU architectures, you must populate the PLATFORM_LD_PATH_ARGbuild argument with the path of the dynamic linker on the target architecture.\n\nAn example build script for arm64is available at util/build_arm64.sh[...]\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-06T13:00:05.626943Z"}