Hace unas pocas semanas comentaba en un post sobre el informe de Mandiant sobre APT1 el tema de los Canales Encubiertos. Buscando los enlaces en el propio blog sobre el trabajo "Covert Channels over Social Networks" que publique con el SANS Institute y que comenté tanto en las conferencias SOURCE como en las GSIC, me di cuenta que nunca llegué a publicar en el blog una serie de posts que tenía previstos sobre este tema, pero... más vale tarde que nunca ¿no?
El concepto de "Canales Encubiertos" está muy ligado a la Esteganografía, que significa "escritura oculta". Como muchos de vosotros sabréis, la esteganografía sigue una filosofía distinta al cifrado. El cifrado pretende hacer un mensaje indescifrable para cualquier persona que no sea el receptor del mismo, pero no pretende oculta la existencia de dicho mensaje. La esteganografía, sin embargo, consiste precisamente en la ocultación de un mensaje dentro de un contexto, de tal forma que nadie salvo el receptor se percate ni tan siquiera de su existencia. La forma más típica de esteganografía la hemos encontrado en imagenes, donde por ejemplo podemos substituir los bits menos significativos de cada uno de los puntos de la imagen de tal forma que contengan un mensaje oculto. Al estar modificando los bits menos significativos, la alteración de la imagen es mínima, y por lo tanto es sencillo que nadie se percate de las modificaciones realizadas sobre ella.
Los canales encubiertos aplican este mismo concepto pero en comunicaciones de red, para ocultar transmisiones realizadas por puertas traseras u otros tipos de software similares. Uno de los ejemplos típicos de canales encubiertos era la ocultación de información a través del IPID que se emplea en TCP/IP como identificador único de un paquete en el caso de que se produzca fragmentación de paquetes, pero que no se utiliza para nada en caso de que no se produzca.
La primera columna son IPID's tomados de una captura real de tráfico web con un navegador, mientras que la segunda contiene un canal encubierto con la secuencia "cat /etc/passwd" ¿lo veis? Como podéis imaginar, no resulta fácil de detectar, ya que es necesario hacer estudios estadísticos para determinar si una secuencia es aleatoria o si sigue algún patrón no aleatorio, que podría significar la existencia de un canal encubierto.
Los proxies, NAT y otros mecanismos son de mucha utilidad para neutralizar algunos tipos de canales cubiertos, especialmente aquellos en los que la conexión termina en la frontera y es iniciada una nueva, como es el caso de los proxies. Por ello los atacantes están empleando cada vez más canales de comunicación basados en protocolo HTTP, ya que este es uno de los pocos que habitualmente están permitidos en cualquier organización. Como medida de ocultación, suelen utilizar conexiones HTTPS que impiden la inspección de los paquetes por parte de los detectores de intrusos.
Pero ¿a que servicios HTTP se conectan? Generalmente a servidores comprometidos o alquilados en diferentes lugares del mundo, que les sirven de Command & Control (C&C). Esto hace que los especialistas en seguridad hayan desarrollado listas de negras y de reputación de direcciones IP, redes y nombres de dominio, que sirven para identificar estas conexiones anómalas.
¿Y si el destino de estas conexiones no son anómalas? ¿Y si son conexiones a Google, Facebook o Twitter? Cuando se desarrolló esta investigación (hace ya casi 2 años), muy poco malware hacía uso de estos canales cubiertos. Tan solo se conocían algunos casos en la red Twitter, en la que las direcciones de los servidores de C&C eran publicadas en una cuenta específica. En estos momentos, el uso de canales cubiertos por parte de malware está más extendido, como vimos en el informe de Mandiant, aunque sigue sin ser algo extremadamente común.
En el próximo post entraremos al detalle en algunas de las redes sociales y servicios conocidos que analizamos para el trabajo.
No hay comentarios :
Publicar un comentario