Blog Archives

Crowdsourced CSIRT en LACSEC

Hoy presenté el concepto del CCSIRT en el marco de LACSEC 2012. En el enlace está la presentación, el código, el paper y las bases conceptuales, y obviamente el sistema que ya está funcionando.

Al final de la presentación, la SUPERTEL me entrevistó para saber más sobre crowdsourcing y la importancia de los CERTs/CSIRTs en la región y colgaron el video en YouTube.

Quiero agradecer a Feando Gont, chair de LACSEC, y al Comité de Evaluación de Trabajos de LACSEC por haber aceptado la presentación y al público por su fenomenal participación, estoy muy honrado de haber podido participar en este evento como ponente en mi primera asistencia.

Hacking WhatsApp for fun and profit

A estas alturas ya debes haber escuchado que WhatsApp es inseguro. El popular sistema de mensajería entre plataformas transmite números de teléfonos y mensajes en texto plano a través de, aparentemente, una versión codificada de XMPP sobre el puerto TCP 443.

Lo que seguramente no te han contado es de que te sirve eso, y por qué debería importarte. En primer lugar, sirve para que hackers de todo el mundo le hagan ingeniería reversa al protocolo de WhatsApp, existiendo proyectos que dicen tener la API completa y estar trabajando en una aplicación de escritorio, una Web, un plugin para Chrome… situación que, asumo, será un poco conflictiva.

En la práctica, significa que cuando utilizas WhatsApp conectado a una red que no está bajo tu control, por ejemplo una red Wi-Fi en un café o en un restaurant, o en tu centro educativo, estás exponiendo todas tus conversaciones, contactos y multimedia que compartes por WhatsApp a cualquier persona que tenga los motivos para querer esa información.

Solo se necesita lanzar un ataque de ARP spoofing (con arpspoof de dsniff, ettercap et al.) para que el atacante pueda hacer que todo el tráfico de tu smartphone pase por su equipo, donde puede estar capturando paquetes con wireshark, tcpdump y otros. Ya existe un sniffer para WhatsApp, pero a alguien se le ocurrió la genial idea de subirlo a Megaupload, que ahora está cerrado. En todo caso no se necesita sniffer, como explico ahora.

Tu WhatsApp se contacta con la matriz a través de la dirección bin-short.whatsapp.net que básicamente se sirve por DNS round robin a 12 direcciones IPv4, 10 en Texas y 2 en Califoia. Tu equipo enviará un mensaje saludando, informando la versión del cliente, el sistema operativo del teléfono, las capacidades de cifrado con las que cuenta, tu número de teléfono, tu nombre, y algunas cosas más.

Pro Tip: puedes trollear bloqueando la resolución de DNS de esa dirección en tu red

Las imágenes se pasan en Base64 (el thumbnail) junto con una URI que, esta sí, cifra sobre HTTPS. Hay una granja de servidores (mmsXXX, 18 servidores según mis cálculos) que utilizan una estructura de directorios (p.ej., /d3/22/15/8/7) para almacenar multimedia y luego un hash MD5 como nombre de archivo.

Descubrir como arman esta URI es interesante, pero innecesario, porque igual pasan la URL por texto plano y no implementan control de acceso para servir el contenido. Un ejemplo aquí (note la URL)

Como nota curiosa, parecen usar lighttpd sobre FreeBSD para esta granja, específicamente una versión que podría ser susceptible a un ataque de DoS aunque personalmente no creo que lo sea, además de poder mitigar el riesgo con otros 17 servidores. Pero siempre es divertido averiguarlo.

Las otras posibles derivaciones de esto, como por ejemplo, que se hagan pasar por ti para enviar mensajes en la red, están un poco inmaduras aun. Al usar un challenge SASL MD5, debe haber una clave (tú no le pusiste una clave a tu cuenta de WA), que aunque según algunos es simplemente “password”, al parecer se calcula usando valores UUID que están en el teléfono, y un algoritmo propio del cliente, para identificarse por XMPP. En s.whatsapp.net tienes un CNAME a im101 (intenté buscar más, sin éxito) que aunque no responde por XMPP es el nombre del realm. Enjoy. Y no uses WhatsApp en redes Wi-Fi públicas, por ahora.

Puntero Nulo – Episodio 5

Escúchalo:: PunteroNulo-Episodio5

La semana pasada me dijeron que el podcast era demasiado técnico. Gracias, aunque siempre intento digerir las noticias de tecnología algunos días después de que estén de moda (para no caer en la agenda) y de una forma que sea comprensible para la mayoría de la audiencia técnica.

Como siempre, sus comentarios y sugerencias son siempre bienvenidos en el correo j en bureado.com y en Twitter, @bureado.

De facto, el podcast ha estado saliendo quincenal así que mejor no engañaos. A continuación las fuentes de este episodio:

Enabling 6to4 with FireHOL

