Covert Channels es una forma de comunicarse mediante un sistema por el cual no estaba diseñado o pensado para tal comunicación. Por eso es una de las principales técnicas utilizadas por los atacantes para exfiltrar información de las víctimas.
Un sistema de comunicación que habitualmente está siempre abierto en la electrónica de red y que otras tantas no está securizado como es debido, es el servicio de resolución de nombres o DNS. Esto hace que el protocolo DNS sea un canal fantástico para realizar covert channel sin apenas impedimentos.
Poder consultar Servidores de Nombres externos a la organización es un grave problema se seguridad, ya no por posibles covert channels como veremos, sino porque entre otros, permites a los atacantes poder consultar sus dominios de C2 sin pasar por los servidores DNS corporativos y sin dejar logs, más que en la electrónica de red. Esto, por ejemplo, dificultaría una investigación de ciberseguridad.
Diseñando un sistema Covert Channel por DNS
Como se ha comentado, DNS es un buen sistema para realizar Covert Channel y enviar información al exterior de una organización sin dejar apenas rastro. Ahora, veremos como de sencillo es hacer una prueba de concepto para exfiltrar información mediante el protocolo DNS.
Para poder realizar la PoC necesitamos dos componentes, el primero de ellos es un servidor DNS. Éste deberá actuar como si fuera el servidor DNS legítimo, pero ante ciertos nombres debe ser capaz de interactuar de forma diferente. El segundo componente es el cliente o malware. Éste realizará, entre otras cosas, peticiones DNS. Las peticiones deben lucir ‘normales’, pero en realidad esconden información crucial para una posible víctima.
El flujo de las peticiones DNS es el típico de una arquitectura cliente-servidor. El cliente realiza una petición al servidor DNS y este responde según vea conveniente.
Para el caso que tenemos entre manos, el servidor DNS debe actuar como es habitual y, ante un dominio especial, debe de responder según se diseñe el protocolo para el Cover Channel.
A continuación, se describe el protocolo utilizado en la PoC que vamos a mostrar.
El cliente, para nosotros el malware, obtendrá información del sistema infectado y lo enviará al servidor en la forma de subdominios. Por ejemplo, esto.es.informacion.critica.sothis.tech. La petición será de tipo TXT, podría valer casi cualquiera, pero con la petición TXT podría ser utilizada para descargar información del servidor.
En la imagen anterior se puede observar la respuesta a una petición DNS del tipo TXT. El recuadro rojo es la respuesta en si misma y el recuadro verde es la información de la respuesta. En este caso es un texto plano e información referente al SPF, pero se podría utilizar cualquier tipo de información siempre que se transmita respetando el código ASCII legible.
Por la parte del servidor, deberíamos de disponer de un servidor de DNS completo, pero para la PoC haremos que solo responda a peticiones del tipo TXT. Además, el servidor solo responderá ante consultas de un dominio en particular. Finalmente, añadiremos un flujo de control de envío y recepción de información.
Cabe aclarar que este es un diseño muy sencillo y poco funcional, pues se ha desarrollado simplemente a modo de demostración.
El malware
Es un código malicioso que recolecta información del sistema infectado y la envía hacia el exterior. Para la demo, el malware obtendrá las variables de entorno y las exfiltrará hacia el servidor DNS.
El envío de información será a modo de peticiones a subdominios y para que no se generen alertas o errores éstas se enviarán según el RFC1034, limitaremos el tamaño de las consultas a 63 caracteres para el subdominio. Además, por nuestro diseño de protocolo de exfiltración, añadimos un preámbulo y un epílogo a la información exfiltrada. Por último, codificamos la información enviada para que no haya problemas, siendo esta codificación compatible con el formato de URL. Lo que haremos será codificar la información en hexadecimal, caracteres de 0-9 y A-F. Pero se podría, por ejemplo, cifrar con RC4.
Aquí disponéis del código fuente para el cliente o malware.
El servidor
El servidor actúa de forma inversa, básicamente. El servidor responde a las peticiones TXT para el dominio de exfiltración, por ejemplo covert.sothis.tech.
El servidor también debe de entender el protocolo de exfiltración, así que el servidor debe de identificar el preámbulo, la información exfiltrada y el epílogo. Además, después de extraer la información exfiltrada el servidor de ser capaz de recuperarla, básicamente invirtiendo la codificación o cifrado.
Llegados a este punto, el servidor ya dispone de toda la información exfiltrada por el malware mediante Covert Channel en DNS. La PoC solo pretende mostrar lo importante que es monitorizar las comunicaciones más allá del uso habitual. Porque ahora el servidor podría actualizar el malware, por ejemplo, o podría emitir ordenes a un malware más elaborado, en fin, las posibilidades son casi infinitas.
Versión extendida
Como ya hemos dicho la comunicación la inicia el cliente y por lo que hemos estado viendo, el cliente envía directamente la información, pero ¿y si llevamos un poco más allá? El servidor también puede enviar información al cliente mediante la respuesta a las peticiones TXT del cliente, o podría indicar al malware que lea información de entrada por otra vía, por ejemplo, https a una dirección en concreto.
Utilizando la información enviada por el cliente y por el servidor convertimos nuestro escenario en un perfecto C&C basado en DNS. Desde el servidor podemos llegar ejecutar comandos a petición en el cliente o malware. Podríamos también enviar archivos desde el servidor al cliente (por ejemplo, nuevo malware, actualizar el actual, etc.) En definitiva, con implementar la lógica necesaria dispondríamos de un malware y un C&C completamente funcional.
