Conta de teste hackeada da Microsoft tinha privilégios de administrador
(arstechnica.com)- A invasão da Microsoft é mais grave do que um simples sequestro de conta, pois uma conta de teste antiga sem MFA levou ao acesso a e-mails de executivos seniores e das equipes de segurança e jurídica
- O grupo ligado ao Estado russo Midnight Blizzard explorou credenciais fracas por meio de password spraying e fez login em uma “legacy non-production test tenant account”
- A partir do tenant de teste comprometido, os invasores usaram permissões de app OAuth para obter a função
full_access_as_appno Office 365 Exchange Online - Como conceder
full_access_as_appexige privilégios de administrador, surgiram críticas de que a conta de teste era uma configuração incorreta com privilégios excessivos no ambiente de produção - Contas de teste fora do princípio do menor privilégio e password spraying baseado em proxies residenciais dificultam a detecção centrada em indicadores de comprometimento tradicionais
Da conta de teste ao acesso a e-mails
- Hackers estatais russos exploraram credenciais fracas com password spraying e fizeram login em uma “legacy non-production test tenant account”
- Essa conta de teste não era protegida por autenticação multifator
- Depois disso, foram obtidas permissões capazes de acessar contas de e-mail de executivos seniores da Microsoft e de funcionários das equipes de segurança e jurídica
- O grupo de ataque Midnight Blizzard abusou do protocolo de autenticação OAuth para manter acesso contínuo a contas de e-mail privilegiadas
- Criou um app malicioso no tenant de teste comprometido
- Concedeu ao app permissão para acessar todos os endereços de e-mail do serviço de e-mail Microsoft Office 365
- Concedeu a uma aplicação OAuth de teste existente a função
full_access_as_appno Office 365 Exchange Online
Conta de teste legacy com privilégios de administrador
- A atualização da Microsoft incluía a informação de que uma “legacy test OAuth application” tinha elevated access no Microsoft corporate environment
- Segundo Kevin Beaumont, para conceder a um app OAuth a função
full_access_as_app, a conta precisa ter privilégios de administrador - Beaumont avaliou essa configuração como “um erro de configuração bastante grande em produção”
- Surgiram críticas de que é difícil imaginar uma justificativa razoável para conceder e manter permissões tão amplas em uma conta de teste legacy antiga
- A Microsoft se recusou a explicar por que a conta de teste foi configurada assim desde o início e por que foi mantida mesmo depois de se tornar legacy
Configuração fora do princípio do menor privilégio
- Essa configuração viola o princípio do menor privilégio, segundo o qual uma conta deve ter apenas as permissões mínimas necessárias para executar suas tarefas
- O ponto central do problema é que é difícil entender por que uma conta de teste legacy deveria ter privilégios de administrador
- Beaumont comparou isso a ter um usuário Domain Admin de um sistema de produção em um domínio de teste sem segurança, MFA, firewall ou monitoramento
- Um usuário Domain Admin tem privilégios administrativos totais sobre dispositivos conectados à rede, incluindo controladores de domínio e Active Directory
- Por ser a conta mais poderosa da rede, deve ser isolada, e raramente deveria fazer parte de sistemas de produção
- Se uma conta desse tipo ficar abandonada sem uma senha forte e medidas de segurança padrão, o dano aumenta
Invasões a outras organizações e password spraying discreto
- A Microsoft detectou que o Midnight Blizzard também havia comprometido outras organizações e notificou as organizações afetadas
- A Hewlett-Packard Enterprises também informou que sua rede foi hackeada pelo Midnight Blizzard
- Essa invasão ocorreu em maio
- A descoberta e o bloqueio só ocorreram em dezembro
- O password spraying usado para acessar a conta de teste foi realizado contra um número limitado de contas, com poucas tentativas por conta
- Os invasores usaram uma infraestrutura distribuída de proxies residenciais para tornar a atividade maliciosa menos visível
- Conectavam-se a partir de endereços IP com boa reputação
- Usavam endereços IP localizados em regiões esperadas
- Faziam a atividade parecer misturada ao tráfego de usuários legítimos
Limites da detecção baseada em indicadores de comprometimento tradicionais
- O método usando proxies residenciais não é novo e também foi usado no ataque à cadeia de suprimentos da SolarWinds em 2020
- O ataque à SolarWinds também é atribuído ao Midnight Blizzard
- Como proxies residenciais roteiam tráfego por meio de um grande número de IPs de usuários legítimos, a detecção tradicional baseada em indicadores de comprometimento se torna praticamente difícil
- Midnight Blizzard é um grupo que os governos dos EUA e do Reino Unido afirmam atuar para o SVR, o serviço de inteligência externa da Rússia
- Outros nomes usados para rastrear o mesmo grupo incluem APT29, the Dukes, Cloaked Ursa, UNC2452 e Dark Halo
1 comentários
Comentários do Hacker News
Isso lembra um antigo hack do Roblox sobre o qual ouvi falar. Havia um site de staging não operacional com cadastro de usuários habilitado, e um banner dizendo “o que está aqui não é permanente”
Uma nova conta de administrador foi adicionada ao ambiente de produção, e alguém se cadastrou no site de staging com o mesmo nome de usuário; depois, usando esse cookie e token, conseguiu tomar a conta de produção e comprometer o site
Se os tokens criptográficos são gerados com base no nome de usuário ou no ID do usuário sem usar segredos diferentes para produção e staging, ou se o site de staging se comunica com serviços externos e isso se mistura com concessões de privilégio em produção, esse tipo de problema provavelmente não é tão raro
Assim que percebi, avisei imediatamente e com total transparência
Em grandes empresas, a fronteira entre desenvolvimento e produção tem muito mais brechas do que as pessoas gostam de imaginar
Pensando em um dia típico: você faz login no PC, checa o e-mail e depois entra no portal do Azure com as mesmas credenciais. No fim, tudo está preso ao mesmo tenant, e a conta também está ligada ao GitHub e às contas de nuvem
Groups e Teams são criados por toda parte, e coisas que surgiram só para usar Teams ou OneDrive, com permissões suspeitas anexadas, acabam ficando no diretório corporativo quase indistinguíveis dos grupos de segurança
De vez em quando chega um e-mail automático perguntando “você ainda precisa disso?”, mas a mensagem é opaca e, numa empresa muito grande, nem há para quem perguntar. O help desk só responde dois dias depois, e também não dá para perguntar ao John Savill no Twitter, então você simplesmente clica em confirmar e segue em frente
No fim, o tecido da organização começa a se rasgar, e o atacante entra por algum ponto fraco com um pouco de sorte, faz movimentação lateral dentro do tenant e leva o que quiser
Como disse um CISO sábio, hackers não invadem, eles fazem login
Como se todo mundo usasse Microsoft Cloud, Skype, Twitter, OneDrive e afins, e ainda joga no meio o nome de uma pessoa como se isso desse credibilidade
Sobre a fala de Kevin Beaumont — “apenas contas com privilégios de administrador podem conceder ao app OAuth a função full_access_as_app, que dá algo próximo a acesso total. Alguém cometeu um erro de configuração bem grande no ambiente de produção” —, olhando de fora e sem conhecer os detalhes do sistema, isso não parece ser o problema central
Não deveria nem existir uma forma de cometer esse tipo de erro. Quem projetou e quem opera o sistema deveriam ter tornado isso impossível, e é aí que está a responsabilidade
Se você constrói e opera uma fábrica com um botão que eletrocuta todo mundo lá dentro, e alguém aperta esse botão por engano, fica bem claro onde está o problema
Durante anos, vi políticas, procedimentos, normas e leis sendo ignorados, e recebi várias vezes a exigência de dar privilégios de superadministrador/root a VIPs que não precisavam de nada disso
Hoje tudo piorou porque todo mundo acumula funções, trabalha em tempo parcial, tem papel duplo ou triplo
Já vi controle de acesso baseado em papéis com mais papéis do que permissões reais que podiam ser concedidas. Nessa hora, o próprio objetivo do RBAC entra em colapso. Era mais rápido conceder permissões individualmente, mas isso não era permitido porque depois os relatórios não mostrariam um papel
Isso não vem da equipe técnica, vem de má liderança
No passado, cheguei a projetar uma extensão para o sistema de permissões RBAC de um ERP interno para mitigar esse problema. Criei um tipo chamado “exceção de permissão”, de modo que pessoas que precisavam de permissões fora do papel recebessem isso por esse mecanismo, permitindo gerar um relatório com a lista de quem podia executar tarefas fora da função do cargo
No fim era só um flag a mais na permissão, mas funcionou bem. O RH revisava trimestralmente as exceções de permissão para removê-las, e alguém que realmente entendia as permissões podia manter o controle, em vez de um help desk meio período ir desmontando tudo na base da tentativa e erro
Há um monte de certificações de segurança bonitas dizendo que protegem empresas e setores com risco quantificável, mas é engraçado como boas práticas racionais e ponderadas descritas num livro de US$ 36 na Amazon são completamente ignoradas
Segurança acaba parecendo uma campanha de laço decorativo
Quem vende segurança como se fosse produto está enganando os outros
Funcionários em geral quase não se importam com segurança; eles só fazem o trabalho deles
Há servidores, aplicações e configurações demais para que apenas funcionários com consciência de segurança consigam revisar tudo
Se você olhar por tempo suficiente, em algum momento toda empresa vai acabar com algo aberto que não deveria estar aberto. O trabalho dos grupos de hackers é justamente continuar procurando essas brechas
E como a empresa precisa continuar criando novos servidores e novas configurações durante a operação, isso não é algo que se configura uma vez e pronto
Odeio quando, ao entrar num emprego novo, alguém sai distribuindo permissões porque “assim é mais fácil”. Não devia ser assim
Isso não só expõe a empresa a comprometimentos, como também joga sobre mim uma responsabilidade que eu não quero. Posso quebrar algo importante por engano e, se alguma coisa for hackeada, as pessoas podem suspeitar de mim só porque eu tinha aquelas permissões
Na prática, estamos vivendo algo como os pop-ups de segurança do Windows XP no nível dos serviços. A cada etapa do trabalho pedem autenticação em alguma coisa diferente, e pode levar dias até você receber as credenciais certas com as permissões adequadas
Dá até para entender humanamente quando a equipe de suporte desiste e entrega de uma vez só para o recém-contratado um pacote com contas e permissões
O que está faltando neste texto é como os autores definem “produção” se uma conta não operacional tinha privilégios de administrador do domínio de produção
Então, focar no ângulo de que “em uma empresa de 220 mil pessoas, alguém cometeu um erro em algum momento” não ajuda muito
Mas, na maioria das empresas, normalmente existe uma linha firme e bem espessa entre sistemas de produção e de teste. Dar a uma conta de teste acesso à produção deveria ser praticamente impossível, então a investigação deveria se concentrar em como isso pôde acontecer
Já vi coisa pior. Trabalhei em um escritório de advocacia onde davam acesso de administrador a tudo para administradores e sócios
Depois da redefinição de senha, a senha padrão era “passme”, porque a senha original era longa demais e difícil de lembrar. Era obrigatório trocar a senha depois de fazer login no servidor
Um hacker comprometeu algumas dessas contas, mexeu em várias coisas e roubou dados. Algumas contas de teste também tinham privilégios de administrador
Ainda bem que não trabalho mais lá. Eu era analista-programador e só tinha privilégios de administrador no meu PC para conseguir rodar o Visual BASIC 6.0
Esse padrão está mais para regra do que exceção em todo o ecossistema Microsoft, mas o fato de a própria Microsoft ter feito isso é especialmente vergonhoso
A equipe de segurança da Microsoft vem dedicando um esforço considerável a ferramentas e documentação de boas práticas para evitar incidentes grandes como esse
O M365 é bem ruim para impor autenticação multifator. É algo que exige pagamento
O problema maior é que as pessoas esquecem. Criam cinco contas de teste com privilégios de administrador, e isso só aparece quando alguém faz uma auditoria das permissões de usuários em toda a empresa
Em uma empresa onde trabalhei, todas as senhas dos servidores e bancos de dados de produção ficavam em um arquivo de texto no repositório de código. O motivo era que o arquiteto-chefe não queria ter que memorizar senhas
Quando falei ao CTO o quão idiota aquilo era, ele respondeu: “nós confiamos nos funcionários” e “passamos na auditoria de segurança”
Até hoje sinto os efeitos de ter dado um tapa na própria testa
Acabam sendo só um incômodo, não um recurso de segurança. Em vez de usar uma senha como “c00lz500”, eu colocaria algo como uma string vazia
Em vez disso, usaria firewalls e rede interna