AWS WAF, parte 2
Nessa segunda parte do artigo, vou demonstrar uma das vulnerabilidades do site que podemos estar protegendo com a implantação do WAF.
Links do artigo anterior:
Introdução ao Web Application Firewall
e Montando o ambiente para testes do WAF na AWSIdentificando as vunerabilidade do Site
Primeiro precisamos entender o funcionamento do site, os campos de pesquisas são grandes candidatos a sofrerem ataques de “SQL Injection”, pois muitos desenvolvedores concatenam a formação do “Select” sem nenhuma ou poucas validações.
Pesquisando pelo nome “viagens” ele trouxe todos conteúdos que tem essa palavra, logo provavelmente está sendo utilizado o comando “like” do SQL. Vamos fazer a mesma pesquisa usando aspas duplas:
Quando faço uma pesquisa com aspas duplas, consigo obter diversas informações sobre essa aplicação: Ela está rodando um linux numa ec2, a aplicação é feita em python com flash e sqlalchemy, está usando o sqlite3 e consigo quebrar o SQL para tentar obter mais informações.
Neste momento, um invasor com as informações encontradas vai tentar identificar mais brechas de seguranças para conseguir acesso a informações que possam ter algum tipo de valor.
Com uma rápida pesquisa na internet descobrimos o nome das tabelas de schema do sqlite3:
Pelo erro anterior, descobrimos que conseguimos inserir informações dentro do SELECT * FROM posts WHERE Content LIKE “%”%”; logo podemos adicionar qualquer informação no meio dos símbolos de percentagem, como informações das tabelas obtidas na documentação do SQLite. Exemplo:
Se inserirmos o trecho:
X” union select name, sql from sqlite_master where type='table' --
Vamos formar o seguinte SQL:
SELECT * FROM posts WHERE Content LIKE "%X" union select name, sql from sqlite_master where type='table' --%";
Esclarecendo o que foi feito no comando:
- Fechamos o primeiro SELECT
- Utilizamos a função UNION para adicionar o SELECT que desejarmos
- o traço duplo é para comentar o ultimo símboloE com esse comando recuperamos os nomes de todas as tabelas:
O logo já chama a atenção à tabela de login para conseguirmos acessar a área restrita do site, então vamos consultar essa tabela:
O resultado retorna um e-mail e um hash, que deve ser o login e senha da aplicação. Sendo assim, podemos usar esse hash para tentar identificar, então vamos usar um site de conversão para ver se retorna a senha:
Ele identificou que a senha é “admin123” para o usuário admin, então testando essa senha consegui acesso a área restrita do site:
Este site tem vários tipos de ataques que podem ser vistos na documentação, mas o objetivo foi mostrar uma das brechas encontradas no site que poderemos estar protegendo com o WAF, como esse erro de programação ou de falhas de seguranças identificadas.
Neste exemplo, recuperamos um acesso a área restrita, mas em sites com falhas similares poderíamos recuperar informações confidencias e até mesmo cartões de crédito. Por isso é muito importante estarmos atentos à segurança, mesmo quando ela não está clara.
Implantando e mostrando a importância do WAF
Chegamos na parte esperada por muitos, a implantação do WAF.
Relembrando, o WAF pode ser implantando em alguns recursos da AWS que trabalham com a camada 7, como: Amazon CloudFront, Application Load Balancer, Amazon API Gateway e AWS AppSync.
O legal é que se as aplicações já utilizam esses recursos, é muito fácil e transparente a implantação do WAF, o mais trabalhoso é selecionar as regras corretas para não bloquear funções das aplicações e adicionar uma camada de segurança em cima dela, ou seja, escolher os riscos aceitáveis e trabalhar em conjunto dos desenvolvedores ou fornecedores das aplicações para mitigar os possíveis problemas, para não precisar criar exceções no WAF.
Neste exemplo vamos colocar o WAF na frente do ALB para protegê-lo de possíveis ataques vindos da internet.
Criando o WAF:
Passo a passo:01) Clique no botão para criar um o WAF;
02) Nome ao WAF;
03) Descrição do WAF;
04) Um prefixo para as métricas;
05) Como vamos trabalhar com o Application Load Balancer selecione o recurso regional;
06) Selecione a região que estão os seus recursos;
07) Clique no botão "Add AWS resources" para adicionar o ALB;
08) Selecione o tipo de recurso (ALB);
09) E selecione o seu ALB;
10) Após adicionar o recurso que será protegido pelo WAF podes adicionar outros recursos, isso mesmo WAF pode proteger diversos recursos para facilitar a manutenção. Depois de selecionado clique em "Next";
11) Aqui já podemos adicionar as regras, mas vou adicionar num próximo passo para detalharmos;
12) É a regra default, neste caso vai permitir todo o tráfego e bloquear apenas o que especificarmos nas regras;
13) Apenas continuar;
14) Vamos deixar para monitorar tudo;
15) Confirme a criação e aguarde.Na tela principal do WAF temos um resumo das últimas conexões. Vamos acessar e navegar pelo nosso site usando endpoint do load balancer algumas vezes para gerar informações (talvez demore um pouco para aparecer os dados de acesso).
Como podem ver, mesmo sem nenhuma regra o WAF já está monitorando os acessos ao ALB, mas como não adicionamos nenhuma regra não haverá nenhum tipo de bloqueio ou proteção.
Relembrando, no início desse artigo realizamos um ataque baseado em “SQL Injection” na nossa aplicação de testes antes de adicionarmos as regras de proteção no WAF para poder obter informações confidenciais:
Agora vamos reproduzirmos os mesmos ataques com o WAF ativado e sem qualquer ajuste da aplicação. Então vamos ativar a regra gerenciada pela AWS que protege contra ataques SQL, que tem algumas opções e entre elas o “SQL Injection”.
Passo a Passo
01) No WAF vai em "Rules";
02) Clique em "Add to web ACL";
03) Selecione "AWS managed rule groups";
04) Dentro dela adicione o "SQL database";
05) No final da página clique em "Add rules";
06) Confirma a adição do SQLiRule e clique no botão salvar;
07) A regra foi adicionada com sucesso;
08) Vai em "Associated AWS resources" e confirm se o ALB está associado ao WAF, neste ponto pode ser adicionado outros recursos da AWS para o WAF proteger.Após a adição das regras vamos realizar o mesmo ataque do “SQL Injection” acima.
Como podem ver, com a mesma consulta anterior, o WAF protege a aplicação recusando a autorização da requisição, status 403.
X” union select login || ‘: ‘ || email, password from logins --Ok, e seu fizermos a consulta na página procurando a palavra “viagens” a aplicação vai funcionar ou o WAF vai atrapalhar?
Como podem ver, o WAF não atrapalha no funcionamento da página, ele vai bloquear apenas o que representar um tipo de ataque conhecido ou uma regra personalizada por nós. Caso ele bloqueie alguma função da aplicação, precisa ser avaliado, pois ela pode estar mal escrita ou possuir uma particularidade de um risco que devemos assumir. Neste caso temos duas opções: Liberar essa regra no WAF e/ou solicitar a correção da aplicação apontando o motivo.
O WAF da AWS oferece muitas regras gerenciadas que englobam muitos problemas conhecidos, como o OWASP (Open Web Application Security Project), que é uma comunidade de especialistas que compartilha experiências de vulnerabilidades, ameaças e ataques para que possamos proteger nossas aplicações.
Além das regras gerenciadas pela AWS e nossas regras personalizadas, também existem regras mantidas por parceiros da AWS que podemos estar utilizando.
Chegamos ao fim desse artigo, espero que tenham gostado.
Fonte: https://docs.aws.amazon.com/waf/index.html, https://github.com/wesleyit/python_safesite
