El experimento del HoneyPot en Internet de @elevenpaths: SIP & SSH under attack

Nuestros compañeros de la unidad de ciberseguridad de ElevenPaths tienen siempre un oído en la red. Nuestro servicio de CyberThreats se basa precisamente en eso, en saber qué es lo que está pasando en Internet para poder ayudar a nuestros clientes a tener algo de anticipación ante las posibles amenazas y ataques.

Figura 1: El experimento del HoneyPot en Internet: SIP & SSH under attack

Entre las cosas que se hacen en la unidad, existen proyectos de HoneyPotting, es decir, de poner servidores falsos con herramientas de "deception" o engaño, que se dejan atacar para ver qué es lo que se está explotando o probando en Internet.  Los últimos resultados, solo como forma de hacer una actualización y puesta al día los han publicado en un informe que puedes obtener y leer en SlideShare.

Figura 2: Honeypotting: Un oído en Internet de ElevenPaths

Entre lo más destaco, es digno de resaltar los siguientes puntos que han publicado en el blog de ElevenPaths como resumen del informe total.

• SIP es un protocolo muy abusado en la red. Se buscan servidores vulnerables para atacar o realizar ataques a través de ellos. La herramienta más utilizada para conseguirlo es SIP Vicious, detectable por su user-agent "friendly-scanner" y con el método OPTIONS. Las direcciones IP vienen principalmente de Francia. 

• SSH, con más de 36.000 peticiones (2.560 direcciones únicas), es el protocolo del que más tráfico se ha recibido con diferencia. Estados Unidos lidera la lista de países de origen del tráfico SSH recibido. Le sigue China y a menor distancia Holanda, Vietnam, India, Francia y Rusia. 

• En los ataques contra servidores SSH, no se está buscando un ataque por fuerza bruta que agote por completo un diccionario de contraseñas habituales. Lo que los atacantes de este servicio buscan es el servicio mal configurado o por defecto, probando un puñado de combinaciones de contraseñas y usuarios conocidos.

• Los usuarios intentados más repetidos son ‘root’ y ‘admin’ son, con diferencia, seguidos a distancia por ‘user’ y ‘pi’, ‘test’, ‘ubnt’, ‘guest’ o ‘ftpuser’. 

• El tráfico restante lo componen protocolos comunes: DNS, HTTP, SNMP y algunos curiosos para Internet como DHCP.

Llaman la atención los ataques a sistemas de VoIP, algo que en muchas empresas quizá no se le presta todavía la atención necesaria. De hecho, muchos de los ataques SIP están enunciados en el informe son ampliamente conocidos y están descritos al detalle en el libro que escribió José Luis Verdeguer a.k.a. "pepelux" sobre Hacking y Seguridad VoIP.

Figura 3: Ataque SIPvicious y huella en hnneypot

Otro de los puntos destacados ha sido la cantidad de ataques SSH de todo tipo, desde ataques de Default Passwords, ataques de fuerza bruta, y, como no, actividad que en algún caso pudiera ser incluso relativa a la pruebas con el bug de Libssh del que os hablamos en el blog de ElevenPaths. La recomendación es que si tienes un servicio SSH te leas este artículo de My SSH en Paranoid Mode donde te damos algunos consejos para poner medidas de protección extra contra este tipo de vulnerabilidades en el futuro. En el libro de Hardening GNU/Linux también tienes recomendaciones para fortificar el sistema completo en caso de ser un servidor basado en kernel Linux.

Figura 4: User_Agents bots SSH

Los User-Agents de los bots más utilizados los tenéis en una tabla, y en el informe podéis ver qué tecnologías de bots se utilizan más a menudo, destacando el uso de Python como lenguaje más utilizado.

Figura 5: Ataques de países por direcciones IP

Por último, desatar la "ciberparanoia", hemos analizado la procedencia de los ataques, y aunque la mayor parte de los ataques proceden de USA, si se clasifican por direcciones únicas, el gráfico pone a China en cabeza. Pero eso no quiere decir nada, o puede decir algo, o mucho, o solo es un intento de suplantar y simular algo...o quién sabe.