I use FireHOL as my iptables helper. FireHOL has proven very effective in managing complex set of rules, including multiple interfaces and protocols, “strong” protection against several types of attacks, and other stuff that would take me a huge amount of time to take care of. And, when it comes to security, analysis time is paralysis time.

However, FireHOL isn’t particularly aware of IPv6, rest alone tunneling techniques, such as Teredo or 6to4. 6to4 does encapsulate IPv6 traffic on top of IPv4 traffic to an anycast address (in most scenarios) and iptables does support protocol filtering using numeric code 41 which equals to ‘ipv6′.

A solution: create a new interface with matching rules to proto 41, and then set your restrictions accordingly:

interface eth0 6tunnel proto 41        # Example policy        policy accept        server all accept        client all accept

If you’re not using FireHOL, and rather some homebrew iptables script, you could always use -p 41

6to4 is a very effective way to start using IPv6 if you have an static, globally routeable IPv4 address. ifupdown provides a very elegant way of managing it, which is documented in Debian’s wiki.

SOCKSificando aplicaciones en Linux

SOCKS5 es un protocolo de la IETF que fue aprobado en el año 1996, escasamente después de que yo empezara a usar Inteet. El objetivo de SOCKS es enrutar las conexiones de un cliente a un servidor utilizando un proxy SOCKS como intermediario, muy similar a un proxy HTTP (como Squid, por ejemplo) pero con la peculiaridad de que puede enrutar varios tipos de tráfico, no solamente el habitualmente relacionado con la Web.

Por ejemplo, a partir de SOCKS4a, se pueden enrutar las resoluciones de nombres de dominio (DNS) y es normal conseguir implementaciones de SOCKS donde se enruten todas las conexiones TCP y UDP posibles. A pesar de ser un estándar abierto, SOCKS se hizo más popular en plataformas de Microsoft, antes de que los administradores de sistemas empezaran a considerar otros mecanismos como VPNs, túneles y proxies en capa de aplicación para resolver estos problemas, soluciones que son más populares en sistemas Unix.

Recientemente utilicé Dante para conectar mis equipos Linux a un servidor SOCKS5, así que aquí resumo mi experiencia:

  • These are not the droids you’re looking for: en primer lugar verifique si el problema puede ser resuelto con cualquier otro método más accesible para usted en su sistema Linux; por ejemplo, si quiere permitir el acceso a HTTP y FTP desde su red corporativa, use un proxy HTTP como Squid; si quiere hacer un túnel seguro para sus conexiones cuando esté en redes públicas, use una VPN como OpenVPN, o Tor si su preocupación es el anonimato.
  • Soporte nativo: varias aplicaciones en Linux ya tienen soporte nativo para SOCKS, en particular SOCKS5, por ejemplo Firefox, Curl y OpenSSH. Aprovecho aquí para remitir al lector al contenido preparado por Rafael Bonifaz, en el que se explica como usar un proxy SOCKS con SSH.
  • Verifique que dante-client esté disponible en su distribución: en Debian necesitará utilizar squeeze o sid para obtener dante-client, de otra forma, tendrá que compilarlo obteniendo el código fuente de la página Web de sus creadores
  • Use socksify: dante-client provee la aplicación socksify, que en realidad es un shell script que hace uso del omnipresente y omnipotente LD_PRELOAD para precargar las librerías de Dante que “engañan” a las aplicaciones cuando intentan usar la red para que usen SOCKS. También puede usar la variable LD_PRELOAD en sus scripts de arranque, efectivamente socksificando todo su sistema operativo, operación que no recomiendo porque en un sistema Linux modeo se necesita hacer uso de ICMP y otros protocolos que no conviene o no se pueden socksificar.
  • Configure Dante: la configuración de Dante está documentada en el sitio Web de sus creadores, y básicamente se remite a preparar un archivo de configuración /etc/socks.conf o como su distribución lo nombre. Para ello mis recomendaciones son 1) haga una ruta directa a su proxy en caso de que la dirección IP no pertenezca a su misma subred (Dante hará rutas directas para cualquier intento de conexión a IPs en la misma subred) y 2) provea y utilice un servicio de DNS forwarding, con caché opcional, dentro de su red. La razón de esto es que a pesar de que SOCKS4a y SOCKS5 pueden enrutar las solicitudes de resolución por SOCKS, no todos los servidores SOCKS pueden hacer esto de forma correcta, así que es mejor que su servidor DHCP sirva una dirección de servidor de nombres que sea útil dentro de su red. Le ahorrará dolores de cabeza. Con esto, un archivo de configuración puede ser tan sencillo como:
route {                                                                                from: 0.0.0.0/0 to: 0.0.0.0/0 via: [IP/hostname del proxy] port = 1080        proxyprotocol: socks_v5        method: none}

Disfrute su Linux socksificado.

Follow

Get every new post delivered to your Inbox.

Join 1,929 other followers