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