El nodo que todo lo ve

#DISCLAIMER

Antes de nada los dos autores (Shargon y Belane) queremos aclarar que todos los datos recopilados durante la investigación, de los cuales han resultado las dos entradas; «24 horas en la vida de un nodo de salida de Tor» y la aquí presente, han sido destruidos. Entendemos que durante dicha recopilación ha sido parcialmente vulnerada la privacidad de todas las personas que pasaban a lo largo de nuestro nodo de salida y a diferencia de en la primera entrada, las 24 horas siguientes (antes de cerrar en nodo) fueron utilizadas para capturar tanto cabeceras como el paquete completo de varios protocolos inseguros.

Aclarar que el nombre de los dominios que aparecen como atacados no necesariamente contienen una vulnerabilidad, ya que cualquiera lanzando un sqlmap sobre google.es habría hecho saltar nuestras alarmas.

Esta entrada intentará tratar de la forma mas científica posible dichos datos. Esperamos que os guste 🙂

 

INTRODUCCIÓN

Continuamos con el análisis de 24 horas en un nodo de salida de la red Tor y como decíamos en la primera entrada el uso de protocolos inseguros pone en peligro la comunicación, da igual que usemos Tor si después no vigilamos estos detalles.
También que no todo el trafico era delictivo pero eso no quita que si hay mucho trafico sospechoso.
En esta segunda parte de la investigación vamos a centrarnos en estos casos, los ataques que hemos detectado y la falta de privacidad por el simple hecho de utilizar protocolos inseguros. Lo dicho, ya puedes usar 2 VPNs+Tor que siempre debes saber que haces y donde lo haces.

 

PROTOCOLOS INSEGUROS

Lo primero. Para ilustrar que es trivial interceptar trafico de protocolos en texto claro, hemos configurado nuestro cliente Tor para salir por nuestro Nodo y navegamos a fwhibbit, como puede verse en la siguiente captura todo el trafico queda en claro.

Existe una configuración específica para obtener este resultado, donde se le especifica que se quiere salir por un nodo concreto (Link a la documentación).

Ahora vamos a ver algunos ejemplos del trafico inseguro que observamos en nuestras 24 horas. Gracias a las estadísticas de la anterior entrada, se distribuyó la captura en 24 horas para cada uno de estos protocolos, pero el único dónde no capturamos los Response del servidor fue en HTTP, debido a que se nos hubiera hecho inmanejable.

POP3

El puerto de SMTP se puede utilizar para hacer Spam y no lo dejamos abierto en el nodo, pero el puerto de POP3 si. ¡Que levante la mano quien tiene una clave distinta en smtp y en pop3!

Hay una forma insegura de trabajar para leer tu bandeja de correos, durante las 24 horas de pop3 sin SSL, recibimos un total de 34 conexiones diferentes (al distinto servidor o con las distintas credenciales). De las cuales la heurística aplicada a la trama TCP de la conexión, nos ha confirmado que hay 27 claves reales, ya que a lo largo de la trama el servidor las ha confirmado como correctas.

El protocolo POP3 tiene varias formas de autenticarse de una forma «mas segura«, os mostramos la gráfica de cuales han sido los AUTH más utilizados para «proteger» el envío de claves en texto plano al servidor.

FTP

Curiosamente ningún paquete FTP fue capturado durante las 24 horas de nuestro nodo, así que lamentablemente no podemos ofreceros una gráfica o estadística de este protocolo. De hecho fue mala suerte porque en las 24 horas previas si se detectó tráfico por dicho puerto pero en esa ocasión solo grabamos las cabeceras TCP, por lo que dichos datos no son válidos para el propósito de esta entrada 🙁

TELNET

El caso del Telnet es un tanto especial. Ya que no existe un estándar que dicte como se ha de hacer las cosas, cada aplicación lo hace un poco a su aire, por lo que cabe decir, que el número de falsos positivos (sobretodo a la hora de saber si son conexiones correctas o no) puede variar bastante.

El proceso que hemos seguido para extraer las claves del Telnet y verificar si son correctas es el siguiente.

  • Si la primera linea enviada por el servidor contiene «login», «user» o «usuario», la siguiente linea enviada por el cliente será el usuario
  • Si por el contrario contiene «pass», «key», «credential», «clave», la siguiente linea enviada por el cliente será la clave.
  • Se crearon otros filtros varios, según fuimos analizando los resultados.
    • Esto es debido a que, por ejemplo, en algunos BusyBox que nos hemos encotrado el servidor responde al login correcto con «warning: cannot change to home directory
      root login», y nos creaba un falso negativo
  • Para saber si es correcto o incorrecto, nos basamos en que el servidor corte la conexión antes de que el cliente envíe cualquier mensaje que no sean los anteriores descritos, usuario o contraseña.

Según estas premisas los resultados obtenidos han sido:

Los usuarios utilizados a lo largo de todas las tramas son los siguientes:

Las claves mas utilizadas son:

Pudimos ver el incesante ataque de los Bots a los servicios de Telnet a la caza de otro zombi mas. Así es como se construyen las redes de bots. Mas de 1500 intentos fallidos de login sobre 844 host en solo 24 horas. (descargar pcap ataques Telnet)

24tor_telnet_bots

Por desgracia muchos logins con contraseñas por defecto que es lo que buscan los bots para ampliar su red.
Podemos ver aquí un Router Cisco con credenciales por defecto

24tor_cisco

También DVRs, muy afectados por botnets como Mirai.

24tor_dvr24tor_login_dvr

 

HTTP Basic Auth

Otro ejemplo de que proteger información importante o sensible por medio de un protocolo inseguro no es la solución, da igual lo compleja que sea la contraseña si viaja por un canal inseguro.

En este caso encontramos claves privadas de un sitio web. Que estaba protegido por Http Basic Auth, enviadas por http y para el colmo con directory Listing, un ejemplo deplorable de como montar un sitio seguro.

Capturamos 2468 peticiones únicas de Http Basic Auth a diferentes sitios, en los que encontramos 207 usuarios diferentes y 288 contraseñas diferentes. Al no capturar las respuestas no podemos verificar con exactitud si son válidos o no, pero en su mayoría, sobretodo a los cgi (cámaras ip) hemos podido verificar que casi siempre que no se trataban de usuarios y claves por defecto, eran correctos.

 

Autenticación en HTTP

Se capturaron un total de 7.458.355 peticiones HTTP de las cuales se examinó el contenido buscando en GET, POST y HTTP Basic Auth usuarios y contraseñas en campos habituales como «user», «username», «password», «pass», etc… la gráfica representa el número de peticiones en las que encontramos intentos de logins. En este caso al no capturar las respuestas no podemos certificar si son válidos o no, pero la gráfica representa el total de las 70.901 peticiones de login capturadas.

Intentos de Login por hora

 

 

 

DISPOSITIVOS IoT EXPUESTOS

Existen multitud de dispositivos IoT, seguramente atacados por la botnet Mirai u otras. Se aprovechan de configuraciones por defecto y de exploits en dispositivos IoT para hacer de las suyas y como no podía ser de otra manera, a través de nuestro nodo, se enviaron multitud de contraseñas en texto plano que conectaban con, entre otros, cámaras ip donde se pueden ver desde cunas de bebes hasta camas matrimonio.

Los modelos de cámara más explotados (no los únicos) se tratan de IPUX (ICS2330) , TRENDnet (TV-IP422w), FOSCAM, Marmitek (IpRobocam).
Basta abrir los enlaces para darse cuenta que se trata de la misma cámara en marcas diferentes. En su mayoría no eran claves por defecto, pero debido a exploits existentes en el mercado, se pueden obtener y entrar en ellas. La botnet las utilizó para algún fin y nosotros recibimos las claves en texto plano.


Y lo peor de todo esto es que el ser humano no aprecia que estés mirando, no sabe que estás ¿Que por qué digo el ser humano? aparte de que en muchos de estos dispositivos guardan logs (que pueden ser borrados con relativa facilidad), existen otros seres en el mundo con dotes sobrenaturales, capaces de detectar presencias que alguien normal no es capaz de detectar. Sí señores, fuimos cazados por uno de esos seres sobrenaturales que habitan nuestro planeta, «EL GATO».

No olvidemos que el entrar en una cámara no sólo te puede dar acceso a ver la intimidad de las personas, sino que también a través de la configuración puedes obtener mas credenciales, en este caso Dyndns y la propia clave de la wifi. Sin mencionar que disponga de algún exploit que permita entrar y dejar residente algún Malware o un actualizar el firmware por uno malicioso.

 

No importa lo segura que sea tu Wifi, si está expuesta por dispositivo vulnerable, entrarán hasta la cocina (nunca mejor dicho).

ATAQUES

A lo largo de las 24 horas hemos detectado varios ataques de fuerza bruta, principalmente sobre Telnet y sobre páginas de Login.

 

Pero también inyecciones SQL y ataques XSS. Algún que otro sqlmap, en concreto aquí mostramos a alguien interesado en acceder a una página pornográfica. Luego nos preguntamos como surgen escándalos como el de Ashley Madison.

 

Uso de herramientas automatizadas sobre dominios gubernamentales, posiblemente sqlmap.

 

Haciendo una consulta a los campos de contraseñas que contienen la palabra SELECT se puede ver que se detectan cantidad de ellos.

 

Intentos de XSS sobre dominios de ebay.


Al final detectamos un total de 4562 ataques SQLi y XSS.

Países mas atacados

Dominios mas atacados (Top 20)

Objetivos atacados por hora

 

Bonus

Pero no todo iban a ser ataques malintencionados. Descubrimos acciones de la botnet benévola Linux.Wifatch.
Esta Botnet lleva varios años circulando por la red a modo de protector o vigilante, atacando los mismos dispositivos IoT que sus hermanas malvadas con la diferencia que cuando consigue un acceso, inhabilita los servicios remotos con un mensaje informativo impidiendo así que otras Botnets puedan hacerse con el dispositivo.

 

 

Ahora queremos que te preguntes, que reflexiones… Si hemos hecho esto nosotros, unos don nadies con 3 euros ¿Que no estarán haciendo nuestros gobiernos?

 

3 comentarios en «El nodo que todo lo ve»

Los comentarios están cerrados.