La vulnerabilidad Windows Metafile (también llamada Ejecución de código de imagen de metaarchivo y abreviada como MICE ) es una vulnerabilidad de seguridad en la forma en que algunas versiones del sistema operativo Microsoft Windows manejaban las imágenes en formato Windows Metafile . Permite que se ejecute código arbitrario en los equipos afectados sin el permiso de sus usuarios. Se descubrió el 27 de diciembre de 2005 y los primeros informes de equipos afectados se anunciaron en 24 horas. Microsoft lanzó una actualización de alta prioridad para eliminar esta vulnerabilidad a través de Windows Update el 5 de enero de 2006. [1] Los ataques que utilizan esta vulnerabilidad se conocen como exploits WMF .
La vulnerabilidad se encontraba en gdi32.dll y existía en todas las versiones de Microsoft Windows desde Windows 3.0 hasta Windows Server 2003 R2 . Sin embargo, los vectores de ataque sólo existen en las versiones de Windows basadas en NT (Windows NT, Windows 2000 , Windows XP y Windows Server 2003 ). Los exploits que aprovechaban la vulnerabilidad en los sistemas basados en Windows NT facilitaban la propagación de varios tipos de malware , normalmente a través de descargas automáticas .
Debido a su impacto extremo, este error ganó el premio Pwnie 2007 por "Destrucción masiva" y "Rompiendo Internet".
Todas las versiones del sistema operativo Microsoft Windows son compatibles con el estándar de gráficos Windows Metafile. Todas las versiones desde Windows 3.0 hasta Windows Server 2003 R2 contienen esta falla de seguridad. [2] Sin embargo, Windows NT 4.0 y Windows XP , a menos que se les apliquen parches , son más vulnerables que las versiones anteriores porque su instalación predeterminada permite la ejecución de código de Windows Metafile, la fuente de la vulnerabilidad. [3] Las versiones posteriores de Windows no tienen esta vulnerabilidad. [2]
Según el experto en seguridad informática Steve Gibson , Windows NT 4 es vulnerable a exploits conocidos si la vista previa de imágenes está habilitada. [3] Los sistemas operativos Windows que no tienen habilitada la vista previa de imágenes o que tienen activa la Prevención de ejecución de datos (DEP) basada en hardware para todas las aplicaciones no deberían ser susceptibles a este exploit. [4]
Los sistemas operativos distintos de Windows (por ejemplo, macOS , Unix , Linux , etc.) no se ven afectados directamente. Sin embargo, un sistema que no sea Windows podría volverse vulnerable si ejecuta software para ver archivos WMF de Windows. Esto podría incluir software que incorpora o clona la biblioteca de vínculos dinámicos (DLL) de la Interfaz de dispositivo gráfico (GDI) nativa de Windows [1] o que ejecuta Windows o programas de Windows a través de un emulador o una capa de compatibilidad . Un sistema tipo Unix que usa Wine para emular Windows, por ejemplo, podría ser explotado. [5] Gibson escribió el programa MouseTrap, que su empresa distribuye como freeware , para detectar la vulnerabilidad de Windows Metafile en sistemas que ejecutan Windows y emuladores de Windows. [3]
Según las evaluaciones de F-Secure , [2] la vulnerabilidad es un defecto inherente en el diseño de los archivos WMF, ya que la arquitectura subyacente de dichos archivos es de una era anterior e incluye características que permiten que se ejecute código real cada vez que se abre un archivo WMF. El propósito original de esto era principalmente gestionar la cancelación de trabajos de impresión durante el spooling .
Según Secunia , "la vulnerabilidad se debe a un error en el manejo de los archivos Windows Metafile ('.wmf') que contienen SETABORTPROCregistros 'Escape' especialmente diseñados. Dichos registros permiten ejecutar funciones arbitrarias definidas por el usuario cuando falla la representación de un archivo WMF". Según la documentación del SDK de Windows 3.1, el SETABORTPROCescape quedó obsoleto y fue reemplazado por la función del mismo nombre en Windows 3.1, mucho antes de que se descubriera la vulnerabilidad de WMF. Sin embargo, el código de escape obsoleto se mantuvo para la compatibilidad con programas de 16 bits escritos para (o al menos compatibles con versiones anteriores) Windows 3.0. Este cambio se produjo aproximadamente al mismo tiempo que Microsoft estaba creando la reimplementación de 32 bits de GDI para Windows NT, y es probable que la vulnerabilidad ocurriera durante este esfuerzo.
El mecanismo 'Escape' en cuestión permite a las aplicaciones (no a los metarchivos) acceder a las características del dispositivo de salida que aún no están abstraídas por GDI, como las curvas de Bézier aceleradas por hardware , el soporte de postscript encapsulado, etc. Esto se hace pasando un código de operación, un tamaño y un puntero a algunos datos a la llamada, que normalmente solo los pasará al controlador. Debido a que la mayoría de las llamadas de Escape producen gráficos reales, el mecanismo de escape general está permitido en los metarchivos sin pensar originalmente en la posibilidad de usarlo para cosas como SETABORTPROC, los intérpretes de metarchivos modernos no vulnerables ahora verifican el código de operación contra una lista negra o lista blanca, mientras mantienen el conjunto completo de códigos de operación disponibles para el código regular que llama a las funciones de escape de GDI directamente (porque dicho código ya se está ejecutando de la misma manera que el código que podría hacer que GDI llame, no hay ningún riesgo de seguridad en ese caso).
Vale la pena señalar que Windows de 16 bits (excepto el modo Real de Windows 3.0, raramente utilizado) era inmune a la vulnerabilidad porque el puntero especificado en el metarchivo solo puede apuntar a datos dentro del metarchivo, y Windows de 16 bits siempre tenía una aplicación completa de no ejecución de datos exigida por la arquitectura segmentada del modo protegido de 16 bits. Windows NT para arquitecturas de CPU distintas de x86 de 32 bits (como MIPS, PowerPC, Alpha, Itanium y x86_64) requería programación orientada al retorno para explotarla porque esas arquitecturas tenían la funcionalidad de no ejecución que faltaba en los procesadores x86 más antiguos.
La vulnerabilidad es CVE - 2005-4560 en la base de datos Common Vulnerabilities and Exposures , referencia US-CERT VU#181038 y artículo 912840 de Microsoft Knowledge Base. Fue observada por primera vez en la red por investigadores de Sunbelt Software el 28 de diciembre de 2005 y anunciada públicamente por el presidente de la empresa, Alex Eckelberry. [6] [7]
Los equipos informáticos pueden verse afectados por la difusión de correos electrónicos infectados que contienen el archivo WMF pirateado como archivo adjunto . La infección también puede deberse a:
También se pueden utilizar otros métodos para propagar la infección. Dado que el problema se encuentra dentro del sistema operativo, el uso de navegadores que no sean de Microsoft, como Firefox u Opera, no proporciona una protección completa. Normalmente, se solicita a los usuarios que descarguen y visualicen un archivo malicioso que infecta el equipo. Los archivos infectados pueden descargarse automáticamente , lo que abre la posibilidad de infección mediante la indexación del disco o la vista previa accidental.
Según las evaluaciones de la empresa antivirus McAfee , [3] la vulnerabilidad se ha utilizado para propagar el troyano de puerta trasera Bifrost . Otras formas de malware también han explotado la vulnerabilidad para distribuir diversas cargas útiles maliciosas .
McAfee afirma que la primera generación de dichos exploits había sido detectada por más del 6% de su base de clientes hasta el 31 de diciembre de 2005.
Microsoft lanzó un parche oficial para solucionar el problema el 5 de enero de 2006. [8] Este parche puede aplicarse en lugar de otras medidas correctivas.
El parche oficial está disponible para Windows 2000 , Windows XP y Microsoft Windows Server 2003. Windows NT 4 y otros sistemas operativos más antiguos no recibieron un parche porque Microsoft ya no los soportaba. Steve Gibson afirmó en su podcast Security Now! nº 20 que su empresa Gibson Research Corporation pondría a disposición un parche para los sistemas Windows 9x si Microsoft no lo hacía. [9] Después de una investigación más profunda, Steve Gibson afirmó, en un podcast Security Now! nº 23 posterior , que Windows 9x y ME no son vulnerables y no necesitan parches. [10] Los usuarios de Windows 9x/ME pueden ejecutar su utilidad Mouse Trap para comprobarlo por sí mismos.
Paolo Monti, de Future Time, el distribuidor italiano del sistema antivirus NOD32 de Eset , ha proporcionado un parche descargable gratuito para Windows NT [11] . El parche funciona en sistemas operativos más antiguos, pero se suministra sin garantía.
Se han recibido informes de que el parche oficial se instala automáticamente incluso cuando la actualización automática de Windows está configurada para preguntar antes de instalar actualizaciones descargadas automáticamente. Esto provoca un reinicio automático , lo que puede provocar la pérdida de datos si el usuario tiene un programa abierto con cambios sin guardar. [4]
Estas medidas son de interés histórico sólo en los sistemas actualizados a partir del 5 de enero de 2006.
Como solución alternativa antes de que hubiera un parche disponible, [5] el 28 de diciembre de 2005, Microsoft recomendó a los usuarios de Windows que anularan el registro del archivo de biblioteca de vínculos dinámicos shimgvw.dll (lo que se puede hacer ejecutando el comando regsvr32.exe /u shimgvw.dlldesde el menú Ejecutar o el símbolo del sistema ) que invoca la vista previa de los archivos de imagen y es explotado por la mayoría de estos ataques. La DLL se puede volver a registrar después de aplicar el parche ejecutando regsvr32.exe shimgvw.dll. Esta solución alternativa bloquea un vector de ataque común pero no elimina la vulnerabilidad.
El 31 de diciembre de 2005, Ilfak Guilfanov publicó un parche de terceros [6] para desactivar temporalmente la llamada a la función vulnerable en gdi32.dll. Este parche no oficial recibió mucha publicidad debido a la falta de disponibilidad de uno oficial de Microsoft, y recibió la recomendación de SANS Institute Internet Storm Center [7] y F-Secure. [8] Debido a la gran cantidad de publicidad, incluida la publicación indirecta de slashdot , [9] el sitio web de Guilfanov recibió más visitantes de los que podía manejar y fue suspendido el 3 de enero de 2006; el parche todavía estaba disponible para su descarga desde varios espejos , incluido el sitio web de Internet Storm Center. [10]
El sitio web de Guilfanov volvió a estar disponible el 4 de enero en un estado muy reducido. Como ya no se ofrecía el parche en el sitio debido a problemas de ancho de banda , la página de inicio ofrecía una lista de servidores de réplica donde un usuario podía descargar el parche y el verificador de vulnerabilidades asociado, así como la suma de comprobación MD5 del archivo, de modo que se pudiera comprobar que el archivo descargado era probablemente genuino.
Después de que Microsoft lanzó su parche, Guilfanov retiró el suyo.
Microsoft afirma que su parche elimina la funcionalidad defectuosa en GDI32 que permitió la vulnerabilidad de WMF. Para los equipos que ejecutan una versión de Windows sin parchear, se recomendó un enfoque de defensa en profundidad para mitigar el riesgo de infección. Varias fuentes han recomendado medidas de mitigación que incluyen:
Según el artículo del Centro de Tormentas de Internet del Instituto SANS, el uso de un navegador web distinto de Internet Explorer puede ofrecer protección adicional contra esta vulnerabilidad. [12] Según la configuración, estos navegadores pueden preguntar al usuario antes de abrir una imagen con la extensión .wmf, pero esto solo reduce la posibilidad de abrir el metarchivo de Windows creado con fines malintencionados y no protege contra la vulnerabilidad que se está explotando, ya que estos navegadores siguen abriendo el metarchivo si se hace pasar por otro formato. Es mejor desactivar por completo la carga de imágenes en cualquier navegador que se utilice.
En 2006, Steve Gibson sugirió que la naturaleza peculiar del "error" era una indicación de que la vulnerabilidad era en realidad una puerta trasera diseñada intencionalmente en el sistema. [13] La acusación se convirtió en una afirmación y se extendió por Internet como un rumor después de que el sitio web de noticias tecnológicas Slashdot recogiera la especulación de Gibson. [13] El rumor fue ampliamente desacreditado [14] [15] y Thomas Greene, escribiendo en The Register , atribuyó el error de Gibson a "su falta de experiencia en seguridad" y lo llamó un "experto en tonterías". [13]
{{cite web}}: Falta o está vacío |url=( ayuda )