Archivo

Posts Tagged ‘honeypot ssh’

Honeypots: Agrupación y gestión de honeypots con HoneyDrive – Parte 4

marzo 1, 2016 1 comentario

Hace algunos meses comencé a hablar sobre algunos de los honeypots más interesantes que se encuentran actualmente a nuestra disposición, entre los cuales no pueden faltar Kippo y Dionaea, sin embargo hay muchos más que simulan el comportamiento de muchos de los servicios más habituales. Una buena forma de explorar algunos de los más conocidos es por medio de HoneyDrive, una distribución basada en Linux, concretamente con Xubuntu Desktop 12.04 LTS. Cuenta con más de 10 honeypots preconfigurados y listos para ser utilizados en la plataforma, entre los cuales destacan Dionaea, Kippo, Amun, Honeyd, Honeyd2MySQL, Glastopf, Conpot, entre muchos otros que se irán explicando detalladamente en esta y próximas entradas. Evidentemente, es muy ventajoso tener todo correctamente preparado y configurado para que únicamente sea cuestión de arrancar los servicios necesarios y a correr, pero siempre es aconsejado contar con un buen nivel de conocimientos sobre las tecnologías utilizadas ya que en ocasiones resulta conveniente instalar las herramientas “a mano” para entender cuáles son las posibles configuraciones que se pueden aplicar. El proyecto se encuentra ubicado en la siguiente ruta https://bruteforce.gr/honeydrive y se puede descargar la última versión disponible desde el repositorio SVN, el cual se encuentra ubicado en la siguiente ruta: http://sourceforge.net/projects/honeydrive/

Allí se encuentra disponible el servicio virtualizado (.OVA) el cual puede ser desplegado directamente en VirtualBox. Una vez descargada, instalada la imagen OVA e iniciado el sistema, en el escritorio se encuentra un fichero llamado “README” el cual incluye todos los detalles necesarios para poder utilizar todos los honeypots y herramientas que se encuentran instaladas en el sistema. Por ejemplo, es posible utilizar el honeypot Kippo tal como se ha visto en el primer artículo que se encuentra aquí: https://thehackerway.com/2015/03/24/honeypots-parte-1-kippo/

hd1

Imagen 1: Iniciando Kippo en HoneyDrive.

En este caso, Kippo se vinculará al puerto “22” y aceptará peticiones por parte de clientes/atacantes que intenten acceder al sistema. Tal como se ha visto en el artículo sobre Kippo, su configuración es muy simple y únicamente es necesario establecer las opciones adecuadas en el fichero “kippo.cfg”. En el caso de HoneyDrive, dicho fichero de configuración se encuentra ubicado en “/honeydrive/kippo” y su contenido por defecto es el siguiente:

[honeypot]

ssh_port = 22

hostname = svr03

log_path = log

download_path = dl

contents_path = honeyfs

filesystem_file = fs.pickle

data_path = data

txtcmds_path = txtcmds

public_key = public.key

private_key = private.key

ssh_version_string = SSH-2.0-OpenSSH_5.1p1 Debian-5

interact_enabled = false

interact_port = 5123

[database_mysql]

host = localhost

database = kippo

username = root

password = honeydrive

port = 3306

Como se puede apreciar, algunas opciones de configuración vienen con los valores por defecto que trae Kippo, y otras, como el caso de la conexión a una base de datos para el registro de los eventos producidos, si que han sido personalizadas específicamente para funcionar sobre el sistema. Esta configuración puede modificarse sin ningún problema para adaptarse a las necesidades particulares de cualquiera, solamente es necesario conocer cuál es el comportamiento de de cada una de las opciones disponibles, tal como se ha visto en el primer artículo sobre honeypots y Kippo.

En HoneyDrive viene instalado PhpMyAdmin, lo que permitirá conectarse a una de las base de datos MySQL que se encuentran en el sistema y ver los eventos que se han podido registrar. En este caso concreto, interesa la base de datos “kippo”, que es en donde se almacenarán los intentos de acceso al puerto donde se encuentra en ejecución Kippo. El nombre de usuario para acceder a PhpMyAdmin es “root” y la contraseña es “honeydrive”. Una vez el usuario se autentica, tal como se puede ver en el panel de la izquierda, están todas las bases de datos que se encuentran disponibles.

