Boas práticas na escrita de um relatório de Pentest
O relatório é uma das principais entregas de um pentest, tendo em visto que esse documento será lido tanto pela equipe de desenvolvimento quanto de governança. A maneira como ele é escrito se faz tão importante pois é a prova de seu trabalho, ou seja, caso o relatório esteja redigido de maneira não satisfatória, independentemente da qualidade do pentest, o resultado também será insatisfatório ao cliente.
Para entendermos melhor como escrever um bom relatório de Pentest, devemos entender como é composta sua estrutura.
Título
Ao iniciar, o nome da vulnerabilidade deve ser especificado no título, porém de uma certa maneira. Por exemplo, o correto não seria usar apenas “Cross-Site Scripting Armazenado”, mas “Aplicação suscetível à injeção de JavaScript (cross-site scripting refletido) no parâmetro (nome do parâmetro)”
Desta maneira, o título fica mais objetivo e o cliente já saberá qual campo está vulnerável antes mesmo de ler a descrição da vulnerabilidade por completo.
OWASP/CWE
É interessante informar em quais itens do OWASP Top Ten a vulnerabilidade se encaixa, como em Aplicações Web: A01 – Broke Access Control; A02 – Cryptographic Failure; A03 – Injection, entre outros. A lista completa pode ser encontrada aqui.
Também informar a CWE (Common Weakness Enumeration), caso possua, se faz interessante para auxiliar ao time de desenvolvimento a entender melhor sobre o tipo de vulnerabilidade e suas correções. A página pode ser encontrada aqui.
Categoria/Subcategoria
A fim de especificar ainda mais a vulnerabilidade, é relevante informar qual categoria e subcategoria a fraqueza se encontra.
Dentro da aba “Categoria”, os itens devem se assemelhar com o OWASP Top Ten, enquanto em “Subcategoria”, deve ser mais específico ao item em questão.
Exemplo:
Categoria: Cross-site Scripting (XSS)
Subcategoria: Stored
Descrição
Partindo agora para a descrição da vulnerabilidade, inicialmente explica-se sobre a vulnerabilidade de forma geral. Em seguida, é abordado como ela ocorre naquele ambiente específico e, em conjunto com esse passo, são apresentadas provas de conceito (PoCs) realizadas, lembrando sempre de inserir o campo “Figura” abaixo da PoC, explicando exatamente do que se trata aquela imagem.
Caso a vulnerabilidade possua uma CVE (Common Vulnerabilities and Exposures), o mesmo deve ser informado e referenciado no campo “Referências“.
- É importante sempre se atentar a inserir o código utilizado em negrito;
- Nome da empresa que executou o pentest e nome do cliente também devem ser escritos em negrito;
- Palavras em inglês ou botões da aplicação devem ser referenciadas em itálico, com: “Vá até a aba de Configurações”;
- Deve ser mantida uma padronização em todo o texto, como exemplo, ao escrever “e-mail” o mesmo deve ser mantido até o final, não sendo alterado para outra forma como “email”.
- O texto inteiro deve ser escrito em terceira pessoa, obtendo um tom mais formal e passando a visão do pentester como observador. Por exemplo:
Maneira errada:
“Essa ausência de verificação permite a introdução de dados maliciosos ou inesperados, resultando em comportamentos inseguros ou não planejados”
Maneira correta:
“Foi verificado que a aplicação não possui um mecanismo de verificação na entrada de dados, permitindo ao atacante a introdução de dados maliciosos ou inesperados, resultando em comportamentos inseguros ou não planejados”
Prova de Conceito (PoC)
Agora mais a fundo dentro desse elemento, a PoC deve conter, além do texto, o item “Figura” abaixo. Ela também deve ser realizada de forma clara e objetiva. Para deixá-la mais objetiva e intuitiva, também podem ser inseridos retângulos e setas, em pontos onde deve ser dada a atenção/onde ocorre a vulnerabilidade.
Sempre atentar-se ao capturar a evidência, utilizando o tema claro sempre que possível e mantendo um padrão dentro do relatório de Pentest.
Dessa maneira fica mais fácil para o cliente entender o que e onde foi realizado, facilitando na compreensão durante a leitura.
No exemplo a seguir, podemos visualizar a presença de retângulos e setas, além do uso do tema claro, tornando os pontos de atenção mais evidentes:
Figura: Exemplo de PoC reportada
Se a evidência possuir dados sensíveis, os mesmos devem ser ofuscados a fim de resguardar a identidade das pessoas envolvidas.
Impacto
Vamos dizer porque é importante que esse problema seja corrigido, o que aconteceria se ele fosse explorado por um ator de ameaça e o que poderia acarretar de maneira comercial à empresa.
Essa aba é divida em duas partes: Impactos Técnicos e Impactos de Negócio.
- Negócio: Destinado a pessoas mais gerenciais. Nesse caso, não devemos hesitar em colocar sobre cenários de prejuízo financeiro, jurídico, indisponibilidade, etc., para que entendam o quão essencial é o trabalho de segurança.
- Técnico: Descrever o impacto técnico que a vulnerabilidade pode causar, sendo bem específico sobre ela.
Recomendação
Essa parte é uma das mais interessante aos desenvolvedores, pois irá auxiliá-los a corrigir o problema de maneira eficiente. Isso significa que, nessa aba, deve-se abordar, de maneira clara, sobre como corrigir, e explicar onde ir para efetuar a correção. Também é muito positivo incluir códigos que devem ser implementados.
Figura: Recomendação sobre a vulnerabilidade Falsificação de e-mails disponível na plataforma Vantico
Caso essa aba fique muito genérica, os desenvolvedores podem sentir dificuldades para implementar a correção da melhor maneira, enviando diversos re-tests. Sendo assim, com essa aba bem implementada, as correções serão implementadas mais rápida e corretamente.
Referências
Serve como um apoio para a recomendação, fornecendo links úteis para auxiliar na correção. Também é válido inserir links como a CVE identificada e referência a OWASP, trazendo uma visão mais ampla sobre a vulnerabilidade.
Ativo afetados
Nesse campo é inserido exatamente o fluxo em que a vulnerabilidade se encontra, para facilitar sua identificação.
Exemplo:
“https://ativo.com/username?email=“
Re-Test
Dentro do campo de re-test, deve ser inserida a situação atual da vulnerabilidade, como: “Não corrigido”, “Corrigido parcialmente”, “Corrigido parcialmente” e, em seguida falar sobre o ocorrido. Confira um exemplo:
“Não corrigido. Após o re-test, foi constatado de que a porta do serviço de SSH mantém-se aberta à internet.”;
“Corrigido parcialmente. Ao realizar o re-test, constatou-se que apenas alguns IPs tiveram suas portas restritas.”;
“Corrigido. Foi realizado o re-test e os ativos afetados tiveram suas portas restritas.”.
Em situações de vulnerabilidade “Corrigida”, é recomendado que seja anexado uma evidência demonstrando a correção junto à mensagem. Para essa evidência deve ser utilizado o mesmo padrão citado nas evidências, porém é interessante trocar os quadrados e setas vermelhas por quadrados e setas na cor azul, encaixando melhor ao status de corrigido. Confira o exemplo a seguir:
Figura: Exemplo de evidência de re-test
Como classificar corretamente uma vulnerabilidade?
Primeiro, devemos entender quais recursos temos para classificar uma vulnerabilidade. O mais utilizado no contexto de pentest é o CVSS Score.
Para calcular é simples: basta acessar a calculadora que está disponível neste link.
Nela podemos marcar várias informações, como: vetores de ataque, complexidade, privilégios requeridos, confidencialidade, integridade, disponibilidade, entre outros. Assim, ela irá retornar o valor do CVSS Score que será utilizado para determinar a gravidade da falha encontrada.
Figura: Calculadora CVSS
A classificação correta de uma vulnerabilidade serve para auxiliar os desenvolvedores a priorizarem quais vulnerabilidades corrigir primeiro.
Para entender melhor sobre a priorização, vamos explicar sobre cada um dos 5 tipos de gravidade possíveis nas vulnerabilidades.
Os 5 tipos de classificação das vulnerabilidades
Crítica
Falhas de gravidade máxima, com uma certa facilidade de exploração e que podem causar danos e prejuízos imediatos. São situações que devem ser priorizadas sob qualquer outra falha encontrada.
CVSS score: 9.0 a 10.0
Alta
Vulnerabilidades com alto potencial de impacto, como o bloqueio ou roubo de contas, com algum grau de dificuldade na exploração.
CVSS score: 7.0 a 8.9
Média
Falhas que dependem de certas condições específicas para serem exploradas, mas que, se ocorrerem, ainda podem causar perdas relevantes ou comprometer funções importantes.
CVSS score: 4.0 a 6.9
Baixa
Problemas de impacto limitado e de difícil exploração, geralmente associados a situações muito específicas ou configurações atípicas. Mesmo assim, representam um risco que merece atenção.
CVSS score: 0.1 a 3.9
Informativa
Não representam risco direto à segurança, mas indicam pontos de melhoria técnica ou boas práticas que podem ser adotadas no desenvolvimento.
Aqui se encaixam itens como a ausência de cabeçalhos de segurança, por exemplo.
CVSS score: 0
Exemplo de como reportar uma vulnerabilidade
A vulnerabilidade encontrada foi de SQL Injection.
A vulnerabilidade foi explorada usando uma ferramenta conhecida por sqlmap, que faz a exploração do SQL Injection.
Antes de sua utilização foi identificado um ponto da aplicação, parâmetro Usuario, expondo erros SQL ao inserir dados não esperados.
Figura: Erro de SQL
Agora que temos a validação da vulnerabilidade, vamos partir para a exploração, onde iremos gerar nossa prova de conceito sobre a vulnerabilidade.
Com o sqlmap foi explorado a vulnerabilidade.
Figura: Banco de dados descobertos via falha de SQL Injection
Com isso, foi possível acessar contas sem autorização dumpando dados dos bancos em texto plano, agravando ainda mais a vulnerabilidade.
Figura: Dados dumpados do banco de dados
Em seguida, devemos classificar nossa vulnerabilidade. Para isso, vamos utilizar o CVSS Score, como citado anteriormente.
Figura: Vulnerabilidade classificada com o CVSS Score
Como podemos visualizar, ela foi classificada como Crítica com um valor de 10.0, o que se deve aos blocos escolhidos.
- Escopo: Alterado, pois caso a vulnerabilidade obtenha uma exploração de sucesso, podemos acessar ativos internos não antes declarados no escopo.
- Confidencialidade, Integridade e Disponibilidade: Alta, pois a injeção de SQL pode expor dados confidenciais, modificá-los ou interromper serviços.
Exemplo de Relatório de Pentest
Com a nossa vulnerabilidade calculada, iremos iniciar a escrito do relatório de Pentest. Inicialmente devemos buscar um título que corresponda a vulnerabilidade identificada. Iremos utilizar:
Título: “Possibilidade de manipular comandos SQL na aplicação no parâmetro Usuario”.
Partindo para a descrição, devemos buscar primeiro explicar sobre a vulnerabilidade e, em seguida, sobre como foi identificada, prova de conceito, etc.
Descrição: “SQL Injection é uma vulnerabilidade que ocorre quando a aplicação não valida, filtra ou sanitiza adequadamente os dados fornecidos pelo usuário. Isso permite que um invasor insira comandos SQL maliciosos nos campos de entrada, o que pode resultar em acesso não autorizado a informações sensíveis ou até no comprometimento completo do sistema.
Esse tipo de ataque explora falhas na validação dos dados de entrada — como formato, tamanho e caracteres permitidos — para injetar trechos de comandos SQL diretamente nas consultas feitas ao banco de dados. Quando bem-sucedido, o invasor pode manipular essas consultas para realizar ações maliciosas, como visualizar, alterar ou excluir dados.
Além dos impactos diretos ao banco de dados, um SQL Injection pode abrir portas para que o atacante acesse outros sistemas conectados, ampliando os danos e comprometendo toda a infraestrutura da aplicação.”
Dessa maneira, criamos a introdução da nossa descrição explicando sobre o que é a vulnerabilidade em si, agora iremos aprofundar mais no contexto do cliente.
“Foi identificado uma exposição de erros SQL em demonstrou um possível ponto vulnerável a injeção de comandos SQL.
Evidência 1
Figura: Erro SQL
Através disto foi realizado uma exploração com a ferramenta sqlmap, em que foi possível “dumpar” todos os dados presentes nos 66 bancos disponíveis dentro do banco de dados, como é possível visualizar a seguir:
Evidência 2
Figura: Bancos presentes na aplicação
Explorando mais a fundo o banco (nome do banco) foi possível obter e-mails, usuários, senhas, grupoacesso, id e nome, todos em texto plano sem criptografia.
Evidência 3
Figura: Dump de dados como e-mail, usuário, grupos, nomes, senhas.”
Aqui finalizamos a descrição da nossa vulnerabilidade, partindo para a aba de Impactos. Ela será dividida em “Impacto técnico” e “Impacto de negócio”, com a vulnerabilidade podendo ser inserir do seguinte modo:
“Impacto de Negócio:
Exposição de Dados Sensíveis e Propriedade Intelectual: A execução de comandos maliciosos pode levar ao vazamento de informações confidenciais, como dados de clientes, segredos comerciais e informações financeiras. Isso pode resultar em fraudes, perda de vantagem competitiva e até casos de extorsão.
Interrupção de Operações e Serviços: A manipulação direta do banco de dados pode comprometer funcionalidades essenciais — como sistemas de cadastro, pagamento ou produção — gerando paralisações, perda de receita e danos à imagem da empresa.
Sanções Regulatórias e Ações Judiciais: Vazamentos de dados pessoais podem violar legislações de proteção de dados, resultando em multas aplicadas por órgãos reguladores e processos judiciais movidos por clientes afetados, impactando diretamente as finanças e a estratégia da organização.
Impacto Técnico:
Controle Indevido do Banco de Dados: O atacante pode obter privilégios elevados, executando comandos para visualizar, alterar ou excluir dados, além de modificar a estrutura das tabelas ou comprometer o funcionamento da aplicação.
Escalonamento de Acesso e Exploração de Outros Sistemas: A partir da injeção SQL, o invasor pode acessar funcionalidades avançadas do SGBD, explorar arquivos locais e capturar credenciais, expandindo o ataque para outros sistemas conectados.
Baixa Visibilidade e Resposta Tardia: A natureza silenciosa das consultas maliciosas dificulta sua detecção imediata, permitindo que o invasor permaneça por longos períodos no ambiente, coletando informações e planejando ações mais sofisticadas.”
Escrito dessa maneira, o “impacto” fica de acordo com a fraqueza identificada e demonstra ao cliente a que a aplicação dele está potencialmente exposta.
Agora, na aba de recomendações, vamos passar ao cliente quais medidas ele deve tomar com o intuito de corrigir a vulnerabilidade. É interessante buscar configurações que podem ser adicionadas de acordo com as tecnologias da aplicação a fim de facilitar a correção.
“Recomendação:
Utilize Instruções Preparadas (Consultas Parametrizadas): Instruções preparadas separam a lógica da consulta SQL dos dados fornecidos, impedindo que entradas maliciosas sejam interpretadas como parte da consulta. São também conhecidas como consultas parametrizadas ou consultas vinculadas. Essa técnica é essencial para evitar a manipulação de comandos SQL por meio de entradas do usuário.
Valide Dados de Entrada: Qualquer dado vindo de fontes externas, como formulários de usuários ou requisições de APIs, deve ser validado cuidadosamente. Não confie em dados externos sem verificação.
Aplique Filtros de Validação: Implemente filtros que definam claramente quais dados são considerados válidos. A abordagem mais segura é utilizar listas de permissões (whitelists), permitindo apenas caracteres ou formatos previamente definidos como aceitáveis.
Exemplo de dados permitidos: letras (A-Z, a-z) e números (0-9).
Caracteres especiais e comandos devem ser rejeitados ou tratados com cuidado.”
Por último, iremos buscar referências que auxiliem na correção da vulnerabilidade especificada, neste caso iremos utilizar as seguintes referências:
“Referências:
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
https://www.owasp.org/index.php/SQL_Injection”
Unindo todos os campos, nosso relatório de Pentest ficou da seguinte maneira:
Título:
Possibilidade de manipular comandos SQL na aplicação no parâmetro Usuario
Descrição:
SQL Injection é uma vulnerabilidade que ocorre quando a aplicação não valida, filtra ou sanitiza adequadamente os dados fornecidos pelo usuário. Isso permite que um invasor insira comandos SQL maliciosos nos campos de entrada, o que pode resultar em acesso não autorizado a informações sensíveis ou até no comprometimento completo do sistema.
Esse tipo de ataque explora falhas na validação dos dados de entrada — como formato, tamanho e caracteres permitidos — para injetar trechos de comandos SQL diretamente nas consultas feitas ao banco de dados. Quando bem-sucedido, o invasor pode manipular essas consultas para realizar ações maliciosas, como visualizar, alterar ou excluir dados.
Além dos impactos diretos ao banco de dados, um SQL Injection pode abrir portas para que o atacante acesse outros sistemas conectados, ampliando os danos e comprometendo toda a infraestrutura da aplicação.
Foi identificado uma exposição de erros SQL em demonstrou um possível ponto vulnerável a injeção de comandos SQL.
Figura: Erro SQL
Por meio disso, foi realizado uma exploração com a ferramenta sqlmap, em que foi possível “dumpar” todos os dados presentes nos 66 bancos disponíveis dentro do banco de dados, como é possível visualizar a seguir:
Figura: Bancos presentes na aplicação
Explorando mais a fundo o banco (nome do banco) foi possível obter e-mails, usuários, senhas, grupoacesso, id e nome, todos em texto plano sem criptografia.
Figura: Dump de dados como e-mail, usuário, grupos, nomes, senhas
Impacto de Negócio:
Exposição de Dados Sensíveis e Propriedade Intelectual: A execução de comandos maliciosos pode levar ao vazamento de informações confidenciais, como dados de clientes, segredos comerciais e informações financeiras. Isso pode resultar em fraudes, perda de vantagem competitiva e até casos de extorsão.
Interrupção de Operações e Serviços: A manipulação direta do banco de dados pode comprometer funcionalidades essenciais — como sistemas de cadastro, pagamento ou produção — gerando paralisações, perda de receita e danos à imagem da empresa.
Sanções Regulatórias e Ações Judiciais: Vazamentos de dados pessoais podem violar legislações de proteção de dados, resultando em multas aplicadas por órgãos reguladores e processos judiciais movidos por clientes afetados, impactando diretamente as finanças e a estratégia da organização.
Impacto Técnico:
Controle Indevido do Banco de Dados: O atacante pode obter privilégios elevados, executando comandos para visualizar, alterar ou excluir dados, além de modificar a estrutura das tabelas ou comprometer o funcionamento da aplicação.
Escalonamento de Acesso e Exploração de Outros Sistemas: A partir da injeção SQL, o invasor pode acessar funcionalidades avançadas do SGBD, explorar arquivos locais e capturar credenciais, expandindo o ataque para outros sistemas conectados.
Baixa Visibilidade e Resposta Tardia: A natureza silenciosa das consultas maliciosas dificulta sua detecção imediata, permitindo que o invasor permaneça por longos períodos no ambiente, coletando informações e planejando ações mais sofisticadas.
Recomendação:
Utilize Instruções Preparadas (Consultas Parametrizadas): Instruções preparadas separam a lógica da consulta SQL dos dados fornecidos, impedindo que entradas maliciosas sejam interpretadas como parte da consulta. São também conhecidas como consultas parametrizadas ou consultas vinculadas. Essa técnica é essencial para evitar a manipulação de comandos SQL por meio de entradas do usuário.
Valide Dados de Entrada: Qualquer dado vindo de fontes externas, como formulários de usuários ou requisições de APIs, deve ser validado cuidadosamente. Não confie em dados externos sem verificação.
Aplique Filtros de Validação: Implemente filtros que definam claramente quais dados são considerados válidos. A abordagem mais segura é utilizar listas de permissões (whitelists), permitindo apenas caracteres ou formatos previamente definidos como aceitáveis.
Exemplo de dados permitidos: letras (A-Z, a-z) e números (0-9).
Caracteres especiais e comandos devem ser rejeitados ou tratados com cuidado.
Referências:
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
https://www.owasp.org/index.php/SQL_Injection
Com isso, nosso relatório de Pentest fica completo, contendo: título adequado, descrição explicativa sobre a vulnerabilidade, como ela afeta a aplicação e com uma prova de conceito, impactos que ela traz tanto do ponto de vista técnico quanto comercial, recomendações para facilitar a correção e referências como apoio para a correção.
Além disso, seguir esse padrão estruturado garante clareza na comunicação com os times técnicos e de negócio, facilita o entendimento das prioridades de correção e contribui para a tomada de decisões mais rápidas e eficazes no processo de mitigação de riscos.
Créditos
Referências
The Art of Writing Security Reports
Pro tips from 10 ethical hackers for stellar reports
Common Vulnerability Scoring System SIG
SQL Injection Prevention Cheat Sheet