Violações de alto impacto na AWS e como evitá-las

Poucos dias antes do Natal de 2021, funcionários e clientes do serviço de agendamento Flexbooker descobriram que agentes mal-intencionados haviam roubado dez milhões de registros de identificação de clientes — incluindo fotos, carteiras de motorista e senhas com hash.

Os invasores roubaram milhões de dados de identificação pessoal (PII) porque a conta da AWS da Flexbooker estava configurada incorretamente — mais especificamente, um bucket do AWS S3 cujo conteúdo ficou exposto ao público. Essa violação relacionada à AWS ganhou destaque na imprensa, mas não por ser algo inédito. Capital One, Twilio, Uber e outras empresas também já sofreram violações relacionadas à AWS. Nesses casos, os invasores não violaram a própria AWS, mas sim uma empresa, explorando uma configuração incorreta na AWS.

Apesar da dimensão dessas violações, a causa dos problemas de segurança na nuvem costuma ser a mesma: configurações incorretas. A segurança na nuvem se baseia em um modelo de responsabilidade compartilhada: o provedor protege a infraestrutura, mas cabe ao cliente implantar seus aplicativos de forma segura em todos os ambientes, não apenas em produção. Na maioria dos casos, configurações incorretas simples em aplicativos ou serviços implantados criam brechas que podem facilitar uma violação.

Neste artigo, vamos explicar algumas das violações de segurança de alto impacto na AWS que ocorreram nos últimos anos por causa de configurações incorretas e mostrar como você pode evitar violações com práticas de segurança melhores.

Capital One: firewall configurado incorretamente afeta 100 milhões de clientes

Em julho de 2019, o grande banco e provedor de serviços financeiros Capital One revelou que um ex-funcionário da Amazon havia invadido seus servidores na AWS.

O ataque afetou mais de 100 milhões de clientes e expôs dados de identificação pessoal, como números do Social Security, números de contas bancárias, pontuações de crédito e muito mais. A Amazon deixou claro que a AWS não foi responsável e que os serviços de nuvem subjacentes não foram comprometidos. Em vez disso, como a Capital One reconheceu, o invasor obteve acesso por meio de um firewall de aplicativo Web (WAF) de código aberto configurado incorretamente.

Os clientes entraram com uma ação coletiva, que a Capital One resolveu com um acordo que concedia até US$ 25 mil por reivindicação. Os autores da ação alegaram que a Capital One “tinha conhecimento das vulnerabilidades de segurança específicas que permitiram a violação de dados”, mas não as corrigiu. A Capital One não concordou nem discordou das alegações e afirmou que faria o acordo “para evitar o tempo, os custos e a incerteza de dar continuidade ao processo judicial”.

Pegasus Airlines: bucket do S3 desprotegido expõe 6,5 terabytes de dados

Em maio de 2022, a companhia aérea turca Pegasus Airlines descobriu, por meio do trabalho de uma empresa de segurança, que havia configurado incorretamente um bucket do AWS S3. O bucket continha dados confidenciais de voos, incluindo mapas de voo, materiais de navegação e dados de identificação pessoal de vários funcionários.

O bucket aberto do S3 também expôs parte do código-fonte da empresa, que continha senhas em texto simples e chaves secretas — dados que possíveis invasores poderiam ter usado para acessar ainda mais informações confidenciais.

No total, a empresa de segurança encontrou quase 23 milhões de arquivos expostos, cerca de 6,5 terabytes de dados. Segundo a empresa, “essa exposição poderia colocar em risco a segurança de todos os passageiros e tripulantes da Pegasus no mundo todo”.

A empresa de segurança notificou a Pegasus Airlines e, segundo ela, “o bucket do AWS S3 foi protegido prontamente, e a PegasusEFB respondeu mais tarde agradecendo o aviso”.

Twilio: bucket do S3 exposto permite que invasores injetem código malicioso

Em julho de 2020, a empresa de comunicação em nuvem Twilio confirmou que invasores acessaram um bucket do S3 configurado incorretamente e modificaram o SDK JavaScript de sua ferramenta TaskRouter.

Os invasores exploraram uma configuração incorreta no bucket do S3 que hospedava a biblioteca do SDK JS do TaskRouter da Twilio (o TaskRouter é uma ferramenta que os clientes da Twilio podem usar para encaminhar tarefas). Depois do ataque, a biblioteca alterada fazia os navegadores carregarem uma URL adicional — que mais tarde foi associada aos infames ataques Magecart.

