12 años. Ese es el tiempo que ha permanecido oculta una vulnerabilidad en PolKit (antes Policykit), un sistema para la gestión de permisos ampliamente usado por las distribuciones Linux más populares. El fallo está en el componente ‘pkexec’, que permite una funcionalidad similar a ‘sudo’, es decir, ejecutar un comando con los privilegios de otra cuenta o usuario. Por lo tanto, al explotarlo, permitiría la elevación de privilegios a root, dado que ‘pkexec’ es un binario SUID root.

Además de estar presente en casi todas las distribuciones Linux, la explotación es trivial. Basta, a grosso modo, con manipular únicamente las variables de entorno para llevarla a cabo. Es decir, no se trata de un exploit al uso, en el que se tiene que evadir protecciones y poseer un contexto de ejecución favorable, sino que prácticamente el éxito de la explotación está asegurado. De hecho, para esta vulnerabilidad (con CVE-2021-4043) están apareciendo gran cantidad de exploits.

Curiosamente, la base del fallo fue descrita en 2013 en un post de un investigador australiano, Ryan Mallon, que ya advirtió que inyectando un puntero nulo en el array de argumentos a un programa podría tener consecuencias desastrosas. Aunque no pudo en ese momento identificar un vector sobre el que aplicar su hallazgo. Finalmente se ha materializado en esta elevación de privilegios, recordemos, trivial de explotar.

Más información: https://github.com/berdav/CVE-2021-4034/blob/main/cve-2021-4034.c

Solo 70 vulnerabilidades corregidas este martes por Microsoft. Curiosamente, ninguna crítica, aunque sí una pública sin exploit. La más grave (que no crítica, hay varias que supuestamente permiten ejecución de código) está en Sharepoint, con un CVSS de 8.8. Parece fácil de explotar aunque necesita de algunos permisos por parte del atacante (que no son tan difíciles de conseguir). Otro fallo con gravedad 8.8 en el servidor DNS parece menos probable de explotar.

El fallo que ya se conocía es una elevación de privilegios compleja de explotar.

Y la cola de impresión sigue en el ojo del huracán. Cuatro fallos corregidos, catalogados como importantes (permitirían la elevación), han sido corregidos. Parece que Microsoft está auditando bien este código desde el fiasco de printNightmare en julio de 2021.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/

¿Crees que el ransomware se detiene solo cuando se cifra la información y se pide el pago? Vamos por varias generaciones de grupos de extorsión que se dedican exclusivamente al ransomware de compañías, y tanto el éxito como la oportunidad de mercado les empujan a la innovación en sus métodos. En realidad, nos encontramos ante unos intentos de extorsión múltiples que cubren todos los flancos para garantizar el éxito de los atacantes y dejar sin opciones a la víctima.

La primera extorsión es obviamente entrar en la empresa y cifrar información importante. Si no se paga, no se descifra y la compañía no puede continuar su operativa. Hace algunos años se introdujo una vuelta de tuerca: no solo cifran la información sino que además la roban, y cuanto más se tarde en pagar, más información de la empresa harán pública. Esto se intentó como método de presión falso con los usuarios domésticos años antes, pero no era cierto. El ransomware no robaba información al usuario medio. El modelo no escalaba. Si embargo con las grandes compañías ha funcionado bien porque sí que extraen y almacenan los datos.

La tercera extorsión además de las anteriores, es meter presión ejecutando ataques de denegación de servicio hacia las páginas públicas de la empresa atacada. Las hacen desaparecer de internet. La cuarta que se ha observado sería el acoso. Los atacantes, perfectamente organizados, contactan con proveedores, partners, clientes e incluso medios de comunicación para alertarles sobre el ataque y arruinar su reputación.

Pero además existe una quinta. LockBit desde hace algún tiempo invita a los atacados a ofrecer datos de terceros que les ayuden a entrar en su red (credenciales VPN, RDP…). Esto podría servir para que les “rebajara” el pago del rescate. Condenar a un tercero para aliviar la propia condena. Perverso pero, al parecer, efectivo.

Más información: https://www.linkedin.com/pulse/lockbit-introduce-un-nuevo-elemento-en-el-negocio-del-abraham-pasamar/

Microsoft ha corregido 71 vulnerabilidades este mes, un número relativamente pequeño para lo que nos tiene acostumbrados. Lo importante es que:

* Tres de ellas son críticas. Una en Exchange (CVE-2022-23277) y dos más en el tratamiento de extensiones de vídeo.

