¿Quieres ver cualquier fichero del servidor de AT&T?

Hace unas horas se alertaba en diversos lugares de la existencia de una vulnerabilidad en uno de los php de esta gigante compañía de telecomunicaciones AT&T. Gigante también me parece el error, sobretodo a estas alturas.

El fichero PHP vulnerable era subpage.php, y la variable que aceptaba como parámetro cualquier archivo del servidor conociendo su ruta era page: http://www.research.att.com/areas/visualization/papers_videos/subpage.php?page=

Y con él se podían hacer fechorias tales como obtener el fichero /etc/password, /etc/hosts, la configuración de su apache, la información de su servidor... todo lo que uno quiera únicamente sabiendo su ruta y nombre.

Hay rumores de que este descubrimiento puede llegar como respuesta al reciente bloqueo al servidor de imágenes de 4chan por parte de AT&T, el cual parece ser que evitaba que sus clientes de ADSL pudiesen acceder al bloque de direcciones IP asignado para ellos. Esto se confirmó, alegando que en realidad se había decidido bloquear el acceso porque se estaban recibiendo ataques de denegación de servicio desde dichos rangos.

Moscas a cañonazos

Pero, ¿y en qué consiste esta vulnerabilidad? ¿Por qué es explotable? ¿Cual es el despiste que tuvieron ciertos desarrolladores de att.com para permitir la lectura de cualquier fichero alojado en el servidor?

La vulnerabilidad

La vulnerabilidad se conoce como inclusión de archivos locales gracias a directory/path traversal, y consiste en aprovecharnos de un fallo de validación de parámetros de entrada en una variable cuyo valor el desarrollador utilizará como argumento de funciones del lenguaje PHP (en el ejemplo de AT&T) como son include, require, include_once, require_once...

El ejemplo

Si en tu código de un fichero php, que llamaremos recuperar.php, utilizas algo así para llamar a otros ficheros de tu aplicación mediante un parámetro GET por ejemplo (se almacenará en $_GET['fichero'] al realizarse la petición):

-- dramatización --
$fichero = $_GET['fichero'];
include($fichero); // A cascoporro!!!
?>
-- end of dramatización --

y la dirección es parecida a

http://www.miservidor.com/recuperar.php?fichero=pagina1.php

Aprovecha que es verano y hay más tiempo y revísala, porque sin las medidas necesarias, podrías ser víctima de este tipo de ataques.

La consecuencia

Cambiando pagina1.php por por ejemplo:

http://www.miservidor.com/recuperar.php?fichero=../../../../(unos cuantos ../)../etc/passwd

Provocaríamos que el script llamara a dicho fichero para que su contenido fuese pintado en la página. Los "../" son los que provocan a la función saltar hacia atrás en los directorios, saliéndonos del Document Root de la aplicación web (directory traversal). Obviamente, como el passwd no es código php interpretable, veríamos el contenido íntegro incluído en la web.

La solución

• Filtrar, filtrar y filtrar todos los parámetros que un usuario de la página pueda manejar. No hay que fiarse de nadie.
• Asegurarse de que no se pueden servir ficheros más allá del Document Root de la página.
• Procesamiento correcto del parámetro y de la función que se dedique a recuperar el contenido del fichero que necesitemos. Existen funciones del propio lenguaje encargadas de limpiar una cadena para evitar que contengan puntos, barras laterales y cualquier carácter que no sea adecuado.

Otros que han desarrollado sin tener en cuenta estas medidas: software vulnerable a Local File Inclusion y Directory/Path Traversal en milw0rm: [1], [2] y [3]

Pocos no hay...

[+] AT&T exposes /etc/passwd , bad php (webappsec.org)
[+] Reddit
[+] Testing for Path Traversal (owasp.org)

Autor: José A. Guasch
Fuente: Security by Default

Suscríbete a nuestro Boletín