Figura 6: Security Innovation Day 2018

Si quieres saber más cosas, recuerda que el próximo 7 de Noviembre en Madrid tienes una cita con todo el equipo de ElevenPaths en nuestro evento por excelencia, el Security Innovation Day. Reserva tu plaza cuanto antes.

Saludos Malignos!

T-Pot: Una colmena de Honeypots para atraparlos a todos

Los Honeypots son una gran herramienta para un IDS (Intrusion Detection System), ya que nos ayuda a detectar y estudiar con antelación posibles ataques a nuestra infraestructura real. Todos los que hemos sido administradores de sistemas o estamos en el mundo de la seguridad hemos tenido que trabajar alguna vez con ellos de alguna u otra forma. Existen multitud de honeypots adaptados a funcionar simulando todo tipo de entornos.

Figura 1: T-Pot: Una colmena de Honeypots para atraparlos a todos

Por ejemplo, si necesitas un honeypot para monitoriza tu red de ordenadores, puedes elegir por ejemplo Cowrie (un fork de Kippo y uno de los más utilizados) y si necesitas monitorizar los ataques a una infraestructura industrial (ICS) puedes elegir, por ejemplo, Compot (ICS/SCADA).

Cada instalación de un Honeypot requiere configurarlo y adaptarlo para que parezca lo máximo posible un entorno real (una de las claves del éxito del Honeypot). Además, una vez hemos obtenido y recopilado todos los datos de los posibles ataques, será necesario procesarlos y analizarlos para sacar conclusiones sobre los mismos. Existen muchas herramientas que ayudan a este proceso, como por ejemplo Kippo-Graph (que funciona perfectamente con Cowrie).

T-Pot: Una colmena de Honeypots para atraparlos a todos

Pero existe una solución magnífica que nos permite tener varios Honeypots (incluidos los diseñados para simular ICS) dentro de una sola máquina virtual (o física, según sea necesario) y también nos permite visualizar la información de forma espectacular utilizando ELK.

Figura 2: Dashboard de T-Pot

T-Pot es una plataforma de Honeypots que tiene como base una distribución Linux Ubuntu Server 14.04.4 LTS. Esta plataforma incluye una gran variedad de honeypots ya preparados, configurados y listos para entrar en funcionamiento. Algunos de estos honeypots y herramientas que incluye son:

• Conpot: es un honeypot para ICS el cual permite simular un entorno industrial completo, capaz de hacer ver al atacante de que está accediendo a un entorno industrial. 

• Cowrie: es un honeypot que simula un servidor con SSH y Telnet diseñado para monitorizar los ataques de acceso, así como la iteración con la Shell. 

• Dionaea: otro honeypot de caracter general diseñado para simular vulnerabilidades de red y servicios como SMB, http, FTP, MSSQL e incluso VoIP. 

• Elasticpot: es un honeypot basado en una versión simplificada de ElasticSearch. 

• EMobility: otro honeypot de infraestructuras ICS que simula un centro de carga eléctrica de vehículos (incluso simula usuarios que están cargando los vehículos).

Tiene una web central de gestión desde la cual el posible atacante tendría acceso a todos los nodos de carga de la falsa infraestructura.

• Glastopf: es un honeypot orietando a aplicaciones web como, por ejemplo, webmail, wikis, etc, cualquier aplicación en la que el cliente la ejecute desde su navegador web. 

• Honeytrap: este honeypot se centra especialmente en observar ataques contra servicios TCP y UDP. 

• Suricata: un monitor de seguridad de red para detectar intrusiones en tiempo real inspeccionando el tráfico de red. 

• ELK: son tres herramientas en una, Elasticsearch (servidor de búsquedas), Logstash (administración de logs) y Kibana (visualización y gestión de los datos almacenados).

La gran ventaja de esta distribución T-Pot es que los integra todo es una misma instalación (en el mismo servidor) y todos virtualizados con Docker. Esto permite tener en ejecución varios demonios actuando sobre la misma tarjeta de red sin problemas. Además, al tener cada Honeypot su entorno dockerizado, es muy sencillo su mantenimiento (actualizaciones, por ejemplo), gestión y personalización.

