Proteger o ambiente da AWS de uma empresa SaaS após uma violação -

Uma empresa de SaaS crescente entrou em contato comigo após uma grave violação da AWS. O invasor acessou contas de estadiamento e produção com privilégios de administrador e causou danos significativos:

Bancos de dados comprometidos
Recursos e backups críticos excluídos
Exfiltração de dados

Quando o CTO me ligou, a equipe DevOps continha a violação.

A equipe recriou recursos em uma nova conta da AWS. Porém, danos significativos foram causados - a produção foi interrompida por uma semana (em termos simples, sem receita), mais de 1000 horas de desenvolvedor desaparecidas e dados exfiltrados.

Enquanto a empresa continha a violação, eles precisavam de ajuda para identificar a causa raiz e impedir incidentes semelhantes no futuro.

A empresa tinha frustrante Experiências com empresas de auditoria em nuvem para resposta a incidentes em nuvem, o que as levou a entrar em contato comigo através da minha página de chamada Discovery para uma revisão independente da causa raiz do incidente.

O que levou a esse incidente?

Depois de analisar o CloudTrail Logs, a entrada inicial do invasor no ambiente em nuvem ficou evidente – chaves de acesso vazadas pertencentes ao usuário do IAM com permissões excessivas de IAM (AdministratorAccess).

Algumas outras questões arquitetônicas dificultavam a detecção, a conter e a investigação do incidente:

Todos os recursos de produção (máquinas EC2, backups etc.) estavam em uma única conta.
A conta de produção também foi a conta de gerenciamento da Organização da AWS.
Nem todos os logs cruciais foram ativados, como logs de fluxo VPC. Os habilitados, como o Cloudtrail Management e os registros de dados, foram enviados para um balde S3 na mesma conta de produção.
Os sistemas de CI/CD usavam credenciais de usuário de produção de produção para implantar, mas o sistema CI/CD foi hospedado em uma conta de não produção (com controle de acesso indulgente).
Todos os bancos de dados RDS estavam em sub -redes públicas com IPS públicos, e o acesso foi controlado usando grupos de segurança.

Duas questões significativas nas pessoas e parte do processo foram:

As credenciais para inscrições foram compartilhadas entre os membros da equipe.
As chaves SSH dos desenvolvedores foram adicionadas ao mesmo usuário do Linux. Suas sessões SSH e comandos executados não foram registrados.

Devido aos problemas de arquitetura e processo acima combinados com um vazamento de chave do IAM com os privilégios do AdministratorAccess, o invasor teve acesso a quase tudo e pode passar lateralmente do estadiamento para a conta de produção.

Observação: Essas questões contribuíram para a violação, uma vez que o invasor tenha acesso a credenciais codificadas. A empresa SaaS também teve práticas recomendadas de segurança implementadas, como o uso do AWS Identity Center for Developer Login e Habiled GuardDuty, SecurityHub e Config.

Táticas de atacante

Depois de investigar o incidente, encontrei as seguintes táticas usadas pelos atacantes:

Usados endereços IP VPN para esconder sua origem
Usou scripts personalizados para enumerar todos os recursos em todas as regiões
Grupos de segurança de banco de dados modificados para permitir a entrada de seus IPs VPN
Redefinir senhas de banco de dados Master RDS para acesso
Conteúdo exfiltrado do balde S3 usando o comando S3 Sync
Parou o CloudTrail e os troncos excluídos do bucket Cloudtrail
Encontrou proteção contra exclusão sobre recursos (EC2, RDS, etc.), desligou a configuração e depois excluiu os recursos

Como melhores controles de segurança poderiam ter prejudicado o atacante

O vazamento de uma chave de usuário privilegiada do IAM foi o ponto de entrada para a conta da nuvem, mas o impacto da violação também está na arquitetura em nuvem.

Poucas medidas de segurança que poderiam ter impedido certas táticas de invasor e/ou reduziram o impacto da violação:

