Relatório de Pentest com vulnerabilidades

de 23
RELATÓRIO DE TESTE DE INVASÃO
DE:
PARA:
© DEXTERLAB CONSULTORIAS - Todos os direitos reservados 2014
Este documento contém informações confidenciais e proprietárias. É destinado somente para uso exclusivo da rede JOÃOSUPERMERCADOS. A reprodução ou o uso não autorizado deste documento é proibido.
Diversos testes foram conduzidos pelos profissionais de segurança da DEXTERLAB CONSULTORIA. A DEXTERLAB garante que todos os pontos apresentados neste relatório são verdadeiros através de provas de conceitos.
Estes Testes de Invasão identificou e explorou diversas vulnerabilidades que podem causar grandes prejuízos ao negócio da empresa. Como sempre surgem novas vulnerabilidades, recomenda-se que testes como esses sejam conduzidos a cada mudança realizada no ambiente de TI ou em intervalos de 3 a 6 meses.

de 23
DETALHES DO DOCUMENTO
Empresa Cliente
JoãoSupermercados
Título do Documento
Relatório dos Testes de Invasão
Referência
DL-2014010
Classificação
Confidencial
Tipo de documento
Relatório
Responsável pelos testes
Empresa Contratada
Equipe de Pentesting
DEXTERLAB CONSULTORIAS
HISTÓRICO DO DOCUMENTO
Data
Versão
Autor
Comentários
10/11/2014
01.00
Vitor Melo
Versão Inicial.
16/11/2014
01.01
Vitor Melo
Revisão do documento.
CONTATO
Para mais informações sobre este documento e seu conteúdo, por favor, entrar em contato com os serviços profissionais da DEXTERLAB CONSULTORIAS.
Nome
DEXTERLAB CONSULTORIAS
Endereço R. Carlos Silveira Santos, 850 - Centro, João Pessoa - PB, 58040-390
Telefone
(83) 3241-1989
E-mail
dexterlab@consultorias.com

de 23
CONTEÚDO
1. RESUMO EXECUTIVO ............................................................................................................ 4
2. ESCOPO ................................................................................................................................. 5
2.1 SISTEMAS ALVOS ........................................................................................................... 5
3. METODOLOGIA ......................................................................................................................... 6
3.1 FERRAMENTAS .................................................................................................................... 6
3.2 CLASSIFICAÇÃO DOS IMPACTOS DAS VULNERABILIDADES ................................................. 7
4.RELATÓRIO TÉCNICO ................................................................................................................. 8
4.1 INFRAESTRUTURA ............................................................................................................... 8
4.1.1 Ausência de senha no acesso remoto ao MySQL ......................................................... 9
4.1.2 Política de Senha fraca no VNC Server ....................................................................... 11
4.2 APLICAÇÕES WEB .............................................................................................................. 13
4.2.1 Injeção no formulário de upload ................................................................................ 13
4.2.2 Referência insegura e direta a objetos ...................................................................... 17
4.2.3 Exposição de dados sensíveis ..................................................................................... 19
4.2.4 Cross-Site-Scripting .................................................................................................... 20
4.2.5 Furo de Autenticação e Gerência de Sessão .............................................................. 21
5. CONCLUSÃO ............................................................................................................................ 23

de 23
1. RESUMO EXECUTIVO
Este relatório descreve detalhadamente os resultados encontrados dos Testes de Invasão realizados no servidor e aplicações web da rede JOÃOSUPERMERCADOS. Estes testes foram realizados por profissionais qualificados e certificados na área. O objetivo do procedimento efetuado foi identificar e explorar vulnerabilidades de infraestrutura e aplicações que podem impactar nos negócios da rede JOÃOSUPERMERCADOS, antes que um usuário malicioso ou um ataque externo o faça.
Para avaliar a segurança da infraestrutura e das aplicações, a DEXTERLAB CONSULTORIAS, durante o período de testes, do dia 10/11 à 14/11/2014, realizou acessos não autorizados, obtenção de informações confidenciais e identificou e explorou outros tipos de vulnerabilidades.
Inicialmente o reconhecimento da rede foi executado no endereço IP fornecido pela rede JOÃOSUPERMERCADOS, entendendo entre ambas as partes que estes mesmos fazem parte do escopo do acordo. Apesar da rede JOÃOSUPERMERCADOS ter uma presença externa mínima, com apenas um domínio, pelas vulnerabilidades encontradas neste último, a superfície de ataque para usuários com más intenções é muito grande.
Recomenda-se que o resultado destes testes sejam usados pela rede JOÃOSUPERMERCADOS para tomar decisões de melhoria quanto ao seu programa de segurança da informação. É importante enfatizar que todos os resultados transparecem o estado de segurança do ambiente de TI somente no período acordado e por esta razão é interessante que o cliente se submeta novamente aos testes a cada mudança realizada em seu ambiente ou em intervalos de 3 a 6 meses.

