General

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.
Standard
General

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.

Standard
General

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:

Standard
General

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.

Standard
General

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.

Standard
General

Privacidad y seguridad en redes públicas: Barcamp Guayaquil

Desde 2002 he tenido la oportunidad de asistir como participante, como ponente y como organizador a decenas de eventos tecnológicos, desde Argentina hasta la India. Una característica de estos eventos es que, para mantener a los geeks con vida, suele haber una oferta muy buena de acceso a Inteet en la forma de una red alámbrica o inalámbrica. Aquí explico por qué esto es un falso amigo.

La semana pasada estuve en Guayaquil asistiendo al Barcamp que se hizo en la Perla del Pacífico. El evento fue hospedado por la FIEC de la ESPOL, en unas instalaciones que ya conocía por haber participado en el FLISOL 2009 como patrocinante. Llegué al evento muy temprano, cuando aun no habían llegado muchos de los organizadores y prácticamente ningún participante. A través de Twitter hice una recomendación a los participantes que iban al evento: cifren su tráfico.

Sé que es llover sobre mojado, pero definitivamente el acceso a Inteet, o en general a redes de trabajo para computadores en este tipo de eventos, es un falso amigo. La mayoría de la gente considera que por tratarse de un evento de perfil tecnológico, la red de trabajo será algún tipo de panacea técnica de la privacidad y la seguridad, y en la mayoría de casos no es así, y se deberían continuar tomando las mismas medidas que un usuario o usuaria toma en escenarios hostiles.

Desde muy temprano en la mañana, la red inalámbrica de la FIEC, servida a través de varios puntos inalámbricos con dos ESSIDs diferentes y sin cifrado, estaba replicando paquetes a todas las estaciones. La FIEC utiliza un portal captivo de Cisco y esto genera en los usuarios y usuarias, y probablemente en los administradores de la red y de la Universidad una falsa sensación de invulnerabilidad ante escenarios muy simples de violación de la privacidad y seguridad de los usuarios y usuarias.

La utilización de cifrado de punto a punto (por ejemplo a través de una VPN), verificaciones estrictas de identidades en los extremos de una conexión SSL/TLS y/o cifrado peer-to-peer de comunicaciones, por ejemplo con GnuPG, hubiera minimizado el impacto individual y colectivo de esta situación. Y, adicionalmente, considero que muchas de estas tecnologías ya están muy desarrolladas como para centrarse en el triángulo de la seguridad vs. costos vs. usabilidad — para mayor información en este tema, el lector o lectora puede referirse a mi artículo Digital signature and personal mail encryption: an S/MIME and PGP review in real-life scenarios publicado en Security Acts de Agosto 2010.

Dentro del tráfico que fue posible interceptar con el objeto exclusivo de generar estadísticas y conclusiones para aumentar la sensibilidad de los usuarios y usuarias de la red del Barcamp Guayaquil y de otros eventos en Ecuador y la región, fue posible interceptar navegación Web no cifrada y especialmente tráfico de clientes Twitter (al parecer, este evento recopila demasiadxs twitters) que divulgaban desde Direct Messages hasta listas de contactos. También fue posible percibir el flujo de cantidades muy importantes de imágenes, específicamente avatares, imágenes de perfiles de Facebook, entre otros.

Una pequeña muestra tomada en 7 minutos y 53 segundos, desde las 1420 ECT del 31/07/2010, permitió obtener 97310 paquetes con un tráfico promedio de 1,355 Mbps, para un total de 80 MB. de tráfico. De este total, 98,41% de los paquetes son de protocolo IP y de esto solo 1,63% son de protocolo UDP (DNS y NTP) con un abrumador índice de 12,84 más tráfico sin cifrar que tráfico cifrado, del cual hubo escasos 3 Mb. bajo TLS/SSL.

En otra muestra un poco más grande, que cubrió 1 hora y 12 minutos desde las 0855 ECT, se obtuvieron 350716 paquetes con un tráfico promedio de 0,422 Mbps (todavía no había llegado la gente) donde se observan los mismos patrones de uso. En otra captura, la más grande, que cubrió 1 hora 46 minutos, desde las 1018 ECT, se percibió 1 MB. en archivos GIF y 2.76 MB. en archivos JPEG, así como adjuntos de mensajería electrónica, archivos XML con parámetros de configuración de clientes de Twitter y otros temas. Todas las muestras fueron destruídas luego de la obtención de estas estadísticas de uso y de la misma manera se exceptuó de las capturas información que permitiera correlacionar estas capturas con personas particulares.

Todo esto se hizo para una población variable que promedió 82 dispositivos en una de las dos redes, que, por cierto, usa direccionamiento IPv4 para sus clientes, lo cual es sinceramente un malgasto de recursos, que incluía 2 iPod/iPhone, 3 Nokia, 2 Blackberry, 47 equipos con Windows, 7 con MacOS X y 3 con Linux.