hd2

Imagen 2: PhpMyAdmin en HoneyDrive.

Cuando un usuario intenta acceder al servicio de Kippo, automáticamente su intento de autenticación queda registrado en la base de datos, concretamente en la tabla “auth”, la cual almacena todos los intentos con su correspondiente nombre de usuario y contraseña, así como si el intento ha tenido éxito o no. Por otro lado, dicha tabla se encuentra relacionada con la tabla “sessions”, en donde se registran los datos básicos del usuario que ha intentado autenticarse, incluyendo su dirección IP.

hd3

Imagen 3: PhpMyAdmin en HoneyDrive.

En otras dos entradas se ha hablado de Dionaea, un honeypot enfocado a la detección y análisis de malware y en el caso de HoneyDrive también se encuentra preconfigurado y listo para ser utilizado. Los detalles se encuentran incluidos en el fichero README y son los que se listan a continuación.

[Dionaea]

Location: /opt/dionaea/

Start script: /honeydrive/dionaea-vagrant/runDionaea.sh

Binary: /opt/dionaea/bin/dionaea

Configuration: /opt/dionaea/etc/dionaea/dionaea.conf

Logs: /opt/dionaea/var/log/

SQLite database: /opt/dionaea/var/dionaea/logsql.sqlite

Malware samples: /opt/dionaea/var/dionaea/binaries/

Log rotation: enabled

phpLiteAdmin: /var/www/phpliteadmin/

+ password: honeydrive

+ allow only localhost: enabled

+ URL: http://localhost/phpliteadmin/phpliteadmin.php

Con la configuración por defecto se puede arrancar Dionaea sin ninguna dificultad, simplemente ejecutando el script “/honeydrive/dionaea-vagrant/runDionaea.sh”. Este script se puede modificar con el fin de personalizar el comando de ejecución y remover o incluir otros parámetros que admite el programa “dionaea”.

hd4

Imagen 4: Dionaea en HoneyDrive.

A continuación se puede utilizar Metasploit Framework para comprobar su funcionamiento. Esto mismo se ha visto en una entrada anterior de esta misma serie de artículos: https://thehackerway.com/2015/04/14/honeypots-parte-3-configuracion-y-analisis-de-malware-con-dionaea/

msf > use exploit/windows/smb/ms06_040_netapi

msf exploit(ms06_040_netapi) > set PAYLOAD windows/shell/bind_tcp

PAYLOAD => windows/shell/bind_tcp

msf exploit(ms06_040_netapi) > set RHOST 192.168.1.42

RHOST => 192.168.1.42

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

En el fichero de logs de Dionaea se puede apreciar lo siguiente:

hd5

Imagen 5: Logs de Dionaea.

Tal como se ha visto en una entrada anterior, Dionaea también es capaz de detectar y almacenar muestras de malware que envíe un atacante, algo especialmente útil si se desea analizarlas después con Cuckoo Framework o cualquier otra herramienta.

Aquí se ha visto un ejemplo muy simple del uso de Kippo y Dionaea en Honey Drive, sin embargo existen muchos más honeypots y herramientas que se encuentran incluidos en esta interesante distribución y que se irán viendo con mucho más detalle en próximos artículos.

Un saludo y Happy Hack!
Adastra.

HoneyPots Parte 3 – Configuración y análisis de malware con Dionaea

abril 14, 2015 1 comentario

En el articulo anterior he hablado sobre el funcionamiento e instalación de Dionaea, un honeypot que es capaz de detectar payloads maliciosos y recolectar muestras de malware para su posterior análisis. Para la detección de shellcodes utiliza otra librería de la que ya se ha hablado anteriormente llamada LibEmu, la cual utiliza varias técnicas avanzadas para encontrar patrones maliciosos basadas en heurísticas del tipo GetPC. En este articulo, se continuará con la exploración de las funcionalidades incluidas en Dionaea y las opciones de configuración que se pueden utilizar para modificar el comportamiento del programa según las necesidades particulares del “blue team” o equipo defensor.