de 23
2. ESCOPO
Assim como todo projeto de segurança da informação, as estratégias e táticas que serão aplicadas nos testes de invasão devem ser muito bem planejadas. Por esta razão juntamente com os diretores da JOÃOSUPERMERCADOS, diversas reuniões foram realizadas para definir bem o escopo do serviço de Pentesting que foi realizado pela equipe de profissionais da DEXTERLAB CONSULTORIAS.
A JOÃOSUPERMERCADOS se submeteu aos testes de invasão buscando alcançar os seguintes objetivos:
 Testar a efetividade das suas soluções tecnológicas implementadas;
 Determinar as medidas que devem ser tomadas para melhor aliviar os riscos provenientes das vulnerabilidades e ameaças detectadas;
 E avaliar a habilidade de reação do departamento de TI em identificar e responder aos ataques corretamente.
Preocupados com o impacto que os testes poderiam causar ao seu ambiente de TI, foi solicitado à realização de um Pentesting menos agressivo, onde as explorações não causariam a disponibilidade dos sistemas.
Por ter um ambiente relativamente pequeno, o prazo estipulado e acordado para os dias, foi de uma semana, sem contar com os dois dias do final de semana, sábado e domingo. Iniciando no dia 10/11/14 com término no dia 14/11/14. Sendo este prazo alterado, se solicitado.
O tipo de teste executado foi o não anunciado e o Grey-box. Quando os testes não são anunciados, significa que todos os funcionários não sabem que estão sendo auditados. E por ser Grey-box, a Equipe de Pentesting da DEXTERLAB CONSULTORIAS teve acesso somente algumas informações como endereços IPs, sendo eles responsáveis por descobrir as outras informações.
A garantia das informações aqui reportadas foi assegurada por meio da assinatura de um contrato formal, onde a DEXTERLAB CONSULTORIAS juntamente com o JOÃOSUPERMERCADOS concordou em não divulgar as informações compreendidas pelo acordo.
2.1 SISTEMAS ALVOS
Segue a lista das URLS e servidor definidos como alvo para os testes de invasão:

de 23
APLICAÇÕES
URL 1
vitor.physecure.com.br
URL2
192.168.56.102/dvwa
SERVIDOR (Metasploitable)
ENDEREÇO IP
192.168.56.102
3. METODOLOGIA
No ambiente da Tecnologia da Informação, diversas metodologias são usadas para diferentes finalidades, compreendendo não só os níveis táticos, mas também o operacional da organização.
Dessa forma, é fato concluir que a metodologia é parte fundamental no processo de execução de um Pentesting, pois o mesmo consiste em um conjunto de procedimentos. Apesar de existirem diferentes metodologias no mercado, como OSSTMM, OWASP, ISSAF, NIST, que podem ser executadas para aplicar um Pentesting, a DEXTERLAB CONSULTORIAS baseada na sua experiência de mercado prefere utilizar a sua própria, composta de quatro fases:
Os tamanhos das caixas coloridas variam representando a jornada do amplo ao específico ao longo do Pentesting. Por exemplo, a fase inicial de coleta de informações recomenda-se que seja a mais duradora, pois quanto maior o conhecimento sobre o ambiente alvo, mais fácil será invadi-lo. A duração de cada fase pode variar dependendo das informações encontradas.
3.1 FERRAMENTAS
Várias ferramentas comerciais e de código aberto foram usadas durante os testes. São elas:

