Vulnerabilidad Log Poisoning

La vulnerabilidad log poisoning reside de LFI ya que en este caso nos aprovechamos del funcionamiento de los archivos de log. Recordemos que la función de los mismos es la de guardar cada registro de evento que suceda en el sistema. En el caso de no estar bien configurados, podríamos tener vulnerabilidades como se muestra a continuación.

Archivo access.log

A modo de ejemplo veremos el funcionamiento de este archivo a través del script example_script.php dentro del directorio /var/www/html:

La función del archivo access.log radica en guardar información acerca de las peticiones o intentos de autenticación. La ruta del mismo es la siguiente: /var/log/apache2/access.log.

Veamos un ejemplo, intentemos buscar cualquier cosa en el navegador:

Como podemos ver, no nos muestra nada ya que no existe dicha dirección o archivo.

Ahora verifiquemos access.log en nuestra shell:

Por lo tanto, visto está, cual es la función de este archivo de log. Ahora bien, ¿Dónde está la vulnerabilidad?

Podemos notar lo remarcado en la imagen “Mozilla/5.0 …”. Este hace referencia al USER_AGENT que el cliente envía ya que, como vimos en la primera parte de LFI con el archivo /proc/self/environ, podemos aprovecharnos y colocar código PHP dentro de esta cabecera y generar un backdoor en el servidor. Esto se puede hacer tanto con la herramienta proxy o a través de una Shell de comandos.

Inclusión a través de la cabecera User Agent

Veamos cómo podemos generar un backdoor a través de esta vulnerabilidad:

Por defecto si lo buscamos a través de nuestro script en el navegador nos mostrará todas peticiones realizadas. Recordemos que con Ctrl+u podemos verlo en un formato más “amigable” a dicho resultado de búsqueda.

Esta vez practicaremos nos aprovecharemos de la vulnerabilidad de log poisoning desde la terminal con el comando curl.  Enviaremos un “whoami” dentro de un código PHP, a través de la opción –A, la cual se usa para cambiar el user-agent, y así verificar dicha vulnerabilidad.

Como vemos, nos devuelve el resultado con todas las peticiones. Ahora bien, si nos dirigimos al navegador y actualizamos la página, en la última petición veremos lo siguiente:

¡Exacto! Se nos ha ejecutado el comando whoami (cuyo usuario es www-data) y por lo tanto podríamos aprovechar esta vulnerabilidad para inyectar código PHP y generar un backdoor.

Archivo auth.log

La función del archivo auth.log es la de registrar los usuarios que quieran acceder al sistema ya sea un acceso válido, o inválido, su registro quedará guardado. Dicha ruta es /var/log/auth.log. Veamos el siguiente error en el ejemplo:

En dicho archivo veríamos lo siguiente:

Inclusión a través de SSH

Ahora bien, veamos esto aprovechando la vulnerabilidad de log poisoning usando SSH. Así como podíamos ver el archivo /etc/passwd, también podemos hacerlo con el archivo /var/log/auth.log. Teniendo esto en cuenta lo primero que haremos será tratar de conectarnos mediante ssh con un usuario inexistente de ejemplo, para ver lo que interpreta dicho archivo de log.

Vemos que quisimos ingresar a través del usuario “usuario-inexistente” y en dicho archivo, obtenido a través de la barra del navegador, se puede ver que en las últimas líneas queda registrado el intento fallido de este «usuario».

Veamos otro ejemplo para entenderlo un poco mejor, para esto usaremos el servicio ssh. En caso de no tenerlo activado lo podemos hacer de la siguiente manera: systemctl start ssh

Se observa que no fue un usuario lo que le pasamos al servidor, sino que se trata de código PHP cuya función se basa en el comando “whoami” es decir, saber el usuario logueado actualmente en el sistema, cuya respuesta hace referencia al usuario www-data y, por si fuera poco, el servidor lo ejecuta y nos lo hace saber con un mensaje de fallo de autenticación en las líneas del archivo de log.

Generar un backdoor

Sabiendo lo anterior podemos usar esta vulnerabilidad de log poisoning con ejecución remota de comandos a través de una inyección de código PHP, con respecto al “usuario inexistente” que le pasemos por ssh. Solo que esta vez, no será un usuario lo que enviemos, sino un comando cuyo objetivo será generar un backdoor a través de la herramienta netcat.

Primero, para no tener problemas con espacios o comillas, vamos a codificar nuestro comando a través de base64. Para esto podemos usar Burpsuit, o también es una buena práctica hacerlo desde nuestra shell de la siguiente manera:

Como vemos, dicho comando ha sido codificado. El mismo será usado como “usuario” para pasarlo a través de ssh como hicimos anteriormente. Para decodificarlo haríamos lo siguiente:

Sabiendo esto último, la idea es decodificar el comando netcat en el servidor y generar una Shell inversa. Por lo tanto, el “usuario” a usar en ssh será el siguiente:

Ahora bien, lo primero que haremos será ponernos en escucha por el puerto 4447. Luego, a través de ssh, pasaremos nuestro código PHP al servidor. Veamos los detalles de las comillas en este último comando:

Luego de ejecutar dicho comando, nos pedirá colocar una contraseña, colocamos cualquiera y después actualizamos la página en el localhost. Veremos que la misma se queda actualizando de forma constante.

Por lo tanto hemos tenido éxito con nuestro ataque. En otras palabaras, hemos generado un backdoor a través de una conexión inversa. Podemos verificarlo con el usuario “www-data” del sistema.

No olvidar

Esta no es la única forma de generar un backdoor, podríamos haber usado el código PHP de otra manera como se muestra a continuación:

¿Cómo podemos prevenir esta vulnerabilidad log poisoning?

Primero y principal debemos prevenir inclusión de archivos locales en el sistema ya que, esta representa el canal para luego aprovecharnos de los archivos de logs mencionados anteriormente. Por tanto, principalmente debemos tener en cuenta lo siguiente:

• Sanitizar todas las entradas, o peticiones, hacia cualquier archivo local del sistema.
• Parchear las entradas de modo tal que no se permita la ejecución remota de comandos.
• Implementar de manera correcta los parámetros de las URL. Es decir, las cookies, cabeceras HTTP y peticiones GET/POST.
• Gestionar las cuentas de usuarios con respecto a los grupos que pertenece, privilegios y autenticación. Esto puede ser: Cantidad de intentos fallidos, cambios de contraseñas, tiempo de espera, etc..

 Con respecto a los grupos, es importante testear donde se encuentra el usuario del servidor “www-data” u otro. Ya que si se encuentra dentro de un grupo con determinados privilegios (como el grupo “sudo”) podría significar el acceso total al sistema. Para practicar con dicha vulnerabilidad y hacer uso del script exampl_script.php podemos colocar al usuario “www-data” dentro del grupo adm. Este grupo es usado para monitoreo del sistema. También, los miembros de este grupo pueden ver los archivos de eventos en /var/log sin tener que utilizar los comandos «su» o «sudo». Históricamente el directorio /var/log se conocía como usr/adm, y luego /var/adm, de ahí su nombre.

Ahora bien, hasta acá habrá notado que lo malo de una vulnerabilidad no radica solo en esta misma, sino que, el solo hecho de existir una pueda encadenar en la existencia de otras. La constante actualización y aprendizaje en estos temas serán nuestra mayor herramienta de defensa para cualquier ciberataque.