Figura 3: Arquitectura de T-Pot

Los puertos que serán utilizados por los Honeypot instalados en T-Pot tendremos que redireccionarlos hacia el Honeypot desde nuestro firewall o router si fuera necesario:

Figura 4: Lista de puertos a utilizar por los diferentes servicios

La instalación de T-Pot es bastante sencilla, simplemente se puede descargar la imagen ISO y montarla en un sistema virtual o uno físico. También crear la imagen ISO desde este enlace.

Figura 5: Arranque de la ISO de T-Pot

Las recomendaciones de hardware varían en función de si quieres activar todos los Honeypots y herramientas. En esta captura puedes ver las diferentes opciones que aparecerán durante el proceso de instalación. En nuestro caso hemos optado por la opción “E” (todo) en una máquina virtual:

Figura 6: Opciones para elegir tipo de instalación

Durante el proceso de instalación (el equipo se reiniciará dos veces) no se realizan apenas preguntas más allá de la configuración del teclado y el usuario y contraseña para el acceso vía web al panel del control (el usuario para acceder al servidor Linux con T-Pot es “tsec” y la contraseña “tsec”):

Figura 7: Datos de inicio de sesión en T-Pot con el usuario "tsec"

Para acceder al Honeypot de forma segura tendremos que hacerlo desde SSH. Desde Windows podemos utilizar OpenSSH y Putty como puedes ver en este video. Desde Linux o macOS podemos abrir un terminal y ejecutar:

ssh -p 64295 -l tsec -N -L8080:127.0.0.1:64296 192.168.56.100

Ya solo tenemos que abrir el navegador utilizando http://127.0.0.1:64296

Figura 8: Dashboard de T-Pot en la primera ejecución con todos los marcadores a cero

Para comprobar el estado de los contenedores Docker podemos utilizar el plugin ya instalado “UI-For-Docker” el cual nos permite de forma fácil, controlar todos los parámetros de los contenedores como reiniciarlos, pararlos, configuración de red, puertos, etcétera:

Figura 9: Control de todos los contenedores Docker desde T-Pot, "UI-For-Docker"

Para ver el funcionamiento de T-Pot y también como organiza y muestra los resultados, vamos a realizar simular algunos intentos de acceso desde la red interna donde hemos ubicado el Honeypot (no está conectado a Internet para esta demostración) utilizando Kali Linux 2. Antes de continuar es importante decir que toda la información contenida en los Honeypot (contenedores Docker) se pierde cada vez que la aplicación falla o se produce un reinicio del servidor. Es posible activar la persistencia de esta información accediendo a la carpeta /etc/systemd y ajustar los parámetros individualmente de cada servicio para que mantenga la información.

Figura 10: Ficheros con todos los servicios de cada Honeypot para su configuración individual

Vamos a realizar un ataque por fuerza bruta utilizando Metasploit, en concreto utilizaremos el módulo ssh_login. De esta forma veremos cómo es la estructura del Honeypot una vez se ha conseguido acceso (Cowrie). Posteriormente accederemos al dashboard de T-Pot para ver cómo ha registrado el ataque:

Figura 11: Metasploit utilizando el módulo ssh_login

Figura 12: Acceso por SSH al falso servidor para ver su estructura

En el siguiente vídeo muestra la información que ha recopilado T-Pot en su Dashboard después de nuestro acceso. Hemos omitido algunos paneles que no tienen información como por ejemplo la ubicación geográfica (en este enlace puedes ver cómo sería un ejemplo real de T-Pot):

Figura 13: Dashboard de T-Pot después del ataque y los datos registrados

Para probar los Honeypot orientados a ICS, vamos a realizar un acceso al Honeypot Conpot. Este Honeypot simula un contador de consumo eléctrico modelo Kamstrup 382 con conexión Telnet y sin contraseña de acceso.

Figura 14: Acceso al honeypot Conpot (simulando un Kamstrup 382) desde Telnet

Otro ejemplo sería la web del Honeypot eMobility, que simula centros de carga para vehículos eléctricos (sólo tendríamos que poner la IP del Honeypot con el puerto 8080):