* Otra relevante previamente conocida se encuentra en el en cliente de RDP. Al conectarse a un potencial servicios malicioso, podría conseguir ejecutar código en el cliente vulnerable. El cliente RDP este mes tiene en total tres parches.

* Las otras dos conocidas previamente se encuentran en el servicio de Fax y en .NET y Visual Studio.

También se han corregido 41 fallos en Chromium, que ahora es el core de Edge. información: https://msrc.microsoft.com/update-guide/vulnerability/

Se están acumulando las vulnerabilidades de elevación en el Kernel Linux. Por un lado tenemos CVE-2022-0847, “Dirty Pipe”, que lleva ahí desde 2020 y es trivial de explotar (y aun así, se necesitaron meses para depurar el fallo y comprender la vulnerabilidad). Por otro, CVE-2022-0492 y CVE-2021-4034 que también permiten elevar.

En el caso de Dirty Pipe, Max Kellermann necesitó meses para entender por qué a un cliente de una distro se le corrompían ficheros. Después de mucho investigar entendió cómo convertir un error en una elevación. Primero escribiendo desde una cuenta no privilegiada una clave en el fichero de claves SSH… de root.

Así luego podía conectarse como tal por SSH. Al hacerlo público, otros tantos investigadores descubrieron cómo aprovecharla en ficheros con SetUID, escribir en ficheros read-only, crear tareas… etc.

El fallo está en la función splice que permite mover datos entre ficheros. En el momento en el que la información está en un búfer en memoria, se pueden escribir libremente datos. Está corregido en 5.16.11, 5.15.25 y 5.10.102 y también afecta a Android.

Por otro lado, en enero se descubrió un fallo en polkit que se llamó, PwnKit (CVE-2021-4034), otra elevación que estuvo ahí 12 años. La elevación más reciente es un fallo en «cgroups» CVE-2022-0492. Cgroups permite controlar los recursos de un grupo de procesos. En principio se trata de tocar el fichero release_agent para que ejecute tras la terminación de unos procesos como root. Ese fichero solo puede ser tocado como root, pero en entornos con contenedores, ser root no significa tener todo el control, por tanto en realidad este fallo permitiría controlar un conjunto de contenedores dado el caso y escapar de ellos.

Más información: https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/

No es ningún secreto que desde hace unos tres años, Chrome sufre de muchos más fallos graves descubiertos mientras son aprovechados por atacantes. O sea, 0-days. Tanto es así que en Google han escrito una entrada explicando por qué. La respuesta rápida es una mezcla de muchos motivos que no llevan a ninguna sorpresa.

Primero alegan que no es que antes no ocurrieran, sino que se veían menos. O sea, hay más transparencia por parte de Chrome. El segundo argumento (aunque parece no complementar bien con el anterior) es que Chrome es ahora más popular y otras vías de explotación (como Flash) ya no les funcionan a los atacantes.

Otro argumento: antes bastaba un fallo para comprometer el navegador, ahora al menos dos: uno para ejecutar código y otro para salir de la sandbox. Esto engorda el número. Aunque lo cierto es que el aumento de 0-days en Chrome se experimenta desde 2019, y la sandbox de Chrome lleva desde 2015.

Por último, la mayor complejidad del navegador, y la inevitabilidad de los errores, hacen que el número haya crecido. Para contrarrestar esto, Chrome sigue mejorando su eficaz sandbox. Ahora con dos proyectos para eliminar los user-after-free (MiraclePtr y *Scan), escribiendo en lenguajes que mejoren el manejo de memoria y la seguridad, y aprovechando mejoras en combinación con el sistema operativo.

La realidad es que la cantidad de vulnerabilidades encontradas en Chrome aumenta, y los atacantes la aprovechan. Aunque sean cada vez más difíciles de explotar. Esto implica que los atacantes no escatiman recursos para conseguir su objetivo.

Más información: https://security.googleblog.com/2022/03/whats-up-with-in-wild-exploits-plus.html

La botnet Muhstik ha encontrado un nuevo impulso gracias a un fallo en la base de datos Redis bajo Debían y Ubuntu (aunque podría darse en más plataformas), que permite ejecutar código LUA en ella escapando de la sandbox. El fallo, que se encontró a principios de marzo, se une así al arsenal de vulnerabilidades que utiliza la botnet para propagarse desde 2018. Seis en total aprovechando problemas en Oracle WebLogic, Drupal, Confluence… Muhstik se encarga de, entre otras actividades realizar ataques de denegación de servicio distribuido.

