Yet another APT1 analysis (y posibles contramedidas)

Sin duda el informe sobre APT1 de Mandiant es el tema de moda, lo más comentado tanto en círculos profesionales como entre gente de la calle. Seguramente llego tarde a hacer mi pequeña aportación a este tema, porque ya ha habido mucha gente que ha escrito sus opiniones e incluso que han publicado sus soluciones, pero aquí va mi granito de arena.

Hablando de posibles soluciones con gente ha surgido un tema importante. Yo parto de la base que el que se desea proteger de APT1 es una empresa grande, con infraestructura y con medios. Si una empresa quiere protegerse de estos ataques y no tiene la infraestructura para ello, una de dos, o lo que protegen no tiene ningún valor, o están tomando muy malas decisiones en materia de seguridad,

Otra cosa que asumo es que lo que queremos es aprender de lo ocurrido. En el proceso de gestión de incidentes existe una última fase que se llama "lecciones aprendidas", en la que se pretende analizar el incidente y tomar medidas para que ni este, NI SIMILARES vuelvan a ocurrir. Bloquear los nombres DNS o certificados SSL de un APT tiene una utilidad relativa, ya que en cuanto hayan visto que empezaban a perder el control de servidores comprometidos habrán empezado a registrar otros nombres y certificados, que seguramente son los que estarán usando en este momento, así que hay que ampliar un poco la visión e intentar aplicar medidas de protección que puedan ayudarnos también en el futuro. Por poner un ejemplo práctico, si nos infectan porque no hemos aplicado el parche para MS12-1234, de poco sirve que instalemos este parche, porque el atacante mañana utilizará un exploit que aproveche la ausencia del parche MS12-1235. Es mejor ver con perspectiv que ha ocurrido y establecer un mecanismos para que todos los parches sean aplicados a la mayor brevedad posible.

Dicho esto, vamos al lio:

Nombres DNS utilizados

En el Apéndice D del informe de Mandiant tenemos una lista de un montón de dominios que han sido utilizados por el malware que ha sido detectado. Una manera de protegernos es, sin duda, evitar que estos nombres sean resueltos. Ha habido propuestas, como por ejemplo la de Snortby Labs, que consisten en crear reglas de Snort para detectar la resolución de los nombres de dominio utilizados por el malware. En mi opinión, esta aproximación tiene algunos riesgos debido a la cantidad de reglas que hay que crear (2046). Hace años que no trabajo diariamente con IDSs, pero el tema del rendimiento en sistemas de detección de intrusos sobre redes con gran cantidad de tráfico siempre ha sido un problema, ya que corres el riesgo de perder paquetes por no ser capaz de procesarlos, y por lo tanto perder capacidad de detección. En este caso, crear 2046 reglas para esta amenaza, y otras tantas para otra, y otras tantas para otra, puede hacer que el rendimiento de nuestro IDS se vaya a hacer gargaras, y que perdamos parcialmente su utilidad.

En mi opinión, la mejor solución para este caso es usar un DNS Sinkhole/Blackhole (lo oigo con los dos nombres), que no es más que un servidor DNS que impide la resolución de los nombres de dominios presentes en una lista negra. Este es un sistema especialmente pensado para esto, para bloquear nombres de dominio maliciosos, y es lo que mejor rendimiento nos va a dar. Además tiene varias ventajas sobre el uso de Snort: La primera de ellas que que protege automáticamente toda la red, no solamente los puntos en los que hemos colocado un IDS, y en segundo lugar es que bloquea los accesos, no solo los detecta (si el Snort está "inline" también podría, pero en ese caso su sobrecarga sería mucho más peligrosa).

En el caso de que no dispongas un DNS Sinkhole... ¿a que esperas?! Es sencillo de desplegar, depende del servidor DNS interno que estés utilizando quizá no tengas ni que añadir otra máquina. El el peor de los casos, puedes mantener toda tu infraestructura, y hacer que tu DNS interno resuelva, en lugar de al servidor DNS de tu ISP, contra el DNS Sinkhole, y este contra internet.

Certificados SSL

En el Apéndice F del informe se muestran una serie de certificados autofirmados que emplean las diferentes familias de malware utilizadas para realizar las conexiones. Esta ha sido la aproximación que han tomado otros como por ejemplo SourceFire, los "papis" de Snort. 

Los creadores de malware usan conexiones SSL para que los analistas o detectores de intrusos no puedan encontrar patrones, pero... ¿no es el uso de un certificado auto-firmado algo sospechoso en si mismo? Creando una regla de IDS que detectara cuando un usuario (o un servidor!) está conectando por SSL a un lugar de remoto con un certificado auto-firmado podríamos detectar estas y otras muchas amenazas futuras ¿Peligros? El exceso de falsos positivos, ya que, queramos o no, hay muchos sitios legítimos que emplean certificados auto-firmados. En cualquier caso, siempre se puede aplicar sobre esta regla un poco de correlación. Si un PC de usuario accede a una web con un certificado SSL auto-firmado, quizá no es muy sospechoso, pero si lo hace de forma repetitiva igual sí que puede servir como señal del compromiso del equipo.

