Covert Channels over Social Networks (y IV)

¡Y por fin llegamos al último post de la serie! Ya tenemos el FaceCat programado (aunque os recuerdo que es fácil que algo haya cambiado y en estos momentos necesite modificaciones) y podemos usarlo para establecer canales encubiertos a traves de FaceBook:

$ ./facecat.py 

Usage: facecat.py [options]

Options:

  -h, --help                       show this help message

  -w WALL, --wall=WALL  wall pipe account

  -c HOST, --host=HOST  connection host

  -p PORT, --port=PORT  listening or connection port

  -v, --verbose                  verbose output

El ejemplo más típico, porque es el que menos problemas puede dar, es hacer un simple chat TCP, que podemos hacer de la siguiente manera:

$ ./facecat.py –v –m wall1@gmail.com –p 4444

Luego utilizamos un par de putty's o NetCats para conectar a los puertos a la escucha, y a ver si conseguimos establecer una comunicación.

¡Perfecto! Parece que la cosa marcha. Ahora el siguiente paso es intentar hacerlo con una comunicación de un troyano convencional. En este caso hemos usado Poison Ivy, para ver si podíamos emplear toda su funcionalidad a través de un canal encubierto.

Para ello crearemos el malware de Poison Ivy con su generador, diciéndole que conecte a 127.0.0.1 al puerto 3460, donde tendremos escuchando un FaceCat que encapsulará la comunicación a través de FaceBook:

> facecat.py –v –m wall1@gmail.com –p 3460

En el lado del C&C, tendremos otro FaceCat que recibirá la comunicación de FaceBook y conectará al C&C del Poison Ivy para transmitirle la información ya desencapsulada:

> facecat.py –v –m wall1@gmail.com –c 127.0.0.1 –p 3460

Con todo eso, y el propio Poison Ivy, podemos ver como tomamos el control de un sistema empleando tráfico completamente encapsulado a través de FaceBook:

Por supuesto, el uso de canales encubiertos no es gratuito, y los que habéis usado el Poison Ivy con anterioridad habréis observado que funciona más lento de lo habitual, especialmente al realizar la captura de pantalla, pero es el precio que se tiene que pagar por la "invisibilidad".

El código fuente está disponible AQUÍ, pero como ya os he comentado, esta investigación fue realizada hace tiempo, por lo que es probable que necesitéis hacer cambios para que consigais que funcione.

Covert Channels over Social Networks (III)

Como os comentábamos en el anterior post, desarrollamos una prueba de concepto llamada FaceCat en la que pretendimos demostrar que podíamos introducir un canal encubierto a través de FaceBook.

Una de las primeras complicaciones que nos encontramos fue los continuos cambios y mejoras que se aplican sobre el interface de FaceBook, y la cantidad de Javascript/Ajax que este contiene. Esto puede hacer el uso de canales encubiertos una pesadilla, ya que cada cambio podría inutilizar el canal. La solución que se nos ocurrió es usar la aplicación para móviles de FaceBook, por tratarse de una aplicación basada en un HTML sencillo, y que presumiblemente sufrirá muchos menos cambios que su "hermano" para equipos de escritorio.

El siguiente paso fue ver como podíamos autenticar contra FaceBook para poder acceder a los muros que queríamos. En este caso, buscámos entre las cookies almacenadas por los navegadores más comunes una sesión autenticada de FaceBook, y empleamos esta misma sesión para la comunicación.

En una primera versión de FaceCat, este mismo usuario era utilizado para todo el proceso, pero durante su desarrollo se produjo un cambio en el sistema de permisos de FaceBook que impedía a un usuario dar permiso a cualquier otro usuario para escribir en su muro, aún sin ser contactos, y como no quería levantar las sospechas por añadir a este usuario como amigo de un usuario desconocido, optamos por realizar un "pass-the-cookie" a través de este muro, de tal forma que el usuario de esta cookie sea contacto del propietario del muro y, por lo tanto, pueda escribir en este:

Para introducir la información, como podéis apreciar, utilizamos Base64, ya que los comentarios en los muros de FaceBook deben ser texto, y el contenido de una comunicación es binario y podría contener caracteres no permitidos por FaceBook. En la idea original, pensamos en separar el código base64 en grupos de caracteres y mezclarlo con palabras comunes entre signos de puntuación para evitar su detección, de la siguiente forma:

R0VU  IC8gSFR UUC, as I just said, 8xLjAK SG9z dDogd3, when he started to, d3 Lmdv b2dsZ S5jb20, then he came back home and, KVXN lc i1BZ2Vud DogT W9 6aWxsY, and so on, Q oKZm9v PX Rlc 3Q., and thats all

Sin embargo, no fue necesario llegar hasta este punto, ya que FaceBook no bloqueaba la publicación de gran cantidad de comentarios en Base64 sin ningún tipo de modificación.

Lo siguiente que introdujimos fue un control de flujo, ya que en el mismo muro se juntan los mensajes en ambos sentidos de la comunicación, además de que cada uno de los lados debe poder saber hasta que mensaje ha leido, para poder leer el siguiente y no leer varias veces el mismo. Para ello empleamos una aproximación similar a la de TCP/IP, ya que empleamos un número de secuencia y una marca (M o S) que establece quien es el originario del mensaje.

