- Karl Voit considera que a nuvem Microsoft Azure foi, na prática, hackeada e que, por falta de isolamento adequado, incidentes posteriores começaram a vir a público
- Como caso divulgado, ele relaciona a reportagem da Reuters de que 60.000 e-mails foram roubados de 10 contas do Departamento de Estado dos EUA
- A principal preocupação é que a Microsoft não conseguiu remover os invasores, ou não os removeu, o que torna difícil confiar em todo o sistema baseado em autenticação da Microsoft
- O escopo do comprometimento inclui a autenticação do Windows e, se houver uma relação interna de confiança entre certificados Azure hackeados e o GitHub, então o GitHub também seria afetado
- Isso se estende como fator de insegurança até ambientes de uso com forte dependência do GitHub, como o NixOS, além de ampliar o problema para a dificuldade de o usuário controlar seus próprios dados na nuvem
Preocupação com hack do Azure e falha de isolamento
- Karl Voit descreve toda a nuvem Azure da Microsoft como, na prática, hackeada
- Ele afirma que reuniu a lista de fontes relacionadas em seu texto You Can't Control Your Data in the Cloud
- O ponto central do problema, mais do que o hack em si, é sua avaliação de que as medidas de isolamento não foram suficientes, e por isso incidentes posteriores começaram a ser revelados
Caso de roubo de e-mails do Departamento de Estado dos EUA
- Como exemplo de incidente posterior, ele apresenta a reportagem da Reuters de que 60.000 e-mails foram roubados de 10 contas do Departamento de Estado dos EUA
- A reportagem da Reuters vinculada diz que hackers chineses roubaram 60.000 e-mails do Departamento de Estado dos EUA por meio do hack da Microsoft
- Esse caso é usado como evidência de que danos reais continuaram após o hack da Microsoft
Desconfiança no sistema de autenticação da Microsoft
- Voit considera que a Microsoft não conseguiu remover os invasores ou optou por não removê-los
- Como resultado, ele avalia que tudo o que a Microsoft certificou está tainted, ou seja, contaminado
- Ele afirma explicitamente que o alcance desse comprometimento também inclui a autenticação do Windows
Preocupações que se estendem ao GitHub e ao NixOS
- Em um texto posterior, ele diz que, se houver uma relação interna de confiança da Microsoft entre os certificados Azure hackeados e o GitHub, então o GitHub também deve ser considerado hackeado ou comprometido
- Ele afirma que, mesmo após migrar alguns hosts para NixOS, a ansiedade permaneceu por causa dos problemas envolvendo Microsoft e GitHub
- Ele avalia que a profunda dependência do GitHub mencionada em seu texto sobre experiência com NixOS, I Started With Nix, NixOS, Home Manager and Flakes, acabou se revelando uma grande desvantagem desse sistema operacional
Problema de controle de dados na nuvem
- O texto vinculado, You Can't Control Your Data in the Cloud, amplia o problema de Azure e da autenticação da Microsoft para a questão do controle de dados na nuvem
- O alerta na postagem do Mastodon se concentra na dificuldade de confiar em sistemas que dependem da autenticação da Microsoft e de relações internas de confiança
1 comentários
Opiniões do Hacker News
Olhando as seções de mitigação e fortalecimento no post do blog de incidentes da Microsoft, em 26 de junho o OWA deixou de aceitar a renovação de tokens emitidos por
GetAccessTokensForResource; em 27 de junho, o OWA bloqueou o uso de tokens assinados com a chave MSA roubada; e, em 29 de junho, a troca de chaves e a revogação das chaves de assinatura MSA válidas na época foram concluídasEm 3 de julho, diz que o uso dessa chave foi bloqueado para todos os clientes consumidores afetados a fim de impedir o abuso de tokens já emitidos
Não sou especialista em segurança, mas fico curioso para saber qual é o furo nessa estratégia
Se houvesse logs de auditoria permanentes e imutáveis, daria para rastrear todas as ações realizadas com autenticações assinadas direta ou indiretamente pela chave vazada, mas criar logs de auditoria que nem mesmo alguém com privilégios máximos consiga adulterar não é fácil nem barato
No pior caso, os logs de auditoria têm apenas a identidade autenticada, sem o método de autenticação, então talvez nem seja possível identificar facilmente acessos potencialmente comprometidos
No fim, o furo dessa estratégia é que ela não leva em conta os backdoors persistentes que podem ter sido adicionados enquanto era possível acessar usando a chave vazada. Ela impede novos abusos, mas, considerando a forma como a chave foi roubada, se o invasor era muito sofisticado, é quase impossível saber quantos caminhos de acesso secundários ele deixou criados
Esse problema parece se limitar ao Azure e à Microsoft; AWS e GCP devem estar ok
A Microsoft tem algumas das piores vulnerabilidades e práticas de segurança que já vi. Simplesmente não entendo como executivos de grandes empresas da Fortune 500 transferem workloads para o Azure
Em algumas áreas, o único argumento de venda do Azure é que a Amazon é uma concorrente. Seria bom se a Amazon simplesmente deixasse a AWS como algo independente
Espero que a Microsoft melhore a segurança, mas, a esta altura, parece quase sem esperança
Depois que as empresas entram no dashboard do Azure, a estrutura faz com que elas também experimentem algum serviço de aparência bacana oferecido ali
Parece tudo fumaça e espelhos, mas funciona
Por isso, se a organização ainda não cadastrou a AWS como fornecedora, normalmente é mais fácil empurrar o fornecedor existente
Eu também administrava um servidor web com Windows 2000 Pro e acabei mudando para Linux por falta de segurança
A Microsoft pode ser popular, mas tem grandes furos de segurança, e sempre teve
Serviços são comprometidos com frequência, sejam eles em nuvem ou gerenciados pelo cliente. A Microsoft tem uma equipe de segurança madura, profissional e eficaz
Foi comprometida por falhas de implementação e, em meu palpite pessoal, por um ou mais insiders corruptos
A maioria das organizações nem saberia o que aconteceu, e provavelmente não teria identificado o que foi divulgado
Em retrospecto, tudo parece fácil
É uma formulação muito exagerada. Foi claramente uma invasão grave, e talvez ainda não se entenda totalmente seu escopo, mas, em “poderiam ter implantado backdoors e chaves próprias por toda parte”, o ponto central é poderiam — ou seja, “até onde eu sei, é teoricamente possível”, não que eles de fato tenham feito isso
A conclusão de que “tudo da Microsoft foi hackeado e eles não conseguem, ou não querem, remover os invasores. Tudo que a Microsoft certificou está contaminado, inclusive a certificação do Windows” também é extrema
A resposta da Microsoft parece dizer claramente que eles substituíram as chaves e as moveram para um armazenamento mais seguro. Não dizem que removeram o atacante, mas também não dizem que o ataque continua em andamento. Isso também não significa que toda autenticação esteja arruinada para sempre
Sinto que a conclusão tirada é extrema
https://msrc.microsoft.com/blog/2023/09/results-of-major-tec...
E ainda assim é para acreditar que não deixaram backdoors persistentes em alvos de alto valor?
A conclusão tirada aqui é totalmente razoável. Para clientes comuns da nuvem pública, talvez essa afirmação até faça sentido. Backdoors indiscriminados só aumentariam o risco de descoberta
Mas grandes empresas e usuários governamentais precisam presumir comprometimento; caso contrário, é uma postura inacreditavelmente ingênua
Referência:
https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
A própria Microsoft escreve que o Storm-0558 tem alto nível de capacidade operacional técnica e segurança operacional, além de bom conhecimento do ambiente-alvo, políticas de logs, requisitos de autenticação, políticas e procedimentos
Quando se encontra uma vulnerabilidade zero-day, ninguém ignora o patch dizendo “provavelmente ninguém mais tem isso”
Este caso foi noticiado muito menos do que deveria, e o impacto potencial pode ser enorme. Minha queixa contra a Microsoft é esta: a chave vazou em 2021 e ainda estava assinando tokens de autenticação em 2023, mas entre os serviços do Azure não há nenhum em que o usuário possa inserir uma credencial de 2 anos
É o típico caso de “faça o que eu digo, não faça o que eu faço”
app registration secretsque duram até 2 anos. Até pouco tempo atrás, também era possível criar segredos praticamente sem expiraçãoIsto parece exagerado demais e alarmista. Não acho que as fontes comprovem a extensão da violação alegada no texto, ou seja, “a Microsoft inteira”.
Parece mais um caso de vazamento de chave temporário, depois revogada.
Também há isto:
https://infosec.exchange/@briankrebs/110820474957163710
Se for verdade, é bastante grave.
[1]: https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
[2]: https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...
https://karl-voit.at/cloud/
Na longa lista, há também a informação de que, em agosto de 2023, houve no Azure um problema de “acesso não autorizado a aplicações entre tenants e a dados sensíveis, incluindo segredos de autenticação”, que a Microsoft não conseguiu corrigir por meses e que, em 03/08/2023, ainda era uma vulnerabilidade pública do Azure.
No incidente de julho de 2023, diz-se que os clientes nem conseguiam detectar o invasor apenas com os logs básicos, e que era preciso pagar a mais para acessar esses arquivos de log.
A Microsoft não informou quais serviços foram ou não afetados, e a conclusão apresentada é que todos os serviços de nuvem da Microsoft devem ser considerados potencialmente comprometidos.
Também se afirma que especialistas em segurança, como Mike Kuketz, consideram que todos os sistemas Microsoft que usam autenticação em nuvem, até hosts Windows, devem ser tratados como comprometidos.
O texto da própria Microsoft no mesmo link também diz:
https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
“Atividade pós-comprometimento: nossa telemetria e investigação indicam que a atividade pós-comprometimento ficou limitada ao acesso e à exfiltração de e-mails de usuários-alvo.”
Portanto, não foi “a Microsoft inteira”. É o típico título exagerado; desta vez, só chamou atenção por causa de um post no Mastodon.
Essa plataforma também não é muito diferente do Twitter.
Acho que, daqui a alguns anos, hardware on-premises e hospedagem simples de servidores voltarão a ficar na moda.
Quando tudo era local e privado, a segurança muitas vezes era fraca, mas o invasor só conseguia acessar um dispositivo ou uma rede específica.
Agora, a recompensa por atacar uma única organização centralizada ficou tão grande que vale muito mais a pena para o atacante investir recursos muito maiores.
A cada um ou dois meses, era preciso migrar para alguma nova versão idiota do ambiente; mexer em entradas de DNS porque o app não conseguia enviar e-mail; configurar o IAM ruim e desnecessário do provedor de nuvem; registrar o app para acesso ao banco de dados.
Hoje há apps que exigem 15 minutos de manutenção por ano e 5 minutos para instalação e configuração.
Alguns provedores de nuvem têm recursos impressionantes, mas todos parecem estar ficando cada vez mais inchados, e o meu caso de uso não precisa de um cluster inteiro.
Também ouvi falar de vários projetos para criar mais serviços de nuvem europeus.
Se isso virar tendência, o mais provável é que seja na forma de contêineres ou orquestradores de Kata Containers sobre hardware on-premises.
Além disso, mesmo com software implantado on-premises, grandes organizações ainda precisam de single sign-on, e podem continuar expostas a esse tipo de ataque.
Isto é realmente sério. Graças a este texto, só agora estou lendo com atenção, e não entendo como isso passou tão abaixo do radar.
A empresa onde trabalho também integrou recentemente toda a autenticação de apps e serviços internos via Azure. Agora, olhando para trás, parece ter sido um erro, embora talvez eu esteja sendo paranoico demais.
Pouco antes deste caso, também houve um “incidente” em que qualquer pessoa podia alterar resultados específicos de busca do Bing, e provavelmente outros serviços também.
Como resultado, era possível acessar todos os dados que o navegador compartilhava com o Bing, incluindo todas as chaves de acesso da conta MS do usuário que usasse o Bing naquela busca específica.
O impacto é desconhecido, porque a Microsoft não divulgou. O motivo fica para cada um imaginar.
O texto é excelente e assustador, e parece conter apenas informações verdadeiras e verificáveis, mas não sei bem o que deveríamos esperar
Pessoas “comuns” não leem isso, não entendem e não conseguem avaliar o impacto. Ficou complexo demais. Socialmente, também não dá simplesmente para parar de usar os serviços mencionados
Talvez fosse mais razoável ensinar o seguinte: não existe privacidade, ela não pode ser garantida e ninguém tem incentivo para garanti-la; não existe segurança, e toda segurança já foi violada, foi projetada para ser violada ou será violada no futuro; toda informação digital já se tornou pública ou um dia se tornará pública
Não é preciso ter 10 anos de carreira em TI para entender que “a Microsoft permitiu que clientes abrissem os cofres de escritório de todo mundo com a chave da própria casa, escondeu isso por 2 anos e ainda não tem plano para consertar”
McNeally estava simplesmente errado. Mas o desespero é mais fácil do que consertar, então muita gente escolheu o desespero, e a popularidade da nuvem e do SaaS é o resultado disso
Isso não é um destino inevitável; na prática, basta não confiar em quem você realmente não confia
Mesmo que seja preciso usar o temido martelo regulatório
As pessoas ainda podem ter privacidade garantida. Por exemplo, entrando na floresta sem nenhum dispositivo
O incentivo para garantir a privacidade de outras pessoas pode ser um mecanismo legal de punição em caso de falha
Segurança absoluta não existe, mas existe segurança contra um determinado modelo de ameaça
Também é difícil aceitar por que dados guardados em um dispositivo que não está conectado à rede necessariamente se tornarão públicos
Mesmo deixando passar a expressão “pessoas comuns”, não vejo por que não se poderia viver sem serviços que nem sequer foram mencionados, ou mudá-los para algo mais favorável à privacidade
Uma educação mais razoável é a de que a privacidade é essencial para uma sociedade e uma economia funcionais. Quem diz o contrário está dizendo que vê uma oportunidade de ganhar dinheiro no curto prazo usando a assimetria de informação entre você e essa pessoa
Respeito Scott, mas aquela fala não foi um bom momento. Se trocarmos a mesma frase por “não existe propriedade, ela não pode ser garantida e ninguém tem incentivo para garanti-la”, também pode soar completamente verdadeira, mas na prática criamos formas de garantir a propriedade, que são a lei e o governo encarregado de aplicá-la. Podemos aplicar esse conceito comprovado à privacidade também
Toda fechadura pode ser aberta, mas nem todo mundo consegue arrombar uma fechadura, então ainda trancamos as portas
Também acho duvidoso que as maiores consultorias partam do princípio de que toda informação digital se tornará pública. Empresas como as descritas em “The Big Con”, de Mazzucato e Collington, até podem vender essa premissa, mas não operam de fato dessa forma
Por exemplo, se a McKinsey soubesse que os conselhos que deu à Purdue Pharma seriam tornados públicos, não teria perdido tanto
Em resumo, quem diz que privacidade não importa está, na verdade, dizendo que a sua privacidade não importa, e está confiante demais de que eles próprios podem permanecer privados por estarem à frente na assimetria de informação. A ironia disso aparece quando o Google tenta manter suas próprias informações em sigilo em um julgamento antitruste público
Online não há privacidade, e os provedores têm incentivo para vender os usuários. Por isso, é preciso se defender mantendo apenas uma presença online superficial
Se você é um usuário comum, deve colocar o mínimo de informação possível online, especialmente em redes sociais. Se precisar ter uma presença online, deve avaliar os riscos e gastar tempo e dinheiro para mitigá-los. Se esse esforço de mitigação não mostrar retorno sobre o investimento, é bem provável que você tenha sido enganado a acreditar que precisa de uma presença online
Segurança absoluta não existe. Toda defesa pode ser contornada, mas não necessariamente será. Basta avaliar o maior número possível de riscos e mitigar apenas aqueles em que se espera um retorno positivo sobre o investimento. Os riscos que não forem mitigados devem ser aceitos; os riscos que você não pode arcar devem ser evitados recusando-se a usar o sistema
Mesmo sem nenhum gerenciamento de risco, existe um nível básico de segurança porque uma parte da população com tendência criminosa calcula custos e recompensas. Quanto mais pessoas cínicas que conhecem os bastidores dizem que segurança não existe, mais essa linha de base se aproxima de zero, e mais vulnerável fica o público em geral
Quanto mais baixa a linha de base, mais tempo e dinheiro cada indivíduo precisa investir por conta própria para alcançar um nível de segurança tolerável. O cinismo nos faz pagar um preço; a ideia é não urinar nem defecar no moinho da vila só porque isso parece descolado
Hoje, informações digitais já se tornaram públicas ou podem se tornar públicas algum dia. Mas é possível escolher tecnologias que empurrem esse momento para um futuro mais distante, e, quanto às informações que ainda não foram digitalizadas, decidir conscientemente se a conveniência vale o risco
“Especialistas em segurança como Mike Kuketz acham que todos os sistemas da Microsoft que usam autenticação em nuvem, até mesmo hosts Windows, devem ser considerados comprometidos” é uma afirmação enorme
Parece haver uma possibilidade teórica de que a chave de assinatura roubada tenha sido usada como parte de um ataque maior para acessar serviços centrais como o Windows Update ou o plano de controle do Azure
Mas, se tivesse havido esse tipo de comprometimento sistêmico, acho que alguém teria percebido
A explicação da Microsoft mostra isso muito melhor do que o texto principal e o blog: https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
Além disso, ao contrário do que se afirma aqui, a Microsoft corrigiu o problema depois que tomou conhecimento dele: https://msrc.microsoft.com/blog/2023/09/results-of-major-tec...
E essas pessoas já tinham hackeado contas de engenheiros. A probabilidade de hackear apenas uma conta de engenheiro e encontrar essa chave por acaso é muito baixa, então é razoável considerar que várias contas de engenheiros da Microsoft já haviam sido hackeadas
Basicamente, contas MS não são seguras