Conhecendo um pouco mais sobre o serviço Amazon S3

Texto por Boot Santos e Allan Kardec | Revisão por Isaque Costa.

Criada em 2006 a Amazon Web Services é um dos maiores provedores de serviços e infraestrutura para a nuvem, atualmente traz como objetivo para o usuário serviços confiáveis, escaláveis e acessíveis. Dessa forma proporciona que não tenhamos gastos tão elevados e mesmo assim tenhamos um serviço estável.

Um dos seus vários serviços disponíveis é o Simple Storage Service (Amazon S3), um serviço de armazenamento de objetos que oferece performance e escalabilidade. Dessa maneira você tem disponibilidade de dados. Isso significa que clientes de todos os tamanhos e setores podem usá-lo para armazenar qualquer volume de dados em uma grande variedade de casos de uso, como sites, aplicativos para dispositivos móveis, backup e restauração, arquivamento, aplicativos empresariais, dispositivos IoT e análises de big data.

Para armazenar essa quantidade gigantesca de dados o Amazon S3 utiliza do conceito de buckets, que seriam contêineres para objetos (dados). Você pode ter um ou mais buckets, sendo eles globais. Podendo ter controle do acesso para cada um (quem pode criar, excluir e listar objetos no bucket), exibir logs de acesso para ele e seus objetos. Mesmo que os buckets sejam globais é fundamental escolher a região geográfica onde o Amazon S3 armazenará o bucket e seu conteúdo. Isso permite que você controle onde seus dados são armazenados.

A princípio o armazenamento de um objeto no Amazon S3 é bem simples, basta carregar os arquivos desejados e definir as permissões sobre eles, assim como quaisquer metadados.

Security misconfiguration

Ao desenvolver uma aplicação pode ocorrer de algumas configurações de segurança ficarem incorretas, sejam elas no servidor, no banco de dados ou em algum componente chave para que a aplicação funcione de forma precisa. Isso ocorre geralmente quando atualizações não são instaladas, quando o desenvolvedor esquece de configurar corretamente, ou quando usuários especiais (que podem manipular a aplicação) estão ativos, temos então, a ocorrência da vulnerabilidade de Configuração Incorreta de Segurança.

A exploração desse problema é vista como fácil, já que o atacante utiliza de contas padrões que são instaladas na configuração do sistema. De acordo com a OWASP Top Ten: “O impacto é moderado, pois uma vez que esta vulnerabilidade é explorada, pode comprometer por completo todo o sistema”.

Para que isso não ocorra é necessário um esforço de todos os envolvidos no projeto, já que essa falha não necessariamente é ocasionada apenas no código ou na infraestrutura.

Configurando o ambiente (AWS-CLI)

Antes de iniciar os testes é necessário preparar o ambiente. Nos exemplos a seguir foi utilizado uma máquina linux e iremos utilizar a ferramenta AWS Command Line Interface (AWS-CLI). A ferramenta possui código aberto e ela permite fazer interação com os serviços da AWS por meio de linhas de comando.

Para a instalação é necessário ter o Python Package Installer (pip3) instalado na sua máquina, e a instalação é bem simples.

Linux/macOS

Para instalação no linux basta executar o seguinte comando:

$ pip3 install awscli --upgrade --user

Windows

Para instalação no windows basta executar o seguinte comando:

C:\> pip3 install awscli

Com o ambiente configurado, iremos realizar alguns testes e verificar se seu bucket está realmente seguro, e se não estiver, como corrigir.

Quais são as falhas

Antes de tudo devemos descobrir o nome do bucket, algo que não é muito difícil já que é algo público, a partir disso o atacante vai testar diversas configurações incorretas que podem ser utilizadas para acessar ou modificar as informações do bucket. Para testar basta se conectar a API da Amazon com AWS-CLI, obtendo três possíveis cenários:

• Listar e ler os arquivos no bucket;
• Baixar ou enviar arquivos para o bucket;
• Alterar permissões de acesso e controlar o conteúdo dos arquivos (o controle total do bucket não significa que tenha acesso de leitura total, mas pode controlar o conteúdo).

