HoneyPots Parte 1 – Kippo

Este será el primer articulo de una serie en la que se hablará sobre algunos de los honeypots más utilizados para la detección y prevención de ataques. Antes de continuar y para los que no lo saben, un Honeypot en informática es un servicio activo que acepta y procesa peticiones como cualquier servidor del tipo SSH, HTTP, SMB, etc. Pero en realidad se encarga de monitorizar y registrar los intentos fallidos de autenticación y cualquier ataque contra el supuesto servicio, se trata de un señuelo. Es una forma de engañar a un atacante haciéndole creer que se encuentra perfilando y analizando un servicio del objetivo, cuando en realidad lo que está haciendo es suministrándole información al objetivo sobre las actividades que está realizando.
Uno de los más conocidos y utilizados es Kippo, un honeypot que se encarga de levantar un servicio SSH en el puerto indicado y registrar todos los intentos de autenticación realizados contra dicho servicio. Kippo es un honeypot altamente personalizable y es posible utilizarlo para localizar a un atacante e incluso, para que pueda iniciar sesión en el supuesto sistema y permitirle interactuar con un sistema de ficheros ficticio, el cual también es configurable.

A continuación se explica como instalar y configurar Kippo en un sistema Linux.

Instalación y configuración de Kippo.

Kippo es un sistema que ha sido desarrollado utilizando Python y Twisted, una potente librería de la que ya he hablado en alguna ocasión. Una de las ventajas de Kippo, es que se puede lanzar de forma programática desde un script en Python gracias a las funciones definidas en el modulo “twistd” de Twisted, esto significa que puedes crear tus propios scripts en Python y arrancar Kippo en cualquier momento.

Para instalar Kippo, se debe tener Python instalado y algunas librerías en el entorno, tales como Twisted, PyCrypto y service_identity Zope. Una vez cumplidas dichas dependencias, se puede descargar el proyecto desde su repositorio en GitHub.

>git clone https://github.com/desaster/kippo.git >ls -F data/ doc/ honeyfs/ kippo.cfg.dist log/ start.sh* txtcmds/ dl/ fs.pickle kippo/ kippo.tac README.md stop.sh utils/

 

Lo primero que se puede apreciar en el directorio descargado, es que existen dos ficheros ejecutables que son “start.sh” y “stop.sh”, evidentemente son utilizados para iniciar y detener Kippo, pero antes de iniciar el Honeypot, se deben conocer las propiedades de configuración que permitirán personalizar el servicio y que sea más difícil para un atacante determinar que se trata de un honeypot. El script “start.sh” buscará el fichero de configuración “kippo.cfg” en el directorio desde donde se ejecuta y como se puede apreciar en el listado de contenidos del directorio, dicho fichero no existe, pero si que se puede ver el fichero “kippo.cfg.dist”, el cual se puede renombrar a “kippo.cfg”. El fichero “kippo.cfg.dist” contiene las propiedades que pueden ser útiles para iniciar el servicio con por la configuración defecto. Algunas de dichas propiedades (las más interesantes) se explican a continuación.

ssh_addr: Interfaz de red en la que iniciará el honeypot. El valor por defecto es “0.0.0.0”

ssh_port: Puerto en el que iniciará el honeypot. El valor por defecto es “2222”

hostname: Será cadena que verá un atacante cuando consiga una shell en el honeypot. Evidentemente, es una buena recomendación poner un nombre que parezca pertenecer a un servidor real en el objetivo.

download_path: Directorio en el que se guardaran todos los ficheros que intente descargar el atacante en el servidor.

filesystem_file: Probablemente es una de las propiedades más interesantes a la hora de engañar a un atacante haciéndole creer que se encuentra en un sistema legitimo, ya que esta propiedad se encarga de definir un sistema de ficheros completo, con sus correspondientes ficheros, permisos y demás. Este fichero se debe encontrar en formato de objetos serializados en Python (Pickle). Se puede utilizar el script “utils/createfd.py” para crear dicho sistema de ficheros partiendo de un sistema elegido por el usuario.