Otra cosa que suelen hacer los atacantes es emplear certificados que están firmados por una CA de confianza, aunque según creo esto es menos común. Hay CAs que te hacen un certificado SSL para tu dominio de forma gratuita, válida tan solo para unas semanas o pocos meses, para que lo pruebes ¿Cómo hacemos entonces para detectar esto? Es sin duda más complicado, pero se podría detectar a través de la fecha de inicio y fin de validez del certificado. Si ambos son en el mismo año, por ejemplo... es probable que se trate de un certificado temporal, lo cual también es sospechoso.

HTTP en puerto 443

Otras de las cosas curiosas que he visto en el Apéndice C del informe, donde se detallan cada una de las familias de malware y como actúan, es que algunas de ellas emplean HTTP sin SSL a través del puerto 443, algo que es raro raro raro en una conexión legítima, pero que puede ser usado por atacantes para evitar las reglas de detección. Si solo el puerto 80 y 443 están permitidos de salida (lo habitual), es posible que los administradores de seguridad configuren la detección únicamente para el puerto 80, asumiendo que en el puerto 443 "no van a ver nada".

El caso es que, si vemos signos de HTTP (GET, POST, HTTP/1., etc) en el puerto 443, no creo que sea nada bueno, así que tampoco estaría de más una regla de IDS para detectar esto, o en el proxy corporativo si lo usamos. Hay diferentes alternativas de donde podríamos aplicar esta detección.

User agent de navegadores

Algo que se repite constantemente en todo el Apéndice C del informe es el uso de User-Agent de navegadores específicos. Podríamos bloquear estos User-Agent en un IPS o Proxy, pero ocurre lo mismo que con los nombres DNS: mañana el creador del malware nos cambia una coma y ya la hemos fastidiado, además de que muchos de ellos son User-Agent idénticos a los que usan navegadores legítimos.

Si somos una empresa grande, seguramente nuestros equipos estarán construidos sobre una maqueta, así que sabemos exactamente que navegadores están autorizados a existir en nuestra empresa. Si esto lo tenemos así, podemos optar por la aproximación contraria, establecer reglas en el IDS o Proxy para que se generen alarmas cuando un navegador con User-Agent diferente a los autorizados intente navegar. Esto puede ayudarnos a detectar malware y, además, violaciones de la política por parte de nuestros usuarios. No es una medida infalible, pero obliga al atacante a hacer un ataque muy dirigido.

Firmas específicas por familia

Esta medida es similar a la de configurar los nombres de dominios maliciosos en un Sinkhole, ya que es totalmente reactiva, es decir, nos protege de lo que ya conocemos, pero no de ataques similares en el futuro.

En el Apéndice C del informe, cuando se habla de cada una de las familias, hay un apartado llamado "Network based signatures" que nos da unas pistas de como podríamos detectar este malware en la red. Alguna veces hace referencia a técnicas como las que hemos visto antes, y otras veces son aspectos especifico como por ejemplo que aparezca una cadena concreta que es característica de la comunicación con este malware. Si este apartado no os da una respuesta que os guste mucho, leed con detalle el resto de la descripción, porque yo he visto que hay varios casos en los que se puede hacer algo más en la red de lo que pone en este apartado. Algunas otra veces me doy cuenta que no se proporciona mucho detalle, con lo que vais a tener que recurrir al especimen original.

Conexiones TCP "de toda la vida"

He visto solo un caso en todo el informe de malware que empleaba una conexión TCP en lugar de conexiones HTTP. Esto hoy en día es menos común ya que existe un control del tráfico de salida (o al menos debería existir). Si en tu empresa no controlas el tráfico de salida de los usuarios y servidores, quizá es un buen momento para que te emplees en empezar a hacerlo, así te evitarás este y otros riesgos "tradicionales".

Canales cubiertos encubiertos (gracias @mgesteiro por la corrección)

Por último, he visto en el mismo Apéndice C que también se han utilizado canales cubiertos encubiertos a través de servicios bien conocidos y ampliamente utilizados, principalmente servicios de Google (Calendar, GTalk y Docs) y Microsoft (Messenger). Sin duda, el uso de canales cubiertos encubiertos es órdenes de magnitud más complejo que el de canales "normales", ya que conectan a un dominio conocido y de buena reputación, a través de SSL con un certificado perfectamente legítimo, así que las opciones de detección son mucho más reducidas, a no ser que directamente prohibamos estos servicios en nuestra red, algo que muchas veces no es posible.

El año pasado publiqué en el SANS Institute un paper sobre canales cubiertos encubiertos en redes sociales que podéis ver AQUÍ o que podéis verme contando en las SOURCE Conferences AQUÍ (también dí la charla en GSIC en La Coruña). Tenía prevista una serie de posts contándolo que al final por lo que veo se me pasaron poner. En las próximas semanas los pondré, ya que viene al hilo del tema.