Después de profundizar en el servicio SSH y OpenSSH de las ultimas entradas de este blog, es la oportunidad de intentar enseñar algunas técnicas empleadas por hackers (al referirnos a hackers, no significa que este colectivo siempre se encuentre en la posición de atacante). Se trata de algunas técnicas empleadas para comprometer/defender este tipo de servicios.

KIPPO PARA ATACAR Y/O DEFENDER UN SERVICIO SSH

Kippo es un proyecto desarrollado para la creación de un honeypot SSH, el cual permite definir un servicio SSH virtual para registrar ataques de fuerza bruta, de este modo podemos determinar en que momento se realiza un ataque sobre un servicio SSH sin que en realidad se vea afectado el propio servicio y tomar las medidas adecuadas de acuerdo al plan de acción ante amenazas de seguridad (si existe).

Por otro lado también puede ser una herramienta útil para que un atacante capture las credenciales de un usuario por medio de un ataque MITM.

Instalación de Kippo en GNU/Linux Debian-Ubuntu

En primera instancia es necesario descargar el proyecto kippo desde:
http://code.google.com/p/kippo/

La ultima versión del software a la fecha de creación de este documento es la 0.5, descargar y descomprir el fichero kippo-0.5.tar.gz

Posteriormente se instalan las dependencias obligatorias, en el caso de que no se encuentren previamente instaladas:

apt-get install python-twisted

Con lo anterior se deberán instalar todas las dependencias necesarias para la ejecución de kippo, solamente basta iniciar el servicio con el comando ./start definido en el directorio raíz, posteriormente se podrán ver todos los intentos de conexión el el fichero de log ubicado en <DIR_KIPPO>/lib/kippo.log

 Uso de Kippo desde la perspectiva de un defensor

Desde la perspectiva de una persona que intenta defender un sistema SSH de posibles ataques contra el servicio, Kippo es una herramienta que permite alertar sobre un ataque en curso y posteriormente tomar medidas al respecto, como por ejemplo implementar medidas adicionales sobre otros servicios en ejecución, etc.

El defensor intentará direccionar el trafico del puerto 22 (el puerto normalmente habilitado para SSH) hacia el puerto 2222 (el puerto por defecto de Kippo) de esta forma cuando un atacante intente realizar un ataque de fuerza bruta sobre un servicio SSH sobre el puerto 22 del objetivo, realmente estará realizando un ataque a Kippo, el cual no va a intentar realizar el proceso de autenticación sobre el servicio real, para esto el defensor normalmente hace uso de iptables para definir la redirección de paquetes de la siguiente forma:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 22 -j REDIRECT –to-port 2222

 aquí eth0 es la interfaz de red, lo que indica que todo el trafico hacia el puerto 22 será destinado al 2222 de Kippo.

Este mecanismo es útil tal vez para un atacante poco hábil, pero en el mundo real, lo que frecuentemente intentará hacer un hacker, será realizar un estudio profundo del objetivo y realizará un escaneo de puertos y detección de servicios con herramientas como nmap, hping y amap y de esta forma probablemente podrá enterarse que el servicio que supuestamente se ejecuta en el puerto 22 (que puede ser perfectamente un Netcat), no es realmente un servicio SSH, sino un Fake Service, lo que es definido como Seguridad por medio de la Ocultación, por esta razón, es necesario implementar esta solución con un la compañía de un buen firewall y un IDS para detectar posibles ataques de reconocimiento por medio del uso de las herramientas anteriormente indicadas.

 Uso de Kippo desde la perspectiva de un atacante

Desde la perspectiva de un atacante, probablemente utilizará kippo como una herramienta para engañar a la maquina objetivo con un ataque MITM y posteriormente intentará capturar las credenciales de acceso a un servicio SSH, evidentemente para conseguir esto es necesario que el atacante se encuentre en la misma red que los clientes y el servicio SSH real, lo que conlleva que probablemente una maquina interna ha sido comprometida por un atacante interno.

Suponiendo que el Gateway es el: 192.168.1.1, la maquina del atacante 192.168.1.33 y la maquina del objetivo es la 192.168.1.34 el procedimiento podría ser similar al siguiente:

NOTA: Antes que nada, para que esto funcione, la maquina del atacante tiene que tener habilitada la opción de forwarding del sistema operativo, para que este pueda redireccionar peticiones entrantes a otros destinos, para esto se debe editar el fichero /proc/sys/net/ipv4/ip_forward y establecer el valor de “1” por defecto es “0”

  1. Utilizar un ataque MITM para capturar los paquetes que viajan desde y hacia el objetivo, como por ejemplo haciendo uso de envenenamiento de ARP.

    Desde la maquina del atacante:

    >arpspoof -i eth0 -t 192.168.1.34 192.168.1.1

    >arpspoof -i eth0 -t 192.168.1.1 192.168.1.34
    >dnsspoof -f ./hosts

     Donde el fichero host contiene:

    192.168.1.33 *.*

  2. Ahora todo el trafico que viaje desde el cliente, pasará por la maquina del atacante sin que el objetivo se entere de lo que esta pasando, con esto el atacante intentará definir las reglas de redirección con el comando iptables:

    >iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 22 -j REDIRECT –to-port 2222

    >iptables -t nat -L

  3. Posteriormente iniciar el servicio de Kippo con ./start y estará atento de lo que se registre en el fichero de log con el comando

    >tail -f <DIR_KIPPO>/log/kippo.log

  4. El objetivo sin enterarse de lo sucedido, intentará conectarse con ael servicio de ssh de una maquina remota, utilizando un programa como Putty, ingresa la dirección del servidor SSH y el puerto correspondiente, posteriormente intenta autenticarse ingresando sus credenciales.

  5. El atacante aprecia que se producen trazas en el fichero de log de kippo, unas son bastante interesantes:

    2010-04-02 00:39:34+0200 [HoneyPotTransport,0,192.168.1.33] starting service ssh-userauth

    2010-04-02 00:39:42+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.34] adastra trying auth none

    2010-04-02 00:39:42+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.34] adastra trying auth keyboard-interactive

    2010-04-02 00:39:46+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.34] login attempt [jhon/keppler] failed

    2010-04-02 00:39:46+0200 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.1.34] adastra failed auth keyboard-interactive

    Ahora el atacante tiene un usuario y una clave con las cuales podrá conectarse al servicio SSH cómodamente.

  6. El objetivo, siempre recibe el mismo mensaje de error, el cual le indica que no puede conectarse a la maquina remota, apreciando que la respuesta del servidor es un login y password no validos (en realidad se trata de la respuesta de Kippo que dará el mismo mensaje independiente de los valores ingresados por el usuario).