En primer lugar, el fichero de configuración del programa se encuentra ubicado en la siguiente ruta (suponiendo que el software se ha instalado en el directorio /opt/dionaea): “/opt/etc/dionaea/dionaea.conf”.

Cuando se trabaja con ficheros de configuración, algo que es de agradecer es que sean fáciles de entender y se encuentren debidamente separados por secciones. Esto es algo que tiene Dionaea y cuando se abre el fichero de configuración por defecto, rápidamente se pueden apreciar las siguientes secciones de configuración: “logging”, “processors”, “downloads”, “submit”, “bistreams”, “listen” y “modules”. A continuación, se explica brevemente para que sirve cada uno de estos bloques de configuración.

“logging”: Es una sección que puede ayudar a ver las trazas que realmente son importantes y que ayudan a detectar un ataque en curso. Configurar adecuadamente esta sección puede ser bastante conveniente, ya que Dionaea es un programa que genera muchísimas trazas de log que en la mayoría de los casos resultan abrumadoras y poco informativas. En esta sección es posible establecer diferentes niveles de trazas, tales como info, debug, warning, error y all. Por defecto, las trazas generadas por Dionaea se almacenan en el directorio “/opt/dionaea/var/log”.

“processors”: Permite definir los servicios que debe arrancar el programa, tales como SSH, MSSqld, FTP, etc. Además, permite definir una serie de detalles de configuración sobre el proceso de emulación de cada uno de dichos servicios, pudiendo establecer detalles como el número de sockets, número máximo de conexiones abiertas y otros detalles que permiten controlar el funcionamiento de LibEmu.

“downloads”: En esta sección se define el directorio en donde se deben guardar las muestras de malware recolectadas por el honeypot.

“bistreams”: En esta sección se define el directorio en donde se guardarán los registros de la interacción entre el atacante y el honeypot, lo que permitirá posteriormente replicar los ataques y depurar.

“submit”: Además guardar las muestras de malware recolectadas por el honeypot en la máquina local, también es posible transferir dichas muestras por http o ftp a un servidor externo. En esta sección se pueden definir los detalles de conexión a dichos servidores externos en el caso de que se quiera enviar el malware a un motor de análisis ubicado en una máquina remota, como por ejemplo, una que tenga Cuckoo en ejecución.

“listen”: Permite definir las interfaces de red que serán utilizadas por el honeypot para arrancar cada uno de los servicios definidos en la sección de “processors”. Existen 3 modos, el automático vincula todas las interfaces de red encontradas en el sistema, el manual permite definir cuales serán las interfaces de red utilizadas y finalmente, el tercer mecanismo permite definir una expresión regular para recuperar todas las interfaces de red que cumplan con el patrón definido.

“modules”: Finalmente, en esta sección se pueden definir detalles de configuración de los módulos que utiliza Dionaea. Algunos de los módulos más interesantes que soporta este honeypot son LibEmu, p0f, curl, nfq, python, fail2ban, entre otros.

Después de explicar las principales secciones de configuración del programa, ahora se procede a utilizar Dionaea y ver cómo funciona cuando un atacante intenta hacerse con el control de un servicio ejecutado en el honeypot.

Arrancando Dionaea y detectando posibles ataques

Una buena practica a la hora de arrancar Dionaea es utilizar un usuario del sistema con privilegios limitados, para ello se utilizan los interruptores “-u” y “-g”.

>./dionaea -L ‘*’ -u adastra -g users

 

Después de levantar Dionaea (en una máquina virtual preferiblemente), lo primero que se puede hacer es ejecutar un escaneo contra dicha máquina para ver qué puertos se encuentran abiertos.

>nmap -sT -n 192.168.1.98

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-15 23:46 CETNmap scan report for 192.168.1.98
Host is up (0.00012s latency).Not shown: 989 closed ports
PORT STATE SERVICE
21/tcp open ftp

22/tcp open ssh

42/tcp open nameserver

80/tcp open http

135/tcp open msrpc

443/tcp open https

445/tcp open microsoft-ds

1433/tcp open ms-sql-s

3306/tcp open mysql

5060/tcp open sip

5061/tcp open sip-tls

 

Como se puede apreciar, aparecen servicios como MSSql, SIP, MySQL y SMB, todos ellos servicios que ha levantado automáticamente Dionaea.

