Get best of the week

Por que as nuvens se tornam nuvens de trovoada: falhas na implantação da nuvem

imagem

Uma implementação de nuvem em uma grande organização geralmente inclui muitos serviços de vários provedores, cada um com suas próprias regras de interação, configurações e até protocolos. Como resultado, a configuração de segurança se torna tão complexa que é difícil rastrear e ainda mais difícil de entender. Em nosso novo estudo, coletamos os erros mais comuns na implantação de uma infraestrutura de nuvem usando o Amazon Web Services como exemplo e compartilharemos alguns deles nesta postagem.

Hoje, os provedores de nuvem oferecem serviços que vão além da trivial "dedicação" ou armazenamento de arquivos. Todos os aspectos de cada serviço podem ser programados. Isso oferece aos desenvolvedores e operadores mais controle sobre segurança do que um data center tradicional. No entanto, a riqueza de funções e suas ferramentas de configuração levam ao fato de que você pode configurar a partir de várias interfaces e - e isso é importante - os parâmetros padrão são diferentes para métodos diferentes.

Para usuários experientes, isso não é um problema - pelo contrário, eles usarão a ferramenta mais adequada para a tarefa. No entanto, para outros, o resultado pode não corresponder às suas expectativas.

Armazenamento Amazon S3


O Amazon Simple Storage Services ou Amazon S3 é um dos serviços em nuvem mais procurados usados ​​por muitos clientes, de pequenas empresas a grandes corporações. A popularidade transformou o S3 em um alvo favorito dos atacantes que procuram falhas na implementação de serviços e erros em sua configuração.

Os vetores de ataque mais comuns do Amazon S3 usados ​​pelos cibercriminosos são:

  • instalações de armazenamento público para gravação;
  • interceptação de contas;
  • abuso de privilégios.

Compartilhamento de gravação


Em fevereiro de 2018, o minerador de criptomoedas Monero foi descoberto no site de um dos maiores jornais americanos. Cada leitor que visitou o site extraiu moedas de criminosos que adicionaram código malicioso aos arquivos JavaScript da publicação.

O site do jornal foi hospedado pela Amazon e armazenou todas as imagens, scripts e arquivos de estilo no repositório S3. O acesso a esse repositório era limitado apenas pela leitura, portanto, o hacking foi uma surpresa completa para os administradores do site. Eles simplesmente não conseguiam entender como foram invadidos até que os especialistas em serviços em nuvem explicassem que o motivo eram os direitos de acesso incorretos.

Os repositórios do Amazon S3 podem ser usados ​​via http / https e, nesta parte, os administradores do site fizeram tudo certo, restringindo o acesso apenas à leitura. No entanto, o S3 também pode ser acessado por meio do protocolo nativo da AWS por meio da linha de comando, e os direitos de acesso para essas chamadas devem ser definidos separadamente e, por padrão, o acesso ao armazenamento via AWS CLI é permitido para todos os usuários autorizados da AWS.

imagem
O resultado da execução do comando do console aws s3api get-bucket-acl --bucket <BUCKET_NAME> para o cofre padrão

para novos usuários do Amazon S3, a necessidade de restringir duas vezes suas permissões de cofre está longe de ser óbvia, o que levou a numerosos incidentes.

No final de 2018, a AWS redefiniu a política de segurança proibindo o acesso público do console para novos repositórios S3, mas essa política não foi aplicada ao usar a linha de comando. O acesso ainda precisava ser limitado a uma equipe separada.

Em 2018-2019, o comprometimento do armazenamento S3 se generalizou. Alguns profissionais de segurança e hackers amigáveis ​​procuraram especificamente os recursos da AWS abertos para gravação e deixaram os arquivos de aviso lá.

imagem
Aviso anônimo sobre uma configuração insegura do AWS S3

Alguém até ofereceu seus serviços para configurar parâmetros de armazenamento seguro:

imagem
Aviso e oferta de serviços do Pentester Random Robbie

Random Robbie é o pseudônimo de Robbie Wiggins, que em 2018 deixou seu aviso sobre os milhares de armazenamento S3 abertos para gravação.

A capacidade de modificar livremente sites hospedados em repositórios S3 foi imediatamente aproveitada pelos hackers. O grupo Magecart introduziu maciçamente códigos maliciosos para roubar dados de cartões bancários e informações de contas de usuários. Afinal, tudo o que era necessário era encontrar um site que aceite pagamentos e use a AWS. Como resultado, os criminosos conseguiram roubar os dados de centenas de milhares de visitantes desses recursos.

imagem
Exemplo de dados que um skimmer passou para criminosos

Entre as vítimas das ações da Magecart estão centenas de lojas on-line, incluindo marcas conhecidas.

No decorrer do estudo, descobrimos que, apesar das muitas publicações e recomendações relacionadas à configuração segura dos serviços da AWS, pelo menos cinco lojas online do número de comprometidas continuam usando as lojas S3 disponíveis para gravação. Até o momento, seus sites não contêm skimmers, mas podem ser adicionados a qualquer momento, pois os cibercriminosos têm à disposição ferramentas convenientes para facilitar a busca por recursos vulneráveis.

Ferramentas de pesquisa de armazenamento aberto S3


As ferramentas Slurp, Bucket Stream e s3scanner ajudam a encontrar armazenamento legível e gravável.

O Slurp ajuda a encontrar possíveis nomes de armazenamento para um determinado domínio e a verificar as permissões de gravação neles:

imagem
Exemplo de saída Slurp. O acesso por http está fechado.