Vale salientar que o atacante pode obter acesso sem que a empresa perceba ou descubra que houve alteração no bucket. A AWS está ciente do problema, porém esse erro é ocasionado por falha de configuração do usuário S3 e não da Amazon.

Cenários de ataque

Um bucket quando criado é necessário que o usuário defina um nome exclusivo e que seja compatível com o DNS cadastrado na AWS e existem algumas regras para a nomeação desse bucket, isso vem especificado na documentação.

Sabendo dessa informação, vamos realizar alguns testes para identificar possíveis falhas de configuração em um bucket.

Permissão READ

Nesse exemplo não foi possível listar, já que o bucket não tinha permissão para essa operação.

Explicação rápida

• ls - para realizar uma listagem dos objetos;
• s3://palestra1001/ = nome exclusivo do bucket;
• --no-sign-request = realizar um acesso sem uma chave aws configurada;

Para acessar esse bucket tendo em vista que o mesmo encontra-se na região: sa-east-1
https://palestra1001.s3-sa-east-1.amazonaws.com

Conhecendo o arquivo XML

Ao acessar um link de um bucket no browser, teremos a apresentação de um arquivo XML:

Temos uma informação útil na segunda linha: <Name>, é essa informação que utilizamos na ferramenta aws-cli. É comum encontrar buckets com dns, como por exemplo cdn.site.com.br ou static.site.com.br, e não necessariamente os mesmos nomes de bucket, ou até hashs e outros nomes incomuns à aplicação:

Ex: prod-deve86b4dbb36d94d8ba66532f2bc0d8051

Um novo teste com a permissão READ e temos o cenário de lista dos objetos desse bucket. Até aqui tudo bem se os dados são públicos, nenhum problema. O que ocorre é que a empresa mantém a configuração de dados públicos para documentos que não deveria, de maneira alguma, utilizar essa permissão.

Permissão WRITE

Temos também um segundo cenário que é o WRITE e esse tem um perigo ainda maior, vamos exemplificar um ataque utilizando a permissão ativa no bucket.

Da mesma forma que o cenário de leitura foi mostrado anteriormente, com o comando cp arquivo conseguimos enviar dados para esse bucket e/ou alterar um dado de um objeto já existente.

Qual o potencial destrutivo de um ataque como esse?

Os Devs têm cada vez mais colocado informações nos buckets js, códigos-fontes e por aí vai. Alterar um js que é carregado como assets de uma página administrativa tem a possibilidade de manipular requisições de login, fazendo com que o atacante receba esses dados:

Então se a página onde o script está sendo carregado for acessada, além do bloco de scripts, o atacante pode também executar o comando e desta forma a imaginação personaliza o ataque, como por exemplo: phishing de login, possível ataque a cookie em algumas situações propícias e mineração.

E ainda temos uma terceira opção que é o rm. Aí é onde mora o perigo, apagar objetos de uma aplicação em produção pode causar um prejuízo imenso.

Como por exemplo:

aws s3 rm s3://palestra1001/ok.txt –no-sign-request

ou ainda pior:

aws s3 rm s3://palestra1001/ --recursive

Como corrigir

A correção é bem simples, vamos exemplificar algumas maneiras de não correr o risco com informações que não deveriam estar públicas..

No console da AWS S3 > Block Public Access, como vocês podem ver, está setado como OFF. Verifique quais permissões serão concedidas para todos os buckets ou para buckets específicos.

Existem algumas formas de controlar as permissões, que são:

1. Bloqueio ou liberação da permissão pública;
2. Em Access Control List, você gerencia o acesso público ou de uma conta AWS;
3. Crie um PRIVACY para o bucket;
4. Sempre verifique seu console, ele mostra a situação de permissão de seu bucket.

Com essas configurações feitas, seu bucket estará protegido e livre de possíveis ameaças de permissões públicas. Agora que você sabe como funciona um bucket e consequentemente o serviço Amazon S3, esperamos ter contribuído para que você se proteja e evite ter informações expostas ao utilizar o serviço.

Fonte: Amazon, Guilherme Teles, DevFúria, Detectify, CloudAcademy