Ahora bien, se puede utilizar metasploit framework para probar el comportamiento de Dionaea cuando un atacante intenta enviar peticiones maliciosas contra alguno de los servicios que se encuentran activos.

SMB es un buen protocolo para probar, ya que existen varios exploits disponibles para atacar este tipo de servicios.

>msfconsolemsf>use exploit/windows/smb/ms06_040_netapi
msf exploit(ms06_040_netapi) >set PAYLOAD windows/shell/bind_tcp
PAYLOAD => windows/shell/bind_tcp
msf exploit(ms06_040_netapi) > set RHOST 192.168.1.98

RHOST => 192.168.1.98

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

 

Posteriormente, en el fichero de logs de Dionaea se podrán ver varios registros que indican el intento de ataque. Dicho fichero por defecto se encuentra ubicado en “/opt/dionaea/var/log/dionaea.log”.

[15032015 23:52:00] connection connection.c:1745-debug: connection_stats_accounting_limit_exceeded stats 0x2b8d720[15032015 23:52:01] pcap pcap.c:180-debug: 192.168.1.98:4444 -> 192.168.1.98:55386[15032015 23:52:01] pcap pcap.c:190-debug: reject local:’192.168.1.98:4444′ remote:’192.168.1.98:55386′[15032015 23:52:01] incident incident.c:365-debug: reporting 0x2c66a20[15032015 23:52:01] incident incident.c:354-debug: incident 0x2c66a20 dionaea.connection.tcp.reject[15032015 23:52:01] incident incident.c:167-debug: con: (ptr) 0x2c67c20[15032015 23:52:01] python module.c:778-debug: traceable_ihandler_cb incident 0x2c66a20 ctx 0x2a134d0[15032015 23:52:01] logsql dionaea/logsql.py:637-info: reject connection from 192.168.1.98:55386 to 192.168.1.98:4444 (id=1005)

[15032015 23:52:01] connection connection.c:667-debug: connection_free_cb con 0x2c67c20

[15032015 23:52:01] connection connection.c:676-debug: AF 0 0 con->local.domain

 

Además de los logs, también se almacenan los flujos de entrada y salida en el directorio “/opt/dionaea/var/dionaea/bistreams”. Se puede también probar otros exploits que intenten comprometer el servicio SMB como es el caso del conocidio exploit “LSASS”.

msf exploit(ms06_040_netapi) > use exploit/windows/smb/ms04_011_lsass
msf exploit(ms04_011_lsass) > set RHOST 192.168.1.98
RHOST => 192.168.1.98
msf exploit(ms04_011_lsass) > exploit

[*] Started reverse handler on 192.168.1.98:4444

[*] Binding to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Bound to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Getting OS information…

[*] Trying to exploit Windows 5.1

 

Dionaea es capaz de detectar el ataque y registrarlo en el fichero de logs.

