Azure CloudSec Tools Review (1) — WhoC — CaaS Enumeration

WhoC is a container runtime enumeration tool created by Unit 42's security researcher Yuval Avrahami. It is especially useful for evaluating the vulnerability and compliance of Container-as-a-Service (CaaS) implementations on public cloud platforms. Services like Azure Container Instances, AWS Fargate, and Google Cloud Run are managed by the cloud provider platforms with customers not having visibility into the underlying implementations and architecture. WhoC can be used to validate the container runtime engine and versions being used by these services.

Creator: Yuval Avrahami

GitHub Repo: https://github.com/twistlock/whoc

How it works: WhoC runs as a container image on a CaaS service like Azure Container Instances, AWS Fargate, Google Cloud Run or IBM Code Engine. When the image runs, it obtains underlying host container runtime information (including version) to a remote file server that you specify. You can then examine this to see if the runtime engine/version used by the cloud provider is vulnerable to known exploits and proceed from there. In the next steps, I will show you how to run it on Azure Container Instance but you can follow similar steps to run on Fargate or Cloud Run.

Run whoC on Azure Container Instance

Pre-Requisites

• An Azure Container Registry resource
• An Azure Container Instance resource
• A Linux/Windows or Mac system with Git, Azure CLI, Python 3 and Docker installed
• You can deploy a test environment using this ARM template that I put together —

1. Setup a file server to receive the extracted container runtime.

• You can do this by cloning the whoC github repo and running the commands below from the system that you are using:

$ git clone https://github.com/twistlock/whoc.git
$ cd whoc
$ mkdir -p stash && cd stash
$ ln -s ../util/fileserver.py fileserver 
$ ./fileserver

2. Build whoc container image and push it into ACR

• There are two modes for running WhoC. A dynamic mode that does not require us to exec into the container OR a static mode that requires us to exec into the container. For more information, please watch Yuval’s presentation at the Defcon 29 Cloud Village.
• Each mode uses a different container image. There are two Dockerfiles in the cloned repo — Dockerfile_dynamic and Dockerfile_waitforexec.
• For this article, I will be using the dynamic mode.

# Build the container image using the Dockerfile
$ cd whoc
$ docker build -f Dockerfile_dynamic -t whoc:dynamic src
# Push into ACR
$ az login
$ ACR_NAME=uksthacr01
$ az acr update -n $ACR_NAME — admin-enabled true
$ ACR_LOGIN_SERVER=$(az acr show — name $ACR_NAME — resource-group cosmoslab-rg — query “loginServer” — output tsv)
$ ACR_USER=$(az acr credential show -n $ACR_NAME — query username — output tsv)
$ ACR_PASS=$(az acr credential show -n $ACR_NAME — query passwords[0].value — output tsv)
$ docker tag whoc:latest $ACR_LOGIN_SERVER/whoc:dynamic
$ docker login $ACR_LOGIN_SERVER -u $ACR_USER -p $ACR_PASS
$ docker push $ACR_LOGIN_SERVER/whoc:dynamic

3. Run whoc on ACI

• Use the /entrypoint argument to pass the IP address of the file server.

$ az container create — name azlab-whoc-dynamic — resource-group cosmoslab-rg — image $ACR_LOGIN_SERVER/whoc:dynamic — registry-login-server $ACR_LOGIN_SERVER — registry-username $ACR_USER — registry-password $ACR_PASS — command-line “/entrypoint 10.1.0.4” — vnet uksth-vnet — subnet aci-subnet

4. Examine the results on the Linux VM

$ chmod +x <file_name>
$ ll <file_name>
$ ./<file_name> -v

To get into more details on Azure Security, please check out my books on Implementing Azure Security Technologies — Defense and Penetration Testing Azure for Ethical Hackers (co-authored with @kfosaeen) — Offense and myself authored — Penetration Testing Azure for Ethical Hackers