MULTIPLEXOR DE SSH, SSH Y HTTPS POR EL PUERTO 443

Frecuentemente los administradores de red bloquean los paquetes salientes por el puerto 22 en entornos empresariales (puerto por defecto de SSH) para evitar que el personal interno utilice estos servicios para fines tales como la creación de túneles SSH que burlen las reglas del firewall/proxy de la organización, sin embargo es muy poco frecuente que el puerto 443 (puerto por defecto de HTTPS) se encuentre bloqueado. Por esta razón existe SSLH, se trata de un script escrito en Perl que acepta conexiones HTTPS, SSH y OpenVPN sobre el mismo puerto, de esta forma es posible conectarse a un servidor SSH o OpenVPN utilizando el puerto 443 como salida de la conexión, lo que es realmente útil en entornos corporativos donde el puerto 22 o la salida a servidores OpenVPN se encuentran bloqueados.

Su instalación es muy sencilla sobre plataformas basadas en Debian:

>apt-get install sslh

 Aunque se trata de la forma mas sencilla para instalar el programa, por defecto en los repositorios de Debian Squeeze tienen la versión 1.6, mientras que si se instala de forma manual, es posible tener la versión 1.8 que es la ultima que se encuentra liberada. Para descargar la ultima versión de sslh es necesario dirigirse a: http://www.rutschle.net/tech/sslh.shtml

Para instalar SSLH desde el código fuente, es necesario compilar e instalar el software utilizando el comando “make install” después de que se encuentre instalado, se podrá apreciar que se crea el correspondiente script en el directorio /etc/init.d/

Ahora bien, en primer lugar es necesario tener un servidor web instalado con soporte a SSL, en el caso de Apache es necesario que tenga instalado el módulo correspondientes a mod_security y los certificados RSA necesarios para inicializar dicho módulo, estas son tareas que se pueden conseguir fácilmente conociendo un poco el servidor web Apache, sin embargo estas tareas se salen de la extensión de este post, por esta razón si no se tienen conocimientos sobre apache, se aconseja o bien comenzar a instalar y configurar este servidor o utilizar XAMPP (http://www.apachefriends.org/es/xampp.html) si se desea hacer una prueba de concepto rápida de SSHL XAMPP es perfectamente valido ya que viene configurado con varias características interesantes como por ejemplo integración con MySQL, PHP, servidor FTP y soporte a SSL/TLS, por esta razón es altamente recomendado su uso.

Una vez configurado el servidor web (ejecutando HTTPS por el puerto 443) se procede a configurar el arranque de SSHL, que consta solamente de dos pasos:

1.En primer lugar es necesario editar el fichero de configuración de SSLH para indicar la ruta del servidor Web y la ruta del servidor SSH, dicho fichero se encuentra ubicado en: /etc/default/sslh una vez ubicados en dicho fichero se incluyen las siguientes lineas:

DAEMON_OPTS=»-u sslh -p 0.0.0.0:443 -s 192.168.1.34:22 -l 192.168.1.35:443 -P /var/run/sslh.pid»

RUN=yes

En el caso anterior, se indica a SSLH que inicie el servicio en el puerto 443 de la maquina local, mientras que el servicio SSH y el servicio SSL se encuentran en las maquinas 192.168.1.34 y 192.168.1.35 respectivamente, también se indica el parámetro obligatorio relacionado con el fichero donde se almacenará el PID del proceso. Finalmente se establece la opción RUN=yes la cual le indica al servicio que debe arrancar con las opciones definidas anteriormente.

En este caso concreto en la maquina local el puerto 443 se encuentra disponible y por este motivo el servicio SSLH se inicia en él, sin embargo es posible utilizar cualquier otro.

2. Ahora, cuando se realice una conexión a la maquina local apuntando al puerto 443, lo que realmente ocurrirá será que SSLH recibirá la petición y dependiendo del protocolo utilizado por el cliente redireccionará al servidor web por el puerto 443 (HTTPS) o al servidor SSH por el puerto 22, por ejemplo:

>ssh -p 443 root@localhost

root@localhost’s password:

 En la maquina local no existe ningún servicio SSH ejecutándose en el puerto 443, solamente esta SSLH el cual ha detectado que se trata de una conexión por medio del protocolo SSH y ha enviado la petición al host y puerto correspondiente, la contraseña solicitada en este caso corresponde a la cuenta del usuario root en la maquina 192.168.1.34. Por otro lado si desde un navegador se introduce la ruta “https://localhost” SSLH enviará la petición al servicio correspondiente en la maquina 192.168.1.35, todo lo anterior respondiendo a la configuración establecida en el fichero de configuración de SSLH.

En la próxima entrada se definirán mas “tips” de hacking a modo defensivo y ofensivo con SSH