Conta foi comprometida após incidente na AWS

Após a recente interrupção de serviço ocorrida na AWS, um usuário relatou ter sofrido um incidente em que sua conta da AWS foi comprometida por um atacante externo.

Caminho da invasão e situação do problema

• Foi mencionado que, durante o período da falha, algumas políticas de segurança podem não funcionar corretamente.
• O atacante deixou rastros de acesso anormais nos logs da conta após o incidente, e houve casos de criação/exclusão de recursos de forma inesperada.
• O usuário também expressou preocupação com a possibilidade de alteração de permissões ou exposição de credenciais durante a falha.

Danos e resposta

• Houve danos reais, como aumento de custos e vazamento de dados.
• Foi contatado o suporte da AWS para obter o histórico do incidente e orientar a resposta.
• Na comunidade, foi enfatizada a importância da prevenção prévia, como ativar autenticação de dois fatores e limitar o acesso por meio de controle de acesso baseado em funções.

[GN⁺]

Comentário do Hacker News

• Normalmente se pensa que coisas assim são coincidência, mas eu também já tive um caso de conta de cliente comprometida. O cliente era uma organização pequena, e de repente houve histórico de login no console e alteração de senha em duas contas IAM antigas que não eram usadas há mais de cinco anos. Na investigação, o que foi confirmado até agora foi apenas a criação de um ticket de suporte para habilitar acesso de produção do AWS SES e o aumento do limite diário de e-mails para 50 mil. É estranho que contas inativas há mais de cinco anos tenham começado a agir exatamente neste momento.

  • Dá para sentir cheiro de phishing. Por exemplo, se a pessoa receber um e-mail fingindo ser um aviso de incidente da AWS e for levada a fazer login no console, a segurança da conta pode ser comprometida ao autenticar via um wrapper malicioso.
  • Eu já passei por quase a mesma coisa há um ano. Login em uma conta muito antiga, acesso ao SES e pedido de aumento de limite de e-mail. Conseguimos agir rápido justamente porque o ticket de aumento de limite era obrigatório. Se ainda não verificou, também é preciso conferir as Roles recém-criadas. Nós limpamos a conta comprometida imediatamente e, enquanto revisava as roles, removi todas com menos de um mês de criação ou com privilégios de administrador. Ao mesmo tempo, foi confirmado que a invasão realmente começou a partir da minha própria chave. O primeiro usuário criado foi quase um mês antes da solicitação do SES, e o invasor pode ter nos comprometido primeiro e aproveitado quando aconteceu a pane da AWS. Isso pode ter sido escondido por se misturar com outros problemas da AWS.

• Para quem já tem acesso, é possível esperar por um incidente como a confusão na infraestrutura da AWS para então atacar, escondendo-se no tumulto. Mesmo que um token tenha sido exposto semanas ou meses atrás, pode não agir de imediato e esperar até um grande incidente. Se eu fosse o atacante, gostaria de testar essa estratégia.

  • Claro que é possível. Como analista de segurança, ouvi relatos reais disso. Atacantes às vezes preparam tudo com antecedência e esperam até um evento importante, como venda de empresa, para agir. Atacantes mais sofisticados também esperam proativamente por essas oportunidades.
  • Também sou da mesma equipe: eu tinha recebido um e-mail de alerta sobre a chave usada no abuso de hoje há dois anos por uma pessoa aleatória. Mas até ontem não houve abuso algum.
  • Estranhamente, talvez esse não seja um bom momento para ataque. Hoje todo mundo está de olho na AWS e fazendo muitos logins, então qualquer anomalia provavelmente será notada mais rápido. Se nossa empresa usa AWS, com certeza vamos monitorar tudo ainda mais nesse cenário.

• Se eu fosse atacante, eu escolheria o momento de ataque; uma grande pane em que a consolidação de logs nem funciona direito pode ser uma boa oportunidade. De fato, pode ter sido explorada nessa hora, já comprometidos, ou pode ter havido um ataque a partir de outros recursos aproveitando a pane da AWS.

