gilalau rhianah vyctor
Rosella Bowlan
Being that this is also hosted on Apache, and the box is called Shocker, we can assume that the intention is for the path forward to be related to the Shellshock vulnerability. However, for this to happen, we need a URL to a specific script in the /cgi-bin/ directory that we can exploit to get RCE.
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.
One important note: If your command has a plaintext output, and you want the output returned to you, your output needs to follow a specific format/protocol. Most importantly, the returned output must be preceded with a blank line. For example, if you want the server to return a list of files in its folder, your command could be structured like this:
It turns out that you can also include a [media] [type] by setting the Content-Type field to explicitly state the format of the output that follows (e.g., Content-Type: text/plain indicates that the output is plaintext), which should be followed by an empty line, and then your output. For example, see the getenv.cgi script, which adheres to this format when returning plaintext output consisting of the environment variables.
You must use absolute paths in the payload of your Shellshock attack. An exception to this is calling echo because that is (also) a built-in function in bash. Why do you need to use absolute paths for commands? Because the PATH environment variable is not actually set in the shell that gets launched! You can verify that PATH is not set for the shell that your commands run inside by executing /bin/env as the payload of a Shellshock attack.
The Shellshock vulnerability allows attacks to run arbitrary commands on the target machine. In real attacks, instead of hard-coding the command in the attack, attackers often choose to run a shell command, so they can use this shell to run other commands, for as long as the shell program is alive. To achieve this goal, attackers need to run a reverse shell.
The key idea of a reverse shell is to redirect its standard input, output, and error devices to a network connection, so the shell gets its input from the connection, and prints out its output to the connection as well. At the other end of the connection is a program run by the attacker; the program simply displays whatever comes from the shell at the other end, and sends whatever is typed by the attacker to the shell, over the network connection.
A commonly used program by attackers is netcat, which, if running with the -l option, becomes a TCP server that listens for a connection on the specified port. This server program basically prints out whatever is sent by the client, and sends to the client whatever is typed by the user running the server. In the following experiment, netcat (nc for short) is used to listen for a connection on port 9090 (let us focus only on the first line).
The above command is representative of one that would normally be executed on a compromised server. It can be quite complicated to read terse commands such as these; we provide a detailed explanation below:
starts a bash shell on the server machine, with its input coming from a TCP connection, and output going to the same TCP connection. In our experiment, when the bash shell command is executed on 10.0.2.5, it connects back to the netcat process started on 10.9.0.1. This is confirmed via the Connection from 10.0.2.5 ... message displayed by netcat.
The lab report is to help me see that you did the lab and followed the instructions. For each task, you should include a screenshot to show you completed the task. If the task asks you to write down observations, you should also include those in your lab report. For the tasks that requires you to do some thinking and find ways to exploit a program, you should write a brief description about your approach and the steps you took to get your output. This is a lab report taken from a previous offering of this course. This is a good example of how you should format your lab report:
Once you are ready, submit your lab report AS A PDF to the appropriate D2L submission box.
It gets low traffic, so it's actually possible for me to read through the whole access log and spot unusual entries. These are mostly "white hat" scans such as Errata Security's "Shellshock Scan of the Internet", with the Shellshock attempts visible in the log entry through being present in the user agent.
The first appears to be a scan (testing vulnerability?), then there's an attempt to target a cgi script. Unlike the white hat stuff like the Erratta Security scan, there's nothing giving away its purpose in the user agent (my understanding is that 'serious' Shellshock attacks will use headers that are not logged).
I've never heard of tmUnblock.cgi and it doesn't appear to exist on my server, so I'm mostly asking out of curiosity (I hope!). What is tmUnblock.cgi and is it something that could be targetted with a shellshock attack?
My own attempts to research tmUnblock.cgi ended in confusion. It seems associated with an exploitable bug in Linksys routers discovered in Feb 2014, which seems to be related to executing shell commands and seems to have been used to propagate worms in the past, but that's all I can find.
tmUnblock.cgi is a binary CGI executable in some Cisco/Linksys router firmwares that has multiple security holes that permit various attacks on the router. It is unrelated to the "shellshock" vulnerability.
About the cgi_list_example.txt of shellshock-scanner, the inclusion of tmUnblock.cgi in the list is maybe unrelated to shellshock. I made that list taking some CGIs from different places, some of them have been taken from my own logs as "possible vulnerable cgis" (just in case I test for them).
I am currently attempting Blue and it seems to successfully establish connection and send the payload (ETERNALBLUE overwrite completed successfully). But instead of a WIN I get a FAIL, and it restarts the process twice more. My process for debugging has been:
c01484d022