Para verificar a disponibilidade do armazenamento encontrada através do AWS CLI, você pode usar o comando-get-balde acl:

imagem
O acesso ao recurso através da AWS API também está fechado.

O utilitário s3scanner escrito em Python usa uma heurística simples para encontrar possíveis nomes de armazenamento e acesso cheques para eles.

imagem
Pesquisando e verificando a disponibilidade do armazenamento S3 usando o s3scanner

O utilitário Bucket Stream procura armazenamento S3 potencialmente vulnerável em fontes públicas, por exemplo, em Transparência de certificados e outras revistas.

O utilitário AWSBucketDump lista os arquivos do repositório cujos nomes contêm palavras-chave específicas:

imagem
resultado do utilitário AWSBucketDump

Usando esses utilitários, de dezembro de 2018 a janeiro de 2019, encontramos mais de 5200 armazenamentos S3 exclusivos. Cerca de 4.400 deles estavam disponíveis para utilitários de linha de comando padrão da AWS. Apenas 79 deles estavam disponíveis para leitura e 40 para escrita. Para acessar parte deles, era simplesmente necessário atribuir os direitos necessários.

Como as contas vazam


Os direitos de acesso aos recursos são uma fonte de dor de cabeça para os desenvolvedores. E no caso de fundos na nuvem, o problema se torna ainda mais agudo. Os processos devem ser autenticados para obter acesso aos recursos, caso contrário, existe o risco de roubo ou comprometimento dos dados. A questão toda é como fazer isso sem arriscar comprometer os dados ao publicar o código no repositório, como fez o autor do seguinte fragmento publicado no Pastebin:

imagem
Um fragmento do código publicado no Pastebin com ID e chave válidos da API da AWS

Usando esses dados, o invasor pode obter todos os direitos fornecidos pela conta deste aplicativo.

Outra fonte de vazamentos de credenciais são os certificados de cliente da API do Kubernetes. Por um lado, na configuração padrão, esse sistema de orquestração de contêiner exige proteção obrigatória na forma de um certificado de cliente. Por outro lado, desenvolvedores com surpreendente ingenuidade publicam certificados junto com o código no GitHub, Pastebin e outros serviços.

Somente em Pastebin conseguimos encontrar cerca de cinquenta certificados de cliente diferentes colocados com scripts de configuração.

Se a publicação de certificados em texto não criptografado em qualquer lugar é uma má idéia, publicá-lo no GitHub é nojento, porque:

  • Para excluir um certificado, você deve excluí-lo de todas as versões salvas no repositório;
  • - , , ;
  • , , , .

Chaves e certificados de API comprometidos podem se tornar uma fonte de sérios danos financeiros, como uma empresa russa devia à Amazon US $ 12 mil por um dia : invadiu um site no Bitrix, que, entre outras coisas, indicou uma chave de API para acessar o armazenamento S3.

imagem
Captura de tela do painel de cobrança de uma empresa russa, cuja chave de API roubada foi usada para criar muitas máquinas virtuais e mineração de criptomoedas. Fonte: habr.com/en/post/357764

O vazamento de dados de clientes pode se tornar menos doloroso, como na Imperva em 2019 . O Imperva também roubou a chave da API e mesclou todos os dados do cliente.

As contas roubadas podem ser usadas por criminosos cibernéticos para negociar ilegalmente servidores dedicados da AWS, que deverão ser pagos pelos verdadeiros proprietários. No fórum lolzteam, encontramos mais de 250 anúncios oferecendo "Dedicos com zero puro".

imagem
Anúncio no fórum lolzteam. Quem pagará a Amazon no final?

Uma terceira fonte de vazamentos de chaves da API é uma variedade de cursos de treinamento para programadores.

Tentando explicar o processo de conexão dos serviços da AWS aos iniciantes da maneira mais simples possível, os autores replicam as práticas inadequadas, que no futuro levam a novos e novos casos de comprometimento.

imagem
Um trecho de um curso Python que explica como trabalhar com os serviços do Amazon S3. As chaves são oferecidas para codificar no programa

Os autores do curso sobre a linguagem Java progressiva e segura demonstram uma atitude tão descuidada com a segurança das chaves da API: a

imagem
linguagem é diferente, mas o conselho é o mesmo - as chaves estão corretas no texto do programa.

Nossas recomendações


A configuração incorreta dos serviços em nuvem apresenta muitos riscos, do uso ilegal de recursos de computação alugados para mineração de criptomoedas, roubo de dados e introdução de skimmers online. Nesse sentido, recomendamos que a equipe de segurança analise os cenários de implantação na nuvem para identificar possíveis vulnerabilidades antes que o processo seja concluído. Os scripts de validação na nuvem, como o AWS CloudFormation, fornecem informações sobre como a infraestrutura resultante funcionará, onde procurar configurações ou logs de segurança incorretos ou ausentes. Entre as ferramentas de segurança desenvolvidas pela Trend Micro, há um produto destinado a proteger ambientes em nuvem - Deep Security for Amazon EC2 instance.E a ferramenta Conformidade em nuvem permite que o ambiente em nuvem da empresa faça configurações inseguras.

Para programadores que usam chaves de API da AWS para interagir com repositórios S3, sugerimos que você alterne para trabalhar nos AWS Secrets Manager, Docker Secrets, Blackbox, git-secrets e outras ferramentas semelhantes que permitirão evitar o comprometimento e o uso mal-intencionado das credenciais armazenadas junto com o original textos de aplicação.

More articles:


All Articles