Run a compromised pod¶
In this section we deliberately introduce a container image with a known vulnerability so that you can enjoy the experience of exploiting it!
Run an Apache server vulnerable to Shellshock¶
We're using a container with Shellshock, a vulnerability in
bash that allows an attacker to remotely execute commands. To make it really easy, we're providing a Helm chart that installs the vulnerable deployment.
DO NOT RUN THIS IN A REAL CLUSTER!
This will run a deployment with a single pod. It might take a few seconds to pull the image so check that it's up and running (your pod name will be different):
You'll see something like this:
In a separate terminal window, run port forwarding so we can make curl requests to this pod. This maps localhost port 8081 to the pod's port 80.
You can now use curl (or a browser) to view the web service running on this pod. For example, if you open localhost:8081 in your web browser, you'll see the Apache2 default welcome page. There is also a script that will return the words "Regular, expected output" at the address localhost:8081/cgi-bin/shockme.cgi.
If you look at the source for the script you'll see that it's executed using
bash. This container is using a compromised version of
bash with the Shellshock vulnerability, that an attacker can exploit to execute commands.
First let's see the regular text is returned if we use
curl to make the HTTPS request:
This should show the response
Regular, expected output
You've seen the web server return content as expected. Now it's time to act like an attacker and exploit the Shellshock vulnerability.
Exploit the vulnerability¶
You can exploit Shellshock by passing a User-Agent header on the
curl request with the
-A parameter. This gets expanded as an environment variable by
bash, and because of the Shellshock vulnerability, it can be used to execute arbitrary commands. For example
Instead of running the CGI script as normal, this reponds to the HTTP request with the contents of
Preventing this attack¶
The safest way to prevent this attack is to ensure the vulnerable version of
bash isn't included in the container image before it's deployed. This is done with container image scanning.
Image scanning can only detect known, published vulnerabilities. You can also limit the likely damage of as-yet-unknown compromises by configuring containers to run more securely and using policies to enforce safer configuration.
Optional questions and exercises¶
If you have the time and interest, here are some additional things you might like to think about.
- Try running some other commands as if you were an attacker! For example, you could
- find out what environment variables are set
- see what user ID you're running as
- explore the contents of the filesystem to see what is available
- Where does this
/etc/passwdfile come from - the host or the container?
- What would happen if you mounted files from the host into this container?
- Take a look at the Dockerfile that builds the container image used in this example. It deliberately installed an old, vulnerable version of
- Try running a deployment with an up-to-date version of
apache2without the vulnerability, and check that you can't exploit it in the same way.