Algunas curiosidades es que esta botnet utiliza IRC para comunicarse con su command and control y que el descubridor del fallo en Redis advirtió a Ubuntu del problema esperando que a su vez avisaran a Debian. Pero no fue así y tuvo que notificar por separado del problema.

Más información:
https://blogs.juniper.net/en-us/security/muhstik-gang-targets-redis-servers

0days, 0days everywhere. Recordando siempre su definición real: vulnerabilidades encontradas mientras son aprovechadas por atacantes (y no fallos recién descubiertos por investigadores). En este caso es Apple quien corrige CVE-2022-22675 en iOS y MacOS y CVE-2022-22674 solo en MacOS. La primera en AppleAVD, y la segunda en el driver gráfico de Intel.

Como es costumbre, Apple no ha dado ningún detalle. Los 0days están más activos que nunca. Si Apple corrigió 12 en 2021, en estos primeros tres meses de 2022 lleva ya 5. Y no solo Apple. Chromium (y por tanto Edge, Chrome y Opera) se han visto afectados desde hace tiempo por una insistente campaña de ataques que están poniendo a prueba su seguridad. Ahora que el motor está en dos de los navegadores más usados, la rentabilidad de cada fallo se multiplica. Y aunque con menor frecuencia Firefox tampoco se libra. En marzo se descubrieron dos 0days (CVE-2022-26485 y CVE-2022-26486).

¿Volvemos a la época en la que el navegador vuelve a ser el principal vector de ataque ahora que se está atajando la vía del correo?

Más información: https://threatpost.com/apple-rushes-out-patches-0-days-macos-ios/179222/

La nueva versión de la PCI DSS, de obligado cumplimiento para todas las pasarelas de pago, contempla medidas muy concretas contra el tipo de ataque Magecart. Se trata de grupos operando para perpetrar “skimming virtual” inyectando JavaScript en la página de la víctima y redirigir los datos de la tarjeta de crédito a sus propios servidores a la hora de realizar el pago.

En el punto 6.4.3 de la famosa normativa, se contemplan tres requerimientos. A) Implementar un método que confirme que cada script en la web está autorizado. B) Garantizar la integridad de los scripts. C) Un inventario de justificación de cada script para saber por qué es necesario.

Aunque no se menciona explícitamente, esta normativa está claramente orientada contra los métodos de ataque usados por Magecart y, de nuevo, aunque no se mencione, las recomendaciones mapean perfectamente sobre dos tecnologías ya existentes. El primer punto se satisface con las Content Security Policy correctas (de dónde están autorizados a cargar los scripts). El segundo, a través de Subresource Integrity (se define en la etiqueta script el hash del script que se carga y esto garantiza que no cambia).

La tercera parece meramente burocrática e implica identificar para qué es necesario, en la web de pago, que se carguen otros scripts no imprescindibles. Como indica Scott Helme, esta medida podría haber detenido el famoso ataque de Magecart a TicketMaster, puesto que en ese caso se atacó a Inbenta, que proporcionaba scripts de chatbot en la página de pago de Ticketmaster. Chatear con un bot en el momento de pago no es esencial y bajo la nueva PCI DSS se podría haber planteado eliminar preventivamente de la web de pago esos scripts que fueron finalmente atacados.

Más información: https://scotthelme.co.uk/pci-dss-4-0-its-time-to-get-serious-on-magecart/

El malware de Android sigue su evolución, ahora innovando con algo aparentemente superado en el escritorio: los troyanos bancarios. Desde el legendario Marcher se evolucionó a Exobot en 2016, de ahí a ExobotCompact. Ahora con nuevas funcionalidades, esta familia parece llamarse Octo. La capacidad más llamativa (entre las clásicas para robar todo lo posible) es la de acceder al smartphone directamente a través de una especie de VNC y por tanto, realizar el fraude sobre el propio dispositivo, controlándolo casi en tiempo real.

Esto aporta enormes ventajas para el atacante. Virtualmente actúa como el usuario, levantando menos sospechas ante el banco, como hacían los tradicionales troyanos bancarios de Windows que a mediados de los 2000, irrumpieron inyectándose en los navegadores.

