Anteriormente, nós sobre unha vulnerabilidade de día cero descuberta en Internet Explorer, que permite utilizar un ficheiro MHT especialmente preparado para descargar información do ordenador do usuario a un servidor remoto. Recentemente, esta vulnerabilidade, descuberta polo especialista en seguridade John Page, decidiu comprobar e estudar outro coñecido especialista neste campo: Mitya Kolsek, director de ACROS Security, unha empresa de auditoría de seguridade e cofundador do servizo de micropatch 0patch. El crónica completa da súa investigación, que indica que Microsoft subestimou significativamente a gravidade do problema.
Curiosamente, Kolsek non puido reproducir inicialmente o ataque descrito e demostrado por John, onde utilizou Internet Explorer que se executaba en Windows 7 para descargar e despois abrir un ficheiro MHT malicioso. Aínda que o seu xestor de procesos mostrou que system.ini, que estaba planeado para ser roubado a el mesmo, foi lido por un script oculto no ficheiro MHT, pero non foi enviado ao servidor remoto.
"Isto parecía unha situación clásica de marca da web", escribe Kolsek. "Cando se recibe un ficheiro de Internet, as aplicacións de Windows que se executan correctamente, como os navegadores web e os clientes de correo electrónico, engaden unha etiqueta a ese ficheiro no formulario chamado Zone.Identifier que contén a cadea ZoneId = 3. Isto permite que outras aplicacións saiban que o ficheiro procede dunha fonte non fiable e, polo tanto, debe abrirse nun sandbox ou noutro ambiente restrinxido."
O investigador comprobou que IE realmente estableceu esa etiqueta para o ficheiro MHT descargado. A continuación, Kolsek intentou descargar o mesmo ficheiro usando Edge e abrilo en IE, que segue sendo a aplicación predeterminada para ficheiros MHT. Inesperadamente, o exploit funcionou.
En primeiro lugar, o investigador comprobou "mark-of-the-Web" e resultou que Edge tamén almacena a fonte da orixe do ficheiro nun fluxo de datos alternativo ademais do identificador de seguridade, o que pode suscitar algunhas dúbidas sobre a privacidade deste ficheiro. método. Kolsek especulou que as liñas adicionais poderían ter confundido a IE e impedirlle ler o SID, pero polo que se ve, o problema estaba noutro lugar. Despois dunha longa análise, o especialista en seguridade atopou a causa en dúas entradas da lista de control de acceso que engadiron o dereito a ler o ficheiro MHT a un determinado servizo do sistema, que Edge engadiu alí despois de cargalo.
James Foreshaw do equipo dedicado á vulnerabilidade día cero - Google Project Zero - tuiteou que as entradas engadidas por Edge fan referencia a identificadores de seguridade de grupo para o paquete Microsoft.MicrosoftEdge_8wekyb3d8bbwe. Despois de eliminar a segunda liña do SID S-1-15-2 - * da lista de control de acceso do ficheiro malicioso, o exploit xa non funcionaba. Como resultado, dalgunha forma o permiso engadido por Edge permitiu que o ficheiro ignorase o sandbox en IE. Tal e como suxeriron Kolsek e os seus colegas, Edge usa estes permisos para protexer os ficheiros descargados do acceso de procesos de pouca confianza ao executar o ficheiro nun ambiente parcialmente illado.
A continuación, o investigador quería comprender mellor o que fai que o sistema de seguridade de IE falle. Unha análise en profundidade utilizando a utilidade Process Monitor e o desensamblador IDA revelou finalmente que a resolución definida do Edge impediu que a función Win Api GetZoneFromAlternateDataStreamEx lera o fluxo de ficheiros Zone.Identifier e devolveu un erro. Para Internet Explorer, tal erro ao solicitar a etiqueta de seguridade dun ficheiro foi completamente inesperado e, ao parecer, o navegador considerou que o erro equivalía ao feito de que o ficheiro non tiña a marca "marca da web". o que automaticamente fai que sexa de confianza, despois de que IE permitiu que o script oculto no ficheiro MHT se execute e envíe o ficheiro local de destino ao servidor remoto.
"Ves a ironía aquí?" pregunta Kolsek. "Unha función de seguridade non documentada utilizada por Edge neutralizou unha función existente, sen dúbida moito máis importante (marca da web) en Internet Explorer".
A pesar da maior importancia da vulnerabilidade, que permite executar un script malicioso como un script de confianza, non hai indicios de que Microsoft teña a intención de corrixir o erro en breve, se algunha vez se soluciona. Polo tanto, aínda recomendamos que, como no artigo anterior, cambie o programa predeterminado para abrir ficheiros MHT a calquera navegador moderno.
Por suposto, a investigación de Kolsek non foi sen un pouco de auto-PR. Ao final do artigo, demostrou un pequeno parche escrito en linguaxe ensamblador que pode usar o servizo 0patch desenvolvido pola súa empresa. 0patch detecta automaticamente o software vulnerable no ordenador do usuario e aplícalle pequenos parches literalmente sobre a marcha. Por exemplo, no caso que describimos, 0patch substituirá a mensaxe de erro na función GetZoneFromAlternateDataStreamEx por un valor correspondente a un ficheiro non fiable recibido da rede, de xeito que IE non permitirá que se executen ningún script oculto de acordo co establecido na rede. en política de seguridade.
Fonte: 3dnews.ru