Es importante resaltar que toda esta información estaba disponible sin ninguna restricción debido a la falta de configuración en los equipos inalámbricos y redes conexas utilizadas en el evento. De la misma forma de que yo me percaté, lo pudo haber hecho cualquier otra persona, incluyendo potencialmente gente simplemente ociosa que hubiera podido generar daños gracias simplemente a la disponibilidad de esta información.

Lamentablemente, en mi experiencia, es futil arrojar la culpa a los administradores de la red solamente. Si bien ellos pueden encontrarse responsables del asunto, el enfoque de privacidad y seguridad en redes públicas debe ser proactivo y no solamente reactivo. En este sentido, el uso de tecnologías por parte del emisor y del receptor para facilitar los mecanismos que permitan incrementar la percepción de seguridad a la vez que se reducen tangiblemente los vectores de ataque es una de las medidas que es importante promover entre los usuarios y usuarias.

Hay distintos foros en Ecuador para apoyar sin fines de lucro a los usuarios y usuarias en el tema de seguridad de la información; uno de los más específicos era COMSec (seguridad.com.ec/hackers.ec) que ahora está offline, pero existen otros espacios, desde Twitter (hashtag #Ecuador) hasta listas de correo como Equinux o foros de grupos de interés. Yo estoy como siempre a la orden para aquellxs que quieran dar el primer paso para formar una cultura de seguridad de la información en su quehacer tecnológico diario.

Update: estamos en proceso de traducir la Cartilla de Seguridad del CERT.br al castellano con el apoyo del Grupo de Seguridad de LACNIC, ISOC Ecuador y voluntarios de la región.

Standard
General

Participación ciudadana en VenCERT

VenCERT es un organismo gubeamental bastante joven encargado de la atención proactiva, preventiva y reactiva de incidentes de seguridad que afecten, principalmente, a la operación de la Administración Pública Nacional (lo cual incluye al ISP más grande de Venezuela), aunque tienen en el horizonte ampliar el enfoque a mediano plazo a la Academia, sector privado y ciudadanía.

En 2008, cuando todavía se estaban organizando, incluso un año antes de que fueran aceptados en FIRST, empecé a apoyarlos como ciudadano preocupado por la seguridad de la información. Hoy en día dedico un par de horas cada dos semanas a evaluar incidentes de seguridad reportados por mis clientes, terceras personas o que vivo como usuario final, y canalizarlos a VenCERT y otros organismos competentes.

He trabajado con VenCERT en siete incidentes, principalmente de phishing orientados a organizaciones públicas y privadas en Venezuela, aunque también -y como muestra de lo relevante que es el ecosistema venezolano en el submundo del negocio de la inseguridad electrónica- en vulnerabilidades de sistemas críticos como el Módulo de Notificación de Viajes de CADIVI.

El último caso que estamos revisando es de un grupo de atacantes en Brasil que usó una página en Austria para enviar una campaña vía Alemania que hace que la gente pase por Polonia, usando un proxy que instalaron gracias a un Roundcube comprometido, para descargar finalmente el malware, siendo lo más interesante que cosechan direcciones de la base de datos del RNC y proveedores de PDVSA.

Mi política independiente de atención de estos incidentes es plenamente informativa e investigativa por no encontrarme relacionado formalmente con ningún CERT en el mundo, ni con ningún equipo de trabajo de Abuso y/o Seguridad de un ISP o alguna organización afectada. En muchos casos no tengo tiempo para desensamblar malware y/o ejecutar sandboxes para identificar patrones de comando y control.

Aunado a eso, estoy bastante seguro de que atender mis correos y follow-ups llega a ocupar gran parte de la paciencia y del tiempo de la gente del VenCERT, que en muchas ocasiones podría no tener mayor apoyo y remitirse a escalar el caso a otra parte. En dos ocasiones se han podido ralentizar campañas gracias a la acción de los dueños de los bloques de IPs o los dominios, pero no necesariamente de VenCERT. Y si, como profesionales y ciudadanos, podemos hacer algo para apoyar a VenCERT en estas situaciones, será un gusto seguirlo haciendo.

Quizás el ejemplo más reciente es el de Carlos Guerrero, a quien vi por allí avisándole a sus contactos de una popular campaña de phishing, explicando muy didácticamente el asunto. En el otro extremo del espectro -ambos se necesitan- si hay alguien allá afuera que desensamble malware y pueda aportar a organizaciones como Shadowserver información que lleve a desmantelar organizaciones delictivas asociadas con estas incidencias, creo que sería muy bienvenido en la comunidad. Véalo desde un punto de vista patriótico -si usted cree en eso-, también puede ofrecerse al CICPC en Venezuela, a la Policía Nacional en Ecuador, a la Guardia Civil en España. Hay muchos casos allí afuera (hola: elsanto, apostols et al.) y no es tan idealista como suena.

¡Apoyemos el trabajo del CERT!

Standard