Para conseguir ese acceso en tiempo real, se basan en la funcionalidad nativa de Android MediaProjection (para proyectar en pantallas) y AccessibilityService (para la accesibilidad, algo que ya es abusado abiertamente por los atacantes). El atacante envía el comando start_vnc al sistema y consigue proyectar la pantalla del dispositivo en el command and control. A continuación pone una pantalla en negro en el sistema para no ser descubierto, quita notificaciones y el brillo a cero.

Con toda la información recogida y la proyección, puede enviar comandos como “click_at”, “paste”, “long_click”, “set_text”… mientras controla a un ratio de 1 frame por segundo en el command and control, el efecto de sus actos. Los descubridores apuntan a que esta puede ser la versión manual. Porque con este nivel de control en realidad podrían simplemente automatizar un envío de comandos en lote a través de un archivo que ejecutar. Así el ataque ganaría en escalabilidad.

Por supuesto, han colado en Google Play aplicaciones maliciosas que servían de dropper para este malware.

Más información: https://threatfabric.com/blogs/octo-new-odf-banking-trojan.html

145 vulnerabilidades corregidas un martes de Microsoft es mucho (contando las de Chromium). Y peor aun cuando 10 son críticas. Al menos solo una era conocida con anterioridad y solo otra aprovechada activamente por atacantes. En este último caso, por supuesto, como suele ser habitual, una elevación de privilegios a través de Common Log File System Driver (CVE-2022-24521). La razón es que las suelen encontrar casas antivirus en malware específico, aunque en este caso, aparece la NSA como descubridora también.

Uno de los fallos más graves podría ser la ejecución de código a través del Windows Network File System (CVE-2022-24497). Al menos, solo aplica a sistemas con el protocolo activo.

Pero sin duda el crítico afecta al RPC, activo por defecto, sin necesidad de contraseña y explotable en remoto (CVE-2022-26809). Por tanto, fácilmente gusanable. De nuevo, a través del puerto 445.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/

Ya tenemos el fallo criptográfico del año, justo 12 meses después del problema en la implementación de curvas elípticas de Microsoft descubierto por la NSA (CVE-2020–0601), llega CVE-2022-21449, un problema de implementación de ECDSA (DSA en curvas elípticas) en Java desde su versión 15. Convierte la verificación criptográfica de firmas en una farsa en cualquier entorno que se utilice.

ECDSA se basa en dos valores, r y s. La verificación criptográfica se basa en comprobar las dos partes de una ecuación en la que se introduce r por un lado y por el otro, r multiplicado por un valor derivado de s. Si ambos son cero, la verificación siempre sería válida independientemente del resto de valores… que en la práctica implican que da igual el mensaje y la clave. Todo se daría por válido.

El algoritmo de verificación explícitamente establece que es necesario comprobar que ambos valores son enteros mayores o igual a uno antes de la verificación de firma. Java 15, de 2020, omitió esa comprobación en el momento en el que se reescribió de C++ a Java el código relacionado con las curvas elípticas. Seguro que se evitaron fallos relacionados con el manejo de memoria… pero se les olvidó un paso y ningún criptógrafo lo comprobó.

El fallo se notificó en noviembre de 2021. Oracle ha publicado la corrección en abril de 2022.

Más información:
https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/

El Project Zero de Google intenta encontrar y difundir 0days. Importante de nuevo: no los descubren directamente, sino que los “detectan” en cualquier fabricante mientras están siendo aprovechados por atacantes (esta es la definición de 0day). Así pueden analizar, alertar y corregir para cerrar esa puerta a los atacantes. Abogan por catalogarlos adecuadamente y ser transparentes para mejorar la comunidad.

Acaba de publicar sus conclusiones de 2021, con 58 0days encontrados mientras son aprovechados por atacantes, récord desde 2014 cuando comenzó su actividad. La plusmarca anterior fueron 28 en 2015.¿A qué se debe? Según la propia Google, no al mayor uso de 0days por parte de atacantes, sino a una actividad de detección y difusión mayor por su parte. Nunca se sabrá qué parte no se conoce o qué porción representa esos 58 del total.

Otra de las conclusiones es que la mayoría de esos 58 0days siguen prácticas muy similares a las de siempre: se basan en exploits y vulnerabilidades ya conocidas para desarrollar nuevos y exploits derivados. Solo dos constituían una novedad sus técnicas y sofisticación. Y esto es relevante. Porque siempre que se usen métodos, técnicas o procedimientos conocidos, en teoría es más fácil detectarlos de forma más sencilla por “esperables”. Aquí debería mejorar la industria.