Em uma divulgação, a Twilio explicou que corrigiu o incidente em quinze minutos e reconfigurou o bucket do S3 uma hora depois. A Twilio também afirmou que os invasores não acessaram dados de clientes nem sistemas internos.

A Twilio foi transparente e explicou: “Não configuramos corretamente a política de acesso de um dos nossos buckets do AWS S3”. A empresa implementou esse caminho específico em 2015 e, na época, ele não era vulnerável. Mas, alguns meses depois, a Twilio não “restaurou as permissões corretamente” após solucionar um problema.

Uber: autenticação fraca expõe chaves secretas que deram aos hackers acesso a armazenamentos do AWS S3 com registros de 600 mil motoristas dos EUA

Em novembro de 2017, a empresa de transporte por aplicativo Uber revelou que, em 2016, invasores haviam roubado os dados pessoais de mais de 50 milhões de passageiros e motoristas, além dos registros de 600 mil motoristas dos EUA, incluindo números de carteiras de motorista.

Os invasores conseguiram acessar o repositório GitHub da Uber porque a empresa não havia habilitado a autenticação multifator. Apesar da falta de segurança, esses repositórios continham credenciais importantes da AWS, que permitiram aos invasores acessar os armazenamentos de dados do AWS S3 da Uber.

A Uber explicou que protegeu os dados, encerrou o acesso não autorizado, convenceu os invasores a excluir os dados e reforçou os controles das contas de armazenamento em nuvem. No entanto, reportagens posteriores revelaram que a Uber havia disfarçado o ataque inicial como um programa de recompensa por bugs bem-sucedido e pagado US$ 100 mil aos invasores para que mantivessem silêncio.

Imperva: uma chave de API da AWS exposta dá aos invasores acesso a um banco de dados com endereços de e-mail e senhas de clientes

Em outubro de 2019, a provedora de cibersegurança Imperva revelou que invasores haviam roubado dados de clientes ao explorar uma instância da AWS configurada incorretamente.

O CEO da Imperva explicou que os invasores usaram uma chave de API administrativa encontrada em uma das contas da AWS da empresa para acessar um snapshot de banco de dados com endereços de e-mail e senhas.

A Imperva foi transparente sobre os erros que levaram à violação de segurança na AWS e explicou que quatro etapas principais acabaram causando a exposição dos dados dos clientes:

1. A Imperva criou um snapshot do banco de dados para testes durante uma avaliação da AWS.

2. A Imperva deixou uma instância interna de computação acessível ao público, embora ela contivesse uma chave de API da AWS.

3. Os invasores comprometeram a instância de computação e roubaram a chave de API da AWS.

4. Os invasores usaram a chave de API da AWS para acessar o snapshot do banco de dados e todos os dados que ele continha.

Desde então, a empresa tomou várias medidas corretivas, incluindo o reforço dos controles de acesso de segurança e a implementação de auditorias de acesso.

Três lições aprendidas com violações de dados na AWS

Você pode tirar algumas lições dessas violações na AWS para tornar o uso da AWS pela sua empresa mais seguro:

1. Conheça seu ambiente: Muitas violações na AWS acontecem por erros de configuração. Quanto melhor você conhecer e auditar seu ambiente, menor será a chance de haver uma configuração incorreta que os invasores possam explorar.

2. Capacite seus desenvolvedores: Os desenvolvedores estão em melhor posição para identificar e corrigir erros de configuração. As empresas podem evitar melhor as violações na AWS se derem aos desenvolvedores as ferramentas e orientações necessárias para criar ambientes seguros.

3. Priorize a prevenção e o design seguro: Muitas dessas violações na AWS poderiam ter sido evitadas se as empresas afetadas tivessem priorizado o design seguro. Com ferramentas como a verificação de vulnerabilidades da AWS da Snyk, as empresas podem identificar vulnerabilidades antes que os invasores as explorem. Saiba como a Snyk se integra às ferramentas de segurança da AWS aqui.

Se você quer saber mais sobre segurança na nuvem, baixe nosso eBook The Five Fundamentals of Cloud Security. E, se quiser saber mais sobre a integração entre a Snyk e a AWS, confira o guia de início rápido da AWS.