Sodin, el ransomware que se aprovecha de los MSP
A finales de marzo de este mismo año Kaspersky informaba sobre un nuevo vector de ataque para los ciberdelincuentes. Se trata de los proveedores de servicios gestionados (MSP – Manage Service Provider), un objetivo que puede llegar a ser muy lucrativo.
En especial, el ransomware Sodin (también conocido como Sodinokibi y REvil) ha dado muchos quebraderos de cabeza a diferentes expertos en el mundo de la seguridad. Sodin aprovechó una vulnerabilidad en servidores Oracle WebLogic para introducirse en los sistemas de los MSP y, además, no es necesaria la participación del usuario para activarse.
Propagación de Sodin
Los atacantes aprovecharon la vulnerabilidad CVE-2019-2725 para ejecutar un comando en PowerShell en un servidor de Oracle WebLogic y cargar un dropper (Software diseñado para instalar algún tipo de malware) que, más tarde, instalaría el ransomware Sodin.
En abril, Oracle lanzó los parches para corregir la vulnerabilidad de la que hablamos más arriba, pero a finales de junio se descubrió la vulnerabilidad CVE-2019-2729, similar a la anterior.
En algunos casos los atacantes utilizaron las consolas de acceso en remoto Webroot y Kaseya para enviar el troyano. En otros casos los atacantes consiguieron penetrar en la infraestructura de los MSP mediante una conexión RDP y descargaron el ransomware en los ordenadores de los clientes.
Esquema criptográfico
Sodin utiliza un esquema híbrido para cifrar los archivos. el contenido del archivo es cifrado mediante el algoritmo salsa20, y las claves con un algoritmo asimétrico de curva elíptica.
Generación de la clave
La configuración de Sodin contiene el campo pk, que se guarda en el registro con el nombre sub_key; esta es la clave pública de 32 bytes del distribuidor del troyano.
cuando se ejecuta, el troyano genera un nuevo par de claves de sesión. la clave pública se guarda en el registro con el nombre pk_key, mientras que la clave privada se cifra usando el algoritmo ECIES, con la clave sub_key y se almacena en el registro con el nombre sk_key.
La misma clave de sesión privada también se cifra con otra clave pública codificada en el cuerpo del troyano. El resultado del cifrado se almacena en el registro con el nombre 0_key.
Si alguien conoce la clave privada correspondiente a la clave con la que se ha cifrado 0_key, puede descifrar los archivos de la víctima, incluso sin la clave privada para sub_clave. Todo indica que los desarrolladores del troyano crearon una forma de descifrar archivos a espaldas de los distribuidores.
Cifrado de archivos
Durante el cifrado de cada archivo se genera un nuevo par de claves asimétricas, file_pub y file_priv. A continuación se calcula el SHA3-256 y el resultado se utiliza como clave simétrica para cifrar el contenido del archivo con el algoritmo Salsa20.
Además de los datos descritos anteriormente también se encuentra un archivo para la inicialización del cifrado Salsa20.
Los archivos cifrados reciben una nueva extensión arbitraria, la nota de rescate se guarda junto a los archivos cifrados y el fondo de pantalla generado por el malware se configura en el escritorio.
Como podemos ver, se está consiguiendo un grado muy alto de especialización y sofisticación por parte de los desarrolladores de malware que, a día de hoy, pone a prueba a los analistas de todo el mundo.
Más información:
Powered by WPeMatico