[16032015 00:16:41] connection connection.c:4349-debug: connection_unref con 0x2b8d320[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c001530 dionaea.shellcode.detected[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c001530 ctx 0x2a134d0[16032015 00:16:41] thread threads.c:52-debug: Thread fn 0x41d38d con 0x2b8d320 data 0x2c5a760 took 0.000018 ms[16032015 00:16:41] incident incident.c:212-debug: could not find key ‘con'[16032015 00:16:41] incident incident.c:365-debug: reporting 0x7fd24c0711d0[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c0711d0 dionaea.module.emu.profile[16032015 00:16:41] incident incident.c:167-debug: profile: (string) [

{

“call”: “LoadLibraryA”,

“args” : [

“ws2_32”

],

“return” : “0x71a10000”

}

]

[16032015 00:16:41] incident incident.c:167-debug: con: (ptr) 0x2b8d320

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a0cfc8

[16032015 00:16:41] emu dionaea/emu.py:45-debug: profiling

[16032015 00:16:41] emu dionaea/emu.py:53-info: profiledump [{‘return’: ‘0x71a10000’, ‘args’: [‘ws2_32’], ‘call’: ‘LoadLibraryA’}]

[16032015 00:16:41] connection connection.c:1368-debug: connection_sustain_timeout_set 0x2b8d320 3.000000

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a134d0

[16032015 00:16:41] logsql dionaea/logsql.py:699-info: emu profile for attackid 1009

 

Puede ser muy complicado buscar y encontrar información útil sobre los incidentes reportados por el honeypot en los logs, por este motivo existe una base de datos SQLite que almacena todos los resultados relevantes. Para consultarla basta con ejecutar la utilidad “readlogsqltree”.

>python /opt/dionaea/bin/readlogsqltree /opt/dionaea/var/dionaea/logsql.sqlite

 

Los resultados que enseña la ejecución anterior son mucho más condensados y fáciles de leer, ya que identifica únicamente aquellos registros que Dionaea ha detectado como incidentes o intentos de ataque.

dcerpc request: uuid ‘3919286a-b10c-11d0-9ba8-00c04fd92ef5’ (DSSETUP) opnum 9 (DsRolerUpgradeDownlevelServer (MS04-11))profile: [{‘return’: ‘0x71a10000’, ‘args’: [‘ws2_32’], ‘call’: ‘LoadLibraryA’}]2015-03-16 00:28:17connection 1010 SipSession udp connect 192.168.1.98:5060 -> /192.168.1.98:47685 (1010 None)Method:OPTIONSCall-ID:78617845@192.168.1.98User-Agent:LJtDLdXwaddr: <> ‘sip:nobody@192.168.1.98:None’

to: <> ‘sip:nobody@192.168.1.98:None’

contact: <> ‘sip:nobody@192.168.1.98:None’

from: <> ‘sip:LJtDLdXw@192.168.1.98:5060′

via:’UDP/192.168.1.98:5060’

 

Por otro lado, cuando un exploit transfiere algún tipo de fichero a la máquina atacada, el honeypot captura y almacena dicho fichero en el directorio que se ha definido en la sección de configuración “downloads”. Dichos ficheros pueden ser utilizados posteriormente para ser analizados con Cuckoo o con cualquier otra herramienta de análisis de malware.

msfcli exploit/windows/smb/ms10_061_spoolss PNAME=XPSPrinter RHOST=192.168.1.98 EXITFUNC=process LHOST=192.168.1.98 LPORT=4444 E
[*] Initializing modules…PNAME => XPSPrinter
RHOST => 192.168.1.98
EXITFUNC => process
LHOST => 192.168.1.98

LPORT => 4444

[*] Started reverse handler on 192.168.1.98:4444

[*] Trying target Windows Universal…

[*] Binding to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Bound to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Attempting to exploit MS10-061 via \\192.168.1.98\XPSPrinter …

[*] Printer handle: 0000000000000000000000000000000000000000

[*] Job started: 0x3

[*] Wrote 73802 bytes to %SystemRoot%\system32\jv3zNgf80OaKcs.exe

[*] Job started: 0x3

[*] Wrote 2237 bytes to %SystemRoot%\system32\wbem\mof\tOpOFGImh6sT6j.mof

[-] Exploit failed: NoMethodError undefined method `unpack’ for nil:NilClass

 

En este caso concreto, al utilizar el exploit SMB Spoolss, se transfiere un fichero malicioso al servicio atacado y Dionaea lo almacena en el directorio “/opt/dionaea/var/dionaea/binaries”

 

>ls -l var/dionaea/binaries/
total 152
-rw——- 2 adastra adastra 73802 mar 16 00:45 c9a0a0ccbd330b43d5196cd69b80159d-rw——- 2 adastra adastra 73802 mar 16 00:45 spoolss-d1fgrg.tmp
>file var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d

var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d: PE32 executable (GUI) Intel 80386, for MS Windows


>file var/dionaea/binaries/spoolss-d1fgrg.tmp

var/dionaea/binaries/spoolss-d1fgrg.tmp: PE32 executable (GUI) Intel 80386, for MS Windows

El programa descargado es un ejecutable PE para sistemas Windows, capturado y almacenado por Dionaea.

Saludos y Happy Hack!
Adastra.

HoneyPots Parte 1 – Kippo

marzo 24, 2015 1 comentario

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.

Más sobre Honeypots en un próximo articulo.

Saludos y Happy Hack!

Adastra.

A %d blogueros les gusta esto: