El lunes de la semana pasada, el periodista Juan Gómez, con el que hecho alguna cosa en el pasado, me pidió una pequeña entrevista de unos 15 minutos para hablar un poco sobre la Deep Web en un podcast de Radio Televisión Española en el que colabora junto con María Paredes, llamado "Terror en Blanco".
Querían hablar conmigo sobre este tema en su programa de divulgación, así que me llamaron, y estuve unos minutos respondiéndole a esas preguntas de la misma forma que lo haría con cualquier persona que me pregunte en la calle. Sin guión ni preparación previa, así que quedó muy casual.
El programa lo publicaron este jueves, y lo tienes ya disponible para escuchar en todas las plataformas habituales, e incluso en la web que el Podcast Terror en Blanco tiene en RTVE, donde tienes todos los programas.
Hoy sábado, os he cortado la parte de la entrevista y la he subido a mi canal Youtube, para conservar la participación en este programa dentro de mi canal, que ya sabéis que intento conservar todo lo que voy haciendo en él.
Y nada más por hoy, que tengáis un feliz 15 de Febrero, que hagáis deporte, y que disfrutéis al máximo del descanso físico y mental. Y de leer cómics si puedes }:)
En este artículo me gustaría contaros una pequeña PoC que hicimos en el equipo de Ideas Locas que teníamos guardada para algún evento de Web3, pero que como tengo ganas de contárosla, he decidido hacerlo desde hoy. No es un estudio completo, ni mucho menos, porque el escenario es enorme, pero se basa en un idea muy sencilla, que es hacer Serverless & Bullet-Proof WebSites, capaces de soportar el intento de bloqueo o censura de cualquier entidad.
Figura 1: Serverless & Bullet-Proof Web Sites (1 de 2)
Esto no es algo nuevo, y la Serverless Web lleva tiempo estudiándose, y trabajándose con diferentes arquitecturas, todas ellas totalmente distribuidas.
Dust-RSS
Uno de esos ejemplos fue un proyecto personal del equipo de Ideas Locas, en aquel entonces en Informática 64, en aquel entonces del año 2010, y que presentamos en la RootedCON de 2011 y se llamó Dust-RSS.
La idea era muy sencilla, evitar la censura de los servidores RSS de los blogs para permitir que cualquiera que tuviera algo que comunicar lo pudiera hacer siempre, y para eso diseñamos una arquitectura muy sencilla, basado en claves PGP y una red P2P para hacer la distribución. Esto hacía que no hubiera un único punto de fallo en el servidor web, ni en el DNS, y que con tener la clave pública PGP del publicador se pudiera buscar por redes P2P las publicaciones.
De esta forma, el publicador lo único que debía conservar era su clave PGP privada para poder poner en la red P2P una nueva publicación. La arquitectura funcionaba, pero se quedó en una PoC que presentamos en DefCON 2012, y que se quedó como un bonito experimento.
OSIRIS SPS
Uno de las arquitecturas que buscaba solucionar estos problemas de censura de servidores Web se trataba de OSIRIS SPS (Serverless Portal System) y su Gateway ISIS, para poder publicar servidores Web que no dependieran de un único punto de fallo. Para ello, la solución era similar a tener a páginas web cacheadas y compartidas por una red P2P.
Figura 4: Foro de Anime publicado en Osiris SPS visible vía Isis Gateway
Las páginas web de los portales que se ven a través de esas URLs realmente no están en ningún servidor web concreto, sino distribuidos por toda la red P2P de Osiris SPS, lo que impediría un bloqueo o censura del sistema. Es perfecto para crear foros y portales de denuncia social que no puedan ser quitados de Internet si no quieren sus usuarios.
DeepWeb: TOR, I2P, FeeNet, Hyperboria, CJDNS
Todas estas soluciones no accesibles a través de los navegadores de "superficie", son consideradas redes de la DeepWeb, no solo porque no son accesibles con las herramientas más comunes de Internet, sino porque además cuentan con herramientas y protecciones contra el control, ya sea cifrados especiales o como hemos visto, para evitar el bloqueo de sus contenidos, como en el caso de OSIRIS SPS o el sistema DUST RSS que utiliza mecanismos P2P para ello. q
Por supuesto, muchas de las funciones de seguridad que se buscan en estas redes, están en las más conocidas de la DeepWeb como son TOR, FreeNET e I2P, donde el cifrado de las comunicaciones es una de las claves en todas ellas.
Pero la búsqueda de arquitecturas distribuidas y seguras ea algo que se ha estudiado mucho, como el caso de CJDNS y su red Hyperboria con conexiones cifradas y certificadas sobre IPv6, GNUNet, Lantern, YaCy para conseguir que no puedan ser accesibles los contenidos por nadie.
Malware en BlockChain
Por supuesto, pensar en arquitecturas Serverless y Distribuidas, es hablar del core de las cadenas de bloques de BlockChain, y utilizar las capacidades que tiene para poder almacenar datos de forma permanente y protegida con la distribución por diseño que tiene esta tecnología.
Figura 7: PoC de C&C con OP_Code en cadena de BitCoin
propuesta por Yaiza Rubio y Felix Brezo en EuskalHack 2017
En la EuskalHack del 2017, Felix Brezo y Yaiza Rubio hacían una demostración de cómo se podrían almacenar comandos de un C&C de una Botnet de malware en el campo OP_CODE la cadena de bloques de BitCoin.
Esto, al precio que está hoy el BitCoin parece un poco caro, pero esta idea de usar la cadena de OP_CODE para hacer servicios no es nueva, y algunos proyectos lo han utilizado en el pasado, aunque co la proliferación de cadenas de bloques a precios mucho más más económicos, hace que ya no sea necesario centrarse en ese campo.
Y como muestra de esto lo hemos tenido con el caso del malware de Etherhiding, donde el binario del malware se han escondido dentro de la cadena de Binance Smart Chain, y ha utilizado SmartContracts para actualizarse.
Redes Sociales Descentralizadas
Por supuesto, la explosión de las cadenas de Blockchain, y otras arquitecturas distribuidas, hayan ido apareciendo en todos los verticales tecnológicos nuevos servicios que pretenden ser más resistentes contra los ataques a servicios descentralizados, como son las Redes Sociales.
Ahí, propuestas como Mastodom, Diaspora, Matrix, Block Square, que son sólo una pequeña muestra, han ido apareciendo por todos los rincones de Internet, y se han convertido en parte de la transformación y disrupción que se está viviendo en este mundo de las redes sociales.
Pero la descentralización de todos los servicios digitales que se están construyendo hoy en día. Algunos que se han hecho piezas fundamentales en las arquitecturas Web3, como el almacenamiento IPFS (Inter Planetary File System) del que ya hablamos.
Y esto nos lleva a nuestra PoC, que es cómo aplicar todas las arquitecturas al servicio fundamental de la web, y que como veremos es rápido y sencillo, pero será en la segunda parte de este artículo.
Es conocido que si te conectas a un sitio web, tu dirección IP puede ser registrada y analizada. Y esta dirección puede dar información de tu ubicación - más o menos certera -. Esto sucede en todos los servicios que permiten compartir URLs y esta dirección IP que los sitios web pueden capturar y analizar, apunta, más a o menos, al lugar donde te encuentras, salvo que hagas uso de la red TOR, utilices una VPN o un Proxy que haga anónima tu conexión.
Figura 1: Cómo pueden saber dónde vives por pulsar un enlace de un WhatsApps "Status"
Algunas aplicaciones te avisan del peligro de esta redirección, pero otras muchas aplicaciones como Twitter, Telegram, Instagram o WhatsApp, no lo hacen. En este artículo explicamos cómo poder explotar la información que muestra el histórico de visitas de nuestro ESTADO de WhatsApp (WhatsApp Status), qué contactos de WhatsApp y cuándo lo han visualizado, lo que puede ser un problema para la privacidad del uso que haces de WhatsApp, así que toma nota.
Como vamos a ver, a partir de recoger las conexiones que hagan los contactos de WhatsApp a nuestro ESTADO podremos correlacionar este historial con fecha y hora, con un log ad-hoc en la web donde fueron redirigidos los contactos que hicieron clic. Mediante una serie de pasos fáciles de realizar, una tabla en una BBDD y un fichero en PHP.
La mitigación podría ser tan sencilla como un aviso por parte de WhatsApp del peligro que conlleva esta redirección o bien una concienciación a los usuarios de los riesgos contra su privacidad a los que incurren, esto último es el propósito final de esta explicación, para que puedan protegerse de los peligros en Internet correctamente.
La funcionalidad del estado de WhatsApp
El ESTADO de WhatsApp es una funcionalidad que según su ayuda se describe de la siguiente forma en la plataforma:
“Con los estados, puedes compartir actualizaciones de texto, fotos, videos y GIF que desaparecen después de 24 horas y están cifradas de extremo a extremo. Para recibir actualizaciones de estado de tus contactos y que ellos reciban las tuyas, tú y tus contactos deben tener sus respectivos números de teléfono guardados en la libreta de contactos de sus teléfonos”.
Curiosamente, la funcionalidad de añadir texto nos permite que este texto sea una URL, y al hacer doble clic sobre él, este híperenlace nos redirige a una web, como muestra la figura siguiente. En este ejemplo concreto lo hará a la URL de la web Xxx.com
Figura 4: Creación de un Estado en WhatsApp con una URL
que registrará direcciones IP.
Esto no es nada nuevo, y los Stories de Instagram funcionan exactamente. Es una funcionalidad que utilizan muchos en la plataforma para difundir sus contenidos. La única diferencia fundamental, como vamos a ver, es que en Instagram el usuario que publica una Storyno tiene un log detallado de horas de conexión y cuentas de sus contactos de Instagram que han visto la Story. En WhatsApp sí.
Figura 5: Si activas las "confirmaciones de lectura de mensajes"
WhatsApp te deja ver un log detallado de a qué hora quién
visitó tu ESTADO, lo que da una información valiosa.
Ahora ya podemos organizar esto. Por un lado un registro de visitas a la web que capture la hora exacta y la dirección IP del visitante. Por otro un registro detallado de contactos de WhatsApp que han visitado el estado. Si hay "match", ya sabes la dirección IP y dónde está el contacto de WhatsApp concreto.
Cómo preparar la web de registro (Stickyweb)
En primer lugar, creamos una tabla en MySQL con el propósito de almacenar la GEO información de las direcciones IP de las visitas de los contactos que han sido redirigidos. La estructura de la tabla Log se muestra en la imagen siguiente.
Figura 6: Estructura de la tabla LOG donde se registrará la
GEO información IP de las visitas a xxxx.com
En segundo lugar, construimos una página web que, por simplicidad, consta de solo un fichero (index.php) y que también por simplicidad está construida en PHP, tal y como se puede ver en la imagen siguiente.
Figura 7: código PHP que obtiene la información de GEOIP
y la registra en la tabla LOG
En la ejecución del código PHP se recuperan las variables de entorno asociado con la navegación del usuario y que junto a un campo “Timestamp” de la tabla Log anterior expuesta, que supone la fecha de creación del registro en el momento que las instrucciones de PHP realizan la inserción de estos datos de navegación en la tabla Log de la base de datos MySQL.
Cronología de los Eventos
Una vez desplegada la web y con la tabla de registro del Log en la base de datos funcionado, punto 1 del cronograma del esquema siguiente. El siguiente paso corresponde al punto 2, en el que publicamos nuestro estado a la espera de que nuestros contactos hagan un clic en la URL asociada a nuestro estado de WhatsApp.
Figura 8: Cronología de creación de la web, creación del estado y clic de los contactos
Cronológicamente los contactos 1, 43 y 22, lo harán en el tiempo en los puntos 3, 4 y 5 respectivamente, como también muestra la imagen anterior.
Análisis de la Información registrada
Una vez que ya está registrada la GEOinformación IP de navegación de los contactos en la tabla Log de MySQL, procedemos a correlacionar el campo “FechaRegistro” (que recordemos que es de tipo TimeStamp) con la fecha y hora que muestra el Historial de los contactos que han visto el Estado de WhatsApp e hicieron clic en la URL del enlace de Estado, como muestra la imagen siguiente.
Figura 9: En el log del Estado de WhatsApp podemos ver qué contacto vio
el Estado y a qué hora, y luego buscamos esa hora en la tabla de Log
para saber qué IP usó en la conexión a la web.
El resto, es mirar la información extendida en la tabla de GEO Información IP que tenemos en la base de datos de MySQL con toda la información extendida que hemos sacado y que va asociada a la dicha dirección IP. Lo dicho, puede ser más o menos exacta.
Figura 10: Información extendida sobre la dirección IP
A partir de esta correlación tenemos accesible la información del número de teléfono (haciendo uso de la agenda) y de la dirección IP de conexión, que determinan la información geográfica asociada, así como el proveedor que nos presta el servicio de interconexión, ya sea móvil o no, exponiendo la privacidad de navegación de los contactos de una manera ni autorizada ni solicitada.
Impacto y mitigación
El impacto de esta práctica es una pérdida efectiva de la "GEO privacidad" de los usuarios que hubieran hecho clic en el estado, pudiendo suponer un seguimiento no autorizado de las personas. Algo que de facto es deducir si se está usando una red móvil o una conexión fija, en qué ciudad, provincia o país se está conectado, con todas las implicaciones para la seguridad de las personas o de sus bienes que ello pudiera implica.
Tal vez, se debiera advertir al usuario que este será redirigido a una web externa, (como ya hace WhatsApp), pero debería informar de lo que ello implica, lo que sería una mitigación muy efectiva, ya que las personas se darían cuenta del peligro de pérdida de privacidad que eso implica.
aaa
Figura 11: WhatsApp avisa antes de hacer una redirección fuera de la cuenta,
y ahí podía poner más información del riesgo de privacidad.
Además, se podía hacer que el registro de accesos al Estado de WhatsApp fuera menos "detallado", y hacerlo más similar al de Instagram, donde se puede ver qué usuarios vieron la Story, y luego datos agregados de clics o comparticiones, pero no quién hizo qué ni a qué hora exacta.
Figura 12: En Instagram, las estadísticas de las Stories no
son tan detalladas como la de los Estados de WhatsApp.
Están agregadas y no dicen quién hizo qué a qué hora.
La curiosidad por saber qué quiere mostrarnos un contacto, unido al desconocimiento general de este funcionamiento y que termina en visitar una URL del Estado de Whatsapp, unido a la funcionalidad del registro temporal del historial de visitas que hace WhatsApp de los Status, conlleva a una importante exposición de la privacidad de navegación, al correlacionar toda esta información.
Este posiblemente sea el primer artículo de una serie que vamos a ir publicando llamada “Aplicaciones prácticas de Docker en ciberseguridad”, donde iremos mostraremos recursos, herramientas y soluciones siempre utilizando Docker como elemento principal. La versatilidad y sencillez de esta tecnología nos permite disponer de nuestra propia caja de herramientas, segura, en cualquier momento y en cualquier lugar.
Figura 1: Docker en ciberseguridad: Tu servidor Proxy para navegar por TOR
Esto para alguien que se dedica a la ciberseguridad o incluso para cualquier usuario que quiera probar o utilizar alguna aplicación, es una opción que debemos de tener en cuenta. Y recuerda, si necesitas ayuda para comenzar esta aventura con Docker, en nuestro libro “Docker: SecDevOps” tienes un buen punto de partida para comenzar en este fantástico mundo de los contenedores Docker.
Utilizar un contenedor Docker nos permite encapsular toda la instalación (componentes, dependencias, etc) y aislarlo de nuestro host (por defecto). De esta manera, podemos, por ejemplo, crear un proxy para navegar a través de la red Tor de una manera segura y rápida. Y esto es justo lo que vamos a contarte hoy paso a paso, así que manos al a obra.
Cómo configurar un Proxy Tor
Para ello vamos a crear una imagen con dos herramientas que seguro ya conocéis: anonsurf y tiny proxy. Con anonsurf navegaremos a través de Tor y tiny proxy, actuará pues como su nombre indica: como un Proxy. Todo ello para que puedas navegar con anonimato a través de la Deep Web o poder hacer labores de Ciberinvestigación.
Lo primero que haremos es crearnos una imagen Docker con dichas herramientas. Para facilitar este proceso, vamos a utilizar una aplicación llamada doig o Docker Image Generator, una aplicación Open Source en lenguaje Go, creada por Tuxotron ;) que tenéis disponible en este enlace.
Esta aplicación permite crear imágenes Docker o ficheros Dockerfile personalizados, simplemente eligiendo las herramientas que necesites. Además de facilitar la tarea de crear la imagen, también es muy instructiva, ya que una vez creada la imagen nos permite exportar el fichero Dockerfile el cual podemos utilizar directamente con el comando docker build o simplemente para ver su funcionamiento. Para instalar doig:
git clone https://github.com/tuxotron/docker-image-generator
cd docker-image-generator
go build
Para crear nuestra imagen para navegar por la red Tor, ejecutamos:
./doig -i myproxy -t anonsurf tinyproxy
…
Successfully built 49e1529560fe
Successfully tagged myproxy:latest
Tools added to the image:
[-] tinyproxy: When you run Tiny Proxy, by defautl listens on port 8888,
so you will need to map that port to a local port. Ex: -p 8888:8888
[-] anonsurf: You need to run the container in privileged mode
Con la opción -i especificamos el nombre de la imagen y con -t listamos las herramientas que queremos incluir en la misma. Una vez terminado el proceso de construcción de la imagen, vemos que al final nos aparecen dos mensajes:
[-] tinyproxy: When you run Tiny Proxy, by defautl listens on port 8888,
so you will need to map that port to a local port. Ex: -p 8888:8888
Este nos avisa que tiny proxy por defecto escucha por el puerto 8888, y que para usarlo necesitaremos mapear dicho puerto al de nuestro host. Si tuvieras cualquier otra aplicación escuchando por ese puerto, mapéalo a cualquier otro. En Docker se pueden mapear puertos del contenedor al host con la opción -p (--publish) host-interface:puerto-host:puerto-contenedor. Por ejemplo:
docker run -p 127.0.0.1:80:8080
Esto mapearía el puerto 80 de la interfaz 127.0.0.1 al puerto 8080 del contenedor. Si se omite la interfaz, se usaría 0.0.0.0:
docker run -p 80:8080
También se pueden especificar rangos de puertos. Por ejemplo:
docker run -p 80-82:8080-8082
Esto mapearía el puerto 80 del host al puerto 8080, 81 al 8081 y el 82 al 8082.
Existe una segunda forma de mapear los puertos con la opción -P (--publish-all). Esta opción no requiere ningún valor, ya que lo que hace es mapear los puertos que expone el contenedor a puertos aleatorios (por encima del 30000) del host. La forma en que Docker identifica los puertos que expone un contenedor viene por el comando EXPOSE de la imagen.
El segundo mensaje:
[-] anonsurf: You need to run the container in privileged mode
Nos dice que anonsurf requiere permisos elevados, ya que éste necesita hacer cambios en las iptables del contenedor. Aquí podemos darle permisos usando las capacidades o bien ejecutar el contenedor en modo privilegiado. Cuando se ejecuta un contenedor en modo privilegiado, tenemos que asegurarnos bien de las funciones que ejecuta, ya que podría comprometer tu sistema.
Si todo ha marchado bien, siguiendo nuestro ejemplo, deberíamos tener una imagen Docker llamada myproxy. Ahora, para ejecutar nuestro contenedor, lo haremos de la siguiente forma:
docker run -it --rm --privileged -p 8888:8888 myproxy
root@9ca7a81698d3:/opt#
Eso nos sitúa en una shell dentro del contenedor. Ahora todo lo que tenemos que hacer es arrancar anonsurf y tiny proxy:
anonsurf start
* killing dangerous applications
* cleaning some dangerous cache elements
[ i ] Stopping IPv6 services:
[ i ] Starting anonymous mode:
* Tor is not running! starting it for you
* Starting tor daemon... [ OK ]
* Saved iptables rules
* Modified resolv.conf to use Tor and Private Internet Access DNS
* All traffic was redirected through Tor
[ i ] You are under AnonSurf tunnel
root@9ca7a81698d3:/opt# tinyproxy
root@9ca7a81698d3:/opt#
Si el indicas a tu navegador que use nuestro Proxy (localhost:8888), estarás navegando a través de Tor, como puede verse en ese vídeo.
Figura 5: Configurar un Proxy TOR en Docker Parte 1
De esta forma, cada vez que queramos arrancar nuestro Proxy Tor tenemos que arrancar el contenedor y levantar ambos servicios. Si queremos automatizar un poco el proceso y ahorrarnos los pasos de levantar dichos servicios de forma manual, podemos usar la opción -d de doig. Esta opción nos dará el fichero Dockerfile que nos permite construir nuestra imagen. Todo lo que tenemos que hacer es añadir al final de dicho fichero la instrucción CMD para que arranque nuestros servicios. Veamos un ejemplo:
Lo que haremos es añadir al final del fichero Dockerfile es el comando:
CMD anonsurf start; tinyproxy -d
Aquí que le decimos a Docker es que ejecute ese comando cuando arranquemos el contenedor. Fíjate que a tiny proxy le pasamos el parámetro -d para que se ejecute en el foreground. Si no Docker terminaría el contenedor. Una vez hecho esto, ahora sólo nos queda construir la imagen:
docker build -t myproxy
Y arrancar el contenedor:
docker run -d -p 8888:8888 --privileged myproxy
Aquí tenemos que prestar un poco de atención, ya que ya no hemos arrancado el contenedor en modo interactivo (-it) si no en modo no interactivo con la opción -d (detach). De esta forma el contenedor corre en el background. También se podría ejecutar en modo interactivo, pero se nos quedaría la shell “enganchada” al contenedor. Aún así, en ambos casos debería de funcionar.
Figura 6: Configurar un Proxy TOR en Docker Parte 2
Recuerda que esta imagen está sólo disponible en tu sistema. Si queremos compartir esta imagen con alguien o simplemente quisieras usarla en otros entornos, sin tener que construir la imagen en cada uno de ellos, puedes subir ésta a un registro de imágenes. Un registro de imágenes es un repositorio donde se pueden almacenar, imágenes.
Dichas imágenes pueden ser públicas o privadas. A las públicas cualquiera puede acceder y a las privadas, pues cómo puedes imaginar, sólo son accesible por aquellos que tengan las credenciales necesarias. En Docker el registro de imágenes por defecto es https://hub.docker.com. Aquí cualquiera se puede crear una cuenta gratuita. Dicha cuenta te permite crear repositorios y subir imágenes a estos. Con la cuenta gratuita, sólo puedes crear un repositorio privado. El resto deben ser públicos.
Para descargar imágenes del https://hub.docker.com, no necesitas ni tener cuenta ni estar autenticado, siempre y cuanto la descarga de las imágenes que hagas sean públicas, pero si necesitas descargar imágenes privados y/o subir imágenes (ya sean privadas o públicas), sí que tienes que tener cuenta y estar autenticado. Con docker login puedes registrar tu cuenta en Docker y una vez hecho eso, ya podrías acceder a tus imágenes privadas y subir imágenes. Para subir una imagen tienes el comando docker push.
docker push usuario/imagen:tag
Es muy importante que crees una imagen, si la vas a subir al registro, que la nombres con tu usuario/nombre-imagen. Esta es la forma en que Docker identifica a quién pertenece la imagen. Por ejemplo, si tu nombre de usuario es usuario1, siguiendo el ejemplo anterior, cuando crees la imagen:
./doig -i usuario1/myproxy -t anonsurf tinyproxy
O si tomas el camino de crear la imagen por tu cuenta, sin doig:
docker build -t usuario1/myproxy
Si por algún motivo se nos olvida ponerle el nombre correcto, tampoco es necesario recrear la imagen, sólo tenemos que dar una etiqueta con el nombre correcto con el comando docker tag:
docker tag myproxy tuxotron/myproxy
Una vez hecho eso ya puedes subir la imagen a nuestro repositorio:
docker push tuxotron/myproxy
The push refers to repository [docker.io/tuxotron/myproxy]
83366880db76: Pushed
3ca184e4825e: Pushed
16542a8fc3be: Mounted from library/ubuntu
6597da2e2e52: Mounted from library/ubuntu
977183d4e999: Mounted from library/ubuntu
c8be1b8f4d60: Mounted from library/ubuntu
latest: digest:
sha256:9fbd8e4c508738ca5ef70211988a3f39734c46ce022d4ed82581139132a9fbc4
size: 1572
Ahora desde cualquier otra máquina (con Docker) sería posible ejecutar el contenedor como hemos visto antes.
Conclusiones
Aunque doig te facilite la vida a la hora crear imágenes, saber cómo funciona y cómo usar Docker te permitirá comprender mejor el funcionamiento interno del proceso de creación de imágenes, posiblemente una de sus partes más importantes. Si creéis que este post ha resultado útil, continuaremos con nuestra serie para ir implementando más herramientas con Docker siempre desde el punto de vista de la seguridad.
Seguramente todo el mundo ha oído hablar de la Deep Web, donde todo lo que existe en el mundo digital - o casi - se dice que se puede encontrar. Claro está, hay que hacerlo buscando correctamente, pero sin buscadores tradicionales, ya que mucho del contenido es contenido no indexado que si no sería "Sufrace Web". En este artículo, nos vamos a sumergir un poco en la DarkNet, en una página que nos permite obtener credenciales de direcciones de correo electrónico que se han visto comprometidas a lo largo del tiempo.
Figura 1: Deep Web: Cómo buscar tus contraseñas en las "profundidades" de Internet
Si quieres conocer mucho mejor cómo funcionan las redes de la Deep Web, como TOR, FreeNET o I2P, y cuáles son los principales beneficios para la privacidad y el anonimato, ya sabes que en 0xWordDaniel Echeverri escribió un libro largo y explicativo sobre este tema.
La página de la que vamos a echar mano es una web publicada como Hidden Service en un dominio .onion. Esto nos indica que estamos en la red TOR, si intentamos acceder a través de un navegador común, obtendremos un mensaje como el que sigue:
“No se puede acceder a este sitio web”
Ya que no encuentra la dirección IP del servidor asociado a ese TLD. Sin embargo, si tiramos a través de la red de TOR podremos hacer nuestras consultas y verificar si nuestro correo regala “contraseñas” a los cibercriminales. En la imagen siguiente se puede ver el resultado usando una dirección de e-mail falsa.
Figura 3: Consulta de dirección de e-mail en el Hidden Service de TOR
Nada complicado. Todos podemos llegar a este Hidden Service y, si tu contraseña sale a relucir, haz un cambio de inmediato, y asegúrate de tener un Segundo Factor de Autenticación. Ahora bien, ¿podemos hacer la consulta a través de un script que nos sea útil para un pentesting usando Python?
De manera “convencional” no, ya que nos devolverá el siguiente error: "Failed to establish a new connection: [Errno 11001] getaddrinfo failed'. Vamos a ver cómo hacemos para que las peticiones de nuestro script en Python puedan ser enviadas a la red TOR.
Automatizando scripts con Python en la red TOR
Un simple requests.get, o requests.post no nos va a servir, necesitamos ir a la red TOR. Para ello podemos configurar el proxy en una sesión y hacer las peticiones. Para montar el script necesitaremos saber qué datos envía la petición. Podemos usar Burp o revisar la petición en el navegador para conseguir esta información.
Figura 5: Petición POST al Hidden Service de TOR analizada en el navegador
La petición es POST y envía 5 parámetros, donde rápidamente se aprecia que el usuario del e-mail y dominio se envían por separado. Ya estamos preparados para obtener la página desde Python, pero a nosotros nos interesa filtrar el contenido, no queremos el HTML completo.
Para ello un simple proceso de "web-scraping" nos ayudará. Si inspeccionamos el contenido de la web con los resultados, vemos que los resultados se muestran dentro de unas etiquetas ‘pre’, así que con el uso de la librería bs4 podemos sacar los datos deseados. La salida del script se puede ver en la imagen siguiente.
Figura 6: Respuesta del servidor en la red TOR con las credenciales
El script ‘make.sh’ son tres líneas simplemente para instalar e iniciar TOR, instalar Python 3 y Pip3 - normalmente ya está instalado como sucede en el ejemplo de la imagen de arriba -, junto a una dependencia en Python, que es Pysocks.
El puerto por defecto está en el 9050, pero podemos cambiarlo si se desea a otro modificando el archivo /etc/tor/torrc y agregando al final la línea SocksPort, en el script podemos indicarle el proxy. Vamos a ver un vídeo de su uso en un sistemas Microsoft Windows con el ejemplo de l correo falso ‘fakemail@gmail.com’.
Figura 8: PoC de búsqueda de contraseñas en la Deep Web
Visto un ejemplo, visto todos, con este tipo de funcionalidad puedes empezar a generar tus propios scripts para ir sacando la información que deseas y no solo contraseñas. Si quieres consultar el código del script, puedes visitar el siguiente repositorio de mi GitHub.
¡Hasta pronto!
Autor: Josué Encinar García (@JosueEncinar), autor del blog BoomerNiX y Security Researcher en ElevenPaths y en el equipo de Ideas Locas de la unidad CDO de Telefónica.
Soy un fan de los cómics desde que era pequeño, así que cuando tuve la oportunidad de conocer a Salvador Larroca y me invitó a participar en el podcast que hacía sobre Deep Web con Elena Merino, no lo dudé. Les busqué una ubicación para grabar una entrevista y hablamos largo y tendido durante un par de horas de muchas cosas.
Figura 1: Un podcast sobre la Deep Web, el hacking y el Big Data
La charla la han publicado en su podcast - que os dejo por aquí embebido - y espero que no me vayan a despedir de Telefónica por que han dicho en la presentación que han hecho de mí que yo soy el "número 2" algo que ya me gustaría a mí, pero que no es verdad. Soy el "número 2" en el corazón de Salvador Larroca, que el número 1 es su comercial de Telefónica asignado. Os la comparto por si no tienes nada que oír este fin de semana.
Figura 3: Podcast sobre DeepWeb, Hacking y Big Data
Por otro lado, Elena Merino ha contado en la presentación que yo de pequeño quería ser dios y, por explicar mejor ese detalle os cuento que la historia es que yo me flipé con Tron donde los "dioses" de los protagonistas eran los programadores informáticos, ya que los protagonistas eran programas bagando por la CPU de un ordenador. Yo quería ser uno de esos dioses... no dios como tal. No vaya a ser que alguien piense que yo tengo algún deseo de ser... Thanos.
Eso sí, Salvador Larroca me recompensó mi participación con un par de dibujos que son... ouh, yeah!! Y que quedan para mi colección personal. Volveré a participar en alguna ocasión en algún otro podcast con ellos, así que ya os informaré cuando haya algo en la agenda de eventos.
Normalmente me gusta prestar mucha atención a lo que está pasando en las series. Me encanta ver Elementary e intentar descubrir al asesino antes que Sherlock Holmes - de esta serie hay algunos capítulos fantásticos que tienen que ver con tecnología, como el de la IA del que os hablaré en algún momento-, o fijarme que el Sistema Operativo de Robocop está basado en un MS-DOS pero con el punto cambiado en el Command.com, o que en Mr. Robot no usaba passcode para el iPhone en el primer episodio de la primera temporada o, como os dejé hace poco, en Stranger Things usan una tabla periódica del futuro.
Figura 1: The Punisher & The Most Secure FTP Server [Spoiler Alert]
Ahora estoy disfrutando The Punisher, y ayer noche, en el carrusel de capítulos que me enchufé, me topé con una escena que me encantó. Si la quieres ver, para aquí, porque puede que te haga algo de SPOILER, así que como aún no la ha visto mucha gente, no está permitido desvelar cosas sin avisar. No como con el final de los Sopra... [Fade to black]
En la escena, Micro (uno de los personajes principales de la serie) está a punto de subir un fichero a un servidor FTP para enviar un correo electrónico con un enlace al fichero a una persona de la NSA. Se supone que nuestro amigo Micro es miembro de la NSA, y para ello tiene una cuenta en The Most Secure FTP Server. La imagen y estética de la web del servidor FTP es espectacular.
Figura 3: El servicio FTP más seguro de la red: Ouh, yeah!!
La he subido a alta resolución por si queréis revisar todos los detalles con cuidado, que las carpetas y ficheros sin nombre en el desktop también tienen su gracia. Sin duda, lo más curioso es el navegador, la web del servicio FTP y la lista de medidas de seguridad que dice disfrutar el sitio, que podemos revisar una a una:
- Supports an Unicode Password: Esta es buena, se supone que puedes poner contraseñas con caracteres no imprimibles, lo que le da una gran seguridad a la contraseña para que alguien la averigüe. Por supuesto, para hacer más compleja la contraseña, a la derecha, debajo del login tenemos información de que la contraseña debe ser de más de 12 caracteres.
- Completely anonymous e2e encryption: A lo largo del proceso no se ve muy claro cómo hace el e2e encryption, ni si se refiere a cuando el fichero se sube al servidor FTP o cuando se envía el correo electrónico vía enlace en un e-mail al destinatario, pero desde luego, para hacer el e2e el fichero debe ser cifrado en el cliente y descifrado en la máquina del destinatario, algo para lo que se necesita algún intercambio de claves entre emisor y receptor. Por supuesto, esto no pasa en ningún momento en la escena, así que el cifrado de las comunicaciones lo hacen reguleramente.
Figura 4: El servidor envía un e-mail cifrado con un enlace
Además, hay dos momentos en los que habría que cifrar. El primero cuando se sube el fichero al servidor FTP para que no quedara una copia un-encrypted en el disco duro del FTP, y una segunda cuando se cifra el e-mail. Dos veces en los que se debería usar la clave de cifrado del destinatario, algo que no aparece por ningún sitio. Raro, raro.Deberían dar un repaso al libro de Criptografía y cifrado de las comunicaciones digitales.
- Free and Open Source: Genial. Eso significa que es Free and Open Source y por tanto, se supone que el código puede ser revisado por cualquiera para garantizar que no tiene bugs o puertas traseras - aunque luego pase como con TrueCrypt y toda la polvoreda de especulaciones que se levantó -. Ahora bien, eso tendría que comprobarlo el emisor en el cliente a la hora de cifrar y destinatario a la hora de descifrar, pero lo que haya en el servidor Web/FTP puede estar manipulado por cualquiera, así que está muy bien que lo pongan en la web de login, pero tiene poco sentido. Eso sí, da color.
- Metadata Protection: Esta es buena. Un hook a la memoria americana y el caso de las filtraciones de Edward Snowden con las políticas de Metadata Retention y el famoso PRISM que otorgaba a la NSA acceso a conexiones y llamadas de teléfono entre personas. En el caso del servidor FTP, se supone que ¿no guardan logs de conexión?
Está claro que aunque el servidor no guarde logs de conexión, por el medio hay muchos dispositivos de red que pueden guardar logs del proceso, por lo que lo suyo sería no fiarse y conectarse vía TOR de forma segura - y desde una conexión que no esté en tu casa mejor que mejor -.
Además, el servidor está bajo un dominio .NET, lo que implica que no está en un hidden service y está sujeto a una legislación que debe cumplir y que si no lo hace, puede ser intervenido. Vamos, que lo del anonimato en las conexiones está regulera también.
- Antispam & Blacklist filters: Esta parte la he tenido que tomar con mucha imaginación para darle algo de sentido. He querido ver que, como se envía un mensaje de correo electrónico con el enlace al fichero en el servidor FTP Super-Seguro, el servidor tenía medidas para garantizar que el mensaje de correo electrónico que se envía ¿se va a saltar los filtros antispam y las listas negras?
Figura 5: El fichero ha sido enviado con un link vía AES. Oh, tell it again!
Desde luego no diréis que no he hecho un ejercicio de imaginación para interpretar estas medidas de seguridad en un servidor FTP. Aún así, garantizar que el mensaje va a saltarse eso es muy complicado, ya os dejé un artículo que explicaba ¿por qué mi correo electrónico llega como spam? Además, que se use AES para recibir el enlace al fichero ¿significa que se utiliza AES en el cifrado e2e del correo?
- Multiples instances of server: Esta debe ser para evitar los ataques DDOS y ser resiliance ante intentos de eliminar el servicio de la red. Algo que si se basa en el nombre de dominio DNS no tiene mucho sentido para nada. Pero... vamos a jugar al pacto de ficción. Esto, además, será necesario para enviar el fichero desde 16 direcciones IP aleatorias para evitar que alguien en un man in the middle pueda recomponer el fichero cifrado. Rebuscado.
- Quick, encrypted set up: Configuración rápida y, eso sí, cifrada. Para que cuando te des de alta en tu cuenta gratuita todo vaya rápido, muy rápido y cifrado, muy cifrado.
Visto todo esto, al final como era de esperar nada más ver lo anterior, el malo de la NSA descubre inmediatamente quién ha enviado este correo con ese archivo - goodbye e2e encryption y anonimato-, y a la mañana siguiente van a por él para matarle. Eso sí, toma la precaución de ponerse el smartphone en el bolsillo del corazón que detiene la bala cuando es disparado como ya ha pasado en la realidad. Un hacker precavido siempre guarda el smartphone ahí.
Figura 8: Al final la tecnología salva la vida de Micro parando la bala
Dicho esto, Micro se supone que es un hacker experto, así que lo de utilizar este servidor FTP tan seguro vía una web en HTTPs es cuanto menos poco creíble. Menos aún que envíe un CD/DVD con el vídeo - ¡ni tan siquiera un pendrive! - o que no haya hecho un análisis de los metadatos del mp4 antes de enviarlo ¡hombre, será posible!.
[Spoiler Alert Ends Here]
Esto no es nada más que una curiosidad. La serie mola mucho. El protagonista lo hace tan bien como lo hizo en Walking Dead y en la segunda temporada de Daredevil. Me encanta. Eso sí, no la veas con niños menores a los que les gusten los superhéroes si no conoces bien a Frank Castle, porque la sangre y los asesinatos son un continuo.Ya sabéis, si quieres saber dónde está The Punisher, solo debes seguir el rastro de cadáveres. Recuerda, If you are guilty...
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