Não anexe a política de administrador a nenhum usuário do IAM – O caminho para menos privilégio na nuvem (para qualquer empresa com poucos anos de presença em nuvem) começa com a identificação de entidades mais arriscadas do IAM e reduzindo as permissões para as mais necessárias, impedindo a criação de novas entidades de IAM de risco. Ferramentas como o CloudSLinging podem ser um bom começo.
Use várias contas em vez de ABAC em uma única conta para isolar os recursos – Uma única conta é operacionalmente mais fácil de gerenciar. No entanto, segregar os recursos Prod e não produzidos (especialmente S3, Zonas Route53, IAM etc.) é complicado. Implementar e manter um ABAC eficaz é mais desafiador do que a segregação no nível da conta. Use o Serviço de Organizações da AWS para gerenciar várias contas.
Crie uma trilha Org Cloudtrail em vez de trilhas individuais – Essa trilha salva logs de todas as contas da AWS em um único balde S3 em uma conta designada para armazenar logs.
- Ativar bloqueio de objeto S3 nos baldes de log – Isso impede adulteração e exclusão de log, mesmo por usuários privilegiados. Use um modo de bloqueio de objeto S3 adequado para seus requisitos.
Ativar logs VPC Flow, CloudTrail e S3 – Os logs ajudam a identificar padrões de ataque e avaliar o raio de explosão de incidentes. Sem toras, é impossível provar ou refutar qualquer hipótese. Os registros S3 são caros, então ative -os para baldes críticos.
Backups e logs devem ser enviados para diferentes contas da AWS – Esses recursos ajudam a investigar e se recuperar de incidentes e não devem ser armazenados em contas em que os incidentes sejam antecipados.
Use SCPs e RCPs para evitar ações sensíveis e configurar o perímetro confiável – Os SCPs ajudam a evitar táticas de invasor, como excluir baldes críticos, modificar ou interromper o CloudTrail, etc. Os RCPs ajudam a impedir que as contas desconhecidas assumam funções de IAM (backdoord) e contornando os SCPs usando contas da AWS controladas por atacantes.
Implementar solução externa para acesso SSH – Ferramentas de código aberto como o Teleport Grant SSH Access a EC2s e oferecem funcionalidades como salvar todas as sessões e comandos executados pelos usuários.
(Opcional, da minha experiência) Não hospede bancos de dados em sub -redes públicas com IPS público – Grupos de segurança podem controlar o acesso da rede a bancos de dados e instâncias do EC2 com IPS públicos, mas se os desenvolvedores os alterarem diretamente do console, é fácil de configurar incorretamente e expor -se a faixas CIDR não intencionais. Se não for possível migrar um banco de dados existente de público para privado, implemente a detecção de alterações para grupos de segurança importantes.

Um relatório com análise detalhada do incidente, os fatores contribuintes, a causa raiz e os controles de segurança pragmática como o acima foi compartilhado com o cliente.

Além disso, a Plano de ação personalizado de 90 dias foi compartilhado para ajudar a evitar violações semelhantes no futuro e fortalecer sua segurança da AWS.

Notas para equipes de segurança

A GuardDuty não conseguiu detectar servidores C&C: Encontrei alguns IPs dos logs de eventos Cloudtrail que executaram ações confidenciais, como o Deletetrail. A Guardduty levantou um alerta de baixa gravidade sobre o que o CloudTrail foi interrompido. No entanto, nunca alertou sobre esses IPs. VIRUSTOTAL E OBUSO.CH Listou -os como servidores C&C conhecidos. Se você ativou o GuardDuty, mantenha sua própria lista de ameaças para ser notificada sobre o tráfego para os servidores C&C.

Raspar o histórico de eventos Cloudtrail pode levar muito tempo: Embora os logs do CloudTrail possam ser excluídos no S3 Bucket, os eventos de gerenciamento do CloudTrail dos últimos 90 dias estão disponíveis no Histórico de Eventos Cloudtrail. Mas há um problema – há um ratelimit para LookupEvents – 2 solicitações da API por segundo por região. Cada solicitação da API para LookupEvents busca 50 eventos. Se você tiver milhões de eventos de CloudTrail, o download deles leva um tempo considerável antes da investigação. Portanto, sempre proteja seus logs de nuvem nos baldes S3 e torne mais difícil adulter -los. Baixe logs do histórico de eventos no pior cenário.

O que é mais preocupante na pós-análise dessa violação?

Essa violação ocorreu apesar da empresa ter implementado várias práticas recomendadas de segurança da AWS – incluindo o AWS Identity Center, GuardDuty, SecurityHub e Config.

(No entanto, preciso mencionar que eles não foram configurados adequadamente.)

O seu ambiente em nuvem está escondendo riscos semelhantes?

Tem certeza de que os controles de segurança em nuvem estão configurados corretamente?

Não espere uma violação catastrófica para descobrir.

Agende uma chamada de descoberta hoje! Vou ajudar a:

Encontre problemas de segurança arquitetônica em nuvem exclusivos para o seu ambiente
Detectar equívocas exploráveis
Implementar controles de segurança em nuvem eficazes

Então você não acaba enfrentando uma violação semelhante em sua empresa.

Source link