Por cierto, de los 58, se han detectado solo 5 exploits funcionales. El resto, solo la vulnerabilidad.

Y para 2022, lo que esperan es que todos los fabricantes sean transparentes con los 0days encontrados, que sean compartidos y difundidos. O sea, etiquetar los fallos públicamente como “in the wild” cuando toque. Por ejemplo, es muy extraño que en programas tan golosos como los de mensajería instantánea, desde 2014 solo se conozca uno en WhatsApp y otro en iMessage.

Más información:
https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html

Después de muchos años hablando de ello, security.txt ya es un estándar con un RFC propio, el 9116. Este sencillo mecanismo permitirá estandarizar la fórmula de contacto con una compañía cuando alguien encuentre un fallo de ciberseguridad.

En la práctica, es tan sencillo como que una web cuelgue en su página un security.txt que describa qué política prefiere seguir cuando alguien quiere reportarle un fallo en ciberseguridad. El estándar permite que el formato sea totalmente legible, inequívoco y completo.
Un ejemplo sencillo de este recurso podría ser:

# Our security address
Contact: mailto:security@example.com
# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt
# Our security policy
Policy: https://example.com/security-policy.html
# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html
Expires: 2021-12-31T18:37:07z

Aunque por herencia puede ser encontrado en la raíz, el archivo security.txt debe ser colocado en la ruta /.well-known/

Más información: https://www.rfc-editor.org/rfc/rfc9116

La Cybersecurity & Infraestructure Security Agency (CISA) de EEUU acaba de publicar las 15 vulnerabilidades más comúnmente explotadas por atacantes durante 2021. No hay sorpresas en cuáles son las sospechosas habituales. Lo que no sorprendería es que, después de identificarlas tan claramente y disponiendo todas de parche, encontrasen objetivos jugosos con ellas.

Aunque sean 15, en realidad 8 corresponden a Exchange. Cuatro relacionadas con el fallo ProxyLogon, tres con ProxyShell y una ejecución de código adicional. También está el conocido fallo ZeroLogon en Windows.

Luego tenemos por supuesto a Log4Shell, un fallo de ejecución en Zoho ManageEngine (CVE-2021-40539) y una ejecución de código en VMware vSphere Client (CVE-2021-21972). El resto:

* Atlassian Confluence Server and Data Center (CVE-2021-26084). No es exactamente ejecución remota, sino ejecución arbitraria (comandos del propio sistema en principio no autorizados).
* Fortinet FortiOS and FortiProxy (CVE-2018-13379) (path traversal).
* Pulse Secure Pulse Connect Secure (CVE-2019-11510). Lectura arbitraria de ficheros.

Como dato curioso, para la mayoría de estos fallos, en dos semanas ya había una prueba de concepto para explotarlas después de que se conociera y solucionase la vulnerabilidad. Por último: tres de ellas ya estaban en el top 15 de 2020.

Más información: https://twitter.com/TelefonicaTech/status/1519976679266992128

La Unión Europea tiene sobre la mesa una iniciativa para permitir la libre competencia respecto a los denominados mercados digitales. Algo que inmediatamente parece apuntar (leyendo las consideraciones de la normativa) al Apple Store, la tienda exclusiva de aplicaciones para dispositivos iPhone, iPad y similares.
La plataforma móvil de Apple solo permite instalar aplicaciones a través de su propia tienda de aplicaciones, sin posibilidad de que un tercero ofrezca un canal alternativo de manera oficial. Al contrario de lo que ocurre en Android, donde ya es posible acceder a alternativas a Google Play.

Previsiblemente, el próximo año podría activarse el “Digital Markets Act”. Obligaría a diversos proveedores que poseen la exclusiva sobre un servicio a abrirse a que terceros puedan ofrecer servicios en igualdad de condiciones. Afectaría también a Facebook, WhatsApp y servicios similares donde solo existe un proveedor designado, para facilitar la interoperabilidad.

Esta directiva supondría una apertura que permitiría una mayor oferta. Pero desde el punto de vista de la ciberseguridad, la apertura de mercados a terceros conllevaría un riesgo implícito si no se emplean filtros adecuados para detectar aplicaciones maliciosas.

De hecho, ya tenemos la experiencia de Android con los mercados de terceros (e incluso a la propia Apple se le cuela malware de vez en cuando). Tendremos que estar vigilantes si esta apertura se materializa y en ese caso cómo se organiza el cibercrimen para abrir brecha a estas nuevas capacidades.

