Relatório BWAPP
Realizado por:
José Raeiro
CISEGP10.20
1
Conteúdo
Introdução ..................................................................................................................................... 3
Análise de Meta-dados para Descobrir Fugas de Informação ...................................................... 4
Mapear os caminhos de execução através da aplicação ............................................................ 10
A1 - Teste de Injeção SQL ............................................................................................................ 12
A7 - Cross-Site Scripting (XSS) ..................................................................................................... 15
Rever Arquivos de Backup Antigos e não Referenciados para Informação Sensível .................. 18
Teste de Segurança de Transporte Restrito HTTP....................................................................... 20
Teste de Segurança da Camada de Transporte........................................................................... 21
2
Introdução
A lista abaixo resume o top 10 OWASP para vulnerabilidades de aplicativos da web. O OWASP
Top 10 representa a lista das falhas mais críticas de segurança, que são acompanhados por
especialistas em segurança do OWASP de todo o mundo. A lista fornece um poderoso
documento de conscientização para a segurança de aplicativos da web e é utilizada em muitos
padrões de segurança:
Categorias:
A1: Injeção;
A2: Autenticação Quebrada;
A3: Exposição de dados sensíveis;
A4: XML Entidades externas (XEE);
AS: Controlo de Acesso Quebrado;
A6: Má configuração de segurança;
A7: Cross Site Scripting (XSS);
A8: Deserialização Insegura;
A9: Utilização de componentes com vulnerabilidades conhecidas AIO: Registo e monitorização
insuficientes;
Critérios para classificações de risco:
Identificam condições que podem resultar diretamente no
comprometimento ou acesso não autorizado de uma rede, sistema,
aplicação ou informações confidenciais. Exemplos de problemas de
alto risco incluem execução remota de comandos, estouros de buffer
conhecidos; acesso não autorizado e divulgação de informações
confidenciais.
Identificam condições que não resultam imediata ou diretamente no
comprometimento ou acesso não autorizado de uma rede, sistema,
aplicativo de informações, mas fornecem um recurso ou informação
que poderia, em combinação com outros recursos ou informações,
resultar no comprometimento ou acesso não autorizado a uma rede,
aplicativo ou informação.
Exemplos de problemas de risco médio incluem navegação em
diretórios, acesso parcial a arquivos no sistema; divulgação de
mecanismos de segurança e uso não autorizado de serviços.
identificam condições que não resultam imediata ou diretamente no
comprometimento de uma rede, sistema, aplicativo ou informação, mas
fornecem informações que podem ser usadas em combinação com
outras informações para obter insights sobre como comprometer ou
obter acesso não autorizado a uma rede, sistema, aplicativo ou
informação.
3
Análise de Meta-dados para Descobrir Fugas de Informação
DATA:20/02/2021 23:35
ID DO TESTE WSTG-INFO-03
Sumário:
Descreve como testar vários ficheiros de meta-dados para verificar a fuga de informação do
caminho da aplicação web, ou funcionalidade. Além disso, a lista de diretórios que devem ser
evitados por Spider, Robots, ou Crawlers também pode ser criado como uma dependência para
caminhos de execução de mapas através da aplicação. Outras informações podem também ser
recolhidas para identificar superfície de ataque, detalhes tecnológicos, ou para uso em
engenharia social.
Objetivo do teste:
Identificar caminhos e funcionalidades ocultas ou ofuscadas através da análise de ficheiros de
meta-dados.
Extrair e mapear outras informações que possam levar a uma melhor compreensão dos
sistemas em questão.
Teste:
Robots.txt: Robots.txt: é um padrão utilizado pela maioria das aplicações de aplicação web para
a listagem de diretórios que deve ser evitada para não ser comprometida por aranhas, robots e
crawlers devido à sua capacidade de estabelecer ligações entre ligações, a fim de recuperar
mais conteúdo que era originalmente pretendido pelos criadores da aplicação. No entanto, o
ficheiro robots.txt não é um mecanismo para impor restrições de conteúdo ou armazenamento,
o seu principal objetivo serve como diretiva para restringir as funções de certas
aranhas/crawlers/robots. As permissões são adicionadas (permitir) ou removidas (não permitir)
aos "utilizadores-agentes".
Devido à possibilidade de consultar este ficheiro escrevendo "robots.txt" no URL no browser,
realizámos este teste navegando estritamente através dos ficheiros proibidos em robots.txt
usando firefox, uma vez que não havia <META> tags, security.txt ou human.txt a serem
encontrados nesta aplicação:
4
No directório /admin/ podemos recolher algumas informações sobre como funcionam os modos
do portal de administração, tais como contornar todos os modos de segurança e concluir que
existem credenciais estáticas para obter acesso a determinadas páginas
No diretório /documentos/ não há muita informação disponível para além de impressões de
filmes de super heróis e um ficheiro bWAPP_intro.pdf que faz sentido uma vez que se trata de
uma aplicação de formação
5
O mesmo se aplica ao diretório /images/
Finalmente no diretório /passwords/ é onde as informações são mais sensíveis.
6
O ficheiro heroes.xml permite nos ter acesso às credenciais de login e a respetiva password:
7
Após descarregar os ficheiros .bak e convertê-los em ficheiros .txt, podemos observar certas
configurações da aplicação e extrair um símbolo de chave pública, que é uma representação da
chave pública:
Repetimos o mesmo processo no ficheiro wp-config.bak e encontrámos o nome da base de
dados e também logins estáticos e credenciais de palavra-passe escritos em php usando a
função define:
8
Os comentários no php ajudaram-nos a compreender como eram geridas as chaves de
aplicação, uma vez que indicavam o método que utilizavam para gerar as chaves, que consiste
em obtê-las numa página de texto simples, sem necessidade de autenticação:
http://api.wordpress.org/secret-key/1.1
Como prevenir este ataque:
Este tipo de reconhecimento seria provavelmente mitigado através da utilização de um
protocolo HTTPS em vez do protocolo HTTP.
9
Mapear os caminhos de execução através da aplicação
DATA:21/02/2021 00:50
ID DO TESTE WSTG-INFO-07
Objetivo do teste:
Mapear a aplicação alvo e compreender os fluxos de trabalho principais.
Resultado:
O ficheiro com as páginas rastreadas encontra-se em ZAP_BWAPP_Crawl.xlsx
Ferramenta utilizada:
OWASP ZAP 2.10.0
Descrição de como o teste foi realizado:
Primeiro, utilizei a ferramenta de Spider normal do OWASP ZAP, tendo-a apontado para o
endereço http://172.17.0.1:82 (O IP e porta da máquina Docker contendo o BWAPP). Como não
obtive resultados satisfatórios através deste método, tive de ativar a autenticação. Depois de ter
adicionado o URL a um novo contexto, no menu do contexto (Session Properties) fui a
Authentication e escolhi a opção “Form-based authetication” tendo inserido o URL
http://172.17.0.1:82/login.php nos campos “Login Form Target URL *” e “URL to GET Login
Page”. Já no campo “Login Request POST Data (if any)” inseri a seguinte string:
“login={%username%}&password={%password%}&security_level=0&form=submit”, tendo
escolhido o parâmetro “login” como Username Parameter e “password” como Password
Parameter do drop-down menu abaixo. No campo “Regex Pattern used to identify Logged Out
messages” inseri o valor “\Q<title>bWAPP - Login</title>\E”, retirado da página de login do
BWAPP, a fim do OWASP ZAP ser capaz de identificar quando e se a sessão tinha terminado,
identificando assim a necessidade de fazer login novamente. Depois, e novamente no menu do
contexto, fui a Users e adicionei o utilizador “Bee” com a palavra-passe “bug”. No menu do
contexto, ainda, fui a Session Management e certifiquei-me de que a opção “Cookie-based
10
session management” estava ativada. Depois fui à barra de ferramentas do OWASP ZAP e
ativei a opção “Forced User Mode”. E, assim, preparei o OWASP ZAP para se autenticar dentro
do BWAPP.
Tendo autenticado, utilizei novamente a ferramenta de Spider normal do OWASP ZAP e,
apesar de obter as páginas correspondentes ao menu de cima do BWAPP, não consegui obter
as demais páginas. Foi então que utilizei a ferramenta de AJAX Spider que me encontrou a
seguinte página http://172.17.0.1:82/aim.php Foi através dessa página que, tendo apontado
para lá o Spider normal, que consegui obter as páginas em falta, pois essa página tinha
ligações em html diretas para todas as páginas do BWAPP sem sequer ser preciso
autenticação.
À atenção dos desenvolvedores:
Recomenda-se que a página aim.php seja retirada da aplicação, pois representa uma
vulnerabilidade grave em termos de funcionamento da aplicação.
Qual controle do OwaspTop 10 Proactive mitiga a vulnerabilidade:
C8 – Protect Data Everywhere
11
A1 - Teste de Injeção SQL
DATA:21/02/2021 00:50
ID DO TESTE WSTG-INPV-05
Sumário:
O teste de injeção SQL verifica se é possível injetar dados na aplicação para que esta execute
um SQL controlado pelo utilizador para consulta na base de dados. É possível encontrar uma
vulnerabilidade de injeção SQL se a aplicação utiliza a entrada de dados através do utilizador
para criar consultas SQL sem a devida validação de entrada.
Uma exploração bem-sucedida desta classe de vulnerabilidade permite a um utilizador não
autorizado aceder ou manipular dados na base de dados.
Objetivo do teste:
Identificar pontos de injeção SQL.
Avaliar a gravidade da injeção e o nível de acesso que pode ser alcançado através dela.
Teste:
SQL Injection (GET/Search)
Através da adição do ‘ no url após o title= criamos um fim na string(Query break), o que causa
um erro na sintaxe, desta forma podemos obter mais informações e conseguir criar um meio de
entrada.
12
Imagem da resposta do erro SQL:
Colocando o seguinte comando ”iron' union select 1,2,3,4,5,6,7 #“ faz se a troca dos
separadores “Title”, “Release”, “Character” e “Genre” por 2,3,5 e 4 respetivamente.
13
Podemos neste caso substituir os algarismos por comandos para obter informações como por
exemplo user ou versão do sistema individualmente:
Aqui temos o exemplo do comando para obter o user e a versão fazendo um request de ambos
simultaneamente:
Como prevenir este ataque:
Para evitar falhas de injeção SQL é simples. Os programadores precisam de parar de escrever
consultas dinâmicas (dinamic queries) e/ou impedir que os dados fornecidos pelo utilizador, que
contenham SQL maliciosos, afetem a lógica da consulta executada.
Defesas primárias:
Opção 1: Utilização de Declarações Preparadas (com Consultas Parametrizadas);
Opção 2: Utilização de Procedimentos Armazenados;
Opção 3: Validação de entrada na lista branca;
Opção 4: Escapar a todas as entradas fornecidas pelo utilizador.
Defesas adicionais:
Também: Aplicação do Menos Privilégio;
Também: Execução da Validação de Entradas da Lista Branca como Defesa Secundária.
14
A7 - Cross-Site Scripting (XSS)
DATA:21/02/2021 01:32
ID DO TESTE WSTG-INPV-01
Sumário:
ocorre quando um atacante injeta código executável de um browser dentro de uma única
resposta HTTP. O ataque injetado não é armazenado dentro da própria aplicação; é não
persistente e apenas impacta os utilizadores que tentem abrir uma ligação maliciosamente
elaborada ou uma página web de terceiros. A cadeia de ataque é incluída como parte do URI
ou HTTP criado indevidamente e processados pelo pedido, seguidamente devolvidos à vítima.
Objetivo do teste:
Identificar as variáveis que se refletem nas respostas.
Avaliar o input que aceitam e a codificação que é aplicada no regresso (se houver).
Teste:
Html Injection – Reflected (GET)
15
16
Como prevenir este ataque:
A prevenção de XSS requer a separação de dados não confiáveis do conteúdo ativo do
navegador. Isto pode ser conseguido por:
* Usando estruturas que escapam automaticamente ao XSS por conceção, tais como o mais
recente Ruby on Rails, Reage JS. Aprender as limitações da proteção XSS de cada estrutura e
tratar adequadamente os casos de utilização que não são abrangidos.
* A fuga de dados de pedido HTTP não confiáveis com base no contexto na saída HTML (corpo,
atributo, JavaScript, CSS, ou URL) resolverá as vulnerabilidades do Reflected and Stored XSS.
A Folha de Consulta OWASP "Prevenção de XSS" tem detalhes sobre as técnicas de fuga de
dados requeridas.
* A aplicação de codificação sensível ao contexto ao modificar o documento do browser do lado
do cliente atua contra o DOM XSS. Quando isto não pode ser evitado, técnicas de fuga
sensíveis ao contexto semelhantes podem ser aplicadas às APIs do navegador, tal como
descrito na Folha de Consulta OWASP 'Prevenção de XSS baseada em DOM'.
* Permitindo uma Política de Segurança de Conteúdo (CSP) como um controlo mitigador de
defesa em profundidade contra XSS. É eficaz se não existirem outras vulnerabilidades que
permitam a colocação de código malicioso através de ficheiros locais (por exemplo,
sobrescritos de travessias de caminho ou bibliotecas vulneráveis de redes de entrega de
conteúdo permitidas).
17
Rever Arquivos de Backup Antigos e não Referenciados para
Informação Sensível
DATA:21/02/2021 02:37
ID DO TESTE WSTG-CONF-04
Sumário:
Embora a maioria dos ficheiros dentro de um servidor web sejam tratados diretamente pelo
próprio servidor, não é raro encontrar ficheiros não referenciados ou esquecidos que podem ser
utilizados para obter informações importantes sobre a infraestrutura ou credenciais.
Objetivo do teste:
Encontrar e analisar ficheiros não referenciados que possam conter dados sensíveis.
Teste:
http://172.17.0.1:82/passwords/wp-config.bak
http://172.17.0.1:82/passwords/web.config.bak
Podemos ver, na imagem acima, os conteúdos do ficheiro wp-config.bak com as credenciais de
acesso à base de dados MySQL.
18
Ferramenta utilizada:
OWASP ZAP 2.10.0
Depois de ter sido realizado o mapeamento da aplicação no teste WSTG-INFO-07, ao utilizar a
funcionalidade de Search do OWASP ZAP em procura por ficheiros com terminação ~, bak, txt,
src, dev, old, inc, orig, copy, tmp e swp.
Como prevenir este ataque:
Recomenda-se que a página wp-config.bak seja retirada da aplicação, pois representa uma
vulnerabilidade grave em termos de funcionamento da aplicação.
Qual controle do OwaspTop 10 Proactive mitiga a vulnerabilidade:
C8 – Protect Data Everywhere
19
Teste de Segurança de Transporte Restrito HTTP
DATA:21/02/2021 03:15
ID DO TESTE WSTG-CONF-07
Sumário:
A funcionalidade HTTP Strict Transport Security (HSTS) permite que uma aplicação web
informe o navegador através da utilização de um cabeçalho de resposta especial que nunca
deve estabelecer uma ligação aos servidores de domínio especificados utilizando servidores
não encriptados HTTP. Em vez disso, deve estabelecer automaticamente todos os pedidos de
ligação para aceder ao site através de HTTPS. É também evita que os utilizadores cometam
erros de certificado.
Objetivo do teste:
Rever o cabeçalho do HSTS e a sua validade.
Teste:
Executando o comando curl https://localhost:82 | grep -i strict, não retornou nada, logo o
cabeçalho não está presente!
Como prevenir este ataque:
Incluir o cabeçalho Strict-Transport-Security: max-age=31536000; includeSubDomains na
página principal da aplicação.
Qual controle do OwaspTop 10 Proactive mitiga a vulnerabilidade:
C8 – Protect Data Everywhere
20
Teste de Segurança da Camada de Transporte
DATA:21/02/2021 04:05
ID DO TESTE WSTG-CRYP-07
Objetivo do teste:
Validar a configuração do serviço
Rever a força criptográfica e a validade do certificado digital.
Assegurar que a segurança TLS não é ultrapassável e que está corretamente implementada
através da aplicação
Teste:
Nenhum dos serviços SSL ou TLS estão presentes, como se pode ver no seguinte output.
Ferramenta utilizada:
Sslscan
Descrição de como o teste foi realizado:
Executamos o comando sslscan 172.17.0.1:82 que retornou que os serviços não estavam
presentes.
Como prevenir este ataque:
Instalar o serviço TLS v1.3 na aplicação, juntamente com um certificado digital.
Qual controle do OwaspTop 10 Proactive mitiga a vulnerabilidade:
C8 – Protect Data Everywhere
21