sábado, diciembre 26, 2009

Data Type Conversion Attack en PHP

Esta prueba permite a un atacante descubrir el path local de la instalación en servidores utilizando PHP en los que los mensages de error no han sido completamente bloqueados. La idea es utilizar los parámetros http para ejecutar una conversión implícita del tipo de datos con el objetivo de generar una excepción no controlada que muestre la ruta de instalación en el servidor web de ese código. Este trabajo fue publicado por Manu "The Sur" en la lista "Full Disclosure".

Local Path disclosure

Supongamos un código PHP de la sigiente forma que esté ejecutándose en un servidor web:

Dca.php
[?php
$vuln= $_GET["var"] +1;
?]


Como se puede ver, este programa recibe un parámetro numérico que es utilizado para ejecutar una función matemática. La forma normal de invocar este programa sería la siguiente:

- http://www.testserver.com/dca.php?var=1

Con el objetivo de forzar la conversión del tipo de datos, la siguiente sintaxis de llamada puede ser utilizada:

- http://www.testserver.com/dca.php?var[]=1

Esta sintaxis, utilizando los corchetes, forzará al motor PHP a convertir el tipo de datos del parámetro en una estructura de tipo array. Si el parámetro display_errors en el fichero de configuración php.ini está activo, el servidor web mostrará un mensaje de error como el siguiente:

Unsupported operand types in C:\server\htdocs\dca\dca.php on line 2

Este comportamiento es debido al hecho de que no hay una función de sobrecarga para el operador suma en las estructuras de datos array. Existen muchas funciones PHP que están programas de forma similar a la mostrada en el ejemplo DCA.php y que permiten que, si los errores no estén bloqueados, se pueda ver la ruta de instalación.


Ejemplo de Local Path disclosure

Este error puede ser mucho más peligroso si, por ejemplo, se descubren nombre de ficheros o extensiones no protegidas en el servidor web.

Saludos Malignos!

7 comentarios:

RoMaNSoFt dijo...

Y para el lunes, la cagadilla del punto y coma del IIS de M$, ¿no? Bueno, mejor el martes, no sea que se confunda con una inocentada de lo trivial que es petar el IIS }:)

-r

Pedro Laguna dijo...

@RoMaNSoFt no seas malo, que seguro que lo tiene a medio escribir :P Ademas, si tienes .Net no funciona ¿Y quien va a tener un IIS si no es para poner ASP.Net? O:-)

Por cierto, se lo comente ya a Manu, pero este recurso se conoce desde hace ya tiempo, no se si se le ha dado un nombre concreto pero yo la recuerdo de hace casi un par de años, de usarla para sacar el path del blog del tecnicoless mayor:
- http://www.securityfocus.com/archive/1/archive/1/456731/100/0/threaded
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-0262

Un saludo y felices fiestas!!!

Pedro

P.D. Por cierto, muy bonitos los enlaces de ejemplo ;-)

Maligno dijo...

@RoMaNSoFt, ya lo había publicado el dab y yo a un amigo no le quito una primicia ;)

@Pedro, el expediente habla sólo de Wordpress cuando en realidad afecta a casi todo el php... está graciosote como lo ha escrito ;)

Saludos!

Dani Kachakil dijo...

El fallo del IIS también se puede explotar subiendo un fichero ASP desde una aplicación desarrollada en .NET (lo he probado y funciona), así que yo no le restaría importancia argumentando eso de que no afecta a los ASPX... ;-)

Anónimo dijo...

Eeee no lo molesten a Chema, que esta usando el chrome ahora!...

KiKiTo

Dr.White dijo...

Muy Bueno maligno =) con este tipo de técnicas se puede encontrar bugs en muchos lugares hasta los mas seguros justo hace unos dias hable sobre este bug en mi blog... esta bien explicado...


Saludos y Feliz navidad atrasada

martin dijo...

Hombre, pero lo que no hay que hacer es tener un servidor en producción con los errores mostrándose tan alegremente...

De todas formas, el tema de los arrays por GET sí es algo que a veces causa problemillas, como pasó hace poco con Wordpress.

Entradas populares