- O incidente Storm-0558 ficou conhecido pela invasão ao Exchange Online e ao Outlook.com, mas surgiu uma análise indicando que a chave de assinatura MSA comprometida também poderia ser explorada para forjar tokens OpenID v2.0 de aplicações do Azure AD
- O alcance potencial do impacto se amplia para apps da Microsoft que usam autenticação com conta pessoal Microsoft, apps de clientes com “Login with Microsoft” e até apps multilocatário sob certas condições
- A chave pública em questão estava na lista de chaves OpenID da Microsoft pelo menos desde 2016, foi substituída entre 27 de junho e 5 de julho de 2023, e corresponde à acquired signing key e ao thumbprint divulgados pela Microsoft
- A Microsoft revogou a chave e impediu novas falsificações de tokens, mas apps que ainda confiam em sessões criadas antes da revogação ou em caches antigos de chave pública precisam de verificação separada
- Como tokens forjados podem ser criados offline, não ficam rastros de emissão no portal do Azure e, sem o token bruto ou logs com
kid, é muito difícil confirmar a invasão
Escopo do impacto além do Exchange Online
- A Microsoft e a CISA divulgaram um incidente de segurança que afetou vários clientes do Exchange Online e do Outlook.com
- Segundo a Microsoft, o Storm-0558, apontado como ator de ameaça ligado à China, obteve uma chave privada MSA e forjou tokens de acesso para o Outlook Web Access e o Outlook.com
- Também foi informado que o ator de ameaça explorou em conjunto dois problemas de segurança no processo de validação de tokens da Microsoft
- Na análise da Wiz Research, a chave comprometida não se limitava ao Outlook.com e ao Exchange Online, podendo também ser usada para forjar tokens de acesso de várias aplicações do Azure Active Directory
- aplicações que oferecem autenticação com conta pessoal
- aplicações gerenciadas pela Microsoft, como SharePoint, Teams e OneDrive
- aplicações de clientes com suporte a “Login with Microsoft”
- aplicações multilocatário em certas condições
Como a chave comprometida foi identificada
- Em 11 de julho de 2023, a Microsoft revelou que um agente malicioso havia obtido a MSA consumer signing key e que isso permitia forjar tokens de acesso para contas do Exchange Online e do Outlook.com
- A Wiz investigou a documentação oficial de validação de tokens OpenID da Microsoft para identificar quais chaves podiam assinar tokens OpenID de contas Microsoft e de aplicações do Azure Active Directory
- Na época, aplicações v2.0 do Azure para contas pessoais dependiam de 8 chaves públicas, enquanto aplicações multilocatário v2.0 do Azure com contas Microsoft habilitadas dependiam de 7 chaves públicas
- Segundo a verificação no Internet Archive Wayback Machine, uma das chaves públicas presente na lista desde pelo menos 2016 foi substituída entre 27 de junho e 5 de julho de 2023
- esse período coincide com o momento de troca da chave obtida mencionado pela Microsoft no blog
- o certificado da chave pública anterior foi emitido em 5 de abril de 2016 e expirou em 4 de abril de 2021
- o thumbprint é igual ao valor que a Microsoft divulgou em seu blog mais recente como “Thumbprint of acquired signing key”
- Embora a chave obtida pelo Storm-0558 fosse uma chave privada do tenant MSA da Microsoft, a análise indica que ela também podia assinar tokens OpenID v2.0 para diversas aplicações do Azure Active Directory
Por que o comprometimento de uma chave de assinatura OpenID é perigoso
- A Azure identity platform publica listas de chaves públicas confiáveis diferentes conforme o tipo de aplicação, e elas são usadas para verificar a integridade dos tokens emitidos pelo Azure Active Directory
- As aplicações AAD validam a assinatura do token com a lista correta de chaves públicas e então decidem se o token é confiável
- Se uma das chaves da lista for comprometida, aplicações que validam por essa lista podem, sob certas condições, aceitar tokens de acesso forjados como válidos
- Com base no que a Wiz inferiu do blog da Microsoft, o Storm-0558 parece ter obtido acesso a uma entre várias chaves usadas na assinatura e validação de tokens de acesso do AAD
- A chave comprometida era confiável para assinar tokens de acesso OpenID v2.0 de aplicações AAD voltadas a contas pessoais e a mixed-audience, ou seja, multilocatário ou contas pessoais
- Como resultado, em teoria o Storm-0558 poderia forjar tokens que o autenticassem como qualquer usuário em aplicações afetadas que confiassem em certificados Microsoft OpenID v2.0 para mixed audience e contas pessoais
- A chave de assinatura de um identity provider pode ser vista como um segredo ainda mais poderoso do que uma chave TLS
- mesmo com uma chave TLS vazada, o atacante ainda precisa se passar pelo servidor correspondente para ampliar o impacto
- uma chave de identity provider pode ser usada para forjar tokens com acesso direto, em uma única etapa, a caixas de e-mail, serviços de arquivos e contas em nuvem
- o mesmo risco se aplica não só à Microsoft, mas também ao vazamento de chaves de assinatura de grandes identity providers como Google, Facebook e Okta
Tipos de aplicações afetadas
- O escopo das afetadas se limita a aplicações do Azure Active Directory que usam OpenID v2.0 da Microsoft
- Aplicações v1.0 não são afetadas, porque não usam a chave comprometida para validação de tokens
-
Aplicações que suportam apenas contas pessoais Microsoft
- Aplicações do Azure Active Directory que usam o protocolo Microsoft v2.0 e suportam “Personal Microsoft accounts only” são afetadas
- Isso inclui aplicações gerenciadas pela Microsoft, como Outlook, SharePoint, OneDrive e Teams, além de aplicações de clientes com autenticação via Microsoft Account
-
Aplicações que suportam multilocatário e contas pessoais Microsoft ao mesmo tempo
- Aplicações do Azure Active Directory que suportam “mixed audience” e usam o protocolo Microsoft v2.0 também são afetadas
- O ator de ameaça podia forjar tokens de acesso válidos para se passar por usuários que entraram na aplicação com conta pessoal Microsoft
- A Microsoft introduziu uma extensão do protocolo OpenID para limitar a capacidade da chave MSA de se passar por contas organizacionais
- Os desenvolvedores devem verificar o issuer claim comparando-o com o campo issuer da lista de chaves públicas OpenID
- Essa validação existe para impedir que a chave MSA assine tokens de acesso com issuer diferente do tenant MSA
- A extensão é específica da Microsoft, e a responsabilidade pela implementação cabe ao dono da aplicação
- A Wiz acredita que muitas aplicações podem não ter esse procedimento de validação e, como resultado, ainda pode existir possibilidade de personificação de contas organizacionais
- Segundo o blog da Microsoft, o OWA também foi afetado por um problema semelhante
- Em 12 de julho, a Microsoft adicionou essa validação ao Azure SDK oficial
-
Aplicações que suportam apenas multilocatário
- Se uma aplicação multilocatário tiver sido configurada para depender do endpoint de chaves v2.0 common, em vez de “Organizations”, ela é afetada
- Esse tipo de configuração deve ser considerado incorreto
- A documentação oficial da Microsoft não deixa claro quando usar o endpoint “common”, então algumas aplicações multilocatário também podem ter sido afetadas
-
Aplicações single-tenant
- Aplicações single-tenant que suportam apenas “contas neste diretório organizacional” não são afetadas
Condições para a falsificação de tokens
- Na validação de tokens OpenID, o desenvolvedor da aplicação deve verificar se o token foi assinado por uma chave privada autorizada para o escopo pretendido e se o campo
audcorresponde ao escopo da aplicação de destino - A aplicação obtém os certificados permitidos para validação de assinatura a partir de um endpoint de metadados chamado
jwks_urie usa isso para validar o token - O ator de ameaça podia criar um token JWT, preencher dados como o endereço de e-mail da vítima e então assiná-lo com a chave comprometida registrada no endpoint público de certificados do Azure Active Directory, forjando assim um token de acesso válido
- No exemplo citado, o
kidda chave comprometida é1LTMzakihiRla_8z2BEJVXeWMqo - Segundo a orientação da Microsoft, para um token ser válido, o claim
issdeve ser o issuer do tenant MSA especificado no campo issuer do endpointjwks_uri, e o claimtidtambém deve ser o ID do tenant MSA,9188040d-6c67-4c5b-b112-36a304b66dad - Em aplicações AAD de mixed audience, desde que o alvo seja a personificação de uma conta pessoal, um token assinado pelo tenant MSA para uma conta Azure AD pode ser tratado como válido
- Os detalhes da validação de ID Token podem ser consultados na orientação oficial da Microsoft
Riscos que permanecem mesmo após a revogação da chave
- Como a Microsoft revogou a chave comprometida, aplicações do Azure Active Directory não aceitam mais como válidos tokens forjados com ela
- Mesmo tokens com tempo de expiração longo passam a ser rejeitados pela aplicação
- Ainda assim, se sessões já tiverem sido criadas em aplicações de clientes antes da revogação da chave, o ator de ameaça pode ter obtido persistência aproveitando permissões da aplicação
- emissão de chaves de acesso específicas da aplicação
- configuração de backdoors específicos da aplicação
- caso em que o Storm-0558 forjou um token de acesso para OWA antes da ação da Microsoft e obteve um token válido de acesso ao Exchange Online
- Aplicações que mantiveram cópias de chaves públicas AAD anteriores à revogação do certificado pela Microsoft também podem estar em risco
- se usarem repositórios locais de certificados ou chaves em cache e continuarem confiando na chave comprometida, permanecem vulneráveis à falsificação de tokens
- a Microsoft recomenda atualizar repositórios locais e cache de certificados pelo menos uma vez por dia
O que usuários do Azure devem verificar
- Para confirmar o uso da chave comprometida no ambiente, é preciso identificar aplicações potencialmente afetadas, procurar indícios de uso de tokens forjados e usar os Indicators of Compromise divulgados pela Microsoft para revisar atividades de IP relacionadas
- Se houver aplicações com cache de certificados públicos OpenID da Microsoft, esse cache deve ser atualizado
- A Microsoft adicionou ao Azure SDK oficial uma validação extra para impedir autenticação de contas organizacionais com chave MSA, e usuários desse pacote devem atualizar para a versão mais recente
Por que a detecção é difícil
- Como o ator de ameaça pode forjar tokens de acesso offline, não há rastros de emissão do token no portal do Azure
- Para verificar se houve uso da chave, clientes de nuvem precisam revisar logs específicos das aplicações AAD potencialmente afetadas
- Segundo a Wiz, o impacto atinge aplicações que usavam os seguintes endpoints na validação de tokens de acesso Microsoft v2.0
- Aplicações AAD potencialmente afetadas podem ser identificadas com Azure CLI consultando apps cujo
signinaudiencesejaAzureADMultipleOrgs,AzureADandPersonalMicrosoftAccount,PersonalMicrosoftAccount - Apps AAD que redirecionam para Azure WebApps também podem ser encontrados com uma consulta CLI separada
- Ao decodificar tokens de acesso usados na aplicação e verificar se o campo
kiddo JOSE Header contém1LTMzakihiRla_8z2BEJVXeWMqo, é possível localizar tokens assinados com a chave comprometida - Segundo a Microsoft, a chave comprometida estava inativa, então todo token de acesso assinado com ela deve ser tratado como suspeito
- Não há prática padronizada de logging por aplicação
- muitos donos de aplicações não têm logs detalhados com tokens de acesso brutos ou com a chave de assinatura
- por isso, identificar e investigar eventos pode ser extremamente difícil
- Em aplicações AAD multilocatário que não suportam contas pessoais Microsoft, é possível detectar tokens forjados pelos claims
issetid- tentativas de conexão com tokens de acesso assinados pelo tenant MSA ID
9188040d-6c67-4c5b-b112-36a304b66dadpodem indicar uso da chave comprometida
- tentativas de conexão com tokens de acesso assinados pelo tenant MSA ID
- Se o WebApp tiver HTTP Logs ativados, é possível verificar no Log Analytics se endereços IP associados ao ator de ameaça, citados no blog da Microsoft, acessaram a aplicação
Perguntas em aberto e conclusão prática
- O impacto total é muito maior do que o inicialmente divulgado e pode ter efeitos de longo prazo na confiança em nuvem, especialmente na camada de identidade, que é um componente básico da nuvem
- As aplicações potencialmente vulneráveis somavam milhões, incluindo apps da Microsoft e de clientes, e muitas não têm logs suficientes para determinar se houve comprometimento
- Donos de aplicações devem priorizar a atualização do Azure SDK para a versão mais recente e verificar se o cache da aplicação foi renovado
- Aplicações cujo cache não foi atualizado ainda podem permanecer vulneráveis a atores de ameaça que usem a chave comprometida
- O caso ainda está sob investigação, e com o que foi divulgado até agora é difícil responder como o ator de ameaça obteve a chave, exatamente quando isso ocorreu ou se outras chaves também foram comprometidas
1 comentários
Comentários do Hacker News
Chaves de assinatura do provedor de identidade são algo próximo do segredo mais poderoso dos tempos modernos. Por exemplo, são muito mais poderosas do que chaves TLS
Em muitos aspectos, estão no mesmo nível das chaves de uma autoridade certificadora (CA), e organizações que usam Microsoft e serviços Azure deveriam avaliar o impacto potencial
Parece que as pessoas esqueceram o velho ditado de “não colocar todos os ovos na mesma cesta”
Fico me perguntando por que a estrutura é de dezenas, centenas, talvez milhares de servidores compartilhando um pequeno número de chaves
Onde estão as chaves-raiz baseadas em HSM, as chaves intermediárias por datacenter, as chaves de assinatura efêmeras por servidor e as listas de revogação de certificados?
Também me pergunto se é realmente possível proteger com segurança tokens de portador (bearer token) nesse tipo de ataque, ou se deveríamos voltar para um modelo em que se apresenta um valor aleatório ao serviço de origem para recuperar a carga útil com segurança
Acabaram surgindo funcionalidades que só podem ser usadas quando os ovos estão todos no mesmo lugar
Já deixei a pipoca pronta para quando tudo desabar, e uma coisa é certa: a empresa não vai culpar a si mesma
Não sei se isso quer dizer apenas usar outro fornecedor que não tenha perdido a chave
Neste ponto, parece que na prática só existem quatro big techs
Chegou-se à conclusão de que “a chave MSA comprometida pode ter permitido que um invasor falsificasse tokens de acesso para vários tipos de aplicações do Azure Active Directory”
Isso inclui SharePoint, Teams, OneDrive, aplicações de clientes que oferecem “Entrar com Microsoft” e qualquer aplicação que ofereça autenticação com conta pessoal, como aplicações multilocatárias sob certas condições
Espero que tenha sido coincidência a Microsoft ter mudado recentemente o nome do Azure AD para Entra ID: https://devblogs.microsoft.com/identity/aad-rebrand/
Quando penso em um produto de segurança, não quero lembrar de um fornecedor que “deixa as pessoas entrarem”, em vez de manter agentes maliciosos do lado de fora. entra vem de entrar, ou seja, entrar/vir para dentro, então /s
Em espanhol, isso até soa como o imperativo, dando a sensação de estar mandando alguém “entrar!”
“O certificado da chave pública existente foi emitido em 5 de abril de 2016 e expirou em 4 de abril de 2021, e a impressão digital correspondia à da chave que a Microsoft publicou em seu post mais recente no blog como a ‘impressão digital da chave de assinatura adquirida’”
Se entendi isso corretamente, então quer dizer que a chave continuou em uso mesmo depois de expirada?
Fico curioso se alguém sabe onde a Microsoft usou essas chaves e qual desses métodos era usado
Um deles é o método de validação do TLS, em que Cn é assinado por Cn-1, depois por … até C0, e ao verificar a cadeia de certificados isso funciona mais ou menos assim
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 return NOT_EXPIRED
A data de expiração de cada certificado é verificada com base na hora atual
O outro é o método usado para assinatura de código, mais ou menos assim
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
Cn é verificado com base na hora atual, e os demais com base no momento em que o certificado imediatamente abaixo foi assinado
Dá para entender por que assinatura de código funciona assim. Em essência, é uma autenticação digital, então não faria sentido que um documento já autenticado deixasse de ser autenticado só porque o tabelião perdeu a qualificação depois e sua licença expirou
E quando disse que “por causa de um problema de validação, essa chave pôde ser confiável para assinatura de token do Azure AD”, deveria ter dito “por causa de vários problemas de validação, essa chave pôde ser confiável para assinatura de token do Azure AD”
E quando disse que “os agentes conheciam bem o ambiente-alvo, a política de logs, os requisitos de autenticação, as políticas e os procedimentos”, talvez fosse melhor ter dito algo assim
“Os agentes talvez estivessem apostando em uma ação ousada de bater e correr e não tenham dado um segundo sequer para detalhes burocráticos como políticas. Ou talvez fossem incompetentes e nem soubessem que o Departamento de Estado dos EUA nos paga muito mais para ter o privilégio de registrar em detalhe eventos de acesso a caixas de correio. A Boeing já deu a dica com o MCAS. Além disso, os agentes parecem ter ignorado que o Chrome 92 recebeu sua última atualização em 2021 e é uma escolha bem ruim de user-agent para atacar sistemas de TIC de órgãos dos EUA, que deveriam usar navegadores atualizados. Também parecem saber muito pouco sobre como as caixas de correio do Departamento de Estado dos EUA são acessadas e ter feito palpites ruins usando datacenters públicos aleatórios espalhados pela Europa.”
[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
[2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
[3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...
Parece muito improvável que essa chave estivesse em um HSM
Sempre fico surpreso toda vez que vejo notícia de uma chave que claramente deveria estar em um HSM ter sido roubada
Recentemente tive a chance de criar eu mesmo uma ferramenta ideal para preencher a lacuna entre toolchains modernas e enclaves de segurança em hardware: https://keymux.com
Mesmo considerando a escala do Azure AD, talvez a Microsoft não precisasse de tantos HSMs para assinatura
Ainda assim, HSMs não são exatamente fáceis de administrar, e isso pode ser uma das razões pelas quais não são usados tão amplamente quanto deveriam
[1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
Primeiro, a Microsoft pode ter carregado a chave de assinatura JWT na memória para uso, e o invasor pode ter obtido a chave por injeção de código ou acesso à imagem de memória desse processo
Segundo, a Microsoft pode de fato ter usado um HSM, mas precisou distribuir a chave geograficamente, e o invasor pode ter conseguido acesso à chave nesse processo
O primeiro parece mais provável, mas o segundo não pode ser descartado
Não deveríamos legalizar que as FAANG façam guerra cibernética/espionagem umas contra as outras?
Assim, em vez de depender de obscuridade, talvez chegassem pelo menos a um nível mínimo de boas práticas de segurança
Já é legal desde que não se cause dano real, não se baixe dados reais de clientes e se divulgue o que foi encontrado
O Satya provavelmente vai precisar dizer IA muito mais vezes na próxima divulgação de resultados para encobrir essa bagunça
É difícil imaginar uma violação pior do que uma potência estrangeira entrar na conta de e-mail de representantes nossos que lidam com essa potência
Espero que o governo dos EUA reavalie seriamente as políticas de migrar computação para os principais provedores de nuvem
“Por fim, agradecemos à equipe da Microsoft por trabalhar em estreita colaboração conosco neste texto e por ajudar a garantir sua precisão técnica”
Como foi tomada a decisão de divulgar essa notícia na sexta-feira?
Procurei por “microsoft” no Google News e desisti depois de olhar as primeiras 5 páginas; havia só 2 menções relacionadas no total
A maior parte eram “notícias” como matérias promocionais, divulgação de produtos e ruído sobre ações
“O impacto total deste incidente é muito maior do que entendíamos inicialmente. Este incidente terá efeitos de longo prazo sobre a confiança na nuvem e nos componentes centrais que a sustentam, sobretudo na camada de identidade, o tecido fundamental de tudo o que fazemos na nuvem. Precisamos aprender com isso e melhorar”
Talvez o começo seja justamente não colocar tudo na nuvem
O problema, no fim, não é a nuvem em si, mas o capitalismo quebrado que acaba produzindo monopólios, ou cartéis de poucas grandes empresas
Para a longa cauda de pequenas empresas, muitas vezes nem faz sentido usar produtos e serviços de gigantes, mas dar ainda mais poder aos vencedores do mercado acaba criando empresas grandes demais para quebrar
Essas grandes empresas passam a ter uma superfície de ataque enorme por causa de um único erro, um único escorregão. Não é uma questão de se isso vai acontecer, mas de quando vai acontecer
No longo prazo, se a sociedade quiser sobreviver, a resposta são serviços federados, mesmo que isso exija abrir mão de parte da conveniência
Líderes empresariais não são nerds de tecnologia sonhando com serviços federados maiores e melhores
TI costuma ser um grande custo, tanto no demonstrativo de resultados quanto no tempo e no desgaste de aprender, decidir e brigar com problemas de computador
Fazendo uma analogia: se o tempo está duvidoso e mesmo assim você decidiu voar com a Microsoft Airlines, se o voo for cancelado e você se atrasar, haverá muita companhia e simpatia junto com você
Já se você escolhe seguir um caminho próprio e pegar o trem, todo o peso de entender horários, estações e afins cai sobre você, porque “avião é o jeito que todo mundo conhece”
E se a Microsoft Air chegar sem problemas, mas o trem der algum problema, você vai acabar se destacando sozinho como uma pilha fumegante no chão da cozinha
Foi um ótimo resumo, e assustador
Mesmo sendo um tema complexo, foi explicado de forma fácil de digerir