Figura 15: Acceso al Honeypot eMobility

Los Honeypot en entornos ICS y IoT (hay que empezar a crear honeypots que simulen el hardware de los ordenadores de placa simple como Raspberry Pi por ejemplo) son una herramienta imprescindible para las instalaciones industriales. En este enlace encontraréis una estupenda selección de recursos para Honeypot que podríamos añadir añadir a T-Pot. Seguro que volveremos a hablar pronto de los Honeypot como parte de la Seguridad de los sistemas de control industriales y las infraestructuras críticas.

Autor: Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths.

CounterCraft: Una startup de contra-inteligencia española

Desde hace poco menos de un año, nuestro ex-compañero y amigo David Barroso (@lostinsecurity), se embarcó en una aventura empresarial para montar una startup de contra-inteligencia. A la start-up, que lanzó junto a dos compañeros más, la bautizó con el nombre de CounterCraft y comenzó el duro camino de emprender para desarrollar su tecnología en un espacio que aún necesita mucho desarrollo en el mercado.

Figura 1: CounterCraft: una startup de contra-inteligencia española

El objetivo de la compañía es automatizar un producto que permita a las empresas ser capaces de detectar a los adversarios que hay dentro de sus sistemas por medio de un conjunto de herramientas que van desde señuelos, automatismos para deception kits, sistemas honeypot o "poisoned apples" que permita saber cuando alguien está haciendo algo que no debería y poder localizarlo cuanto antes, al mismo tiempo que se aprende de su comportamiento de forma sistémica y gestionada.

Figura 2: Equipo fundador de CounterCraft

No hay mucho más que decir por ahora, ya que la compañía no ha querido ir públicamente con demostraciones tecnológicas abiertas a todo el público o explicaciones más detalladas, pero lo cierto es que con las conversaciones privadas y los due diligence técnicos que se han hecho, la empresa ha conseguido levanta ya 1 Millón de € de fondos de inversión de capital semilla, tal y como recoge TechCruch.

Figura 3: Equipo completo de CounterCraft a día de hoy.

A día de hoy se encuentra en la incubadora de Wayra Madrid, como ha explicado el artículo de El Mundo de esta semana, y ha conseguido el apoyo de Adara, un VC que se ha unido junto a Telefónica Open Future_ y Orza para invertir en esta start-up de contra-inteligencia española que está levantando tanta expectación. Enhorabuena a todo el equipo.

Saludos Malignos!

Configurar un HoneyPot en tu aplicación web con Latch

Latch no solo es una aplicación que sirve para abrir y cerrar un pestillo, sino que va mucho más allá. Puede usarse como un Segundo Factor de Autenticación si lo ponemos asociado al login de usuario como en el plugin de WordPress, Moodle, SSH o PrestaShop y si lo tuneas puede ser usado en un esquema de 4-Eyes Verification. Puede ser usado en soluciones como Segundo Factor de Autorización, para permitir o no permitir operaciones en un determinado sistema, como se puede ver en el caso de WordPress in Paranoid Mode - esta tarde Eleven Paths Talk Gratuito sobre este tema -  o como lo puedes probar en Nevele Bank con las operaciones bancarias o con tu cuenta de CajaMar si eres cliente. También puedes usarlo en un esquema de 2-Keys Activation tal y como se usaba en la hucha controlada por biometría y Latch o para proteger el acceso a ficheros seguros.

Figura 1: Configurar una HoneyPot en tu aplicación web con Latch

Se puede usar en sistemas operativos OS X, Windows, Linux o en el mundo IoT y tras ver los concursos de ideas, seguro que se te ocurren nuevas a ti. A mí se me ocurrió montar un entorno de Deception o una HoneyPot para saber lo que hacen los malos en la zona privada de mi plataforma si un día aparece un bug o son capaces de saltarse las protecciones de mi aplicación web. Y no, no hace falta nada adicional. Dejadme que os lo cuente.


Figura 2: Cómo usar Latch en la web de Cajamar
Si un atacante es capaz de obtener unas credenciales robadas por medio de un ataque de Spear Phishing y sabe que son válidas, puede intentar  acceder al sitio correspondiente. Si el sitio tiene un un 2FA o el atacante intuye que puede haber un Latch, esto no será suficiente, pero puede ser que aún así quizás no se rinda tan fácilmente e intente otros métodos para acceder al sistema sin tener que pasar por el login de la aplicación web.

Una base de datos HoneyPot con Latch

Como ya sabéis, con Latch el atacante solo tiene un intento de acceder con las credenciales correctas, ya que el sistema avisa al usuario de que intentaron acceder y/o accedieron con sus credenciales en el sitio protegido. Pero veamos ahora un ejemplo exagerado de lo que podremos conseguir con Latch usando la potencia del interruptor en que se convierte. Si no te has visto alguna de las charlas de Chema Alonso sobre esto, deberías hacerlo. Aquí una que recoge todos los escenarios descritos.


Figura 3: Protección empresarial contra insiders que roban identidades locales
Imaginemos que a pesar de tener el Latch cerrado, la aplicación lo deja entrar porque el atacante no ha usado las credenciales, sino que ha sido capaz de robar una cookie de sesión y hacer un Session Hijacking o ha logrado acceso por medio de una password de aplicación o incluso porque la web permite acceso basado en tokens OAuth como en los ataques de Sappo y RansomCloud. Proteger las cookies contra un ataque de hijacking, los accesos vía Application Password o mediante Tokens OAuth no es algo que se proteja con un 2FA o un Latch puesto en el proceso de login y podría darse un caso en el que el atacante encontrara la forma de llegar a la información y los datos de la parte interna de una aplicación web.

Ahora vamos a cambiar el chip y utilizar Latch de forma más holística dentro de la aplicación, para que sirva no únicamente para bloquear o dejar acceder en el proceso de login, si no que además cambie completamente los datos de la aplicación usando el pestillo para indicar al sistema qué opción debe tomar: La pastilla azul o La pastilla roja. Es decir, el camino de la información falsa o el camino de la información real. Bien, ahora creo que ya sabéis por dónde voy.

Figura 4: Configuración de aplicación Latch para montar el HoneyPot

Cuando Latch esté cerrado, la aplicación estará siempre conectada a la base de datos con la información falsa. Por otro lado, si el Latch está abierto y se inicia sesión, las conexiones a la base de de datos antes de ejecutar los comandos SQL se harán entonces con la base de datos verdadera, obteniendo así la información real. En resumen el pseudocodigo sería algo como:

- Comprobar estado de Latch de AplicaciónWeb
- Si está abierto conectar a base de datos con información real.
- Si está cerrado conectar a base de datos HoneyPot
- Ejecutar consulta SQL con acceso a datos
- Cerrar conexión.

Si un atacante logra robar una sesión y tenemos el Latch cerrado, caerá en la aplicación HoneyPot, y revisando los logs de actividad podremos a posteriori ver cuales son sus intenciones y conocer cómo consiguió el acceso. Tal vez fue un Session Hijacking, tal vez un ataque de CSRF porque no se cerró bien la sesión pero sí el Latch, tal vez un ataque de red... Pero en todos los casos contra la base de datos HoneyPot.

Una pequeña PoC

Veamos ahora una pequeña PoC, de una aplicación donde podremos ver los proyectos de los responsables de una empresa con sus presupuestos (cualquier parecido con la realidad es pura coincidencia). Así es como se ve con el Latch abierto, es decir, información verdadera.

Figura 5: Datos reales a los que se accede con Latch abierto

Si el Latch estuviera cerrado, se vería otro tipo de información preparada, como esta:

Figura 6: Datos que aparecen en la base de datos HoneyPot 

Y aquí vemos un ejemplo preparado de un SQL Injection con el Latch cerrado.

Figura 7: Ataque de SQL Injection a la web con la Base de datos HoneyPot

Mostramos ahora el registro de Logs de lo que está haciendo. Hemos descubierto que el atacante hizo un ataque de SQL Injection para obtener información sobre los presupuestos de PEPITO, y ahora deberíamos investigar cómo lo ha hecho. ¿Será por un CSRF como en el caso de la base de datos atacada desde el iPad del jefe?

