ransomware
A finales de marzo, cuando escribimos sobre el ataque del ransomware GandCrab a los clientes de proveedores de servicios gestionados (MSP, por sus siglas en inglés), supusimos que no se trataría de un hecho aislado. Los proveedores de servicios gestionados son un objetivo tan tentador que los cibercriminales no podrían ignorarlo.
Estábamos en lo cierto, al parecer. En abril, el ransomware llamado Sodin llamó la atención de nuestros expertos. A diferencia de los demás, utilizó las brechas en los sistemas de seguridad de los MSP y aprovechó una vulnerabilidad en la plataforma Oracle WebLogic. Además, normalmente el ransomware requiere la intervención del usuario en algún momento (por ejemplo, a veces la víctima debe lanzar un archivo ubicado en un correo electrónico de phishing), pero en este caso no es necesaria su participación.
En este artículo de Securelist encontrarás más información técnica sobre el ransomware. Desde nuestro punto de vista, lo más interesante sobre este malware son sus medios de distribución.
Los métodos de distribución de Sodin
Para expandir el malware a través de WebLogic, los atacantes utilizaron la vulnerabilidad CVE-2019-2725 para ejecutar un comando de PowerShell en un servidor vulnerable de Oracle WebLogic. Esto les permitió cargar un dropper en el servidor, que posteriormente instaló la carga dañina: el ransomware Sodin. Los parches que solucionaban este error se lanzaron en abril, pero a finales de junio se descubrió una vulnerabilidad similar: CVE-2019-2729.
En los ataques que utilizan a los MSP, Sodin se introduce en los dispositivos de los usuarios de diversas formas. Los usuarios de al menos 3 proveedores ya han sufrido las consecuencias de este troyano. Según este artículo de DarkReading, en algunos casos los atacantes utilizaron las consolas de acceso remoto Webroot y Kaseya para enviar el troyano. En otros casos, tal cual se afirma en Reddit, los atacantes penetraron en la infraestructura de los MSP mediante una conexión RDP, elevaron sus privilegios, desactivaron las soluciones de seguridad y las copias de seguridad y descargaron el ransomware en las computadoras del cliente.
Qué deberían hacer los proveedores de servicios
En primer lugar, deberían tomarse muy en serio el almacenamiento de las contraseñas utilizadas para el acceso remoto y utilizar la autentificación de doble factor siempre que sea posible. Las consolas de acceso remoto, Kaseya y Webroot, admiten este tipo de autentificación. Además, después del incidente, los desarrolladores han comenzado a exigir su uso. Como podemos comprobar, los atacantes que distribuyen Sodin no esperan a la oportunidad perfecta, sino que buscan deliberadamente varios métodos para distribuir el malware mediante los proveedores de servicios gestionados. Por ello, es necesario vigilar todas las herramientas que se utilizan en este ámbito. Como ya hemos señalado, el acceso RDP debería utilizarse como último recurso.
Los MSP y, sobre todo, aquellos que ofrecen servicios de ciberseguridad deberían tomarse aún más en serio la protección de su infraestructura que la de su cliente. Y esto es lo que ofrece Kaspersky a los MSP para su protección y la de sus clientes.
Qué debería hacer el resto de las compañías
Evidentemente, actualizar el software es de vital importancia. Que el malware se introduzca en tu infraestructura mediante vulnerabilidades descubiertas y cerradas hace meses puede ser un ejemplo muy vergonzoso de un error que podría haberse evitado.
Las empresas que utilizan Oracle WebLogic deberían consultar en primer lugar las recomendaciones de seguridad de Oracle para las vulnerabilidades CVE-2019-2725 y CVE-2019-2729.
Además, también es aconsejable utilizar soluciones de seguridad de confianza con subsistemas que puedan detectar ransomware y proteger las estaciones de trabajo.
[kasbanner cat_id=”kesb-trial”
Consejos