Publicación del primer posts

_pages/hacking.md

@@ -1,5 +1,5 @@
 ---
-title: "hacking"
+title: "Hacking"
 layout: category
 permalink: /categoria/hacking/
 taxonomy: hacking

_posts/categoria/hacking/2023-10-22-lfi.md

@@ -4,6 +4,114 @@ title: "Local File Inclusion"
 categories: hacking
 ---
 
-# Deberia listarse
 
-En la página de hacking
+# Concepto
+
+Este ataque 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.
+
+Si no funciona el LFI estándar se pueden usar distintos wrappers de php para intentar que funcione. Como *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 si lo copias le haces un `echo ""` y decodificas con *base64 -d*, tendrías 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 no tenga los permisos restringidos).
+
+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`, sabemos que si la máquina es linux ese *example.html* normalmente estará en */var/www*, aún así el número de `../` es irrelevante ya que se para en la raíz sin dar fallo.
+
+Como conclusión si imprime el archivo */etc/passwd* es vulnerable por lo que nos permite intentar visualizar cualquier archivo del sistema, 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 del *~/.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 a la máquina víctima con los credenciales de un usuario de la mima (primero ejecutar `curl -s http://vulnerable_host/preview.php?file=../../../../etc/passwd | grep "sh$"` para ver que shells hay en el sistema, el *-s* del curl es de silent, y eso es 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.
+
+## /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 es un contenedor de docker o como se comunica el servidor.
+
+## /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 limpiar la salida podríamos usar el siguiente comando:
+
+```bash
+for port in $(curl -s http://vulnerable_host/preview.php?file=../../../../proc/net/fib_trie | awk '{print $2}' | grep -v "local_address" | awk '{print $2}' FS=":" | sort -u); do echo "[$port] -> Puerto $(echo "ibase=16; $port | bc")" '
+```
+
+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 el pattern puesto
+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 son los puertos abiertos internamente, estos suelen estar protegidos desde afuera por un firewall.
+
+# 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
+
+- [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)
+
+- [Vídeo demostración en español(créditos al Pingüino de Mario)](https://www.youtube.com/watch?v=t15Xvv6k-1U)
+
+- [Vídeo demostración en inglés(créditos a John Hammond)](https://www.youtube.com/watch?v=O7-qHZFxjgk)
+