Vulnerabilidad de Inclusión Remota de Archivos
Table of Contents
ToggleIntroducción
La vulnerabilidad de inclusión remota de archivos, también llamada RFI, se produce cuando un archivo de un servidor remoto se coloca dentro de una página web. Generalmente se hace para mostrar contenido en un sitio web desde otro sitio web remoto. Y es aquí donde nace esta vulnerabilidad, ya que algunas veces podemos aprovecharnos de este proceso, en caso de haber un fallo de seguridad, y hacernos con archivos de forma remota.
Hay que tener en cuenta que PHP proporciona funciones nativas que permiten la inclusión de archivos remotos. Otros lenguajes generalmente requieren una solución alternativa para imitar este comportamiento. Por lo tanto, es más probable que aquellas aplicaciones web escritas en PHP sean vulnerables a los ataques de inclusión de archivos remotos (solo en el caso de no estar bien configuradas).
¿Cómo funciona esta vulnerabilidad?
Así como en LFI agregábamos la dirección de un archivo local del sistema, en el caso de una vulnerabilidad de inclusión remota de archivos, haremos lo mismo. Pero agregaremos una URL donde se encuentre dicho archivo. En otras palabras, para acceder a un archivo remoto necesitamos la dirección de dicho servidor remoto. Es decir, podemos usar un sitio web como base para, desde allí “saltar” a otro servidor, y conseguir acceso a archivos del sistema.
En LFI usábamos una URL de la siguiente forma: https://sitio_web.com/index.php?page=text.txt. Sin embargo, en un RFI el aspecto del mismo suele ser el siguiente: https://sitio_web.com/index.php?page=https://otro_sitio_web:port
Veamos los siguientes ejemplos:
Para ello vamos a utilizar la máquina DVWA:
Como vemos, hemos obtenido el buscador de google. En otras palabras, hemos incluido una URL dentro de otra URL para obtener acceso a goole.com.
No obstante, a veces pueden aplicarse script de seguridad que no permitan este tipo de acceso. Veamos el siguiente script:
Este script no nos permite usar http ni https, como así también el directory path traversal (../), ya que se substituyen por un carácter nulo (“”). Sin embargo, la función str_replace es case sensitive, esto quiere decir que no diferencia entre mayúsculas y minúsculas. Por lo tanto, si modificamos un caracter (por ejemplo htTp:), podríamos tener acceso. Veamos a continuación:
Como se muestra, hemos tenido éxito modificando un solo caracter.
Ganar acceso a otra máquina
Ahora bien, vamos a intentar conectarnos a otra máquina (Debian 11) para acceder a ella y ver el contenido del archivo file.txt. Vemos que la dirección IP de nuestra máquina víctima es la 192.168.100.190:
Recordar siempre, en el caso de máquinas virtuales, tenerlas en “bridge adapter” y el servicio apache2 activo. Luego, levantaremos un servidor utilizando Python a través del puerto 4447:
Hecho esto, desde nuestra máquina kali, y conectados a través de DVWA, vemos que podemos tener acceso a nuestra máquina víctima de la siguiente manera:
..?page=http://192.168.100.190:4447
Como podemos ver, hemos explotado una vulnerabilidad de inclusión remota de archivos. Es decir, se nos establecen los directorios y archivos dentro de /home/tiner de nuestra máquina víctima. Cabe aclarar, que los directorios .ssh y .gnupg contienen archivos críticos encriptados, es decir, esta puede ser una vulnerabilidad de acceso al sistema si no se toman las medidas adecuadas. Ahora bien, para ver el contenido del archivo file.txt solo tenemos que aclararlo en el navegador como se muestra a continuación:
Por lo tanto, en el lado del servidor veremos las peticiones que hemos hecho:
¿Cómo prevenimos la vulnerabilidad de inclusión remota de archivos?
Para evitar esta vulnerabilidad podemos desactivar la inclusión remota de comandos en caso de no necesitarla de la siguiente manera: En PHP cambiamos el “allow_url_include” a “0” en RFI. También, como complemento debemos tener en cuenta lo siguiente:
Aplicar la validación de salida en el extremo del servidor. No debemos olvidar que las funciones de validación del lado del cliente, que tienen la ventaja de reducir la sobrecarga de procesamiento, también son vulnerables a los ataques con herramientas de proxy.
Los campos de entradas o validación de usuarios deben complementarse con una lista blanca. Es decir, un conjunto de caracteres permitidos, ya que estas nos permiten tener alejados a los usuarios no deseados. Por ejemplo, podemos implementar una lista de usuarios y direcciones IP que necesitan saber lo que ocurre con ciertos datos o información de una empresa. De esta manera, cualquier usuario que no necesite acceder a estos datos se mantendrá fuera, y eso reduce el número de personas que manejan datos sensibles.
Las listas blancas también se pueden considerar, al igual que LFI, en los archivos permitidos tales como .jpg, .docx, .pdf, etc. Como así también, restringir los permisos de ejecución a los directorios de carga.
Otra manera de desinfectar la entrada de usuarios no deseados es configurando los valores de las cookies, headers o encabezados HTTP, peticiones o request GET/POST y parámetros URL.