Previamente, nosotros sobre una vulnerabilidad de día cero descubierta en Internet Explorer, que permite utilizar un archivo MHT especialmente preparado para descargar información desde la computadora del usuario a un servidor remoto. Recientemente, esta vulnerabilidad, descubierta por el especialista en seguridad John Page, decidió comprobarla y estudiarla otro conocido especialista en este campo: Mitya Kolsek, director de ACROS Security, una empresa de auditoría de seguridad y cofundador del servicio de micropatch 0patch. Él crónica completa de su investigación, que indica que Microsoft subestimó significativamente la gravedad del problema.
Por extraño que parezca, Kolsek inicialmente no pudo reproducir el ataque descrito y demostrado por John, donde utilizó Internet Explorer ejecutándose en Windows 7 para descargar y luego abrir un archivo MHT malicioso. Aunque su administrador de procesos mostró que system.ini, que planeaba robarse a sí mismo, fue leído por un script oculto en el archivo MHT, pero no fue enviado al servidor remoto.
"Esto parecía una situación clásica de marca de la Web", escribe Kolsek. “Cuando se recibe un archivo de Internet, las aplicaciones de Windows que se ejecutan correctamente, como navegadores web y clientes de correo electrónico, agregan una etiqueta a dicho archivo en el formulario con el nombre Zone.Identifier que contiene la cadena ZoneId = 3. Esto permite que otras aplicaciones sepan que el archivo proviene de una fuente que no es de confianza y, por lo tanto, debe abrirse en un entorno limitado u otro entorno restringido".
El investigador verificó que IE realmente estableció dicha etiqueta para el archivo MHT descargado. Luego, Kolsek intentó descargar el mismo archivo usando Edge y abrirlo en IE, que sigue siendo la aplicación predeterminada para archivos MHT. Inesperadamente, el exploit funcionó.
Primero, el investigador verificó la "marca de la Web" y resultó que Edge también almacena la fuente del origen del archivo en un flujo de datos alternativo además del identificador de seguridad, lo que puede generar algunas preguntas sobre la privacidad de este método. Kolsek especuló que las líneas adicionales podrían haber confundido a IE y haber impedido que leyera el SID, pero resulta que el problema estaba en otra parte. Después de un largo análisis, el especialista en seguridad encontró la causa en dos entradas en la lista de control de acceso que agregaban el derecho a leer el archivo MHT a un determinado servicio del sistema, que Edge agregó allí después de cargarlo.
James Foreshaw del equipo dedicado a la vulnerabilidad de día cero - Google Project Zero - tuiteó que las entradas agregadas por Edge se refieren a identificadores de seguridad de grupo para el paquete Microsoft.MicrosoftEdge_8wekyb3d8bbwe. Después de eliminar la segunda línea del SID S-1-15-2 - * de la lista de control de acceso del archivo malicioso, el exploit dejó de funcionar. Como resultado, de alguna manera el permiso agregado por Edge permitió que el archivo pasara por alto la zona de pruebas en IE. Como sugirieron Kolsek y sus colegas, Edge usa estos permisos para proteger los archivos descargados del acceso de procesos de baja confianza ejecutando el archivo en un entorno parcialmente aislado.
A continuación, el investigador quería comprender mejor qué causa que falle el sistema de seguridad de IE. Un análisis en profundidad utilizando la utilidad Process Monitor y el desensamblador IDA finalmente reveló que la resolución establecida de Edge impidió que la función Win Api GetZoneFromAlternateDataStreamEx leyera la secuencia del archivo Zone.Identifier y devolvió un error. Para Internet Explorer, tal error al solicitar la etiqueta de seguridad de un archivo fue completamente inesperado y, aparentemente, el navegador consideró que el error equivalía a que el archivo no tuviera una marca de “marca de la Web”, lo que automáticamente lo hace confiable, después de por qué IE permitió que el script oculto en el archivo MHT se ejecutara y enviara el archivo local de destino al servidor remoto.
“¿Ves la ironía aquí?” pregunta Kolsek. "Una característica de seguridad no documentada utilizada por Edge neutralizó una característica existente, sin duda mucho más importante (marca de la Web) en Internet Explorer".
A pesar de la creciente importancia de la vulnerabilidad, que permite ejecutar un script malicioso como un script confiable, no hay indicios de que Microsoft tenga la intención de corregir el error en el corto plazo, si es que alguna vez se soluciona. Por lo tanto, seguimos recomendando que, como en el artículo anterior, cambie el programa predeterminado para abrir archivos MHT en cualquier navegador moderno.
Por supuesto, la investigación de Kolsek no estuvo exenta de un poco de relaciones públicas. Al final del artículo, demostró un pequeño parche escrito en lenguaje ensamblador que puede utilizar el servicio 0patch desarrollado por su empresa. 0patch detecta automáticamente el software vulnerable en la computadora del usuario y le aplica pequeños parches literalmente sobre la marcha. Por ejemplo, en el caso que describimos, 0patch reemplazará el mensaje de error en la función GetZoneFromAlternateDataStreamEx con un valor correspondiente a un archivo no confiable recibido de la red, de modo que IE no permitirá que se ejecuten scripts ocultos de acuerdo con el código integrado. en la política de seguridad.
Fuente: 3dnews.ru