Resultados da principal investigação técnica sobre a aquisição de chave pelo Storm-0558
(msrc.microsoft.com)- O resultado da investigação técnica sobre o incidente em que o agente de ameaça baseado na China Storm-0558 acessou o OWA e o Outlook.com ao forjar tokens com uma chave de assinatura de consumidor MSA roubada
- Em abril de 2021, um travamento do sistema de assinatura de consumidor gerou um crash dump que, devido a uma condição de corrida (race condition), incluía a chave, e o sistema não conseguiu detectar isso
- O crash dump contendo a chave foi movido de uma rede de produção isolada para um ambiente de depuração na rede corporativa conectada à internet, sem ser detectado nem pela varredura de credenciais
- O motivo pelo qual era possível acessar e-mail corporativo com uma chave de consumidor foi que os desenvolvedores do sistema de e-mail presumiram incorretamente a validação de escopo da biblioteca e não adicionaram a validação de issuer/scope
- Todas as falhas já foram corrigidas, e ações posteriores fortaleceram a defesa em múltiplas camadas, incluindo a automação da validação de escopo de chaves
Como a chave foi obtida
- A Microsoft opera um ambiente de produção isolado e restrito com verificação de antecedentes, contas dedicadas, estações de trabalho de acesso seguro e autenticação multifator baseada em token de hardware
- Esse ambiente bloqueia o uso de ferramentas de colaboração, como e-mail, reuniões e pesquisa na web, para evitar vetores de comprometimento de conta, como infecção por malware e phishing
- O acesso a sistemas e dados é restrito por políticas de Just in Time / Just Enough Access
- O ambiente corporativo (corporate environment) exige certificação de segurança e dispositivos seguros, mas permite o uso de e-mail, reuniões e ferramentas de colaboração, ficando mais vulnerável a spear phishing e malware para roubo de tokens
- De acordo com os princípios de Zero Trust e "assume breach", o material de chaves não deve sair do ambiente de produção
- Em abril de 2021, um travamento do sistema de assinatura de consumidor gerou um crash dump (snapshot do processo que travou)
- O crash dump não deveria incluir a chave de assinatura, já que informações sensíveis passam por mascaramento, mas a chave foi incluída devido a uma condição de corrida (correção concluída)
- O sistema não conseguiu detectar a presença da chave no crash dump (correção concluída)
- O crash dump, então considerado como não contendo a chave, foi movido da rede de produção isolada para o ambiente de depuração
- Isso estava de acordo com o procedimento padrão de depuração, e a varredura de credenciais não conseguiu detectar a presença da chave (correção concluída)
- Depois do vazamento da chave, o agente Storm-0558 comprometeu a conta corporativa de um engenheiro da Microsoft
- Essa conta tinha permissão para acessar o ambiente de depuração onde estava o crash dump com a chave
- Devido à política de retenção de logs, não há registros específicos que comprovem o vazamento, mas esse é o caminho mais provável pelo qual a chave foi obtida
Por que uma chave de consumidor podia acessar e-mail corporativo
- Para atender à demanda dos clientes por suporte tanto a aplicativos de consumidor quanto corporativos, em setembro de 2018 foi introduzido um endpoint comum de publicação de metadados de chaves
- Como parte dessa integração, a documentação foi atualizada para deixar claras as exigências de validação de escopo das chaves por conta corporativa e de consumidor
- Foi fornecida uma API para validar criptograficamente a assinatura, mas a biblioteca não foi atualizada para executar automaticamente a validação de escopo (correção concluída)
- O sistema de e-mail foi atualizado em 2022 para usar o endpoint comum de metadados
- Os desenvolvedores do sistema de e-mail presumiram incorretamente que a biblioteca fazia a validação completa e não adicionaram a necessária validação de issuer/scope
- Como resultado, o sistema de e-mail aceitou solicitações de e-mail corporativo com tokens de segurança assinados por uma chave de consumidor (correção concluída com biblioteca atualizada)
Revisão posterior e medidas de melhoria
- Identificação e correção da condição de corrida que fazia com que chaves de assinatura fossem incluídas no crash dump
- Reforço da prevenção, detecção e resposta para casos em que material de chave seja incluído incorretamente em crash dumps
- Reforço da varredura de credenciais para detectar melhor a presença de chaves de assinatura no ambiente de depuração
- Distribuição de uma biblioteca aprimorada que automatiza a validação de escopo de chaves na biblioteca de autenticação, além de esclarecimentos na documentação relacionada
Atualização adicional de 12 de março de 2024
- Mantém-se a hipótese central de que, devido a um erro operacional, o material de chave saiu do ambiente de assinatura de tokens de segurança e foi acessado no ambiente de depuração por meio da conta comprometida de um engenheiro, sem mudanças no impacto para clientes e Microsoft nem na atividade do agente
- Embora tenha sido dito que o crash dump de 2021 poderia ser a causa do acesso pelo agente, nenhum crash dump contendo o material de chave afetado foi encontrado
- A condição de corrida mencionada afetava não a existência da chave no crash dump, mas sim se o crash dump podia ou não ser retirado do ambiente seguro de assinatura
- A expressão de que a retirada do crash dump estava em conformidade com o procedimento padrão de depuração significava que isso não era proibido no passado; atualmente, o procedimento padrão de depuração da Microsoft proíbe a retirada desse material do ambiente de produção
- A investigação em andamento revelou limitações na tecnologia de varredura de credenciais, que serão corrigidas assim que forem identificadas
1 comentários
Opiniões no Hacker News
Parece haver um elo perdido aqui: é fácil entender como uma chave privada poderia acabar acidentalmente em artefatos de depuração por causa de um bug de concorrência ou de segurança de memória, mas o invasor não teria que saber que ocorreu uma falha, conhecer a estrutura do crash dump e estar à espera dentro da rede interna da Microsoft?
Defesa assumindo comprometimento é uma boa estratégia de segurança de rede, mas não se deve simplesmente aceitar como premissa que houve de fato um comprometimento
Esse tipo de dado muitas vezes não é guardado com segurança proporcional ao seu valor real. Trabalhando em uma FAANG, vi que quase todos os novatos sem experiência em finanças ou conformidade corporativa acham aceitável anexar dados de falha a um bug tracker. Por isso, é preciso mudar o hábito para que coisas como crash dumps sejam colocadas em um cofre fácil de usar o suficiente para que as pessoas não queiram contorná-lo
Se houver uma conta de engenheiro comprometida, deve-se presumir que ela tem pelo menos acesso ao bug tracker e provavelmente também consegue obter ou gerar símbolos de depuração dos binários. O que resta é esperar algum engenheiro, por descuido, enviar um crash dump como anexo de bug e pegá-lo antes que alguém perceba e apague
Além disso, a ferramenta de varredura de credenciais da Microsoft não encontrou a chave, e como dizem que esse problema foi corrigido, parece que a chave estava em um formato detectável por varredura
No geral, parece um caso em que um engenheiro moveu para sua própria conta um dump contendo a chave e o deixou lá por um tempo; depois, o invasor comprometeu a conta, pegou todos os arquivos utilizáveis e, ao varrer as chaves com ferramentas melhores que as da Microsoft, acertou em cheio
Ou seja, o invasor já estava dentro da rede e encontrou o dump por acaso durante uma varredura não detectada, ou desde o início mirou especificamente essa conta
Ainda assim, do ponto de vista do invasor, a cadeia de eventos parece ter dado certo com sorte demais
Existem aulas de engenharia de sistemas que tratam de como pequenos problemas, em sequência e em uma ordem específica, acabam levando a uma falha catastrófica. Este caso pode ser chamado de uma falha catastrófica
Primeiro, precisa haver uma condição de corrida, e essa condição de corrida precisa levar a um resultado inesperado. Se o código foi testado e é muito usado, é bem possível que a probabilidade já fosse menor que 10% nesse ponto. Depois, um engenheiro precisa decidir justamente que precisa desse crash dump, o software de varredura de credenciais precisa não encontrar essa credencial específica, uma conta precisa ser comprometida e dar acesso à rede, esse usuário precisa ter acesso ao dump, e o hacker precisa encontrá-lo e levá-lo
Mesmo assim, como a chave era antiga e só deveria permitir acesso a contas de e-mail de consumidores, ela deveria ser segura; mas ainda havia um bug que aceitava chaves antigas e outro bug que não rejeitava essa chave de assinatura em tokens para contas de e-mail corporativas
É uma boa lição de engenharia de sistemas. Por mais esforço que se faça, no fim, quando pequenas coisas se acumulam em quantidade suficiente, ocorre um grande incidente; portanto, é preciso projetar para que, mesmo quando algo exploda, o raio de explosão seja limitado
A análise posterior é apresentada como se eventos azarados tivessem se sobreposto aleatoriamente. Como se o invasor tivesse por acaso mirado a Microsoft, por acaso houvesse uma condição de corrida, por acaso tivesse ocorrido uma falha e por acaso ele tivesse encontrado um crash dump em algum lugar
Mas também é preciso considerar a possibilidade de o bug inicial de condição de corrida ter sido inserido intencionalmente. A falha pode ter sido provocada de propósito, o invasor pode ter esperado o dump aparecer em um local específico, e pode ter havido um cúmplice
O ecossistema da Microsoft parece um carrinho de Lego montado de qualquer jeito com peças que as crianças do bairro trouxeram de suas casas
Quando se fala em condição de corrida, as pessoas dizem “probabilidade menor que 10%”, mas, na prática, pode acontecer em toda falha grande, só que as falhas não ocorrem com frequência
Só Deus sabe por que não fizeram o mascaramento antes de escrever no disco
Uma estrutura em que mais da metade do mundo empresarial ocidental depende do Outlook.com está muito perto de ser um estado profundamente errado, mas como os incentivos financeiros atuais não estão alinhados com resiliência nem com a fragmentação de entidades ultracentralizadas como o Outlook.com, esse tipo de coisa deve continuar acontecendo
Há pontos que não foram explicados com clareza: se foi detectado em 11 de julho de 2023 e há suspeita de que tenha ocorrido em abril de 2021, isso significa que o invasor tinha essas credenciais havia mais de 2 anos e que levou 2 meses da detecção até a divulgação
Também falta dizer quantos tokens foram falsificados e quanto acesso houve. Se não divulgaram, a tendência é presumir o pior
Também não há cronograma entre a detecção e a aplicação da correção; só dizem que “este problema foi corrigido”. Só dá para torcer que tenham corrigido rápido
Corrigiram os 4 problemas diretos, mas claramente parece haver um problema sistêmico, e também não fica claro o que farão a respeito
https://en.m.wikipedia.org/wiki/Adverse_inference
Uma violação como essa exige um entendimento muito profundo da infraestrutura interna da Microsoft. É seguro presumir que foi um trabalho organizado de uma equipe de hackers
Não é algo barato de fazer, mas a recompensa é enorme. A hipercentralização faz com que hackers concentrem esforços em um pequeno número de alvos de alto valor. Porque, se conseguirem, o ganho é imenso
Tenho quase certeza de que existem equipes de hackers patrocinadas por Estados que já estudam e analisam profundamente a infraestrutura interna de lugares como Google, Microsoft e Amazon. Esta violação mostra o quanto eles já a entendem bem
Acho que está na hora de descentralizar dentro de um perímetro de segurança mais amplo
Retirando a linguagem cautelosa, alguém baixou um minidump do ambiente de produção para uma estação de trabalho de desenvolvimento, e ele provavelmente ficou apodrecendo em algum lugar no OneDrive corporativo desse desenvolvedor até a conta ser comprometida. Alguém pegou o dump, encontrou a chave e tirou a sorte grande
A expressão “alguns bugs obscuros foram explorados de forma sofisticada” parece meio fora de lugar. Parece mais uma cadeia de erros em que nenhum dos sistemas de segurança fez seu trabalho
Não entendo por que não usaram HSM. O objetivo central desse tipo de hardware não é impedir o vazamento de material de chave?
[1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
Isso significa que a chave não estava armazenada em hardware irrecuperável, mas era acessível por um processo de servidor comum, código compilado normal rodando em um ambiente de alto privilégio
Também não há menção de que o sistema com acesso a essa chave estivesse em um ambiente separado, e não no ambiente operacional comum. Portanto, pode-se presumir que qualquer equipamento de produção podia acessar a chave, e que qualquer pessoa com acesso a esse ambiente poderia, potencialmente, exfiltrar material de chave
Olhando a seção de validação em https://learn.microsoft.com/en-us/azure/active-directory/dev..., se não deixei passar nada, parece que ainda falta a importância de verificar a data do emissor ou se ele foi revogado
Isso também não aparece no pseudocódigo, então é bem possível que existam outras implementações que confiem em qualquer chave que a Microsoft já tenha publicado, com exceção de casos como limpeza de cache
Se nem a Microsoft consegue usar corretamente sua própria plataforma de identidade no Outlook, um de seus principais produtos, que chance têm os outros?
Eles basicamente só verificaram se ela tinha sido assinada pela CA da Microsoft. Isso é um problema incrivelmente óbvio de se pegar em uma revisão de código
Um dos motivos pelos quais o impacto foi realmente grande parece ser que eles não fizeram rotação da chave. Pelo que parece, passou bastante tempo entre o momento em que a chave foi movida para onde não deveria estar e o momento em que ela foi de fato roubada
Se tivessem feito rotação frequente das chaves, teria sido impossível forjar tokens com essa chave
Sempre que leio textos assim, fico com a impressão de que é muito estranha a estrutura que deixa a resposta a um ataque em nível estatal nas mãos de uma empresa privada só porque o ataque é digital, e não físico
Se um caça chinês derrubasse um avião da FedEx sobre o Pacífico, isso seria considerado um ataque à soberania dos EUA, e o governo responderia de forma adequada. Ninguém esperaria que a FedEx mantivesse sua própria esquadrilha de caças para proteger seus aviões de carga. Também ninguém diria que “a culpa é da FedEx por não ter feito defesa antiaérea direito”
Mas, quando entramos no domínio digital, cria-se um clima de aceitação de que a Microsoft deve se defender sozinha contra a China e a Rússia
Governos prendem agentes estrangeiros com certa regularidade, mas essas prisões não levam a uma guerra total
Em segundo lugar, os EUA também fazem esse tipo de coisa o tempo todo, inclusive com países aliados, então é difícil justificar medidas mais fortes
O alcance e o volume dos ataques cibernéticos são muito grandes, mas entendo que os EUA também realizam muitos ataques externos em escala correspondente