Shocker Write Up

Shocker is a HackTheBox challenge which revolves around the ShellShock vulnerability. This box was an easy box on HackTheBox, but I chose it because I was working on implementing the same vulnerability in a web-server project.


Shellshock, also known as the Bash Bug, was a significant security vulnerability that was discovered in 2014. The vulnerability affected the Bash shell, a widely used command-line interface for Unix and Unix-like operating systems, including Linux. This vulnerability allowed attackers to execute malicious code on a target system, potentially gaining unauthorized access and control.

It is hard to estimate how many devices were impacted by the vulnerability, but Bash is a widely used tool on Linux system. In 2014, tens of millions of devices were running Linux or Linux-like operating systems. Devices from routers, smart-tvs, and Internet of Things devices, to lots of public infrasturcture, to data centers and cloud computer use Linux as their backbone. Due to the wide usage of linux, the impact of the vulnerability is high. The risk of this vulnerability is also high, because systems can easily be compromised through the vulnerability.

Bash Environment Variables

Bash environment variables are fundamental components of the Bash shell. These variables store information that can be accessed and manipulated by shell scripts, commands, and running programs. They serve various purposes, such as defining system-wide settings, user-specific configurations, and providing data to processes. Environment variables are typically accessed using the dollar sign ($) followed by the variable name, such as $PATH for defining the system’s executable search path. They can store data like file paths, user preferences, system parameters, or temporary values, making them essential for customizing and configuring the behavior of the shell and its associated processes. Additionally, Bash environment variables facilitate communication between different programs and are a crucial part of system administration and software development on Unix-based systems.

Shellshock on Apache

The vulnerability was commonly present on Web Application Servers that were hosted on Linux Servers. The servers would use the bash command line for server side processing. Most often, the Apache server would be using CGI to process and handle user requests. In some implementations, request headers would be communicated to Bash through the use of environmental variables. The variables would be executed by the shell when handling requests. An attacker could set the value of a header, the user-agent, or other field, to include arbitrary code. When this field was written to an environment variable, it would be executed by the shell. This gives the attacker arbitrary remote code execution, which can be used to as an initial foothold in an attack.

Common Gateway Interface

Common Gateway Interface (CGI) is a set of standards and protocols that enables web servers to interact with external programs and scripts to generate dynamic web content. CGI scripts are typically written in languages like Perl, Python, or Shell, and they facilitate the processing of data from web forms and other user inputs, allowing web servers to execute these scripts and return dynamic web pages to users. CGI has been a fundamental technology in the early days of web development, although it has become less common in favor of more efficient server-side technologies like PHP, ASP.NET, and JavaScript frameworks.


Prior to beginning this attack, I have set up a virtual machine with an Ubuntu 22.04 installation. I have installed some common penetration tools on the box. The tools I used for this challenge were: nmap, gobuster, and a shellshock Proof Of Concept that I wrote.

Since I am using HackTheBox for this, I am connected to the HTB infrastructure through my OpenVPN connection.

My IP is:, and my victim’s IP is

Initial Reconnascience

To start of this attack, I ran an nmap command.

nmap -T4 -sV

This is the output:

We can see that there is an Apache Server running on port 80. There is SHH server running on a non-standard port 2222. In a normal pentets, we would investigate this. However, we can rule this out because we know from the context clues that we are looking for a ShellShock vulnerability.

Running a Directory Buster tool (GoBuster) reveals some directories.

gobuster -w /tools/SecLists/Discover/Web-Content/common.txt

The CGI-BIN directory is particularly interesting because it is a common place to find scripts and files that are vulnerable to the BashBug.

After poking around some more, we find a file “”, and upon downloading it, we see the contents of the file:

Initial Foothold

All of our reconnascience is pointing to this web-app being vulnerable to ShellShock. To test, I wrote a proof-of-concept exploit in python. I will go over the code after this section.

Running the exploit gets us a shell.

sudo python3 /tools/

As you can see, the exploit worked. We were able to run a reverse shell code through the Shellshock vulnerability. From our shell, we can do some internal reconnascience, carry out lateral movement, and more.


The proof of concept code is documented in the file. Here is a screenshot of it.

In general, I craft a malicious web request using the python requests library. I set the value of two headers, the cookies header and the referer header to the custom payload. The payload spawns a reverse shell that calls back to my machine. To connect to the reverse shell, I use the python sockets library. From there, I can send commands to the victim and get the response back.

Privelege Escalation

Now is the time to do some internal recon to figure out how we can get to root. In this case, using sudo -l to list privileges of the user reveals that the user can run perl. Using the -e flag for shell exeuction, we can gain a root shell.

And there we have it. Another Hack The Box Challenge Pwned.