Más información: https://www.theverge.com/2022/5/8/23062666/eu-start-enforcing-the-dma-digital-markets-act-spring-2023-big-tech-regulation

75 vulnerabilidades corregidas este martes por Microsoft. 8 críticas, tres previamente conocidas y una ya siendo explotada en el Local Security Authority: CVE-2022-26925. Permite elevar privilegios, especialmente en entornos de directorio activo. Un atacante podría forzar a un controlador de dominio a que se autentique contra él con un NTLM, y aprovechando este token reenviarlo (ataque de relay) para ejecutar código en el servidor. Resulta muy parecida al fallo PetitPotam de agosto de 2021 y es necesario priorizar los controladores a la hora de parchear.

Hablando de controladores de dominio…CVE-2022-26923 es otro fallo grave en Active Directory Domain Services y afecta si en el domino está activo el Active Directory Certificate Service.

Otro fallo grave es el que afecta al sistema de ficheros remoto NFS, también muy parecida a un fallo corregido el mes pasado y descubierto por los mismos autores.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/

En la industria, está estandarizado (y los usuarios acostumbrados a) que las herramientas de cracking o parches para aplicaciones de pago sean detectadas por los antivirus. ¿Supone esto una verdadera ventaja? Los atacantes ya le han encontrado utilidad para pasar desapercibidos.

En la práctica, los usuarios que desean activar sin pagar (o parchear) un programa desactivan su antivirus durante la instalación, o lo activan como excepción. Hay casos como los del conocido KMSauto, que necesitan permanecer el Windows tras el parcheo. El usuario se habitúa a esa detección del antivirus o lo activa como excepción.
Los atacantes Lazarus aprovecharon precisamente esto para esconder su ataque bajo el directorio y la apariencia de KMSAuto que usaba la víctima en una investigación de ESET. No es que el parche fuera malicioso, sino que disfrazaron su ataque de KMSAuto introduciendo un payload malicioso en él. El antivirus lo detectaba, pero todos (incluida la propia ESET) deducían que ocurría por tratarse de una herramienta de parcheo o crack.

A ESET casi se le escapa esta forma de disfrazarse en el sistema. Siempre se ha afirmado que los cracks son un peligro porque pueden venir con algún malware asociado. Pero en este caso los atacantes han usado la detección (o la excepción creada permanente), como elemento de distracción o evasión… precisamente por ser siempre clasificadas este tipo de muestras como malware.

Es cierto que algunas casas antivirus distinguen entren “hacktools”, “crakctools”… en su nomenclatura, pero en la práctica los usuarios no prestan atención estas sutilezas y como en este caso, la detección puede tener un efecto contrario al deseado.

Más información: https://twitter.com/ESETresearch/status/1526183746524876802

Se ha detectado una nueva fórmula para ejecutar código en documentos Office con tres características preocupantes:

*Sin necesidad de macros maliciosas. La detección es muy baja, incluso por parte de Defender como EDR.
* Sin necesidad de adjuntar el documento al email.
* Y sin que el documento en sí tenga nada malicioso por sí mismo, sino que descarga la carga al vuelo.

En resumen, lo que se ha visto que están aprovechando atacantes es un Word que se trae un HTML de un servidor (ahí está la carga) que a su vez utiliza el protocolo MS-MSDT (Microsoft Diagnostic Troubleshooting ) para cargar código (en este caso PowerShell).

A esto añadimos más problemas:

*Aunque todavía no está claro, afecta a la mayoría de Office y O365.
* Si en vez de un formato DOCX, el atacante lo convierte a RTF, la ejecución se lanza sin que la vista protegida lo detenga (sin darle al botón “habilitar contenido”).
* Enviando un email que use el protocolo “ms-excel” y apunte a un xls malicioso colgado en algún punto, bastaría para que Outlook lo abriese con Excel al pinchar sobre él. Además de no ir adjunto de por sí, al no comenzar el protocolo por http, es posible que pase desapercibido para las pasarelas de seguridad del correo.

Todavía no está claro el alcance ni Microsoft se ha pronunciado, pero al haberse hecho público surgirán variantes a tener en cuenta. A este fallo se le ha llamado “Follina” por una referencia a un código postal en el ataque.

Más información: https://doublepulsar.com/follina-a-microsoft-office-code-execution-vulnerability-1a47fce5629e