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.
La Impresión 3D ofrece infinidad de posibilidades a la hora de diseñar y crear piezas de todo tipo y para toda clase de aplicaciones, con la llegada de nuevos materiales mas técnicos cada vez es más sencillo crear piezas cada vez mas funcionales y no solo prototipos. En el mundo Maker, nosotros hemos escrito mucho sobre cómo mezclar la Impresión 3D junto con proyectos de Raspberry Pi, Arduino, Micro:Bit o Drones, para hacer proyectos fantásticos. E incluso hay una ONG llamada Ayúdame 3D que se dedica a crear prótesis a personas utilizando 3DPrinting. Pero también tiene usos malos, como puede ser la fabricación de armas de fuego caseras.
Figura 1: Armas de fuego hechas con Impresión 3D: Riesgos y Peligros
Hace apenas unos días pudimos ver en los informativos un caso en el que la policía había desarticulado un taller clandestino ubicado en Tenerife que se dedicaba a la fabricación y tráfico de armas impresas en 3D. Este descubrimiento fue posible gracias a la detención de un simpatizante del movimiento supremacía blanca al que habían descubierto comprando componentes químicos para la fabricación de artefactos explosivos.
Durante la redada en el establecimiento donde el sujeto fabricaba las armas la policía encontró al menos 19 cuerpos de arma corta, varios cargadores y correderas sin número de serie además de algunos accesorios como silenciadores o visores holográficos. En el “taller de armas” también se encontraron varios manuales de guerrilla urbana y fabricación casera de explosivos. Por el momento no se sabe si este sujeto llegó a comercializar alguna de las armas fabricadas.
Figura 3: Cuerpo de pistola glock siendo impreso en una impresora Prusa
Este caso en particular se dio en el mes de septiembre, pero debido a la preocupación de las autoridades se ha mantenido en secreto hasta hace un par de semanas. La Policía Española no dudó en alertar de esta nueva amenaza a otras policías europeas y organismos internacionales como la Interpol o Europol con el fin de coordinar un grupo dedicado a la investigación de este tipo de organizaciones. Durante el próximo otoño España acogerá un congreso europeo sobre la fabricación de armas impresas en 3D para debatir cual es el riesgo real de este tipo de artefactos, como regular su fabricación y cuáles son los mejores métodos para combatir con esta amenaza.
Durante el congreso se harán una serie de demostraciones y pruebas, como la de la impresión de un arma, y la realización de pruebas con la misma en el campo de tiro de la Policía de Canillas. Es importante tener en cuenta que a pesar de que algunos de los diseños que se pueden encontrar en la red sean bastante seguros una mala configuración a la hora de imprimirlo puede suponer un gran riesgo para la integridad estructural del arma pudiendo llegar a herir gravemente a la persona que la utiliza.
Figura 4: Policía desmantela taller clandestino de armas.
Esta no ha sido la primera vez que se ha dado un caso parecido en Europa, hace 3 años un ataque con armas impresas en 3D dejó dos víctimas mortales en una sinagoga de Halle en Alemania. El autor del tiroteo había adquirido una impresora 3D unos meses antes de cometer el atentado y llegó a ensamblar hasta 5 armas completas. Por suerte para el resto de personas que se encontraban en la sinagoga las armas impresas por el sujeto no eran del todo fiables y se encasquillaron en varias ocasiones haciendo que no hubiese más víctimas mortales.
El diseño e impresión de armas con impresoras 3D es una práctica mas habitual de lo que creemos, sobre todo en Estados Unidos, donde hace aproximadamente una década se vio por primera vez la “Liberator”, una pistola capaz de disparar seis veces seguidas y cuyo diseño fue retirado de Internet por las agencias de inteligencia estadounidense en cuanto se supo de su existencia, pero que se puede encontrar en muchos rincones de la DeepWeb.
La Liberator solo necesita una pieza metálica, el percutor, y es totalmente adaptable para utilizarse con munición de distintos calibres. Durante esta década la Impresión 3D ha avanzado a pasos agigantados y ha hecho que hoy en día prácticamente cualquiera pueda acceder a una impresora 3D por menos de 200 € haciendo más fácil que cualquier ciudadano u organización criminal pueda fabricar sus propias armas desde casa.
Otro de los problemas para la policía es detectar este tipo de talleres clandestinos ya que al contrario que los laboratorios o plantaciones de droga el consumo energético de una granja de impresoras 3D no es muy elevado y los materiales necesarios para fabricar este tipo de armamento se puede obtener legalmente y sin llamar la atención.
Figura 6: Pistola Liberator impresa en 3D completamente irrastreable.
En Estados Unidos ya existen leyes que regulan la producción y distribución de este tipo de artefactos, de hecho, allí es totalmente legal que cualquier ciudadano pueda fabricarse un arma en casa, con lo que todos los controles que se realizan en las armerías dejan de ser eficaces, en la única situación en la que se requeriría una licencia especial sería si queremos realizar producción en serie.
Cody Wilson, el creador de la Liberator, que en 2012 fue designado como una de las 15 personas más peligrosas del mundo por la revista Wired, también es el fundador de Defense Distributed, una organización que se dedica al desarrollo y publicación de diseños de armas de fuego de manera gratuita con el fin de que puedan replicarse utilizando impresoras 3D. En 2013 tras hacer público el diseño de la Liberator, Cody aseguró en una entrevista que a pesar de que Estados Unidos sea uno de los países con una legislación muy permisiva para las armas, España había sido el país en el que más veces se había descargado su archivo.
Figura 7: Defcad, el mayor repositorio del mundo dedicado a la impresión de armas 3d.
Antes de fundar su empresa, Cody era un estudiante de segundo curso de derecho en la Universidad de Texas, y a través de Crowdfounding,Wilson logró recaudar más de 20.000 USD con los que pretendía alquilar una impresora 3D de la empresa Stratasys. Tras conocer las intenciones de Defense Distributred Stratasys rescindió el contrato por considerar la fabricación de armas de fuego un acto ilícito. Esto no freno a Cody, que no dudó en acudir a la ATF para informarse acerca de la legislación y regulaciones existentes relacionadas con la fabricación casera de armas. Antes de poner en marcha su proyecto se aseguró de conseguir una Licencia Federal de Armas de Fuego que le permitiese diseñar, fabricar y distribuir sus propios componentes.
Figura 8: Ghost Gunner y algunos de los Starter Packs ofrecidos por DD.
Durante los últimos años Defense Distributed ha diseñado y compartido numerosos archivos para la fabricación de armas de todo tipo, desde pistolas hasta el mecanismo mas resistente impreso en 3D para AR-15 o cargadores para armas como el AR-15 y el AK-47. De hecho, también ha desarrollado su propia máquina CNC y un software propio (Ghost Gunner) con el que optimizar la fabricación de piezas de armamento caseras. En su página web también vende algunas de sus piezas (en formato físico) o kits para principiantes. La empresa de Cody también es la responsable de Defcad, el mayor repositorio del mundo de armas y partes impresas en 3D.
En 2018 un juez de Washington prohibió a Defense Distributed la publicación de sus planos alegando que podían provocar “daños irreparables”. Tras estudiarse de nuevo la legislación acerca de la fabricación y distribución de armas caseras, Cody Wilson ha reabierto su sitio web para que todos aquellos ciudadanos estadounidenses que quieran tengan acceso a estos archivos. La estrategia utilizada para reactivar el sitio web ha sido muy sencilla ya que la justicia ordenó cerrar el sitio web por “distribuir planos de armas de fuego gratuitamente” por lo tanto la orden solo prohíbe la distribución gratuita de los planos, pero no la comercialización de los mismos.
Figura 9: Algunos de los últimos modelos de piezas y armas añadidos tras la vuelta de Defcad.
Con este movimiento, Defense Distributed ha reactivado su página web y ofrece una suscripción anual por 50 USD (únicamente para los residentes en EEUU) con la que se da acceso a lo que su fundador ha denominado “El Netflix de las armas”, donde hay videos, tutoriales e instrucciones para construir cualquier tipo de arma, desde pistolas hasta fusiles automáticos o escopetas, todos ellos sin numero de serie y capaces de pasar por los arcos de seguridad de un aeropuerto sin hacer saltar la alarma. Con esta jugada DD también ha conseguido una gran notoriedad e impulso mediático que llevó a la empresa a recaudar casi 250.000 USD en donaciones solo en la primera semana desde la reapertura del sitio web.
A pesar de que Defcad siga activo, algunos legisladores estadounidenses todavía no se dan por vencido y ahora se acogen a la Ley de Armas de Fuego Indetectables que prohíbe expresamente la fabricación, posesión y venta de armas que no activen detectores de metales. A pesar de que con esta ley se busque frenar la impresión de armas en 3D no existe ninguna otra ley que regule el diseño o la distribución de los planos de las mismas, por lo tanto, a falta de una prohibición directa o una ley que establezca que tipo de contenidos pueden publicarse en la red Defcad no tendrá ninguna traba para continuar ofreciendo su nuevo programa de suscripciones anuales.
Saludos,
Autor: Sergio Sancho, Security Researcher en Ideas Locas.
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.
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 