de 23
Port Scanning e FootPrinting
Nmap, Google Enumeração em Aplicações Web Nikto
Identificação de Vulnerabilidades
Nessus Teste de Invasão em Redes Metasploit Framework, Hashcat
Teste de Invasão em Aplicações Web
Burp – Free Edition Verificação e Pesquisa de Vulnerabilidades http://securityfocus.com, http://www.osvdb.org, http://www.metasploit.com, www.exploit-db.com/
3.2 CLASSIFICAÇÃO DOS IMPACTOS DAS VULNERABILIDADES
Ao longo do documento, cada vulnerabilidade descrita foi classificada com níveis de severidade. Esta classificação de severidade foi adotada de acordo com o impacto que as mesmas podem causar se exploradas. As categorias são Baixo, Moderado e Alto:
Baixo: São condições identificadas que não resulta diretamente no comprometimento de uma rede, sistema, aplicação ou informação. Mas pode ser usado em conjunto com outras informações para ganhar o conhecimento para comprometer estes recursos. Geralmente apresenta poucas informações sobre um ativo. Como por exemplo, ao banner de algum serviço.
Moderado: Vulnerabilidades classificadas com este tipo de severidade incluem sistemas, arquivos e serviços não protegidos que podem causar a negação dos serviços de sistemas não críticos ou exposição de informações de configurações, que podem fornecer detalhes que facilitaram uma futura exploração.
Alto: São condições identificadas que podem comprometer diretamente uma rede, sistema, aplicação ou informação. Exemplos de vulnerabilidades altas, incluem buffer overflows, senhas fracas ou a não utilizam delas, não criptografia, o que pode resultar na negação de serviços ou sistemas críticos; acesso não autorizado; e a divulgação de informações.

de 23
4.RELATÓRIO TÉCNICO
4.1 INFRAESTRUTURA
Segundo o contrato acordado com a JOÃOSUPERMERCADOS, somente o servidor Metasploitable de IP 192.168.56.102 poderia ser testado. Sabendo disso, inicialmente foi realizado um mapeamento, para coleta de informações, do alvo com a ferramenta Nmap. Com a ferramenta foi possível identificar as portas, serviços e sistema operacional em execução.
Os parâmetros foram combinados em um mesmo comando por questão de praticidade. O parâmetro usado para mostrar as portas abertas na vítima foi o TCP SYN Scan (-sS), pois apesar de ser mais lento do que o TCP Connect Scan (-sT), é mais difícil de ser detectado. O “-sV” para informar as versões dos serviços que estavam executando em cada porta aberta e o “-O”, para indicar o sistema operacional que o Metasploitable estava rodando.
Dentre as vinte e três portas abertas, novecentos e setenta e sete portas foram dadas como fechadas. E em relação à identificação do sistema operacional, ela não foi exata, pois o Nmap indicou corretamente que é uma máquina GNU/LINUX, mas não soube identificar especificamente a versão.
O fato das portas apresentadas no screenshot estarem abertas, não são sinônimos da máquina estar vulnerável, mas apenas que há um serviço sendo oferecido naquela porta. Por esta razão, uma análise mais a fundo de cada informação apresentada no mapeamento, foi feita e para auxiliar a identificação de vulnerabilidades, optou-se por usar a ferramenta Nessus.

de 23
4.1.1 Ausência de senha no acesso remoto ao MySQL
Nível de Severidade
Alto
Resumo
A varredura da ferramenta Nessus nos informou que o banco MySQL que está execução no servidor Metasploitable, pode ser acessado remotamente sem a necessidade de utilizar senhas, o que possibilita a um atacante ter acesso a todo o banco de dados remotamente.
Prova de Conceito
Para comprovar a vulnerabilidade, foi realizada a tentativa de acesso ao banco, com o usuário administrador, sem senha e de imediato o acesso foi obtido.
Estando dentro do banco de dados foi possível conhecer a organização do mesmo. Como evidência, usamos o banco da aplicação dvwa e selecionamos a coluna usuários:

de 23
Identificamos que esta base dvwa, as senhas estão sendo armazenadas com os seus respectivos hashes. Como essa não é uma forma segura de armazená-las em um banco, usamos a ferramenta hashcat para realizar um ataque de dicionário, passando arquivos como parâmetros e assim quebramos a senha do administrador:
Na base da owasp10 obtivemos acesso a uma informação extremamente confidencial e crítica que são as de cartão de crédito dos clientes:
E a senha de cada usuário que está armazenada em texto plano:

de 23
Recomendação
Como foi possível ter acesso ao banco com privilégios de administrador, a primeira recomendação é criar uma senha forte, com no mínimo dez caracteres, contendo letras maiúsculas e minúsculas, números e caracteres especiais para o acesso remoto. Segunda recomendação é limitar o acesso ao banco através do Firewall, por exemplo, para um IP específico, no caso o administrador do banco. A terceira é atualizar a versão do banco para a mais nova, pois está executando uma versão bastante vulnerável e última, é proteger os dados dos clientes criptografando- os, garantindo uma proteção maior aos dados armazenados na base.
Referências
http://www.mysql.com/
http://dev.mysql.com/doc/refman/5.6/en/writing-password-validation-plugins.html
http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html
http://www.myquerybuilder.com/help/howtosetupaconnection
4.1.2 Política de Senha fraca no VNC Server
Alto
Resumo
A varredura da ferramenta Nessus nos informou que o servidor VNC, usado para possibilitar interfaces gráficas remotas no Metasploitable, pode ser acessado com uma senha fraca, ou seja, está utilizando uma Política de Senhas Fraca, possibilitando a um atacante ter acesso e controle da máquina vulnerável com facilidade.

de 23
Prova de Conceito
Para comprovar a vulnerabilidade, tentamos e conseguimos acesso ao servidor com a senha “password” apresentada pelo Nessus:
Estando dentro do servidor Metasploitable, foi possível navegar pelo sistema de arquivos do sistema, encontrando usuários que possuem shell, os bancos e aplicações hospedadas, entre outras coisas. Para garantir que este acesso não seria perdido, a senha de root foi trocada, para possibilitar o acesso posterior à máquina por meio de SSH e ainda outro usuário foi criado:

de 23
Recomendação
Como foi possível ter acesso ao servidor com privilégios de administrador, a primeira recomendação é seguir a Política de Senhas fortes já comentadas na subseção anterior para o acesso remoto. Substituir o uso do VNC no servidor por um tipo de acesso mais seguro como o SSH, o qual garante que os dados trafegados entre cliente e servidor são criptografados, limitando o acesso a determinadas máquinas por meio de chaves criptográficas.
Referências
http://www.openssh.com/
https://www.realvnc.com/products/vnc/documentation/5.0/guides/user/aj1074738.html
4.2 APLICAÇÕES WEB
DVWA
4.2.1 Injeção no formulário de upload
Alto
Resumo
A partir da exploração da vulnerabilidade já apresentada na subseção 4.1.1, obtivemos as credenciais de acesso à aplicação dvwa. Nela exploramos o formulário de upload. Que por falhas de programação não valida adequadamente o tipo de extensão que está sendo enviada para o servidor, o que possibilita a um atacante inserir scripts para obtiver uma shell reversa da máquina vulnerável.
Prova de conceito
Como não há uma validação apropriada, usando o “msfpayload” da ferramenta Metasploit Framework, foi criado um arquivo com o nome “php_shell_reverso.php”, responsável por montar o túnel reverso com a vítima e inserimos no campo:

de 23
Para ativar uma conexão reversa na porta 4444 com a nossa máquina, primeiramente foi setado pelo “msfconsole” do Metasploit Framework um listener, o qual ficou esperando a execução do código.
Execução do código php pelo navegador:

de 23
Após a execução do código, uma sessão “meterpreter” é retornada. Nela, há a possibilidade de fazer o dump dos hashes de senhas do sistema, migrar para outro processo, além de disponibilizar um shell interativo para que sejam escalados privilégios com a execução de comandos específicos na máquina alvo.
Como evidência da exploração, um arquivo chamado “hackeado.html” foi criado e hospedado no servidor, comprovando também que haveria a possibilidade de ser realizar um deface das páginas hospedadas.

