Anteriormente, nós sobre uma vulnerabilidade de dia zero descoberta no Internet Explorer, que permite usar um arquivo MHT especialmente preparado para baixar informações do computador do usuário para um servidor remoto. Recentemente, esta vulnerabilidade, descoberta pelo especialista em segurança John Page, decidiu verificar e estudar outro conhecido especialista nesta área - Mitya Kolsek, diretor da ACROS Security, uma empresa de auditoria de segurança e cofundador do serviço de micropatch 0patch. Ele crônica completa de sua investigação, indicando que a Microsoft subestimou significativamente a gravidade do problema.
Curiosamente, Kolsek inicialmente não conseguiu reproduzir o ataque descrito e demonstrado por John, onde usou o Internet Explorer rodando no Windows 7 para baixar e depois abrir um arquivo MHT malicioso. Embora seu gerenciador de processos tenha mostrado que system.ini, que foi planejado para ser roubado de si mesmo, foi lido por um script oculto no arquivo MHT, mas não foi enviado ao servidor remoto.
“Esta parecia uma situação clássica da marca da Web”, escreve Kolsek. “Quando um arquivo é recebido da Internet, aplicativos do Windows em execução adequada, como navegadores da Web e clientes de e-mail, adicionam um rótulo a esse arquivo no formato chamado Zone.Identifier contendo a string ZoneId = 3. Isso permite que outros aplicativos saibam que o arquivo veio de uma fonte não confiável e, portanto, deve ser aberto em uma sandbox ou outro ambiente restrito."
O pesquisador verificou que o IE realmente definiu esse rótulo para o arquivo MHT baixado. Kolsek então tentou baixar o mesmo arquivo usando o Edge e abri-lo no IE, que continua sendo o aplicativo padrão para arquivos MHT. Inesperadamente, a exploração funcionou.
Primeiro, o pesquisador verificou a “marca da Web”, descobriu-se que o Edge também armazena a fonte de origem do arquivo em um fluxo de dados alternativo além do identificador de segurança, o que pode levantar algumas questões em relação à privacidade deste método. Kolsek especulou que as linhas extras poderiam ter confundido o IE e impedido que ele lesse o SID, mas acontece que o problema estava em outro lugar. Após uma longa análise, o especialista em segurança encontrou a causa em duas entradas na lista de controle de acesso que adicionavam o direito de leitura do arquivo MHT a um determinado serviço do sistema, que o Edge adicionou ali após carregá-lo.
James Foreshaw, da equipe dedicada à vulnerabilidade de dia zero - Google Project Zero - twittou que as entradas adicionadas pelo Edge referem-se a identificadores de segurança de grupo para o pacote Microsoft.MicrosoftEdge_8wekyb3d8bbwe. Após remover a segunda linha do SID S-1-15-2 - * da lista de controle de acesso do arquivo malicioso, a exploração não funcionou mais. Como resultado, de alguma forma, a permissão adicionada pelo Edge permitiu que o arquivo ignorasse a sandbox no IE. Como sugeriram Kolsek e seus colegas, o Edge usa essas permissões para proteger os arquivos baixados do acesso por processos de baixa confiança, executando o arquivo em um ambiente parcialmente isolado.
Em seguida, o pesquisador queria entender melhor o que causa a falha do sistema de segurança do IE. Uma análise aprofundada usando o utilitário Process Monitor e o desmontador IDA revelou que a resolução definida do Edge impediu que a função Win Api GetZoneFromAlternateDataStreamEx lesse o fluxo de arquivo Zone.Identifier e retornou um erro. Para o Internet Explorer, tal erro ao solicitar a etiqueta de segurança de um arquivo foi completamente inesperado e, aparentemente, o navegador considerou que o erro era equivalente ao fato de o arquivo não possuir a marca “marca-da-web”, o que o torna automaticamente confiável, depois do motivo pelo qual o IE permitiu que o script oculto no arquivo MHT fosse executado e enviasse o arquivo local de destino para o servidor remoto.
“Você vê a ironia aqui?” pergunta Kolsek. "Um recurso de segurança não documentado usado pelo Edge neutralizou um recurso existente, sem dúvida muito mais importante (marca da Web), no Internet Explorer."
Apesar da crescente importância da vulnerabilidade, que permite que um script malicioso seja executado como um script confiável, não há indicação de que a Microsoft pretenda corrigir o bug em breve, caso ele seja corrigido. Portanto, ainda recomendamos que, como no artigo anterior, você altere o programa padrão de abertura de arquivos MHT para qualquer navegador moderno.
É claro que a pesquisa de Kolsek não passou sem um pouco de auto-relações públicas. Ao final do artigo, ele demonstrou um pequeno patch escrito em linguagem assembly que pode utilizar o serviço 0patch desenvolvido por sua empresa. 0patch detecta automaticamente software vulnerável no computador do usuário e aplica pequenos patches literalmente instantaneamente. Por exemplo, no caso que descrevemos, 0patch substituirá a mensagem de erro na função GetZoneFromAlternateDataStreamEx por um valor correspondente a um arquivo não confiável recebido da rede, de modo que o IE não permitirá que nenhum script oculto seja executado de acordo com o construído. na política de segurança.
Fonte: 3dnews.ru