lunes, 22 de febrero de 2016

Minimizar exposición a las infecciones por malware

NOTA INICIAL:

No creo que vaya a hacer el descubrimiento del siglo pero si me gustaría exponer la solución que de manera inconsciente, a mi juicio, permite minimizar la exposición a una infección de malware y que con toda seguridad se encuentre implantada en múltiples empresas.

ENTORNO INICIAL

Existen varios vectores de infección, pero yo voy a exponer una solución para el vector de infección a través de archivos lanzadores que intentan descargarse ejecutables de la red.

Normalmente estos lanzadores se basan en archivos ofimáticos que contienen macros que se ejecutan nada más abrir el archivo, y que su objetivo es descargarse un archivo, normalmente un ejecutable, que será renombrado y ejecutado nada más haberlo descargado.

Habitualmente, los recursos solicitados a Internet vienen configurados de dos maneras:

1.  <dominio>/<uri>
2 . <ip>/<uri>

En el primero de los casos, antes de realizar la petición de descargar, se produce una petición de resolución DNS a través de los servidores configurados en nuestro NIC (tarjeta de red), que normalmente suelen ser servidores DNS públicos en Internet (los propios de Telefónica o de cualquier otro ISP o gran corporación - 8.8.8.8 ;-))

Tras la resolución se produce la solicitud de descarga.

Descargado el recurso, el nombre y la ubicación donde se almacena, suelen ser modificados para dificultar un posible análisis. Tras lo cual, se produce la ejecución del mismo infectando nuestro hosts, y como es lo normal en los tiempos que corren, dicho malware reportará información hacia su C&C (Command and Control).

En el segundo de los casos, se realiza todo lo comentado anterior salvo por una excepción. NO se produce la solicitud de resolución DNS.


Flujo del vector de infección analizado.


Las características que son importantes para nuestra investigación y que se dan en ambos casos son:

1.- El "lanzador" utiliza los recursos del propio sistema.
2.- Se utiliza un socket para tramitar la solicitud de descarga.
3.- El socket levantado es un proceso hijo del proceso que abre el documento.

SOLUCIÓN

La solución a este problema mediante el uso de recursos de red pasa por la utilización de:

1.- Un servidor DNS que solo gestione el dominio interno de nuestra red.

NOTA: No realizaría peticiones de resolución de dominios hacía el exterior, de eso ya se encargaría el siguiente elemento.

2.- Un proxy-web, que sea  el único que realice peticiones HTTP/S, SSH, FTP.

NOTAS: 
                A. Por supuesto, la salida a Internet debe de estar controlada, como mínimo por una tupla de usuario/contraseña, que además sea distinta a la utiliza para acceder a la máquina local (este conectada o no a un dominio).

                B. También hay que "adiestrar" a nuestros queridos usuarios para que no almacenen las credenciales para su uso automático, es decir, preferiblemente usar dobles autenticaciones.

3.- Bloquear la salida hacia Internet por cualquier otra medio que no sea uno controlado, vamos, sólo debe salir el proxy-web.

NOTA: Para entornos caseros, este último paso puede ser obviado, y en su defecto, NO definir servidores DNS a utilizar.
Solución con servidor DNS que gestionan, sólo, nuestro dominio interno.


Solución sin servidor DNS interno, enfocado al despliegue en hogares.

EXPLICACIÓN

Si implementamos un servidor DNS que gestiona solamente nuestro dominio interno, las peticiones que realice el lanzador para resolver el dominio del cual quiere descargarse el "malware" no serán atendidas, por lo que la descarga NO se realizará.

Si NO configuramos ningún servidor DNS que gestione las resoluciones DNS, las peticiones que realice el lanzador para resolver el dominio del cual quiere descargarse el "malware" no serán atendidas, por lo que la descarga NO se realizará.

En definitiva, en nuestro sistema permanecerá el "lanzador" pero no se habrá descargado ni ejecutado el verdadero malware.

Si nuestro lanzador no utiliza resoluciones DNS, sino que de manera directa solicita la solicitud de descarga del malware a una dirección IP. Este socket se encaminará hacía nuestra puerta de enlace (Gateway), y no a través de nuestro proxy-web -que es el único que tramita peticiones hacía Internet-, por lo que la conexión contra el servidor solicitado, NUNCA se llevará a cabo.

EFECTOS COLATERALES

Con la solución propuesta tenemos "efectos colaterales", cuales son:

1.- Los archivos que llevan embebidos los códigos malware, se ejecutarán con total normalidad, infectándonos, PERO ... cuando se realicen las conexiones contra el C&C, nuestro entorno bloqueará la salida de las comunicaciones.

2.- Ante los ransomware, esta solución evitará el cifrado de la información o evitará que la clave de cifrado llegue al "C&C". ¿Por qué?.

Todo depende de la versión de ransomware con la que nos encontremos, de las existentes hasta la fecha.

Existe la posibilidad de encontrarnos con versiones que solicitan las claves de cifrado a Internet, en cuyo caso, esta solución bloquearía la salida de la petición, por lo que NO se cifrarían los archivos. Si nos encontramos con versiones que ya poseen la clave de cifrado o la "fábrica" en el momento del cifrado, los archivos será cifrados pero la comunicación que realicen dicho ransomware para distribuir la clave utilizada NO serán entregados.

Esto último supone un inconveniente, incluso el hecho de perder las peticiones que hemos considerado maliciosas, es un inconveniente.

Todo lo comentado con anterioridad puede ayudarnos a alimentar la inteligencia de nuestros elementos de seguridad, si los tuviéramos, ¿cómo?.

Añadamos un "honeypot" a nuestra solución que reciba y responda, si fuera necesario, a todas aquellas peticiones que no pertenezcan a nuestra red interna. Es decir, cuando nuestro servidor DNS interno, reciba una petición de resolución de un dominio que no es el nuestro, dicha petición será enviada a nuestro "honeypot". Si nuestro default gateway recibe un paquete dirigido a una IP que no pertenece a nuestro rango interno, dicha petición será enviada a nuestro "honeypot".

Todas estas peticiones serán recolectadas por los logs de nuestro honeypot, que pueden ser enviadas a su vez a un sistema de correlación, que nos ayude a analizar las peticiones recibidas.

Solución con Honeypot incorporado en nuestra red.


EVOLUCIÓN

Una de las posibles evoluciones consistiría en utilizar el proxy-web, bien, levantando un proceso vinculado con uno de los navegadores existentes en el hosts o bien, configurando un socket que utilice la salida a través de proxy-web.

 En cualquiera de los casos, tal y como se ha comentado antes, habría que:

1.- Adiestrar a nuestros queridos usuarios para que no almacenen las credenciales para su uso automático.

2.- Que las credenciales a utilizar en el proxy-web fueran distintas a la utilizadas frente al dominio o frente a la "base de datos" para el acceso al host de manera local.

3.-  Y para evitarlo,  sería preferible usar dobles autenticaciones.

U otras medidas ...



No hay comentarios:

Publicar un comentario