Con todo esto, programado en Python, ya tenemos una prueba de concepto de canales encubiertos sobre FaceBook. En el próximo post veremos el resultado final y algunos ejemplos prácticos con un troyano real.

Covert Channels over Social Networks (II)

En el anterior post hicimos una introducción a lo que son los caneles encubiertos y como están siendo utilizados por el malware en la actualidad, así como las contramedidas que típicamente están siendo utilizadas por los administradores de seguridad.

La pregunta que dejábamos pendiente en el anterior post era ¿Podríamos utilizar un dominio conocido para ocultar mensajes entre un malware y su C&C? Para dar respuesta a esta pregunta le pegué un vistazo superficial a algunas aplicaciones que se me fueron ocurriendo, a ver si tenían algún tipo de protección que impidiera su uso como un canal encubierto. Os recuerdo que esta investigación fue realizada hace algún tiempo, así que es posible que en este tiempo se hayan introducido nuevas protecciones. También os tengo que comentar que esta primera revisión fue superficial, y que únicamente me metí en detalle con FaceBook.

PASTEBIN

Pastebin me parecía un medio de comunicación interesante, sobretodo porque permite introducir información de forma anónima, así que no hay cuentas de usuario que puedan ser bloqueadas ni nada de eso. Sin embargo, bajo determinadas circunstancias, la aplicación te pedía resolver un captcha, con lo que se complicaba un poco su uso.

DROPBOX

Dropbox fue otra de las aplicaciones que pensé que podía resultar útil. Permitía acceder en raw al contenido de los ficheros y además no parecía tener ningún medio de protección ante la subida masiva de ficheros via HTTP, así que era un buen candidato.

GOOGLE SITES

Por supuesto, el tráfico hacia Google es algo que no resultaría extraño en ninguna red, así que era sin duda un buen candidato. En este caso hice algunas pruebas con los comentarios de Google Site, una aplicación tipo "wiki" que Google ofrece para la creación de sitios web sencillos. Entre sus funcionalidades, existe la opción de pone comentarios. Tras algunas pruebas, no pareció que fuera bloqueado o que se me pidiera resolver ningún captcha ante una entrada masiva de comentarios.

TWITTER

Twitter ya había sido usado con anterioridad por malware como "Naz", ya que no ofrecía ninguna protección contra su uso masivo ni nada similar. Sin embargo, es un sistema que por defecto deja toda la comunicación a la vista de todo el mundo, y requería algo más de trabajo adicional.

FACEBOOK

FaceBook es, sin duda, la red social por antonomasia, por lo que era un excelente candidato, especialmente pensando en usuarios domésticos (y, sorprendentemente, también muchas empresas). Tras algunas pruebas vimos que FaceBook tiene algunas protecciones, pero que estás están pensadas en proteger la privacidad de sus usuarios (como es lógico). Si intentas hacer un crawling para obtener información de otros usuarios sí que eres detectado y bloqueado, pero no encontramos ningún impedimento para leer escribir de nuestro propio muro, o del de otro usuario, siempre que no fuéramos cambiando de usuario.

Al final, nos quedamos con FaceBook, y desarrollamos una prueba de concepto a la que llamamos FaceCat, llamado así porque funciona de forma muy similar a un NetCat tradicional, pero encapsulando el canal de comunicación a través de FaceBook.

En el próximo post veremos en detalle los pasos que se siguieron para el desarrollo de esta herramienta.

Covert Channels over Social Networks (I)

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.

Covert Channels over Social Networks

Como ya anunciamos hace algunas semanas, este pasado fin de semana estuve dando la charla "Covert Channels over Social Network" en las Conferencias GSIC, en A Coruña.

Ante todo, gracias a la organización por invitarme a asistir y por el buen trato recibido.

Dicho esto, las slides que utilicé pueden descargarse de AQUÍ, aunque podeis ver el video de ellas con las transiciones en el siguiente video:

También ha sido publicado ya el video de la charla completa que dí en las Conferencias SOURCE en Barcelona, el pasado año, que básicamente es la misma que la que he dado en GSIC:

El código fuente de la PoC (FaceCat) y una serie de posts explicando con detalles, lo dejaré para dentro de algunas semanas, para hacerlo coincidir con la publicación de un paper sobre este tema que va a publicar el SANS Institute.

FaceCat en GSIC - La Coruña

Los próximos días 23, 24 y 25 de Febrero tendrá lugar en La Coruña la cuarta edición de las Jornadas G.S.I.C, en las que tendré la oportunidad de participar como ponente y hablar de una prueba de concepto de uso de canales cubiertos sobre redes sociales, concretamente FaceBook, llamada FaceCat.

En la charla, además de explicar los pasos que se siguieron para el diseño de la herramienta, haremos un par de demos de como se podría emplear esta herramienta (o técnicas parecidas) para ocultar la comunicación de un conocido troyano, siendo a nivel de red indistinguible de una comunicación de FaceBook.

Además de la mía, podréis asistir a otras charlas muy interesantes, que podéis ver AQUÍ.

Os recomiendo a todos la asistencia.
Nos vemos allí!