data_path: En el directorio indicado en esta propiedad se debe ubicar el fichero “usersdb.txt” en el se definirá por cada línea, el usuario y sus credenciales de acceso al supuesto honeypot. Evidentemente, se recomienda indicar una contraseña que sea fácilmente predecible para que el atacante pueda entrar y contar con más tiempo para saber de quien se trata.

txtcmds_path: En el directorio indicado en esta propiedad se deben definir los programas y utilidades que podrá ejecutar el atacante una vez se encuentre dentro del honeypot.

ssh_version_string: Será el banner que devolverá el servicio cuando se realicen peticiones sobre el puerto definido en la propiedad “ssh_port”

interact_enabled: Kippo permite controlar las sesiones que el atacante tenga iniciadas contra el honeypot en un servicio independiente de monitoreo. Por defecto dicha propiedad se encuentra desactivada, pero es muy útil para ver en tiempo real lo que está haciendo el atacante en el honeypot.

interact_port: Puerto en el que se iniciará el servicio de monitoreo. Solamente tiene sentido indicar un valor en esta propiedad si “interact_enabled” tiene el valor “true”.
Existen otras propiedades en Kippo que también pueden ser interesantes para el lector, por ese motivo se recomienda leer la documentación para hacerse una idea de cuáles son dichas propiedades.

Una buena practica para captar la mayor cantidad de atacantes, consiste en el definir el honeypot un puerto que no requiera privilegios de root para ser utilizado, como por ejemplo el “2222” y redireccionar todas peticiones entrantes por el puerto “22” al puerto donde está corriendo el honeypot. Esto puede hacerse muy fácilmente utilizando una regla de iptables como la siguiente.

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

Ahora bien, si se cuenta con un servicio SSH productivo, se recomienda levantarlo en un puerto distinto al “22”.

El siguiente fichero de configuración puede ser utilizado para arrancar Kippo con algunos valores de configuración personalizados.

[honeypot] ssh_port = 2222 hostname = PROServer log_path = log download_path = dl contents_path = honeyfs filesystem_file = fs.pickle data_path = data txtcmds_path = txtcmds rsa_public_key = data/ssh_host_rsa_key.pub rsa_private_key = data/ssh_host_rsa_key dsa_public_key = data/ssh_host_dsa_key.pub dsa_private_key = data/ssh_host_dsa_key exec_enabled = true fake_addr = 172.28.78.10 ssh_version_string = SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2 interact_enabled = true interact_port = 5000

 

El fichero anterior debe ubicarse en el directorio de Kippo con el nombre “kippo.cfg”. Ahora es el momento de lanzar el script “start.sh” para iniciar el honeypot.

>./start.sh twistd (the Twisted daemon) 14.0.0 Copyright (c) 2001-2014 Twisted Matrix Laboratories. See LICENSE for details. Starting kippo in the background…

EL servicio quedará abierto en el puerto “2222” y además, es posible ver los logs que ha generado Kippo en el proceso de arranque.

>cat log/kippo.log 2015-01-25 23:57:37+0100 [-] Log opened. 2015-01-25 23:57:37+0100 [-] twistd 14.0.0 (/usr/bin/python 2.7.6) starting up. 2015-01-25 23:57:37+0100 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2015-01-25 23:57:37+0100 [-] HoneyPotSSHFactory starting on 2222 2015-01-25 23:57:37+0100 [-] Starting factory <kippo.core.ssh.HoneyPotSSHFactory instance at 0x7fa27d2b67e8> 2015-01-25 23:57:37+0100 [-] Factory starting on 5000 2015-01-25 23:57:37+0100 [-] Starting factory <twisted.internet.protocol.Factory instance at 0x7fa27c03cd40> >nc localhost 2222 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2 >

 

