Introduction
Recently I was blessed by my employer to attend an in-person training for Elastic, who have partnered with Strigo to provide a cloud lab platform. During the training, we were expected to interact with several components of the Elastic stack: we have access to a shell and two Elastic stack instances which run containerized in the instance. Everything we need to gain permanent, unfeathered access to the AWS EC2 instance this is running on, has already been provided.
Becoming root
As-is, the webshell runs as a regular user (elastic) without password. Unless you brute force the password, there is no way to gain superuser access. Thankfully, as members of the docker group, we can run containers with root privilege. Then, by running any container with a volume of /etc/passwd, you can remove the x between the :'s for the root user. This x is simply a placeholder that tells the system that the real password is stored and encrypted, usually in /etc/shadow. Now that the x is gone, the root user will be passwordless. That's pretty cool: we gained root access in our containerized environment. But what happens next is such a disaster, that container root is an insignificant oversight:
Escaping the container
Since this container needs to run its own containers, it has access to the EC2 instance's docker socket, mounted in /run/docker.sock. This means that if we apply the steps from the codevious paragraph, we can gain root access on the machine in question. With the root access, you can insert your own public key in /root/.ssh/authorized_keys (not necessary, but it's nice). Use any of the web-based services that return your IP and ssh into the server.
Congratulations! You just got a free server. Do as your heart desires - run minecraft, host files, borrow source code, or mine cryptocurrency. The sky is the limit!