Como ejemplos, trataremos de envenenar los recursos "access.log" , comenzando mediante la explotación de una vulnerabilidad LFI primeramente para acceder a estos archivos de registro. Una vez hayamos logrado acceder a estos archivos, veremos cómo manipularlos para incluir código malicioso.
En el caso de los logs de SSH, el atacante puede inyectar código PHP en el campo de usuario durante el proceso de autenticación. Esto permite que el código se registre en el log ‘auth.log‘ de SSH y sea interpretado en el momento en el que el archivo de registro sea leído. De esta manera, el atacante puede lograr una ejecución remota de comandos en el servidor.
En el caso del archivo "access.log" de Apache, el atacante puede inyectar código PHP en el campo User-Agent de una solicitud HTTP. Este código malicioso se registra en el archivo de registro ‘access.log’ de Apache y se ejecuta cuando el archivo de registro es leído. De esta manera, el atacante también puede lograr una ejecución remota de comandos en el servidor.
Para prevenir el Log Poisoning, es importante que los desarrolladores limiten el acceso a los archivos de registro y aseguren que estos archivos se almacenen en un lugar seguro. Además, es importante que se valide adecuadamente la entrada del usuario y se filtre cualquier intento de entrada maliciosa antes de registrarla en los archivos de registro.
Buscamos vulnerabilidades en esta web y nos encontramos con Local File Inclusion con el siguiente exploit debido a un plugin
La vulnerabilidad Local File Inclusion (LFI) es una vulnerabilidad de seguridad informática que se produce cuando una aplicación web no valida adecuadamente las entradas de usuario, permitiendo a un atacante acceder a archivos locales en el servidor web.
En muchos casos, los atacantes aprovechan la vulnerabilidad de LFI al abusar de parámetros de entrada en la aplicación web. Los parámetros de entrada son datos que los usuarios ingresan en la aplicación web, como las URL o los campos de formulario. Los atacantes pueden manipular los parámetros de entrada para incluir rutas de archivo local en la solicitud, lo que puede permitirles acceder a archivos en el servidor web. Esta técnica se conoce como "Path Traversal" y se utiliza comúnmente en ataques de LFI.
En el ataque de Path Traversal, el atacante utiliza caracteres especiales y caracteres de escape en los parámetros de entrada para navegar a través de los directorios del servidor web y acceder a archivos en ubicaciones sensibles del sistema.
Por ejemplo, el atacante podría incluir "../" en el parámetro de entrada para navegar hacia arriba en la estructura del directorio y acceder a archivos en ubicaciones sensibles del sistema.
Para prevenir los ataques LFI, es importante que los desarrolladores de aplicaciones web validen y filtren adecuadamente la entrada del usuario, limitando el acceso a los recursos del sistema y asegurándose de que los archivos sólo se puedan incluir desde ubicaciones permitidas. Además, las empresas deben implementar medidas de seguridad adecuadas, como el cifrado de archivos y la limitación del acceso de usuarios no autorizados a los recursos del sistema.
En ocasiones tendremos que cambiar la ruta usando la técnica de path traversal, es decir irse al directorio raíz (http://ex.com/index.php?file=../../../../../../../../etc/passwd), también es posible que tengamos que url encodear( http://ex.com/index.php?page=%252e%252e%252fetc%252fpasswd), o wrappers (http://ex.com/index.php?file=php://filter/convert.base64-encode/resource=index)
Vamos a fuzzear para ver que rutas nos encuentra disponibles
Y encontramos la ruta /var/log/apache2/access.log
En el caso del archivo "access.log" de Apache, el atacante puede inyectar código PHP en el campo User-Agent de una solicitud HTTP. Este código malicioso se registra en el archivo de registro ‘access.log’ de Apache y se ejecuta cuando el archivo de registro es leído. De esta manera, el atacante también puede lograr una ejecución remota de comandos en el servidor.
Comencemos a envenenar los logs mediante un RCE
Las vulnerabilidades de RCE pueden aparecer en cualquier tipo de software, en casi todos los lenguajes de programación y en cualquier plataforma.
Otras vulnerabilidades pueden conducir a la ejecución remota de código arbitrario. Por ejemplo, desbordamiento de búfer, vulnerabilidades de deserialización, inyección SQL o (XSS)vulnerabilidades que conducen a la ejecución remota de código en una aplicación vulnerable.
Algunos ataques RCE pueden ocurrir después de un retraso. Por ejemplo, la aplicación puede almacenar primero la carga útil RCE en un archivo de configuración y solo ejecutarla más tarde, tal vez incluso varias veces. Este tipo de vulnerabilidad RCE se llama a RCE almacenado.
Cada lenguaje de programación común utilizado en el desarrollo web tiene funciones para evaluar (ejecutar) código en ese lenguaje en tiempo de ejecución. Cada vez que los desarrolladores usan tales funciones en aplicaciones web, introducen la posibilidad de ejecución remota de código del lado del servidor web.
A continuación se muestra un ejemplo simple de código fuente PHP con vulnerabilidades de inyección de código (RCE).
Vemos que tenemos ejecución remota de comandos así que tenemos varias maneras de entrar, puesto que hemos envenenado los logs de apache(Log Posioning), así que tenemos varias maneras de entrar, primeramente mediante RFI
La vulnerabilidad Remote File Inclusion (RFI) es una vulnerabilidad de seguridad en la que un atacante puede incluir archivos remotos en una aplicación web vulnerable. Esto puede permitir al atacante ejecutar código malicioso en el servidor web y comprometer el sistema.
En un ataque de RFI, el atacante utiliza una entrada del usuario, como una URL o un campo de formulario, para incluir un archivo remoto en la solicitud. Si la aplicación web no valida adecuadamente estas entradas, procesará la solicitud y devolverá el contenido del archivo remoto al atacante.
Un atacante puede utilizar esta vulnerabilidad para incluir archivos remotos maliciosos que contienen código malicioso, como virus o troyanos, o para ejecutar comandos en el servidor vulnerable. En algunos casos, el atacante puede dirigir la solicitud hacia un recurso PHP alojado en un servidor de su propiedad, lo que le brinda un mayor grado de control en el ataque.
Crearemos un archivo php con una revshell que apunte a nuestra maquina atacante
Montamos un servidor en python y utilizamos curl para indicar mediante RCE al servidor que de descargue el archivo que hemos creado. Como vemos lo a descargado
En muchas ocasiones tenemos que darles permisos de ejecución(este no es el caso) y de la misma manera que le hemos indicado al servidor que descargue nuestra archivo le indicamos que lo ejecute, pero antes nos ponemos en escucha con netcat, obteniendo la revshell
Otra manera de hacerlo es indicando el one liner de la revshell en la URL, también lo podemos hacer utilizando burpsuite.
Os dejo el video explicativo e mi canal de YouTube
.png)
Muchas gracias, por usar la maquina Shared para el ejemplo. Una explicación de 10
ResponderEliminarMuchas gracias compañero, es un placer usar tu maquina, es muy buena y divertida ;)
Eliminar