de 23
Recomendação
Para evitar que este tipo de vulnerabilidade exista na aplicação e ela seja explorada, é recomendado que em nível de código, seja inserida uma validação das extensões dos arquivos, de acordo com a função do campo, que pode variar desde aceitar documentos como imagens.
Referências
http://stackoverflow.com/questions/254184/filter-extensions-in-html-form-upload
http://stackoverflow.com/questions/310714/how-to-check-file-types-of-uploaded-files-in-php
PHYSECURE
Na aplicação physecure, disponibilizada no domínio vitor.physecure.com.br (54.173.106.152), por não gerar tantas requisições, o que poderia comprometer a disponibilidade da aplicação, o web server scanner Nikto foi o selecionado para coletar as informações iniciais que auxiliaram a execução das etapas do processo de invasão. Com este scanner open-source as configurações dos servidores foram checadas, foram verificados a presença de diretórios ocultos, opções de HTTP usados, entre outras informações.
De fato os resultados do Nikto nos trouxe uma série de detalhes e recursos que são considerados vulnerabilidades, alguns deles foram explorados por nós nas subseções a seguir.

de 23
4.2.2 Referência insegura e direta a objetos
Moderado
Resumo
A referência direta ao objeto acontece quando um programador expõe a referência de objetos que deveriam ser somente visualizados em ambientes de homologação, como arquivos, diretórios ou chaves do banco. Quando não há uma verificação ou controle de acesso sobre estes objetos, atacantes podem manipular estas referências para obter acesso não autorizado a dados.
Prova de conceito
A fim de comprovar que de fato a vulnerabilidade da referência direta de objetos apresenta pela ferramenta Nikto existe, a navegação pelos diretórios informados e outros foi executada:
No decorrer da navegação o arquivo de backup do banco da aplicação foi encontrado. O fato de não ter um controle de acesso apropriado para um tipo de arquivo tão crítico como este, torna a vulnerabilidade, que tem o seu nível de severidade classificada como moderada, em crítico.

de 23
Analisando detalhadamente o arquivo de backup, conhecemos a estrutura e organização do banco da aplicação, como versão, base, tabelas, colunas, usuários e senhas.
Com todos os dados em mãos, um usuário da base da aplicação foi selecionado, no caso Ramiro Santos e com suas credenciais, matrícula e senha, acessamos a aplicação:

de 23
A mesma vulnerabilidade existente na página principal da aplicação, anteriormente ao processo de logon, que nos permitiu encontrar o arquivo de backup, também existe sobre a perspectiva do usuário logado. Pois, o Ramiro Santos, que deveria visualizar somente os chamados 106, 107 e 108, poderia através da manipulação da URL acessar outros incidentes que não são de sua responsabilidade. Comprovamos este ponto manipulando o parâmetro “seq” para o número 150 na URL:
Recomendação
Com o uso de boas práticas de desenvolvimento seguro esta vulnerabilidade pode ser facilmente mitigada, bastando aplicar mapeamentos de referências e validações de acessos por cada usuário.
Referências
https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
4.2.3 Exposição de dados sensíveis
Alto
Resumo
Muitas aplicações web não protegem devidamente os dados sensíveis, tais como cartões de crédito, IDs e credenciais de acesso. Os atacantes podem explorar esta vulnerabilidade para roubar ou modificar esses dados desprotegidos. Por esta razão, parada dados sensíveis é recomendado sempre utilizar a criptografia tanto no armazenamento quanto no trânsito de dados na rede (HTTPS).
Prova de conceito
Sabe-se que o protocolo HTTP permite a transferência de páginas web entre o cliente web (browser) e o servidor web. Este protocolo deve ser usado somente quando informações

de 23
confidenciais não estão sendo transmitidas entre eles. Neste caso, isso significa que por aplicação physecure ter em backend um banco com as credenciais de acesso dos usuários, deveria estar utilizando o protocolo HTTPS para garantir a confidencialidade e integridade dos dados trafegados. Tendo o Burp Suite atuando como proxy, comprovou-se que os dados estão trafegando em texto plano. Evidência coletada após inserir uma matrícula e senha qualquer:
Recomendação
A utilização do HTTPS como um HTTP com o SSL (Secure Socket Layer) ou, com TLS (Transport Layer Security) adicionam camadas de segurança que fornecem a confidencialidade e integridade das comunicações, por isso é importantíssimo que em aplicações como estas onde são trafegadas informações sensíveis seja utilizado este protocolo.
Referências
https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure
4.2.4 Cross-Site-Scripting
Moderado
Resumo
Falhas de Cross-Site-Scripting, conhecidas como XSS, ocorrem sempre que uma aplicação recebe dados não confiáveis e apresenta ao navegador sem realizar a validação adequada. XSS permite aos atacantes executarem scripts no navegador da vítima, possibilitando-os “sequestrar” sessões do usuário, bem como redirecionar o usuário para sites maliciosos.

