Practical Shellshock exploitation – Part 1

In this article we will learn about Practical Shellshock exploitation.

What is Practical Shellshock exploitation?

Topics covered

Introduction

• What is Shellshock?
• When can it be abused?
• How to check if you are vulnerable
• Bash version checker
• Running a fancy one-liner on your terminal
• Shellshock technical insights
• Basics of bash shell variables
• Introducing bash environment variables
• Export bash functions to environment variables
• Parsing function definitions from strings
• Real vulnerability
• Possible exploits

Introduction

Shellshock is now one of the buzzwords in the security community. After “Heartbleed”, it is the most used word in the recent past. This article will first give you internal details about this vulnerability. It then walks the reader through the step-by-step process of setting up your own lab to demonstrate the Shellshock vulnerability along with the exploit part.

What is Shellshock?

Shellshock is a vulnerability in the GNU Bourne Again Shell (BASH) that allows an attacker to execute arbitrary commands using specially crafted environment variables.

When can it be abused?

This is the most important part of this article. Before we understand how to exploit this Shellshock vulnerability, we need to understand the potential targets that are vulnerable to Shellshock. This will also help us build a lab that demonstrates how to exploit this vulnerability.

If you’ve read any Shellshock news on the internet, you might have heard about the vulnerable targets: Apache mod-cgi, SSH, DHCP, etc.

I’ll explain things using SSH as an example.

If you use OpenSSH as your SSH Server, as well as bash as your default shell, there’s really no need to abuse your SSH. There are some limitations to using this as explained below.

You may be vulnerable if you have implemented “authorization_keys” for your clients with some specific requirements such as “force command” before the user executes the commands.

Well, you don’t have to worry about that now because we’ll cover it in detail in a moment.

From now on, note that “our services become vulnerable if we use any program that uses a vulnerable version of bash as an interpreter, and if an attacker is able to control the value of an environment variable that is passed to bash “.

Why? Because this is not a security flaw in SSH; rather, it is a vulnerability in “bash”.

How to check if your bash is vulnerable
Checking the bash version:

Bash versions up to 4.3 are known to be vulnerable. One way to check is to check the bash version with the following command.

[bash]
$bash – version

[/bash]

Cool! This is vulnerable.

Running the fancy one-liner in your terminal:

There is a one-liner which became very popular after the disclosure of this Shellshock vulnerability.

[bash]
$env x= ‘() { :;}; echo shellshocked’ bash –c “echo test”
[/bash]

Running the above line in your terminal shows if you are vulnerable to Shellshock. If “shellshocked” gets printed in the output, you are vulnerable and it’s time to update.

Technical insights of the Shellshock vulnerability

Now your questions should be:

What does the above line do?

What’s going on in the background?

Why am I vulnerable when “shellshocked” is printed?

To make things clear, let’s go over the basics first.

Basics of bash shell variables

Generally we can print something using echo command as shown below.

[bash]
$ echo “shellshock”
[/bash]

Now, if you want to store the above value in a variable, very similar to any other scripting language, I will put it in a variable called “myvar”.

[bash]
$ myvar=”shellshock”
$ echo $myvar
shock
[/bash]

This is shown below.

Now, let us open up a child process and see if we can get the value of the variable.

As we can see in the image above, we could not load the value set by the parent process into the child process.

Introducing bash environment variables

Here we can conveniently talk about environment variables.

When you start a new shell session, some variables are already ready for use. These can be called environment variables.

When we want to access the above “myvar” variable in the child process environment, we need to make it an environment variable to make it available to the new process. We can do this using “export”.

This is shown below.

Looking at the above figure, we can clearly see that the sub process is able to access the value of “myvar”.

Now, just to confirm that this is added to your environment variables, run the following command.

[bash]
$ env | grep ‘myvar’
[/bash]

In the above command, we are printing out all the environment variables and filtering out our target variable.

Exporting bash functions to environment variables

Similarly, functions can be exported to child process environments as shown below.

In the above figure, we first defined a function as shown below.

[bash]
x() { somecode;}
[/bash]

Then called this function x.

In order to be able access it from the sub process, I have exported it using ‘–f’ flag as shown below.

[bash]
export –f x
[/bash]

As expected, I am able to print the text inside the subshell.

Parsing function definitions from strings

So far we’ve seen how bash variables and functions work and how we can export them to access them in a subprocess.

We are now closer to Shellshock. J

The above function definition can also be stored as a string.

To demonstrate this, I’m using a new variable called “newfunction”. You’ll see why I name the variable as a function in a moment.

[bash]
$ newfunction='() { echo ‘shellshockdemo’;}’
[/bash]

As we did before, we just define a variable. Now we can access it as a regular variable as shown below.

[bash]
$ echo $new function
[/bash]

The above two steps are shown in the following figure.

Fantastic, even though we can access it as a variable in the parent shell, it is interpreted as a function inside the subshell and executes the body of the function.

Let’s also look at the environment variables to check our function.

How is it possible?

When a new shell is started as a child process, it takes a string value and interprets it as a function because it starts().

Real vulnerability

We’re finally there!

This time I will exit the function definition and pass some arbitrary commands after the function exit as shown below.

[bash]
$export newfunction='() { echo ‘shellshockdemo’;}; echo hell! i’m vulnerable’
[/bash]

In the above code I added: “echo damn! I’m Vulnerable” after the feature is terminated.

Now create a new bash shell by typing “bash” and watch what happens. These two steps are shown below.

Bingo! The code added outside the function definition has been executed during the bash startup.

If we execute the function now, it goes as expected.

This is shown below.

Now if you go back to one of our previous sections “When can it be abused?” here is the answer:

Condition 1 – Your bash version should be vulnerable (up to 4.3).

Condition 2 – The attacker should be able to control the passed environment variables.

Condition 3 – A new bash shell (subprocess) should be created.

To automate the whole process we use “env” as shown below.

[bash]
$env x= ‘() { :;}; echo shellshocked’ bash –c “echo test”
[/bash]

In general, env can be used to print all environment variables, as we saw earlier.

But if you look at the env man page, it can also be used to run commands.

Alternatively, we can use “–help” as shown below.

First let’s look at a simple example as shown below.

[bash]
$env newvar=demo bash –c ‘echo $newvar’
[/bash]

In the command shown above, newvar is an exported variable which is being accessed by a new subprocess and printing the value of it.

Now, if we look at our fancy command,

[bash]
$ env x='() { echo accessme;} echo vulnerable’ bash –c ‘x’
[/bash]

We should see the following output:

Again, the same concept.

X is a variable being exported. Since its value is beginning with (), it will be treated as a function by the subshell and the definition will be executed.

But before that, our “vulnerable” will be printed upon spawning a shell.

This whole process is represented in the following figure.

By this time, you should understand why this simple on-line command is so dangerous.

Possible exploits

Below are the few critical instances where a Shellshock vulnerability may be exposed:

• Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash or spawn subshells.
• Override or bypass the ForceCommand function in OpenSSH sshd
• Allow arbitrary commands to run on the DHCP client computer.

In the next article, we’ll see how to set up a custom lab and demonstrate how to exploit vulnerable OpenSSH and Apache servers.

Also Read:Ethical Hacking Interview Questions 2023