• Em ambiente de nuvem, quando um recurso estranho (EC2 etc.) é criado, é possível conferir no CloudTrail qual evento o originou. Tipicamente, o evento runinstance resolve.

  • Não estou usando AWS ultimamente para checar o console diretamente, mas, se você passar por algo parecido, recomendaria em linhas gerais estes passos:
    1. Verificar a conta/sujeito que criou a EC2 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
    2. Rastrear ações subsequentes por userIdentity
    3. Conferir histórico de login direto no console (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
    4. Verificar históricos de solicitações de autenticação no Security Token Service (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
    5. Confirmar uso de AssumeRole via sessão STS (eventSource:sts.amazonaws.com, eventName:AssumeRole)
    6. Verificar tentativas de persistência como criação de IAM Role/Account novo (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
    7. Verificar se alguma Role/Account existente foi alterada para permissões mais altas (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
    8. Verificar histórico de criação/exclusão de Access Key (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
    9. Checar possibilidade de backdoor via alteração de IAMInstanceProfile em EC2 de produção (para referência, veja o AWS Docs Sample) Se houver suspeita de comprometimento mais profundo, recomendo pedir uma revisão e auditoria feitas por especialistas.
  • É uma boa informação, então vou dar uma olhada nos logs. Além disso, listando outras observações:
    1. Foram criadas cerca de 20 organizações sob a conta root, todas usando endereço de e-mail do domínio co.jp
    2. O invasor deixou vários templates de fargate criados
    3. Recursos foram criados em 16 a 17 regiões da AWS
    4. Pedidos de aumento de cotas do SES, recursos do WS Fargate e manutenção de notebook do SageMaker foram gerados desnecessariamente (recebi vários e-mails de notificação a respeito)
    5. Em alguns e-mails, detectei a adição de novos nomes (randô[e-mail])
  • O evento RunInstances é justamente esse evento.

• Alguns usuários do Reddit disseram que, durante a pane da AWS, ao atualizar a página, foram logados por um breve momento como outro usuário.

  • Numa empresa em que trabalhei antes também houve coisa parecida. Os clientes acabaram acessando os dados de outros clientes, e a causa era um funcionário errado fazendo debug ao vivo no ambiente de produção (era a mesma pessoa que eu tinha se oposto na entrevista). Foi realmente difícil rastrear e resolver.
  • Fico me perguntando se, no momento da pane, o DynamoDB chegou a ficar inconsistente temporariamente, e se as credenciais IAM não também se bagunçaram. Se for verdade, seria gravíssimo. Existe algum link de caso relacionado?
  • Se houver evidências disso, compartilhe. É realmente chocante.
  • Também me vem à cabeça se o ChatGPT não teve uma issue parecida recentemente. Há uma sensação semelhante.
  • Acidentes de segurança assim são muito mais graves do que simples incidentes de indisponibilidade de serviço.

• Em circunstâncias normais, esse tipo de incidente seria, em geral, mera coincidência, mas na maioria dos casos a causa é key de acesso exposta. Há também problemas causados por vazamento de senha de conta de console sem MFA, embora esse caso seja menos comum.

• Em situação de pânico, as pessoas ficam mais vulneráveis a ataques de phishing. É importante redefinir completamente as senhas e avisar a equipe da AWS. Normalmente, eles resolvem isso com base na confiança.

• A região us-east-1 é maior do que parece. Informações públicas recentes dizem que tem 159 datacenters. Pode haver centenas de milhares de contas concentradas lá. Esse fenômeno pode ter se ligado à pane da AWS, mas pessoalmente acredito que a chance de coincidência é maior.

  • 159 é muita coisa. Se tiver uma fonte confiável, compartilhe.

• Soa estranho, mas se você me enviar uma API key talvez eu consiga checar se ela está na lista de vazamentos.

  • Eu sei que é uma brincadeira, mas ainda assim é importante alertar com cuidado. Mesmo que seja uma piada, evite mencionar compartilhar API key ou credenciais; alguém pode levar a sério e isso pode causar problemas.