de 23
Prova de conceito Para validar a existência desta vulnerabilidade, sobre a perspectiva do usuário logado Ramiro Santos, o seguinte código foi inserido na URL: “ <script>alert(document,cookie)</script>”, instantaneamente o navegador trouxe o cookie do usuário logado. Este tipo de exploração é chamado de XSS Stored (XSS Persistente), pois o código malicioso inserido pode ser permanentemente armazenado no servidor web, banco de dados, fórum, campo de comentários e etc. Onde o usuário torna-se vítima ao acessar a área afetada pelo armazenamento do código.
Recomendação
Deve-se levar em consideração que todas as entradas de dados do usuário não são confiáveis. Por isso todos os dados fornecidos por eles, devem ser verificados para assegurar que não causaram um mau comportamento da aplicação.
Referências
https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)
4.2.5 Furo de Autenticação e Gerência de Sessão
Alto
Resumo
Um dos mecanismos mais importantes para a segurança das aplicações web é a Autenticação e Gerenciamento de Sessão. Mesmo assim, comumente é possível se deparar com falhas nesses mecanismos, colocando em riscos as credenciais de acesso dos usuários.

de 23
Prova de conceito Analisando o processo de autenticação (logon) e o logout da physecure, as vulnerabilidades a seguir foram encontradas:  Para troca de senhas não é exigido nenhuma Política de Senhas robusta;  Na autenticação não é utilizado o CAPTCHA, sistema que impede que ferramentas automatizadas realizem ataques de força bruta na senha;  As credenciais são enviadas para o servidor em texto plano;  Na troca de senhas, um link de uso único deveria ser enviado para o e-mail do solicitante e este mesmo trocaria a senha, mas não deve existir a possibilidade de repetição de credenciais já utilizadas;  Senha atual aparece em texto plano na própria aplicação;  Ao se deslogar, a sessão não é encerrada, apenas há um redirecionamento para a página principal da aplicação. Senha do usuário Ramiro Santos foi trocada para o número “1” sem envio de link por e-mail: Captura da troca da senha pelo Burp Suite:
Recomendação
Diversos procedimentos de mitigação destas vulnerabilidades são sugeridos pela OWASP, como por exemplo:
 Não permitir que o processo de login comece em uma página não criptografada;
 Impedir que o usuário possa utilizar senhas antigas;
 Exigir uma Política de Senhas robustas;
 Assegurar que todas as páginas tenham um link de logout;

de 23
 Encerrar a sessão do usuário ao deslogar;
Entre outras que podem ser encontrados nos links de referências.
Referências
http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml
http://www.owasp.org/index.php/Guide_to_Authentication
http://www.owasp.org/index.php/Reviewing_Code_for_Authentication
http://www.owasp.org/index.php/Testing_for_authentication
5. CONCLUSÃO
Durante a execução dos Testes de Invasão, diversas vulnerabilidades foram identificadas. As classificações variaram entre Moderadas e Altas. Onde foi comprovado que a exploração delas, pode causar grandes prejuízos e impactos para o negócio da JOÃOSUPERMERCADOS e seus clientes.
Os objetivos principais definidos no escopo como testar a efetividade suas soluções tecnológicas implementadas e determinar as medidas que devem ser tomadas para melhor aliviar os riscos provenientes das vulnerabilidades e ameaças detectadas foram alcançados.
Assumindo a identidade de um atacante com más intenções, comprovou-se que com o auxílio de ferramentas comerciais e abertas e com o mínimo de conhecimento técnico sobre elas, é possível comprometer as aplicações e oservidor, se caso boas práticas de segurança não forem aplicadas nestes ativos.
Desta maneira a DEXTERLAB CONSULTORIAS sugere fortemente que todas as recomendações sejam aplicadas ou adotadas pela equipe de TI da JOÃOSUPERMERCADOS, pois são elas que irão mitigar riscos maiores ao negócio.

Relatório de Pentest com vulnerabilidades

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (15)

Semelhante a Relatório de Pentest com vulnerabilidades

Semelhante a Relatório de Pentest com vulnerabilidades (20)

Relatório de Pentest com vulnerabilidades