Como se puede ver, el banner devuelto por el servicio es el mismo que se ha definido en la propiedad “ssh_version_string”. Por otro lado, también se ha abierto el puerto “5000” para monitorizar el servicio. En dicho puerto se podrá acceder a una consola de administración básica que permitirá listar las sesiones activas, visualizar en tiempo real lo que el atacante está digitando en la consola del honeypot e incluso, interactuar con dicha sesión y escribir en la misma consola que el atacante está utilizando, algo que evidentemente despertaría sus sospechas.

>telnet -e q 127.0.0.1 5000 Telnet escape character is ‘q’. Trying 127.0.0.1… Connected to 127.0.0.1. Escape character is ‘q’. *** kippo session management console *** List of commands: list – list all active sessions view – attach to a session in read-only mode hijack – attach to a session in interactive mode disconnect – disconnect a session help – this help exit – disconnect the console

 

En el fichero “log/kippo.log” se podrán ver las trazas de cada uno de los intentos de conexión que se han realizado contra el honeypot.

2015-01-26 00:06:42+0100 [kippo.core.ssh.HoneyPotSSHFactory] New connection: 127.0.0.1:43249 (127.0.0.1:2222) [session: 2] 2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] Remote SSH version: SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa 2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] outgoing: aes128-ctr hmac-md5 none 2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] incoming: aes128-ctr hmac-md5 none 2015-01-26 00:06:44+0100 [HoneyPotTransport,2,127.0.0.1] NEW KEYS 2015-01-26 00:06:44+0100 [HoneyPotTransport,2,127.0.0.1] starting service ssh-userauth 2015-01-26 00:06:44+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth none 2015-01-26 00:06:44+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth keyboard-interactive 2015-01-26 00:06:51+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/123456] failed 2015-01-26 00:07:01+0100 [-] adastra failed auth password 2015-01-26 00:07:01+0100 [-] unauthorized login: 2015-01-26 00:07:03+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth password 2015-01-26 00:07:03+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/asadas] failed 2015-01-26 00:07:04+0100 [-] adastra failed auth password 2015-01-26 00:07:04+0100 [-] unauthorized login: 2015-01-26 00:07:05+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth password 2015-01-26 00:07:05+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/wwqwq] failed

Si el atacante consigue acceso, podrá ver una consola en el supuesto servicio y podrá interactuar con ella, limitado únicamente por los comandos que se han definido en la propiedad “txtcmds_path” del fichero de configuración utilizado para arrancar Kippo.

>ssh -p2222 localhost -l root Password: root@PROServer:~# ls root@PROServer:~# pwd /root root@PROServer:~# whoami root root@PROServer:~# id uid=0(root) gid=0(root) groups=0(root) root@PROServer:~# uname -a Linux PROServer 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux

 

Desde la consola de administración, se puede ver la nueva sesión creada en el honeypot y se puede interactuar con ella.

>telnet -e q 127.0.0.1 5000 Telnet escape character is ‘q’. Trying 127.0.0.1… Connected to 127.0.0.1. Escape character is ‘q’. *** kippo session management console *** List of commands: list – list all active sessions view – attach to a session in read-only mode hijack – attach to a session in interactive mode disconnect – disconnect a session help – this help exit – disconnect the console list ID clientIP clientVersion 3 127.0.0.1 SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 view 3 ** Attaching to #3, hit ESC to return ls root@PROServer:~# pwd /root root@PROServer:~# whoami root root@PROServer:~# id uid=0(root) gid=0(root) groups=0(root) root@PROServer:~# ** Interactive session closed. hijack 3 ** Attaching to #3, hit ESC to return Te he pillado… bash: Te: command not found root@PROServer:~# whoami root disconnect 3 ** Disconnecting session #3 exit Connection closed by foreign host.

 

El comando “list” ha permitido visualizar las sesiones iniciadas en el honeypot y con los comandos “view” y “hijack” se puede interactuar con una de dichas sesiones, el primero solamente permite ver lo que el atacante escribe en la consola del honeypot, mientras que el segundo permite interactuar directamente con dicha sesión y enviar comandos/mensajes al atacante. Finalmente el comando “disconnect” interrumpe una sesión activa, cortando la conexión entre el atacante y el honeypot.

Autor adastra