LAB ASSIGNMENT 2 Ashwin Dhinesh Kumar

Task1: Attack CGI programs

Shellshock using CGI:

Observation: We create a program myprog.cgi which is a shell script and place it in the folder
/usr/lib/cgi-bin which is the default CGI directory for Apache web server and it is only writable by the
root. We then change the permissions of the program to 755 by using the chmod command. We also
create a file called dummy.txt in the same directory which is accessible to everyone. We then run the
curl command which is a command line tool to access the CGI program from the web which executes
the myprog.cgi program and the output is displayed.

Explanation: CGI is a way for web servers and server side programs interact. They receive input from a
webserver and the output is then sent to the server which is again sent to the user by the server. Curl is
a command line tool to transfer data from or to the server using one of the protocols. Here we use the
curl command to access the myprog.cgi program we created.
Observation: We use the curl command with user agent argument to pass values into the server and
exploit the shellshock vulnerability. First we use the pwd command to print the current working
directory of the running program which is /usr/lib/cgi-bin. We then try to access a file owned by root
with permissions to read, write and execute and the contents of the file are printed when we pass the
cat command. Now we try to delete the file called dummy.txt which is owned by root, but deletion isn’t
possible as the server doesn’t have permissions to modify the directory in which the file is placed. It can
only edit the file but not delete the file.

Explanation: Curl command with user agent argument allows to pass values to the server. We use this to
exploit the shellshock vulnerability for CGI programs. In the user agent we pass a function followed by a
semicolon and then pass additional code that may be harmful to the system as single variable. So when
the curl command is executed, the CGI program specified with in the URL is executed. The program is a
shell script and invokes bash shell. That time the bash shell tries to parse all variables and executes
functions. In this case, it recognizes that it is a function and not a variable, converts it to a function and
executes it. That time the code injected along will also be executed and hence in the above example
contents of the dummy file is shown.
From the bash source code, we can see that if a function is defined as a variable, it converts it to a
function by replacing the = with a ‘ ‘ (space) and then executes it as shown in the parse_and_execute()
function. This is where the vulnerability is because if the user sends malicious code along with the
variable, the bash executes it after parsing it. Bash only checks for the first part of the function as
indicated in the screenshot and not rest of the function and if it contains multiple commands separated
by semicolons.

Shellshock using reverse shell:

Observation: In one terminal we run the netcat command and listen to input connections. In another
terminal, we run the curl command which calls the interactive bash. After this we get the control of the
server’s shell as indicated by the prompt in the listening terminal. Now whatever commands we write
will be like executing on the server directly.

Explanation: We exploited shell shock by using a reverse shell. Reverse shell is basically getting the
control of the server with www-data user access. So basically we can access all the files accessible to this
user by getting control of the user’s prompt.
Task2: Attack Set-UID programs

Task 2a:

Observation: In the above task we are creating a program which contains setuid(geteuid()); and a
system command and compiling it and making it a Set UID program owned by root. We are also creating
a file called secret.txt and making it a read only file only to the user which is root. When we run this
program, the output is the same as running ls -l. We then declare a function as variable foo to exploit
shellshock. That time when the program is executed, the contents of secret.txt is printed.

Explanation: We declare a foo which is a function as a variable to exploit shellshock. So when the
program is executed, the system command invokes the shell. The setuid(geteuid()) function gets the
effective UID and makes it a real UID. The effective UID is 0 since the program owner is root. So the real
UID also becomes root. When the bash is invoked, it parses variables and it recognizes foo as a function
and replaces the = with a ‘ ‘ (space). For Set-UID programs, it is not allowed to pass functions since the
effective user id may be root and it also is not allowed to execute foo. But in this case it passes and
executes it because the effective UID and real UID is 0 making it seem a root user. Hence the contents of
the file are printed.
Task 2b:

Observation: We change the previous program by removing the line setuid(geteuid()) and run the
program same as previous task. Even though we declare the function in a variable foo, the contents of
secret.txt are not printed in this case. So the output is just ls -l output.

Explanation: Here the real UID would still be that of the user and effective UID would be that of the
root. Since it is a privileged program, shell functions are not inherited to the child environment and it
also won’t execute foo. So the system command executes ls -l itself and the output is printed.

If the program is a privileged program containing a function, i.e., effective UID and real UID is different,
then function defined in the environment variable is not evaluated. This is shown by the screen from the
bash source code. So the privmode would be 0 and it won’t enter the function below.
Task 2c:

Observation: We now create a program with execve instead of system command and retry to explore
the shellshock vulnerability. The output is that it executes ls -l command and prints out the contents.

Explanation: Even though the real UID and effective UID of this program is that of the root, the output
remains the same and doesn’t print contents of secret.txt because the shell isn’t called while using the
execve command. When we execute bash command after the program, then the contents of secret.txt
would be printed.
Task3: Questions

2. What is the fundamental problem of the Shellshock vulnerability? What can we learn from this
vulnerability?

The bash shell has defense mechanism to protect itself from attacks. But the shellshock vulnerability can
be exploited in bash shell. From the code above, we know that if the program is a privileged program
i.e., real UID and effective UID is different (Set-UID program) and it has a function, then the function is
not parsed and executed. Normally, when we declare a function as a variable and pass it, the internal
mechanism of the bash replaces the = sign with a ‘ ‘ (space) and converts it to a function and then parses
and executes it. The shell only checks for the first part of a function definition i.e., ‘() {‘and nothing after
that. The later part may contain multiple commands separated by ;(semicolons). So if we pass additional
code along with the function after a ; (semicolon), the shell assumes it as a single command and parses it
and then executes it. When code like that is executed, the system is vulnerable to attacks. This is the
basic idea of shellshock vulnerability.
So to avoid this, the bash could validate the contents of the function and then parse it and execute it.
This is how we could solve the shellshock vulnerability.
1. Other than the two scenarios described above (CGI and Set-UID program), is there any other scenario
that could be affected by the Shellshock attack? We will give you bonus points if you can identify a
significantly different scenario and you have verified the attack using your own experiment

Other than CGI and Set-UID scenarios described above, the other way would be a normal shell shock
attack in normal mode where there is no Set-UID programs involved. We just declare a function as a
variable and export it. The function contains additional code after a semicolon which may be malicious.
We then invoke the bash. That time bash converts the variable into a function and executes it. In this
approach, we cannot affect the root and make major changes to the system as this is not a Set-UID
program, but it can affect the user as we can run programs with user privileges. The screenshot below
depicts the scenario explained above. The code written after the semicolon was a command to remove a
file. After the bash is called, the file is deleted from the system.