Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Azure Container Instances (ACI) is a container as a service. ACI is ran on both Kubernetes and Service Fabric Clusters. All of the worker nodes are completely separated.

Doing recon for an container escape is really complicated because you need to get outside of the container first. By using a known design flaw with Linux containers (WhoC), they were able to see the container runtime. They found that the RunC version was extremely old and had many known vulnerabilities.

Even though they escaped the container, it was not possible to go to other worker nodes right away, as you plan for these types of issues to happen. They scouted around the other nodes to see any other issues. Since Kubernetes was also using a known vulnerability version (released in 2017-2018), they tried some of the existing issues.

One of these vulnerabilities (CVE-2018-1002102) appeared to be useful. The API server (master node) sometimes reaches out to the Kubelets. The vulnerability was that the API server allowed for redirects to another nodes Kubelet. As a result, we could communicate with other nodes (or so they thought). It ended up being patched and not being possible.

When making the requests to the middleware API server, they noticed an authorization header with an account token. Kubernetes uses JWTs when doing auth, but since anonymous access was enabled, this was surprising to them.

With access to the JWT, they were curious what permissions this gave them. After decoding the JWT, they noticed a permission that was very verbose: pods/exec. This permission allows for the execution of commands on any pod in the cluster In fact, this includes the API-server pod!

With code execution on the api-server, this was a complete game over. Because we control this, we can communicate with the other nodes in the cluster and compromise them cross-tenant. But, there is more!

Between the API-server and worker nodes, Microsoft added a bridge pod between them. While testing the communication to the bridge, they noticed an SSRF vulnerability. This was because whenever a command was to be executed on the pod, it grabbed the pods status.hostIP field, which is configurable by the attacker. The status.hostIP would only persistent for a few seconds but it can be constantly updated.

After playing around with this issue, they noticed that the IP did not just have to be an IP: it could be a full URL with the rest of the URL being added on with a fragment to make sure it did not effect the request at all. By setting the URL to be api-server, they could execute commands once again on this server.

The last bug must have taken an insane amount of time with blackbox reverse engineering. Both of these findings are quite awesome and awesome to see. I particularity enjoyed the race condition with URL issue though. URLs are extremely hard to handle; I personally think they are the best attack vector for finding vulnerabilities.