Vulnerabilidad en II6 con Webdav

Es tarde y recien veo la noticia de hace un par de dias atras.

Encontraron una vulnerabilidad en II6 con Webdav que permite listar directorios con passwords y algo mucho mas grave, permite descargar archivos en ellos.

Segun el sitio Secdev :

Here are a few facts, these are subject to modifications as the news unfolds:

1. Webdav is not enabled by default on IIS6
2. IIS7 + Webdav is not affected
3. You can actually upload content to the web server, afaik only to webdav folders (except if IISuser has write access to other folders)
   
4. This seems similar (root cause) to the 2001 Unicode IIS4/5 bug , but not the same
5. "Translate:f" is required, so unicode + "translate:f" is a good signature for this attack

Mitigation :
Temporary disable Webdav. This is not easy if you have Sharepoint services running. See here

Para quienes hace pocos años estan en internet ( <= 5 años ) en el 2001 hubo un problema similar con IIS 4 y IIS 5 , en el siguiente link hay una explicacion de este problema : 5 mayores vulnerabilidades del año 2001

El documento que publicaron la gente de explica como se aprovecha esta vulnerabilidad :

Authentication bypass of password protected folders

Assume there is a password protected folder in „d:\inetpub\wwwroot\protected\“. The password protection mechanism is not relevant for the attack to work. Inside this folder there is a file named „protected.zip“

The attacker sends a HTTP GET request to the web server.

GET /..%c0%af/protected/protected.zip HTTP/1.1
Translate: f
Connection: close
Host: servername

As seen above the URI contains the unicode character '/' (%c0%af). This unicode character is removed in a WebDAV request. „Translate: f“ instructs the web server to handle the request using WebDAV. Using this malicious URI construct the webserver sends the file located at „/protected/protected.zip“ back to the attacker without asking for proper authentication.

Another valid request an attacker might send to the web server is:

GET /prot%c0%afected/protected.zip HTTP/1.1
Translate: f
Connection: close
Host: servername

IIS 6.0 will remove the „%c0%af“ unicode character internally from the request and send back the password protected file without asking for proper credentials.

ASP scripts cannot be downloaded in this way unless serving of script source-code is enabled.

Listing files in a password protected WebDAV folder

The attack on WebDAV folders is similar. The attacker can bypass the access restrictions of the password protected folder and list, download, upload and modify files.

The attacker sends a PROPFIND request to the web server.

PROPFIND /protec%c0%afted/ HTTP/1.1
Host: servername
User-Agent: neo/0.12.2
Connection: TE
TE: trailers
Depth: 1
Content-Length: 288
Content-Type: application/xml


IIS responds with the directory listing of the folder without asking for a password.



Si existe la posibilidad de hacer un scan que permita deducir que versiones de IIS 6 tienen Webdav activo , y si esto esta instalado de la manera que vemos usualmente ( mal ) entonces estamos a las puertas de un problema grave.
Del tipo de problemas que propagan worms.

Es tarde, pero seguramente este post ira acumulando informacion sobre el problema.

Update : 18/05/09

En el blog Security By Default, realizaron un test que dio positivo


fuente : http://seclists.org/fulldisclosure/2009/May/0143.html

Como se crea un exploit

Con el release por Microsoft del patch emergencial ms08-067.mspx estamos seguramente a las puertas de la aparicion de varios worns. Esta vulnerabiliad a diferencia de muchas de las habituales corregidas por Microsoft tiene la particularidad de poder ejecutarse en forma remota y sin necesidad del usuario estar logueado.

Segun Microsoft el release del patch fuera de su ciclo se debe a que existia ya un exploit ejecutandose en internet.

Pero como hacen para crear estos exploits ?

En gral mediante ingenieria inversa de los patchs publicados por Microsoft.

Luego de publicarse el patch, lo revisan y ven que se corrigio. Entonces desde alli crean el codigo para aprovechar la vulnerabilidad anterior o como en este caso, encontrar una nueva vulnerbilidad.

Segun lo que se ve en el siguiente blog, donde se muestra en forma muy clara como es el proceso, Microsoft emite el patch ms08-67 como correccion al patch MS06-040.

Por lo tanto haciendo la diferencia entre ambos patchs se encuentra la parte del codigo corregida y por ende el error que existia.


En este link un POC ( prueba de concepto ) con el codigo para explotar este error :

http://www.phreedom.org/blog/2008/decompiling-ms08-067/