Shellshock is a critical security vulnerability in the UNIX bash shell, identified on September 24, 2014, affecting various UNIX-like systems. The flaw allows attackers to exploit environment variables to execute arbitrary commands, posing a severe risk compared to previous vulnerabilities like Heartbleed. Users are advised to update their bash versions to mitigate this risk.

1. Shellshock (software bug)
Shellshock is a security bug in the UNIX bash Shell. It was disclosed on 24th September
2014. The bash shell is widely used in many Unix-like systems, including Linux-based systems
(such as Red Hat Enterprise Linux, Fedora, CentOS, Debian, and Ubuntu), *BSDs (such as
FreeBSD and NetBSD), Apple MacOS X, and Cygwin (which runs on Windows). Thus, there were
many systems that were potentially exploitable.
Shells are widely used on these systems to process commands, so there were many
ways to potentially exploit Shellshock.
History:
Stéphane Chazelas contacted Bash's maintainer, Chet Ramey, on 12 September
2014 telling about his discovery of the original bug, which
he called "Bashdoor". Working together with security
experts, he soon had a patch as well. The bug was assigned
the CVE identifier CVE-2014-6271. It was announced to the
public on 24 September 2014 when Bash updates with the
fix were ready for distribution.
Within days of the publication of this, intense
scrutiny of the underlying design flaws discovered a variety
of related vulnerabilities, (CVE-2014-6277, CVE-2014-
6278, CVE-2014-7169, CVE-2014-7186, and CVE-2014-
7187); which Ramey addressed with a series of further
patches.
Shellshock Logo
How it works:
Bash supports exporting not just shell variables, but also shell functions to another bash
instance, via the process environment to (indirect) child processes. Current bash versions use
an environment variable named by the function name, and a function definition starting with
“() {” in the variable value to propagate function definitions through the environment. The
vulnerability occurs because bash does not stop after processing the function definition; it
continues to parse and execute shell commands following the function definition.

2. Ex: UNIX bash shell variables
In the terminal of UNIX or Linux, execute the following commands to hack others system
Step by step process:
As-Mac-mini-5:~ A$ echo "hello"
Hello
As-Mac-mini-5:~ A$ myvar="hello"
As-Mac-mini-5:~ A$ echo $myvar
Hello
As-Mac-mini-5:~ A$ bash
bash-3.2$ echo $myvar
bash-3.2$
‘echo’ is the UNIX command to print something as it is present in the quotes like Hello in the
above example.
Myvar is a user defined variable and assigning a value ‘hello’.
We can print the variable value using variable and echo together
In order to access the ‘myvar’ in the child process, use bash command
No result printed because our ‘myvar’ is not environmental variable to provide access to the
child process
Here we’ve to convert that ‘myvar’ as environmental variable
Environment variables:
When you start your new shell session, some variables are already ready for your use.
These can be called environment variables.
As-Mac-mini-5:~ A$ export myvar="hello"
As-Mac-mini-5:~ A$ echo $myvar
hello
As-Mac-mini-5:~ A$ bash
bash-3.2$ echo $myvar
Hello
bash-3.2$
‘Export’ is used convert the local variable as environmental variable
Observe that we can access the myvar in the child process (after the bash command in the
script)
Exporting bash functions to environment variables:
As-Mac-mini-5:~ A$ export newfunction='() { echo 'hello';}; echo damn! I am vulnerable’
As-Mac-mini-5:~ A$ bash
Echo damn!I am vulnerable

3. bash-3.2$ newfunction
hello
bash-3.2$
If the user writes the malicious code in place of ‘echo “damn! I’m vulnerable”’ , then the
corresponding system gets hacked.
Exploitationvectors:
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. If the request handler is a Bash script, Bash will receive the
environment variables passed by the server and will process them. This provides a means for an
attacker to trigger the Shellshock vulnerability with a specially crafted server request.
OpenSSH server: OpenSSH has a "ForceCommand" feature, where a fixed command is
executed when the user logs in, instead of just running an unrestricted command shell.
DHCP clients: Some DHCP clients can also pass commands to Bash; a vulnerable systemcould
be attacked when connecting to an open Wi-Fi network.
Qmail server: When using Bash to process email messages (e.g. through .forward or qmail-alias
piping), the qmail mail server passes external input through in a way that can exploit a
vulnerable version of Bash.
How worse than Heartbleed:
Shellshock drew comparisons to the Heartbleed bug that was discovered in a crucial
piece of software last spring. But Shellshock could be a bigger threat. While Heartbleed could
be used to do things like steal passwords from a server, Shellshock can be used to take over the
entire machine. And Heartbleed went unnoticed for 2 years and affected an estimated 500,000
machines, but Shellshock was not discovered for 22 years and affected has no limit. Shellshock
severity rated as 10 out of 10 by NVD(National Vulnerability Developement).
That'sa flawed piece ofcode could gounnoticedfor more thantwo decades couldbe surprisingto
many.
How to test our systems:
To test if your systemis vulnerable just try this on bash:
env x='() { :;}; echo vulnerable' bash –c "echo this is a test"
If you're vulnerable it'll print:
vulnerable

4. this is a test
If you've updated Bash you'll only see
this is a test
Protect:
Upgrade to the latest versions of Bash.
References:
http://www.wired.com/2014/09/shellshocked-bash/
https://www.alienvault.com/open-threat-exchange/blog/attackers-exploiting-shell-shock-cve-
2014-6721-in-the-wild
http://www.darkreading.com/shellshock-bash-bug-impacts-basically-everything-exploits-
appear-in-wild/d/d-id/1316064