Los actores maliciosos están utilizando una vulnerabilidad de día cero y clic cero no revelada previamente en Microsoft Office para ejecutar comandos de PowerShell sin interacción del usuario, según investigadores de seguridad.
La vulnerabilidad – descubierto por el investigador de seguridad nao_sec el 27 de mayo y luego denominado CVE-2022-30190 por Microsoft: aprovecha la herramienta de diagnóstico de Microsoft (MSDT), que se utiliza para ejecutar el código de PowerShell después de llamar a un archivo HTML desde una URL remota.
“Utiliza el enlace externo de Word para cargar el HTML y luego usa el esquema ‘ms-msdt’ para ejecutar el código de PowerShell”, dijo nao_sec.
En un blog publicado el 30 de mayo, Microsoft agregó: “Un atacante que explote con éxito esta vulnerabilidad puede ejecutar código arbitrario con los privilegios de la aplicación que llama. Luego, el atacante puede instalar programas, ver, cambiar o eliminar datos, o crear nuevas cuentas en el contexto permitido por los derechos del usuario”.
También conocido dentro de la comunidad de seguridad de la información como “Follina”, el exploit permite a los atacantes ejecutar el código a través de MSDT incluso si las macros están deshabilitadas y ha sido reproducido con éxito por otros investigadores de seguridad, incluido Kevin Beaumont y los expertos de Huntress.
“Este es un ataque atractivo para los adversarios, ya que está escondido dentro de un documento de Microsoft Word sin macros para activar señales de advertencia familiares para los usuarios, pero con la capacidad de ejecutar código alojado de forma remota”, dijo John Hammond, investigador principal de seguridad en Huntress. en un blog
“Para comprender mejor esta amenaza, los investigadores de seguridad de Huntress modificaron las partes internas del documento de Word para llamar a una dirección local dentro de un entorno limitado de análisis y enviaron una carga útil benigna que mostraría un mensaje en lugar de detonar malware”.
Hammond agregó que, después de la prueba, quedó claro que la carga útil no se ejecutaría sin “una cantidad significativa de caracteres de relleno”, que estaban presentes en el archivo HTML.
Si bien inicialmente no estaba claro para los investigadores por qué esto era necesario, Huntress pudo confirmar que cualquier archivo con menos de 4096 bytes no invocaría la carga útil después de que se le envió un blog que indicaba que había un tamaño de búfer codificado para una función de procesamiento de HTML.
Beaumont también descubrió que si el documento de Word se cambia a un formato de archivo de texto enriquecido (RTF), entonces el exploit puede activarse sin ninguna interacción por parte del usuario, extendiendo la gravedad del exploit de un solo clic a cero.
“Esta técnica de ataque ejecuta código bajo la cuenta de usuario que abrió o navegó hacia el documento malicioso. Esto significa que un adversario puede comenzar como un usuario con privilegios bajos (sin permisos de administrador), pero luego puede usar este acceso para desencadenar más ataques para aumentar los privilegios y obtener más acceso al entorno de destino”, dijo Hammond, y agregó que educar a los usuarios para identificar y eliminar correos electrónicos maliciosos sigue siendo la mejor línea de defensa, al menos hasta que haya un parche disponible para implementar en los puntos finales.
“Durante los próximos días, esperamos intentos de explotación en la naturaleza a través de la entrega basada en correo electrónico”.
Beaumont agregó que la detección del exploit seguirá siendo difícil, ya que Word carga el código malicioso desde una plantilla remota, lo que significa que nada en el documento en sí es realmente malicioso.
“Microsoft probablemente quiera reforzar las páginas web incrustadas como plantillas remotas en Office para que no carguen tantos URI, y Outlook probablemente necesite otro paso de refuerzo. Todas mis opiniones, como siempre”, dijo.
De acuerdo a Grupo de persecución de sombrasun grupo de caza de amenazas persistentes avanzadas (APT), la vulnerabilidad se informó por primera vez a Microsoft el 12 de abril de 2022, pero Microsoft cerró el ticket 10 días después diciendo que no era un problema de seguridad, ya que si bien “msdt se ejecuta de hecho… requiere un Código de acceso cuando se inicia y el que se proporciona en este ejemplo no funciona”.
Computer Weekly se puso en contacto con Microsoft para explicar por qué la vulnerabilidad no se consideraba un riesgo de seguridad, así como si planea solucionar el problema y cómo, pero no recibió respuesta al momento de la publicación.