Figura 8: Log de acciones de ataque en la HoneyPot

Evidentemente si en la aplicación con la información falsa existe este fallo, lo habrá igualmente con la información real, y además ha sido descubierto dicho bug por un atacante, pero sin arriesgar la información legítima. Ahora podemos arreglarlo lo antes posible para que no vuelva a suceder. Evidentemente una aplicación de empresa debe estar lo suficientemente probada y no dejar en mano de los atacantes descubrir los fallos, pero... las cosas pasan.

En este ejemplo vimos un uso adicional de Latch, no solo de permitir o prohibir el paso, si no de tomar una opción u otra en función de un estado. Esto no solo se aplica en bases de datos, podríamos usarlo para cambiar el tráfico de un host a otro, y tener muchas opciones más si utilizamos la granularidad de las operaciones. Otro caso útil podría ser el login de una web. ¿Por que mostrarlo si podemos bloquear con Latch tan siquiera la publicación del formulario de login? El límite lo pone nuestra imaginación y las ganas de programar. Te recomiendo que leas el artículo de cómo cocinar una aplicación PHP con Latch que explica paso a paso cómo se puede meter Latch en cualquiera aplicación web que tengas.

Autor: Borja Pintos

HoneyMap en el mapa de ataques a una red de Honey Pots

Ya hace tiempo que se publico el mapa del mundo en guerra, una página web basada en recolectar datos de los servidores de HoneyNet Project y representarlos en una página web sobre un mapa SVG con JavaScript. Basándose en el mismo proyecto, Deutsche Telekom ha puesto los datos de su red de servidores Honey Pot para que puedan ser vistos en tiempo real.

Figura 1: El mapa de los ataques a los honey pot de Deutsche Telekom

Entre los datos de esta red en concreto, sigue apareciendo los ataques a SMB y NetBIOS como los primeros de la lista, supongo que en parte por Conficker, en parte por la cantidad de scanners que buscan el famoso MS08-067 para entretenerse y divertirse largo tiempo con Metasploit y Meterpreter.

Figura 2: El Top 5 de tipos de ataques detectados

Los malos de esta película no son los Chinos como en el informe Mandiant, sino los Rusos, que lideran el top de direcciones IP de los atacantes. Supongo que será en buena parte por las famosas redes y servidores Bullet-Proof que tan buenos réditos económicos dan al país.

Figura 3: El Top 15 de los países "malos"

Si quieres hacer alguna representación similar de tu red de sensores, puedes hacerlo con este mismo software, ya que el código del proyecto lo tienes disponible en el Github de HoneyMap. Puedes aplicarlo para representar cualquier incidente en tiempo real utilizando coordenadas GPS y un mapa, para lo que debes repasarte previamente la tira 977 de XKCD.

Figura 4: Tipos de representaciones de mapas interpretadas por XKCD

He de pedirte que si te vas a meter en el apasionante mundo mapas, mires a ver si te animas a usar alguna representación distinta a la de Mercator, que yo me muero de ganas de ver estos mapas en representaciones tipo Dymaxion o Waterman Butterfly.

Saludos Malignos!

El mundo en guerra

Me ha encantado el proyecto de HoneyNet Project que he descubierto leyendo el Foro de El Hacker creado por Florian Weingarten y Mark Schloesser en el que presentan en un mapa del mundo los ataques que están sufriendo los HoneyPot Servers que tienen desplegados por el mundo.

Figura 1: El mapa del mundo en guerra

El mapa funciona en tiempo real, y muestra en colores rojos los atacantes, es decir, la dirección IP desde la que llega el ataque, y en color amarillo los objetivos, es decir el servidor HoneyPot que es atacado. En tiempo real se pueden ver los logs que se utilizan para representar el gráfico.

Figura 2: Los logs de los ataques

Hay que tener presente que solo representa los ataques que reciben sus servidores, pero si te pasas un rato siguiendo la evolución, podrás ver qué países son los más beligerantes.

Saludos Malignos!