Apostila de Teste de Invasao em Redes e Sistemas

TESTE DE INVASÃO EM REDES E
SISTEMAS
UNICIV – Centro de Inovação Vincit

EAD Ethical Hacking e CyberSecurity
VERSÃO 1.0
08/08/2018
TESTE DE INVASÃO EM REDES E SISTEMAS
PROF. ESP. DIEGO MACÊDO

UNICIV – CENTRO DE INOVAÇÃO VINCIT
HTTPS://SITE.UNICIV.COM.BR
08/08/2018 Teste de invasão em redes e sistemas 1
Prof. Esp. Diego Macêdo

SUMÁRIO
1. Introdução ao Teste de Invasão ......................................................................................... 4
Conceitos básicos ................................................................................................................... 4
Pré-Compromisso ................................................................................................................... 4
Reconhecimento .................................................................................................................... 5
Escaneamento ........................................................................................................................ 5
Exploração .............................................................................................................................. 6
Pós-Exploração ....................................................................................................................... 6
Relatório ................................................................................................................................. 6
2. Metodologias ...................................................................................................................... 8
OWASP Testing Guide v4 ....................................................................................................... 8
NIST 800-115 .......................................................................................................................... 9
PCI-DSS ................................................................................................................................. 10
PTES ...................................................................................................................................... 11
3. Nmap ................................................................................................................................ 12
Identificando hosts ............................................................................................................... 12
4. Metasploit......................................................................................................................... 16
Visão geral ............................................................................................................................ 16
5. Nessus ............................................................................................................................... 24
Visão geral ............................................................................................................................ 24
6. Burp Suite ......................................................................................................................... 32
Introdução ............................................................................................................................ 32
7. Common Vulnerability Scoring System (CVSS) ................................................................. 38
Introdução ............................................................................................................................ 38
Sub-grupo de métricas: Impact ............................................................................................ 42
Pontuação ............................................................................................................................ 44
Temporal .............................................................................................................................. 45
Environmental ...................................................................................................................... 47
Métricas Base Modificadas .................................................................................................. 48
Exercícios .............................................................................................................................. 49
8. Avaliação ........................................................................................................................... 52
Perguntas ............................................................................................................................. 52
9. Bibliografia ........................................................................................................................ 55


1. INTRODUÇÃO AO TESTE DE INVASÃO
Conceitos básicos
Teste de invasão/pentetração ou pentest é a simulação de ataques reais em ativos para

avaliar os riscos associados a possíveis brechas de segurança. Em um pentest, diferente do
teste de vulnerabilidade, o analista não só descobre as vulnerabilidades que podem ser
usadas pelos invasores, mas também exploram as vulnerabilidades, onde possivelmente,
para avaliar o que os atacantes ganhariam após uma exploração com sucesso.
O escopo de um pentest vai variar de cliente para cliente. Alguns deles terão uma postura
excelente em segurança da informação, enquanto outros terão vulnerabilidades que
permitirão os atacantes invadir o perímetro e ganhar acesso aos sistemas internos.
Os testes podem ser feitos em:
 Redes
 Infraestrutura
 Aplicações / Sistemas:
 Cliente / Servidor
 Web
 Mobile
Pré-Compromisso
Antes do pentest iniciar, o analista faz um pré-compromisso com o cliente para garantir que
todos estão alinhados sobre o teste que será realizado. Falha na comunicação entre o
analista e o cliente, que espera um simples escanner de vulnerabilidade, poderia levar a uma
situação desagradável com um teste mais intrusivo. É importante fazer alguns
questionamentos:
 Garantir que estão todos alinhados sobre os testes;

 Qual é o objetivo do pentest?
 Quais os motivos os levaram a contratar este serviço?
 O que é mais importante para o cliente?
 Qual é o escopo?
 Existem algum dispositivo sensível que deve-se ter mais cuidado?
 Você tem permissão para identificar vulnerabilidades ou poderá executar exploits
que talvez causem indisponibilidade?
 Qual é a janela de testes?
 Quem será o ponto de contato em caso de problemas?
 Foi assinado um contrato ou algo formalizando o teste?

Reconhecimento
Esta é a próxima fase, onde você vai analisar de forma livre as fontes de informações sobre o
seu alvo, utilizando um processo chamado Open Source Intelligence (OSINT). Você também
pode começar a utilizar ferramentas como port scanners para ter uma ideia de quais
sistemas estão voltados para internet ou redes internas, assim como saber quais softwares
os dispositivos estão rodando neles. Obter informações sobre os alvos que você quer atacar:
 Quais os sistemas que o nosso alvo utiliza?

 Eles estão devidamente atualizados com as versões?
 Existe algum firewall ou proxy na rede?
 Como é estruturação da rede de servidores e dos usuários?
 Quais sites costumam visitar?
 Quais os parceiros de negócios deles?
 Existe algum diretor da organização viajando?
 Tem servidores de e-mail, web, ftp, etc. na empresa?
Nesta etapa, pode-se usar métodos passivos para ter o mínimo de interação e evitar a
detecção. Posteriormente, pode-se usar os métodos ativos para interagir diretamente com
os alvos.
Escaneamento
Nesta etapa, começamos a descobrir ativamente as vulnerabilidades para determinar quão

sucedido será explorar as vulnerabilidades poderão ser. Falhas ao explorar certas
vulnerabilidades pode causar um crash no sistema, desligar alertas de Intrusion Detection
System (IDS), e por outro lado arruinar as suas chances de fazer uma exploração com
sucesso.
Sempre durante esta fase, os pentesters rodam escaneres de vulnerabilidades, os quais

possuem um banco de dados de vulnerabilidades conhecidas para fazer diversas checagens
e identificar possíveis vulnerabilidades presentes no sistema do cliente. Apesar dos
escaneres de vulnerabilidades serem ferramentas poderosas, elas não dispensam o
pensamento crítico, então também devemos realizar análises manuais e verificar os
resultados por nós mesmos nesta fase. A intenção é descobrir ativamente mais informações
e vulnerabilidades para saber qual é o melhor caminho para os ataques serem realizados;
Algumas informações extras:
 Hosts ativos;
 Portas e serviços;
 SO;
 Tipo de dispositivo;
 Port scanners;
 Mapeamento da rede;
 Enumeração de credenciais;

 Análise de vulnerabilidades;
Exploração
Aqui podemos rodar alguns exploits em sistemas vulneráveis que descobrimos (as vezes
utilizando ferramentas como o Metasploit) na tentativa de acessar o sistema do cliente.
Como veremos adiante, algumas vulnerabilidades serão fáceis de explorar, como logar
utilizando senhas padrões do sistema.
Pós-Exploração
Durante a fase de pós-exploração, coletamos informações sobre o sistema atacado, olhamos

por arquivos importantes, tentamos elevar os privilégios onde forem necessários, e assim
por diante. Por exemplo, nós podemos baixar a base de hashes das senhas e ver se
conseguimos reverte-los ou usar para acessos adicionais aos sistemas. Podemos utilizar
ainda uma máquina explorada para atacar sistemas não disponíveis antes para nós,
simplesmente pivotando dentro deles.
O atacante vai tentar manter o acesso ao sistema para que ele possa voltar futuramente de
forma mais fácil ao ambiente comprometido. Ele tenta “proteger” o sistema para evitar que
seja atacado por outros invasores para manter a exclusividade. Podendo usar:
 Backdoors;
 Rootkits;
 Trojans;
 Pode usar a máquina invadida para fazer ataque lateral;
 Eventualmente, ele poderá excluir ou alterar seus rastros (ex.: logs) para que não seja
detectado e pego;
Relatório
A fase final do teste de invasão é o relatório, pois iremos juntar tudo o que foi encontrado
durante os testes e que merecem atenção do cliente. Contaremos a ele o que estão fazendo
corretamente, onde eles necessitam melhorar sua postura de segurança, como você entrou,
o que você achou e as recomendações para corrigir os problemas.
Escrever um bom relatório de penteste é uma arte que necessita de prática. Você pode
precisar resumir seus achados de forma clara para todos, desde o pessoal da TI responsáveis
por ajustar as vulnerabilidades, até a alta gestão que contratam os auditores externos. Por
exemplo, se um não-técnico ler algo como “E então usei um MS08-067 para pegar uma
shell” ele poderá não entender. Uma forma melhor de dizer isto seria dizer que dados
sensíveis e privados poderiam ser acessados ou modificados. Uma frase como “Fui capaz de
ler seu e-mail” vai causar efeito em qualquer um. O relatório do penteste deve incluir tanto
um sumário executivo e um relato técnico. Veja um modelo de estrutura simples:

 Resumo executivo – escrita não técnica;
 Pontos fortes e pontos de melhoria;
 Vulnerabilidades identificadas;
 Recomendações de correção;
 Conclusão;
Veja o link (https://github.com/juliocesarfort/public-pentesting-reports) para obter algumas

ideias e elaborar seu próprio relatório. Não existe uma fórmula mágica, mas gosto de pensar
que você deve escrever de uma forma que explique tudo o suficiente para mostrar o
potencial dos problemas apontados e de uma forma simples.

2. METODOLOGIAS
OWASP Testing Guide v4
Mais informações podem ser encontradas em

https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
O objetivo deste projeto é coletar todas as possíveis técnicas de teste, explicar essas técnicas
e manter o guia atualizado. O método OWASP Web Application Security Testing é baseado
na abordagem black-box. O testador não sabe nada ou tem muito pouca informação sobre o
aplicativo a ser testado.
O modelo de teste consiste em:
 Testador: quem realiza as atividades de teste

 Ferramentas e metodologia: o núcleo deste projeto do Guia de teste
 Aplicação: A caixa preta para testa.
O teste é dividido em duas fases:
Fase 1 - Modo passivo

No modo passivo, o testador tenta entender a lógica do aplicativo e joga com o aplicativo.
Ferramentas podem ser usadas para coleta de informações. Por exemplo, um proxy HTTP
pode ser usado para observar todas as solicitações e respostas HTTP. No final desta fase, o
testador deve entender todos os pontos de acesso (portais) do aplicativo (por exemplo,
cabeçalhos HTTP, parâmetros e cookies). A seção de Coleta de Informações explica como
executar um teste de modo passivo.
Fase 2 – Modo ativo
Nesta fase, o testador começa a testar usando a metodologia descrita. O conjunto de testes
ativos foi dividido em 11 subcategorias para um total de 91 controles:
1) Information Gathering
2) Configuration and Deployment Management Testing
3) Identity Management Testing
4) Authentication Testing
5) Authorization Testing
6) Session Management Testing
7) Input Validation Testing
8) Error Handling
9) Cryptography
10) Business Logic Testing
11) Client Side Testing

NIST 800-115
O “Technical Guide to Information Security Testing and Assessment” tem o objetivo de

prover diretrizes para as organizações conduzirem testes e avaliações de segurança,
analisando os achados e desenvolvendo estratégias de mitigação. Ele fornece uma visão
geral sobre avaliações de segurança da informação, incluindo políticas, papéis e
responsabilidades, metodologias e técnicas. Também fornece uma descrição detalhada de
várias técnicas de exame técnico, incluindo revisão de documentação, revisão de log, sniffing
de rede e verificação de integridade de arquivo.
Existem algumas seções que descreve várias técnicas para identificar alvos e analisá-los
quanto a possíveis vulnerabilidades (ex.: network discovery e análise de vulnerabilidades),
explica as técnicas comumente usadas para validar a existência de vulnerabilidades, como o
teste de invasão e password cracking, apresenta uma abordagem e processo para planejar
uma avaliação de segurança.
Figura 1 Fases do Teste de Invasão no NIST 800-115
Discute os fatores que são fundamentais para a execução das avaliações de segurança,
incluindo a coordenação, a própria avaliação, a análise e o tratamento de dados, apresenta
uma abordagem para relatar os resultados da avaliação e fornece uma visão geral das
atividades de correção.

Figura 2 Etapas da fase de ataque com Loopback para a fase de descoberta
Esta metodologia pode ser vista em:

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
PCI-DSS
A metodologia do PCI DSS para pentest chama-se “Penetration Testing Guidance”. É um

documento com informações suplementares sobre como atender ao requisito 11.3 do PCI
DSS:
 Componentes do teste de invasão;

 Qualificação do pentester;
 Metodologia do pentest;
 Como elaborar o relatório;
Escopo do PCI DSS é testar os sistemas críticos, ou seja, os que estão envolvidos na
transmissão, processamento ou armazenamento de dados de cartão de crédito. Tudo o que
for parte do escopo, o analista deve realizar os devidos testes para garantir a segurança
deste ambiente.
O PCI DSS existe que o pentester deve possuir uma certificação conhecida (CEH, OSCP, GPEN,
GWAPT, GXPN, etc.) e ter experiências anteriores com este tipo de serviço.
A metodologia é composta pelas seguintes fases:
 Pré-Compromisso: Escopo, documentação, regras (janela, comunicação, etc.),

ambientes de terceiros / Cloud, critérios de sucesso, revisão das ameaças e
vulnerabilidades anteriores, evitar a interferência de appliances de segurança
durante os scans;

 Teste de Invasão: Camada de aplicação, camada de rede, validar a segmentação da
rede, o que fazer quando encontrar dados de cartões, pós-exploração;
 Pós-Compromisso: Melhores práticas, retestar as vulnerabilidades identificadas,
limpar o ambiente;
 Relatório: Vulnerabilidades identificadas, estrutura do documento, considerações
para reteste e relatório, retenção das evidências.
Esta metodologia pode ser vista em:

https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2
015.pdf
PTES
A metodologia “Penetration Testing Execution Standard” consistema de 7 seções principais:

 Interações Pré-Compromisso: Questionamentos sobre escopo, janela de testes,
objetivos, comunicação com o cliente, regras, etc;
 Coleta de informações: OSINT, footprinting, identificar mecanismos de proteção;
 Modelagem de ameaças: Análise dos ativos de negócio (políticas, normas, outros
dados…). Análise dos processos de negócio, análise de ameaças;
 Análise de Vulnerabilidades: Ativa (automatizado, redes, aplicações…), passiva
(metadata e monitoramento de tráfego), validação e pesquisas (documentos de
hardening e configurações, bases de exploits…);
 Exploração: Contra-medidas, evasão, simulação de ataque, perspectiva de zero-day,
customização de exploits;
 Pós-Exploração: Rever as regras de compromisso, análise da infraestrutura, coleta de
informações sensíveis, identificar alvos de alto valor, mapear possíveis caminhos de
vazamento de informações, persistência, ataque lateral, limpeza do ambiente;
 Relatório: Estrutura do relatório.
Existem também cinco anexos para referência futura.
Cada seção oferece uma discussão aprofundada dos fatores que um pentester profissional
deve considerar durante essa fase específica de um compromisso. Ele abrange tudo, desde
monitoramento de frequência de RF até vigilância física de sites, até mineração e pesquisa
de alvos para phishing ou outros ataques de engenharia social.
Mais importante, explica como interpretar alguns dos resultados que podem ser
descobertos e como trabalhar para explorar as vulnerabilidades encontradas.
O documento contém links para recursos e ferramentas que podem ser usados em cada fase
também. Por exemplo, links úteis para sites de pesquisa de registro de empresas estaduais
são incluídos para realizar pesquisas em segundo plano no destino.
Existem também lacunas consideráveis nas informações disponíveis. Grande parte da seção
de exploração aguarda expansão, embora técnicas gerais sejam delineadas. Alguns ataques
específicos são definidos, mas os detalhes são frequentemente datados e de utilidade
limitada.
Esta metodologia pode ser vista em: http://www.pentest-
standard.org/index.php/Main_Page

3. NMAP
Identificando hosts
Nmap é uma ferramenta muito conhecida pelo o que faz: port scanning. Seu manual pode
ser um pouco assustador devido aos diversos comandos e a capacidade que esta ferramenta
tem de trazer informações sobre um host.
Firewalls com sistemas de detecção e prevenção de intrusão podem identificar os pacotes
enviados por ele, sendo assim você não conseguirá obter muitos resultados. Você pode ser
contratado para fazer um pentest em um range de hosts e não conseguir identificar
nenhuma máquina online, e isto provavelmente será porque você está sendo bloqueado por
um firewall. Por outro laod, o resultado de seu escaneamento acusará que as máquinas
estão respondendo e achará diversas portas abertas.
SYN Scan
Começaremos com um SYN scan contra um host. Um SYN scan é um escaneamento TCP que
não finaliza o handshake. Uma conexão TCP inicia com um handshake de 3 vias: SYN; SYN-
ACK; ACK. Veja abaixo:
Figura 3 Estabelecimento de conexão TCP - 3 way handshake
É um SYN scan, o Nmap envia o SYN e espera pelo SYN-ACK se a porta estiver aberta, mas
nunca enviará o ACK para completar a conexão. Se o pacote SYN não receber uma resposta
SYN-ACK, a porta não está disponível, ou por estar fechada ou a conexão está sendo filtrada.
Desta forma, o Nmap verifica se a porta está aberta sem completar a conexão com a
máquina alvo. A sintaxe para o SYN scan é com a flag -sS
Vejamos um exemplo do uso do SYN scan e ao mesmo tempo vamos incluir a flag -o a qual é
a opção de output do resultado do Nmap em um arquivo. A opção -o diz ao Nmap para logar
todo o resultado em alguns formatos, como: .nmap; .gnmap (greppable Nmap) e .xml. O
formato .nmap é fácil de visualizar em tela, igual ao resultado obtido durante o scan. A saída
do tipo .gnmap (greppable Nmap) é formatado para ser usado com o comando grep para
buscar informações específicas. XML é um formato padrão usado para importar o resultado
em outras ferramentas.

Vejamos um exemplo de SYN scan:
nmap -sS scanme.nmap.org
Starting Nmap 7.12 ( https://nmap.org ) at 2016-XX-XX XX:XX Hora oficial do Brasil
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.14s latency).
Not shown: 995 filtered ports
PORT STATE SERVICE
21/tcp open ftp
1024/tcp closed kdm
1863/tcp closed msnp
2048/tcp closed dls-monitor
6901/tcp closed jetstream
Nmap done: 1 IP address (1 host up) scanned in 25.47 seconds

Como pode ser visto, o Nmap retorna as portas que foram encontradas abertas e fechadas.
Veremos nas próximas postagens como prosseguir com as informações que se obtêm no
escaneamento de portas. É muito provável que algumas portas que você encontre aberta
tenha vulnerabilidades. A porta aberta não significa que ela tenha vulnerabilidade, mas isto
nos deixa uma possibilidade que um software vulnerável possa estar rodando nas portas
identificadas. Pode ser que você encontre portas abertas que são de serviços de internet,
como um servidor Web (porta 80), e outra porta local (139) que é de RPC. Elas podem ter
softwares exploráveis ouvindo nestas portas que não tem permissão através do firewall, e
pode existir software vulnerável rodando localmente no host, mas não será possível explorá-
los diretamente através da rede, com exceção do que está exposto para web. Um
escaneamento básico no Nmap nos ajuda a focar nossos esforços durante o pentest.
Escaneando versões dos softwares
O SYN scan realizado acima foi furtivo (stealthy), mas não disse muita coisa sobre os
softwares que estão rodando nas portas que estão escutando. Comparado com a versão
detalhada de informações que se obtêm usando Netcat em uma conexão em alguma porta,
o resultado do SYN scan é pouco informativo. Nós podemos utilizar um scan TCP completo
(nmap -sT) ou podemos ir um pouco além e usar o scan de versão do Nmap (nmap -sV) para
coletar mais dados. Com as versões exibidas na imagem abaixo, o Nmap completa a conexão
e então tenta determinar que software está rodando e, se possível, a versão, usando
técnicas como obtenção de banners.
nmap -sV 192.168.1.3
Starting Nmap 7.12 ( https://nmap.org ) at XXXX-XX-XX XX:XX Hora oficial do Brasil
Nmap scan report for 192.168.1.3
Not shown: 989 closed ports

PORT STATE SERVICE VERSION
21/tcp open ftp OpenBSD ftpd 6.4 (Linux port 0.17)
22/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.7 ((Ubuntu))
139/tcp filtered netbios-ssn
443/tcp open http Apache httpd 2.4.7
3306/tcp open mysql MySQL 5.5.37-0ubuntu0.14.04.1
5800/tcp open vnc-http x11vnc
5900/tcp open vnc VNC (protocol 3.7)
Service Info: Hosts: TSP-WWW-DOD, 192.168.1.3; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at

https://nmap.org/submit/ .
Veja que o resultado é diferente e traz mais informações sobre o nosso alvo. Além de saber
quais serviços estão rodando nele, podemos descobrir a versão aproximada (as vezes exata).
Isto servirá para a próxima etapa do pentest, onde procuramos as versões dos softwares por
possíveis vulnerabilidades.
É importante ter em mente que o Nmap pode trazer a versão errada em alguns casos, pois
um software pode ser atualizado e o seu banner não ser alterado no patch de correção, mas
pelo menos a versão informada nos dá uma pista para pesquisarmos mais a fundo.
Escaneamento UDP
Tanto o SYN scan e o Version scan são escaneamentos TCP que não enviam requisições para
as portas UDP. Devido ao UDP ser sem conexão, o escaneamento lógico é um pouco
diferente.
Em um UDP scan (nmap -sU), o Nmap envia pacotes UDP para uma porta. Dependendo da
porta, o pacote enviado é um protocolo específico. Se ele receber uma resposta, a porta é
considerada aberta. Se a porta estiver fechada, o Nmap receberá uma mensagem do tipo
“ICMP Port Unreachable”. Se o Nmap não receber nenhuma resposta, então a porta está
aberta e o programa que está ouvindo não responde a consulta do Nmap ou o tráfego está
sendo filtrado.
Assim, o Nmap não consegue sempre distinguir enre uma porta UDP aberta e uma que
esteja filtrada pelo firewall. Veja a imagem abaixo:
nmap -sU -F 192.168.1.3
Warning: 192.168.1.3 giving up on port because retransmission cap hit (6).

Not shown: 55 closed ports, 44 open|filtered ports
PORT STATE SERVICE
5353/udp open zeroconf

Escaneando uma porta específica
Por padrão, Nmap escaneia somente as 1.000 primeiras portas consideradas mais
importantes, não as 65.535 portas TCP e UDP possíveis. O padrão de escaneamento do
Nmap irá pegar os serviços mais comuns rodando, mas em alguns casos ele não pegaá
alguma porta. Para escanear uma porta específica, use o parâmetro -p. Por exemplo, para
escanear as portas 80 no alvo:
nmap -p 80 -T4 192.168.1.3
Warning: 192.168.1.3
PORT STATE SERVICE
80/tcp open http

É importante ter em mente que ao escanear alguns serviços, eles podem não estar
preparados para receber os inputs enviados pelo Nmap, o que pode causar um travamento
no serviço ou simplesmente dar um crash. Embora não é algo que desejamos que isto
aconteça durante um pentest, sempre existe a possibilidade de acontecer quando se fala de
computadores. Serviços de sistemas SCADA são particularmente notórios para este tipo de
comportamento. Você sempre tem que explicar que existe essa possibilidade para seu
cliente. Quando trabalhamos com computadores, não temos garantias.
Voltaremos a utilizar o Nmap nas próximas postagens quando usarmos os Nmap Scripting
Engine (NSE) para aprender informações mais detalhadas sobre vulnerabilidade do nosso
sistema alvo antes de começar a explorá-lo.
Para facilitar a consulta de possíveis comandos do Nmap, montei o mapa mental:
https://www.diegomacedo.com.br/mapa-mental-de-redes-e-seguranca-da-informacao-
scanner-nmap/

4. METASPLOIT
Visão geral
Lançado pela primeira vez em 2003, Metasploit alcançou status na comunidade de

segurança. Embora Metasploit agora seja de propriedade da empresa de segurança Rapid7,
uma edição de código aberto está ainda disponível, com o desenvolvimento em grande
parte impulsionado pela comunidade de segurança.
A arquitetura modular e flexível do Metasploit ajuda os desenvolvedores de forma eficiente

a criar exploits que trabalham de acordo com as novas vulnerabilidades quando são
descobertas. Como você verá, Metasploit é intuitiva e fácil de usar, e oferece uma forma
centralizada para executar código confiável de exploração que foi analisado com precisão
pela comunidade de segurança.
Exploit – É o meio por onde um atacante tira vantagem da falha do sistema, aplicação, ou
serviço para atacá-los e obter um resultado que não era esperado pelo desenvolvedor (ex.:
buffer overflow, SQL injection, erros de configuração, etc.);
Payload – É o código que queremos que o sistema execute (ex.: reverse shell que vai criar
uma conexão da máquina alvo para o atacante como um prompt do Windows);
Shellcode – É um conjunto de instruções, normalmente em assembly, usados como o

payload quando a exploração ocorre. Normalmente é enviado um command ou Meterpreter
shell;
Module – É um pedaço de software que pode ser usado pelo MSF para executar uma
atividade específica (ex.: exploit module para executar ataques, auxiliary module para
escaneamento ou enumeração);
Listener – É um componente do MSF que espera uma conexão de entrada (ex.: após uma
máquina ser atacada, ela pode chamar a máquina atacante através da internet. Este listener
vai ajustar a conexão).
Por que usar o Metasploit?
Digamos que você descobriu uma vulnerabilidade no ambiente de seu cliente usando o
sistema Windows XP no 192.168.20.10 e está faltando Microsoft boletim de segurança
MS08-067. Como um pentester, é sua função explorar esta vulnerabilidade, se possível, e
avaliar o risco de compromete-lo.
Uma abordagem pode ser a de criar, em seu laboratório um sistema Windows XP, que
também está faltando este patch, tentar disparar a vulnerabilidade, e desenvolver um
trabalho exploração. Mas o desenvolvimento de exploits na mão leva tempo e habilidade, e
a janela de oportunidade para o seu pentest pode estar fechando.
Você poderia, em vez disto, procurar o código que explora a vulnerabilidade na Internet.
Sites como o Packet Storm Security, SecurityFocus e Exploit-DB fornecem repositórios de

exploits conhecidos. Mas esteja avisado: Nem todos os códigos de exploits públicos fazem o
que ele deveriam fazer. Alguns exploits podem destruir o sistema alvo ou até mesmo atacar
seu próprio sistema, em vez do alvo. Você deve estar sempre vigilante ao executar qualquer
coisa que você encontrar on-line e ler o código com cuidado antes de confiar nele. Além
disso, os exploits públicos que você encontrar pode não atender às suas necessidades logo
de cara. Você pode precisar fazer algum trabalho adicional para portá-las para o seu
ambiente de pentest.
Seja desenvolver um exploit do zero ou usar um público como base, ainda vai precisar de ter
o exploit para trabalhar em seu pentest. Nosso tempo provavelmente será melhor gasto em
tarefas que são difíceis de automatizar e, felizmente, podemos usar Metasploit para fazer
exploração de vulnerabilidades conhecidas, tais como a MS08-067 de forma rápida e sem
atrasos.
Iniciando o Metasploit
No Kali Linux, o Metasploit pode iniciar em qualquer lugar no sistema. Mas antes de
começar Metasploit, você vai querer começar o banco de dados PostgreSQL, que Metasploit
vai usar para acompanhar o que você faz.
root@kali:~# service postgresql start
Agora você está pronto para iniciar o serviço Metasploit. Este comando cria um usuário do
PostgreSQL chamado msf3 e um banco de dados correspondente para armazenar nossos
dados. Ele também começa a chamada de procedimento remoto do Metasploit (RPC) do
servidor e servidor web.
Criar e iniciar o BF do MSF: msfdb init
Verificando se está ok dentro do msfconsole: db_status
Existem várias interfaces para usar Metasploit. Vamos usar msfconsole, o console baseado
em texto Metasploit e Msfcli, a interface de linha de comando. De qualquer interface pode
ser usada para executar módulos Metasploit. Inicie o console inserindo msfconsole.
root@kali:~# msfconsole
Não se assuste se msfconsole parecer travar por um ou dois minutos; O Metasploit está
carregando os módulos na hora. Assim que terminar, será exibida uma arte ASCII, uma lista
de versão e outros detalhes, e um prompt msf>.

Figura 4 Msfconsole
Veja que ao iniciar o Metasploit, ele informa a quantidade de exploits, módulos auxiliares e
outras coisas. Ao longo do tempo isto vai crescendo de acordo com que novas
vulnerabilidades são descobertas e a comunidade desenvolve.
Caso você tenha dúvidas sobre o que fazer dentro da ferramenta, você pode consultar o
help. Caso queira mais detalhes sobre um comando específico, use o help <comando>.
msf > help route
Usage: route [add/remove/get/flush/print] subnet netmask [comm/sid]
Route traffic destined to a given subnet through a supplied session.
The default comm is Local...
Procurando por módulos
Após realizar uma análise de vulnerabilidade e identificar mais detalhes sobre as falhas do
sistema, podemos partir para a busca no Metasploit para encontrar um módulo que explore
esta vulnerabilidade em particular. Temos algumas opções. Normalmente, uma simples
busca no Google vai encontrar o que você precisa, mas Metasploit também tem um banco
de dados on-line de módulos e uma função embutida de pesquisa que você pode usar para
pesquisar pelo módulo correto.

O banco de dados on-line de módulos
Você pode usar a página de pesquisa Metasploit para combinar módulos Metasploit com as
vulnerabilidades pelo número Common Vulnerabilities and Exposures (CVE), Open Sourced
Vulnerability Database (OSVDB) ID, Bugtraq ID ou Microsoft Security Bulletin, ou você pode
pesquisar o texto completo sobre as informações do módulo para uma string.
Figura 5 Rapid7 – Metasploit Module Database
Busca embutida
Você também pode usar a busca embutida no Metasploit para achar o módulo pelo nome
usando o comando search <string>:
Figura 6 Metasploit – Busca por módulo
Após encontrar um módulo que desejamos, podemos obter mais detalhes sobre ele usando
o comando info <nome do módulo>, veja:

Figura 7 Metasploit – Comando info
Após achar o módulo que deseja usar, você usa o comando use <nome do módulo>
Figura 8 Metasploit – Comando use
Configurando as opções do módulo
Após escolher qual módulo iremos usar, temos que definir alguns parâmetros no Metasploit.
Para saber quais parâmetros são obrigatórios e opcionais para definirmos, antes de executá-
lo, devemos usar o comando show options.
Figura 9 Metasploit – Comando show options

Alguns parâmetros já vêm com valores padrões. Perceba também que existe uma coluna
“Required” que informa quais campos são obrigatórios e precisam de um valor. No caso do
nosso exploit escolhido, precisamos definir os campos SRVHOST e SRVPORT, já o SSL, SSLCert
e URIPATH são opcionais. Veremos cada um deles abaixo e outros possíveis campos que
podem aparecer, dependendo de cada módulo que você escolher.
SRVHOST
É a máquina que estará esperando pelos dados (ouvindo). Deve inserir um endereço de uma
máquina local ou 0.0.0.0. Neste caso, seria a sua máquina atacante.
SRVPORT
A porta local que está aberta ouvindo as informações.
SSL
Informe se será necessário negociar uma conexão SSL
SSLCert
O caminho para o certificado personalizado que foi gerado. Por padrão ele gera um
aleatoriamente.
URIPATH
A URI usada para este exploit. Por padrão ele gera um aleatoriamente.
RHOST
Outros exploits podem utilizar este parâmetro, o que significa qual é o host alvo que
desejamos fazer o exploit. Este parâmetro é obrigatório (se o exploit escolhido tiver), pois é
nele quem você deve apontar para que o Metasploit possa atacar.
RPORT
Refer-se a porta da máquina alvo. Dependendo do exploit escolhido, ele deverá vir com uma
porta padrão. Se for um exploit que utiliza a Web, vai pela porta 80. Caso seja um exploit
para o serviços SMB do Windows, será pela porta 445, e assim por diante.
Exploit Target
Na imagem exibida, temos que o parâmetro está definido como 0 Automatic Targeting.
Neste caso, ele serve para definir qual é o tipo e versão do sistema operacional. Você pode
usar o comando show targets para listar quais as opções disponíveis no exploit. Após listar e
você identificar qual é o S.O. e a versão, podemos usar o comando set target <número>.
Caso você não saiba com certeza qual é a versão do sistema operacional, você pode deixar
que o Metasploit faça o trabalho de reconhecimento e escolha a melhor opção de forma
automática baseada no resultado.

Payloads (ou Shellcode)
Baseado no que lemos após o comando show options, definimos todos os parâmetros para
usar o exploit, mas ainda precisamos informar ao Metasploit o que ele deve fazer de fato, e
para isto devemos usar os payloads. Estão disponíveis diversos payloads na ferramenta, que
vão desde simples comandos do Windows até o Metasploit Meterpreter. Escolha um
payload compatível e o Metasploit criará uma string do exploit, incluindo o código para
disparar a vulnerabilidade e o payload para rodar depois que o exploit for bem sucedido.
Procurando por payloads compatíveis
Use o comando show payloads para que ele possa exibir uma lista dos que são compatíveis.
Caso você esqueça de definir um payload, o Metasploit irá utilizar o que estiver marcado
como padrão, o que não garante que vai funcionar com o seu sistema alvo. É importante que
você defina manualmente qual payload vai usar.
Figura 10 Metasploit – show payloads
Para definir qual payload você usará, envie o comando set payload <nome do payload com
endereço>. Por exemplo:
msf exploit(ms16_051_vbscript) > set payload windows/x64/shell/reverse_tcp
payload => windows/x64/shell/reverse_tcp
Executando o exploit
Para enviarmos o nosso exploit com o payload, precisamos usar o comando exploit. Após
isso você verá um resultado semelhante a este, caso seja bem sucedido.
msf exploit(ms08_067_netapi) > exploit
[*] Started reverse handler on 192.168.20.9:4444
[*] Automatically detecting the target...

[*] Fingerprint: Windows XP - Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (752128 bytes) to 192.168.20.10
[*] Meterpreter session 1 opened (192.168.20.9:4444 -> 192.168.20.10:1334) at
2015-08-31 07:37:05 -0400
meterpreter >
Neste exemplo, foi possível obter uma sessão com o meterpreter (meta-interpreter), que é
uma parte importante do Metasploit. Com ele, você pode fazer tudo na sua máquina alvo
através de comando.
Para sair do meterpreter, use o comando exit.
Tipos de shells
Na lista de payloads compatíveis mostrado no show payloads, você vê uma gama de opções,
incluindo shells de comando, Meterpreter, uma speech API ou a execução de um único
comando do Windows. Meterpreter ou outras formas de shells, acabam sendo de duas
categorias: bind e reverso (reverse).
Bind shells
Uma instrução de bind shell diz para a máquina alvo para abrir uma linha de comando e
escutar na porta local. A máquina atacante então se conecta na máquina alvo na porta que
está aberta. Entretanto, com o advento dos firewalls, a efetividade dos bind shells tem caído
porque firewall de correlação bloqueará o tráfego para portas aleatórias como a 4444.
Reverse shells
Um shell reverso, por outro lado, ativamente envia uma conexão de volta para a máquina
atacante, a qual está esperando por uma conexão de entrada. Neste caso, nossa máquina
atacante está com uma porta aberta e escutando por uma conexão vinda da nossa máquina
alvo, porque é uma conexão reversa, e é mais provável de ser feita através de um firewall.

5. NESSUS
Visão geral
O Nessus é da Tenable Security’s é um dos escaneres de vulnerabilidades mais usados

comercialmente, apesar de vários fornecedores proverem produtos comparáveis. O banco
de dados do Nessus inclui vulnerabilidades de diversas plataformas e protocolos, e seu
scanner realiza uma série de verificações para detectar problemas conhecidos. Você pode
encontrar diversos livros, postagens e treinamentos do Nessus, e quanto mais você fica
familiarizado com a ferramenta, você começará a perceber o que realmente funciona
melhor para você. Veremos a seguir uma ideia superficial sobre esta ferramenta. Nessus está
disponível com uma versão profissional paga que os pentesters e times de segurança
internos podem usar para escanear redes por vulnerabilidades. Você pode usar a versão
gratuita, não comercial chamada Nessus Home para conhecer um pouco sobre a ferramenta.
Esta versão é limitada a escanear até 16 endereços IP.
Apesar do Kali ter diversas ferramentas, precisamos instalar o Nessus. Veja os passos para
instalar:
 Abra o navegador e acesse a URL (http://www.tenable.com/products/nessus-

home/). Complete o registro em “Register for an Activation Code” e depois clique em
“Register” para receber o código de ativação por e-mail.
 Após isto, aparecerá um botão para a página de Download. Escolha a última versão
de acordo com o seu sistema operacional e salve-o.
 Abra o terminal do Linux.
 Vá até a pasta de “Downloads” e entre com o comando ls para ver a lista de arquivos
da pasta. Você poderá ver o arquivo do Nessus que acabou de fazer o download.
 Entre com o comando dpkg -i seguido do nome do arquivo baixado (você pode
digitar as primeiras letras do nome do arquivo e apertar em TAB para autocompletar)
e pressione ENTER para começar o processo de instalação. Isto pode demorar um
pouco.
 Quando retornar para o prompt do root sem erros, o Nessus poderá ser instalado e
você poderá ver uma mensagem como na figura de instalação.

Figura 11 Instalando no Kali
 Agora entre com o comando /etc/init.d/nessusd start

 Abra o endereço https://localhost:8834/ no navegador. Você verá um aviso do
certificado SSL semelhante a imagem a seguir.

 Basta clicar em “Advanced” e depois em “Add Exception…“. Na janela que vai abrir,
clique em “Confirm Security Exception“. Com isto, você conseguirá acessar o Nessus.
 Dentro do Nessus, você irá configurar sua conta de acesso (usuário e senha).
 Na tela seguinte, coloque o “Activation Code” que você recebeu por e-mail.
 Quando continuar, o Nessus vai começar a fazer o download dos plugins e pode
demorar um pouco.

 Após isto ele vai iniciar normalmente e aparecerá a tela de login. Utilize o usuário e
senha que acabou de criar.
 Se você quiser fechar o Nessus, basta fechar a aba do navegador que ele está aberto.
Iniciando o serviço
Antes de rodar o Nessus, você precisa iniciar o daemon do Nessus. Para isto, execute o
comando do serviço para inicia-lo na porta TCP 8834 em seu Kali.
root@kali:~# service nessusd start
Agora abra o navegador e acesse o endereço https://kali:8834. Depois de uns minutos de

inicialização, você deve ver uma tela de login. Utilize as credenciais utilizadas na instalação.

Figura 12 Tela de Login do Nessus
Políticas do Nessus
A interface web do Nessus tem diversas abas no topo da tela, como mostrado na figura
abaixo. Vamos iniciar com a aba de Políticas (Policies). Políticas do Nessus são como arquivos
de configurações que dizem ao Nessus como as vulnerabilidades serão verificadas, portas
escaneadas, e então rodar o scanner de vulnerabilidades.
Para crair uma política, clique em New Policy do lado esquerdo da tela. O wizard de políticas
do Nessus ajudará a criar uma política que será útil para escanear seus objetivos, como
mostrado abaixo. Neste exemplo, vamos escolher a opção Web Application Test.

Figura 13 Tela – New Policy
Agora você precisa incluir algumas informações básicas sobre a política, como mostrada na
figura abaixo, incluindo o nome, a descrição e quais outros usuários do Nessus poderão
acessar a política. Outros detalhes que podem ser definidos são Discovery (descoberta e
scan de portas), Assessment (verificar vulnerabilidades web), Report (tratamento das
informações para relatório) e Advanced (conexões executadas).
Se você tiver credenciais, Nessus pode se autenticar nos hosts e procurar por
vulnerabilidades que podem não ser aparentes de uma perspectiva vista pela rede. Esta
funcionalidade é sempre usada por times de segurança internos para testar a postura de
segurança de suas redes. Você pode definir estas credenciais na aba Credentials. Por
enquanto, você pode deixar isto em branco e clicar em Save.
Como mostrado abaixo, nossa nova política é exibida na tela Policies.

Figura 14 Lista com Website Policy
Escaneando com o Nessus
Agora, vamos trocar para a aba Scans e rodar o Nessus contra nossas máquinas alvos. Clique
em Scans > New Scan, e depois clique em User. Veja que sua política vai estar listada.
Selecione ela.
Figura 15 Scan - Política Websites
Preencha com as informação do scan. Nessus precisa de um nome (Name) para nosso scan e
qual sistema (Targets) iremos escanear.

Figura 16 New Scan Website
Nessus roda uma série de exames contra o alvo em uma tentativa de detectar ou
desconsiderar quanto mais problemas forem possíveis. O scan executado é adicionado a aba
Scans.
Figura 17 Scan - Lista
Uma vez finalizado o scan, clique no item para ver o resultado.
Nessus poderá encontrar algumas vulnerabilidades críticas, altas, médias e baixas na

máquina alvo. Também é possível que ele só encontre dados informacionais. Para ver
detalhes sobre um host específico, clique nele. Os detalhes das vulnerabilidades poderão ser
visto.

6. BURP SUITE
Introdução
Em testes de segurança em aplicações web, podemos usar um proxy para capturar pedidos
e respostas entre o nosso navegador e a aplicação web para que possamos ver exatamente
quais dados estão sendo transmitidos. Kali Linux vem com a versão gratuita do Burp Suite,
uma plataforma de testes para aplicações web que inclui um recurso de proxy. Burp inclui
outros componentes úteis, tais como Burp Spider, que pode rastrear através da aplicação o
conteúdo web e suas funcionalidades, e o Burp Repeater, que permite que você manipule e
reenvie pedidos para o servidor. Por enquanto, vamos nos concentrar na Burp Proxy.
Para iniciar o Burp Suite no Kali Linux, vá para Aplicativos no canto superior esquerdo e
clique em Aplicativos > Web Application Analysis > burpsuite.
Figura 18 Burp Suite – Caminho no Kali

Figura 19 Burp Suite – Tela principal
Na tela do Burp, vá até a aba Proxy. Por padrão, o Intercept deve ser selecionado para que o
Burp Suite intercepte e segure qualquer requisição de saída vinda do seu navegador web
configurado para usar o Burp como um proxy para o tráfego web. Esta configuração permite
que vejamos e até mesmo modifiquemos os detalhes das requisições antes que elas sejam
enviadas para o servidor.

Figura 20 Burp Suite – Tela de Proxy
Agora precisamos dizer ao nosso navegador do Kali para utilizar o Burp Suite como proxy
web.
1. Abra o navegador e vá até Opções (Preferences) > Avançado (Advanced) e selecione

a aba Rede (Network);
2. Clique em Configurar conexão (Settings);
3. Na nova janela, selecione a opção Configuração manual de proxy (Manual proxy
configuration) e coloque o endereço IP 127.0.0.1 e a porta 8080. Marque também a
opção de usar este proxy para todos os protocolos.
Isto fará com que o navegador jogue o tráfego dele para o localhost na porta 8080, a porta
padrão do Burp Proxy.

Figura 21 Firefox – Configurando o proxy
Para confirmar que a configuração está redirecionando todo o tráfego através do Burp
Suite, navegue em qualquer site e o Burp Suite deverá exibir uma requisição HTTP GET da
página. Vou usar o endereço http://testphp.vulnweb.com/login.php

Figura 22 Burp Suite – Capturando a requisição
Veremos a seguir que podemos fazer mudanças na requisição antes de enviar para o
servidor, mas por enquanto, vamos seguir redirecionando as requisições (e quaisquer outras
subsequentes) clicando no botão Forward. Retornando ao navegador, podemos ver que o
servidor respondeu com a página solicitada.
Se tentarmos acessar algum site que tenha um formulário de login, o Burp Suite será capaz
de capturar as credenciais. Veja o exemplo abaixo no site:
Figura 23 Burp Suite – Captura de credenciais
Além de conseguir ler a requisição pura, a qual não é amigável de ler, você poderá clicar na
aba Params no topo da tela de requisição do Burp Suite para exibir os parâmetros
requisitados de uma forma mais fácil de ler.

Figura 24 Burp Suite – Tela Params
Veja que foi capturado o usuário e senha do formulário. Você pode modificar estes campos
diretamente no proxy. Por exemplo, se você mudar a senha capturada por outra antes de
redirecionar a requisição para o servidor, o servidor irá receber a nova senha definida no
proxy.
O proxy permite você ver os detalhes de qualque requisição para o servidor. Se você não
precisar mais do proxy em algum momento, clique em Intercept is on para mudar a chave
para Intercept is off e permitir o tráfego para passar para o servidor sem necessidade do
usuário interagir. Troque o botão de volta se você precisar capturar alguma requisição em
particular.
Além da função de Proxy, o Burp Suite tem outras funcionalidades:
 Spider – Faz o crawling na aplicação para descobrir o seu conteúdo e

funcionalidades;
 Scanner – É usado para fazer scan de requisições HTTP automaticamente para achar
vulnerabilidades de segurança;
 Intruder – Permite realizar ataques automatizados personalizados;
 Repeater – Usado para modificar manualmente e reenviar requisições HTTP
específicas quantas vezes achar necessário;
 Sequencer – Usado para analisar a qualidade da aleatoriedade dos tokens de sessão
de uma aplicação;
 Decoder – Permite transformar bits de dados de aplicativos usando codificação e
decodificação de esquemas comuns.
 Comparer – Permite realizar uma comparação visual dos bits dos dados da aplicação
para achar diferenças interessantes.

7. COMMON VULNERABILITY SCORING SYSTEM (CVSS)
Introdução
O Common Vulnerability Scoring System (CVSS) é uma forma identificar as principais

características de uma vulnerabilidade e calcular uma pontuação numérica que reflita sua
gravidade, bem como uma representação textual dessa pontuação. A partir da pontuação
numérica, podemos traduzir em uma representação qualitativa (como baixa, média, alta e
crítica) para ajudar as organizações a avaliar e priorizar adequadamente seus processos de
gerenciamento de vulnerabilidades.
Benefícios
Primeiro, fornece pontuações de vulnerabilidade padronizadas. Quando uma organização

usa um algoritmo comum para pontuar vulnerabilidades em todas as plataformas de TI, ela
pode aproveitar uma única política de gerenciamento de vulnerabilidades que define o
tempo máximo permitido para validar e corrigir uma determinada vulnerabilidade.
Em seguida, ele fornece uma estrutura aberta. Os usuários podem ficar confusos quando
uma vulnerabilidade recebe uma pontuação arbitrária de terceiros. Com o CVSS, as
características individuais usadas para obter uma pontuação são transparentes.
Finalmente, o CVSS permite o risco prioritário. Quando a pontuação ambiental é calculada, a

vulnerabilidade torna-se contextual para cada organização e ajuda a fornecer uma melhor
compreensão do risco representado por essa vulnerabilidade para a organização.
Métricas
O CVSS é composto por 3 grupos de métricas: Base, Temporal e Environmental.
Base
O grupo de métrica Base é composto pelas características intrínsecas de uma
vulnerabilidade que são constantes ao longo do tempo e nos ambientes dos usuários. Este
grupo é composto de dois conjuntos de métricas: as métricas de exploração (Exploitability) e
as métricas de impacto (Impact).
CVSS Base Score
Sub-grupo de métricas: Exploitability
Refere-se ao ativo que possui a vulnerabilidade e representa a facilidade e os meios técnicos

necessários para exploração da vulnerabilidade. Este sub-grupo é composto por: Attack
Vector, Attack Complexity, Privileges Required, User Interaction e Scope.
Attack Vector (AV): Essa métrica reflete o contexto pelo qual a exploração da vulnerabilidade
é possível acontecer. Este valor métrico (e consequentemente a pontuação Base) será maior
quanto mais remoto (logicamente e fisicamente) um atacante puder ser para explorar o

ativo vulnerável. A suposição é que o número de invasores em potencial para uma
vulnerabilidade que pode ser explorada pela Internet é maior do que o número de invasores
em potencial que podem explorar uma vulnerabilidade que exige acesso físico a um
dispositivo e, portanto, garante uma pontuação maior. Seus possíveis valores são:
 Network (N): Significa que o componente vulnerável está vinculado à pilha da rede e
o caminho do invasor é pela camada 3 do modelo OSI (a camada de rede). Essa
vulnerabilidade é geralmente chamada de “explorável remotamente” e pode ser
considerada como um ataque que pode ser explorado a partir de um ou mais hops
de rede. Um exemplo de um ataque de rede é um invasor que causa uma negação de
serviço (DoS) enviando um pacote TCP especialmente criado através da Internet
pública;
 Adjacent (A): Significa que o componente vulnerável está vinculado à pilha da rede,
mas o ataque é limitado à mesma rede física compartilhada (ex.: Bluetooth, IEEE
802.11) ou lógica (ex.: sub-rede IP local) e não pode ser executada através de um
limite da camada 3 do OSI (ex.: um roteador). Um exemplo de um ataque Adjacente
seria um ARP (IPv4) ou neighbor discovery (IPv6) flood levando a uma negação de
serviço no segmento de LAN local;
 Local (L): Uma vulnerabilidade explorável com acesso local significa que o
componente vulnerável não está vinculado à pilha de rede e o caminho do invasor é
por meio dos recursos de leitura/gravação/execução. Em alguns casos, o invasor
pode estar conectado localmente para explorar a vulnerabilidade, caso contrário, ela
pode confiar na interação do usuário para executar um arquivo mal-intencionado. ;
 Physical (P): Requer que o invasor toque ou manipule fisicamente o componente
vulnerável. A interação física pode ser breve ou persistente. Um exemplo de tal
ataque é o cold boot attack que permite que um invasor acesse as chaves de
criptografia de disco após obter acesso físico ao sistema ou ataques periféricos, como
ataques de acesso direto à memória Firewire/USB;
Figura 25 CVSS 3 – Attack Vector (AV)

Attack Complexity (AC): Esta métrica descreve as condições que devem existir além do
controle do invasor para explorar a vulnerabilidade. Essas condições podem exigir a coleta
de mais informações sobre o destino, a presença de determinadas configurações ou
exceções do sistema. É importante ressaltar que a avaliação dessa métrica exclui qualquer
requisito de interação do usuário para explorar a vulnerabilidade (essas condições são
capturadas na métrica “interação do usuário”). A pontuação será maior para os ataques
menos complexos. Os possíveis valores são:
 Low (L): Não precisa de condições de acesso especializadas ou circunstâncias

específicas. Um invasor pode esperar sucesso repetitivo contra o componente
vulnerável;
 High (H): Um ataque bem sucedido depende de condições além do controle do
atacante. Ou seja, um ataque bem-sucedido não pode ser realizado à vontade, mas
exige que o invasor invista em algum esforço mensurável de preparação ou execução
contra o componente vulnerável antes que um ataque bem-sucedido possa ocorrer.
Por exemplo, um ataque bem-sucedido pode depender de um invasor superar
qualquer uma das seguintes condições:
o O invasor deve realizar um reconhecimento específico do alvo. Por exemplo,
nas definições de configuração de destino, números de sequência, segredos
compartilhados, etc.
o O invasor deve preparar o ambiente de destino para melhorar a
confiabilidade da exploração. Por exemplo, explorar de forma repetida para
ganhar uma condição de corrida ou ultrapassar técnicas avançadas de
mitigação de exploração.
o O atacante deve se injetar no caminho lógico da rede entre o alvo e o recurso
solicitado pela vítima, a fim de ler e/ou modificar as comunicações na rede
(ex.: man-in-the-middle).
Privileges Required (PR): Esta métrica descreve o nível de privilégio que um atacante deve
possuir antes de explorar a vulnerabilidade com sucesso. A pontuação do CVSS aumenta
com a ausência de privilégios necessários. Os possíveis valores são:
 None (N): O invasor não é um usuário autorizado antes do ataque, e portante não
requer acesso a configurações ou arquivos para realizar um ataque;
 Low (L): O invasor está autorizado, ou seja, requer privilégios que fornecem recursos
básicos do usuário que normalmente poderiam afetar apenas as configurações e os
arquivos pertencentes a um usuário. Como alternativa, um invasor com privilégios
baixos pode ter a capacidade de causar impacto somente em recursos não
confidenciais;

 High (H): O invasor está autorizado com privilégios que fornecem controle
significativo (por exemplo, administrativo) sobre o componente vulnerável que pode
afetar as configurações e arquivos de todo o componente;
User Interaction (UI): Essa métrica captura o requisito de que um usuário, que não seja o
invasor, participe do comprometimento para que o invasor seja bem-sucedido. Essa métrica
determina se a vulnerabilidade pode ser explorada somente à vontade do invasor ou se um
usuário separado (ou processo iniciado pelo usuário) deve participar de alguma maneira.
Esse valor de métrica é maior quando nenhuma interação do usuário é necessária.
 None (N): O sistema vulnerável pode ser explorado sem interação de qualquer
usuário;
 Required (R): A exploração bem-sucedida desta vulnerabilidade exige que o usuário
realize alguma ação antes que a vulnerabilidade possa ser explorada. Por exemplo,
uma exploração bem-sucedida só pode ser possível durante a instalação de um
aplicativo por um administrador do sistema;
Scope: Caso um ataque seja bem-sucedido e impacte outro componente além daquele que
está vulnerável, a pontuação Base irá aumentar e as métricas de Confidentiality, Integrity e
Authentication devem ser pontuadas em relação ao componente impactado.
 Changed (C): Uma vulnerabilidade explorada pode afetar os recursos além dos
privilégios de autorização pretendidos pelo componente vulnerável. Nesse caso, o
componente vulnerável e o componente afetado são diferentes;
 Unchanged (U): Uma vulnerabilidade explorada só pode afetar os recursos
gerenciados pela mesma autoridade. Nesse caso, o componente vulnerável e o
componente afetado são os mesmos;

Sub-grupo de métricas: Impact
Refere-se à consequência direta que o ativo sofrerá caso a exploração seja realizada com
sucesso. Independentemente de uma vulnerabilidade explorada com êxito afetar um ou
mais componentes, as métricas de impacto são pontuadas de acordo com o componente
que sofre o pior resultado associado de forma mais direta e previsível a um ataque bem-
sucedido. Devem-se restringir os impactos a um resultado final razoável, que eles estão
confiantes de que um atacante é capaz de alcançar. Este sub-grupo é composto por:
Confidentiality, Integrity e Availability.
Confidentiality Impact: Esta métrica mensura o impacto da confidencialidade da

informação. Confidencialidade refere-se a limitar o acesso e divulgação de informações a
apenas usuários autorizados, bem como impedir o acesso ou a divulgação a usuários não
autorizados.
 High (H): Há perda total de confidencialidade, resultando na divulgação de todos os

recursos do componente afetado ao invasor. Alternativamente, o acesso a apenas
algumas informações restritas é obtido, mas as informações divulgadas apresentam
um impacto sério e direto. Por exemplo, um invasor rouba a senha do administrador
ou chaves de criptografia privadas de um servidor da web;
 Low (L): Há alguma perda de confidencialidade. O acesso a algumas informações
restritas é obtido, mas o invasor não tem controle sobre quais informações são
obtidas ou se a quantidade ou o tipo de perda é restrito. A divulgação de
informações não causa uma perda séria e direta para o componente afetado;
 None (N): Não há perda de confidencialidade no componente afetado;
Integrity Impact: Essa métrica mede o impacto na integridade de uma vulnerabilidade

explorada com sucesso. Integridade refere-se à confiabilidade e veracidade da informação.
Esse valor métrico aumenta com a consequência para o componente impactado.

 High (H): Existe uma perda total de integridade ou uma perda completa de proteção.
Por exemplo, o invasor pode modificar qualquer um dos arquivos protegidos pelo
componente afetado. Como alternativa, apenas alguns arquivos podem ser
modificados, mas a modificação mal-intencionada apresentaria uma consequência
séria e direta para o componente afetado;
 Low (L): A modificação de dados é possível, mas o invasor não tem controle sobre a
consequência de uma modificação ou a quantidade de modificação é restrita. A
modificação de dados não tem um impacto sério e direto no componente afetado;
 None (N): Não há perda de integridade no componente afetado.
Availability Impact: Esta métrica mensura o impacto na disponibilidade do componente

afetado como resultado de uma exploração bem-sucedida. Como a disponibilidade se refere
à acessibilidade dos recursos de informações, os ataques que consomem largura de banda
da rede, ciclos do processador (CPU) ou espaço em disco, todos afetam a disponibilidade de
um componente afetado. Esse valor métrico aumenta com a consequência para o
componente impactado.
 High (H): Há perda total de disponibilidade, resultando no fato do invasor poder

negar totalmente o acesso aos recursos no componente afetado; essa perda é
mantida (enquanto o atacante continua a entregar o ataque) ou persistente (a
condição persiste mesmo após o ataque ser concluído). Como alternativa, o invasor
tem a capacidade de negar alguma disponibilidade, mas a perda de disponibilidade
apresenta uma consequência séria e direta ao componente afetado (por exemplo, o
invasor não pode interromper as conexões existentes, mas pode impedir novas
conexões; o invasor pode explorar repetidamente uma vulnerabilidade que, em cada
instância de um ataque bem-sucedido, vazamentos de uma pequena quantidade de
memória, mas após a exploração repetida faz com que um serviço fique
completamente indisponível).
 Low (L): Há desempenho reduzido ou interrupções na disponibilidade de recursos.
Mesmo que a exploração repetida da vulnerabilidade seja possível, o invasor não
tem a capacidade de negar completamente o serviço a usuários legítimos. Os
recursos no componente afetado estão parcialmente disponíveis o tempo todo, ou
totalmente disponíveis somente em parte do tempo, mas no geral não há
consequência séria e direta para o componente afetado.
 None (N): Não há impacto na disponibilidade dentro do componente afetado.

Pontuação
A fórmula usada irá gerar uma pontuação que varia de 0 (zero) à 10 (dez).
Especificamente, a equação Base é derivada de duas sub-equações: a equação de

Exploitability e a de Impact. Após isto, ela pode ser refinada com a pontuação das métricas
Temporal e Environmental para refletir com mais precisão o risco representado por uma
vulnerabilidade no ambiente de um usuário. No entanto, elas não são obrigatórias para se
obter o CVSS Base.
É importante notar que todas as métricas devem ser pontuadas com a suposição de que o
invasor já localizou e identificou a vulnerabilidade. Ou seja, o analista não precisa considerar
os meios pelos quais a vulnerabilidade foi identificada. Além disso, é provável que muitos
tipos diferentes de indivíduos estejam pontuando vulnerabilidades (por exemplo,
fornecedores de software, analistas de boletins de vulnerabilidade, fornecedores de
produtos de segurança, etc.), mas observe que a classificação de vulnerabilidades deve ser
agnóstica para o indivíduo e sua organização.
Escala de classificação de gravidade qualitativa
É útil ter uma representação textual das pontuações numéricas das métricas Base, Temporal
e Environmental. Todas as pontuações podem ser mapeadas para as classificações
qualitativas da seguinte forma:
Avaliação Pontuação CVSS
Nenhum 0,0
Baixo 0,1 – 3,9
Médio 4,0 – 6,9
Alto 7,0 – 8,9
Crítico 9,0 – 10,0
Para facilitar o cálculo, você pode usar estas calculadoras online:
 https://www.first.org/cvss/calculator/3.0
 https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

Temporal
O grupo de métrica Temporal reflete as características da vulnerabilidade que pode ser

alterada ao longo do tempo. Por exemplo, a existência de um exploit público tornaria a
pontuação do CVSS maior, já a divulgação de um patch de correção a diminuiria.
Geralmente, as métricas Base e Temporal são especificadas por analistas de boletim de
vulnerabilidade, fornecedores de produtos de segurança ou fornecedores de aplicativos,
pois normalmente possuem as informações mais precisas sobre as características de uma
vulnerabilidade.
Figura 26 CVSS 3 Temporal
Exploit Code Maturity: Esta métrica mensura a probabilidade de uma vulnerabilidade ser
atacada com base no estado atual das técnicas de exploração, disponibilidade do código ou
exploração real de forma ativa. Os valores são:
 Not Defined (X): O uso desse valor não interfere na pontuação.
 Unproven (U): Não existe um exploit ou ele é apenas teórico.
 Proof-of-Concept (P): Existe um código para PoC disponível, mas não é prático para
todos os sistemas, demandando uma modificação significativa do código por um
atacante habilidoso.
 Functional (F): Existe um código funcional que funciona na maioria dos casos.
 High (H): Código funcional e autônomo existente, ou que não necessita de exploit (de
forma manual). O código funciona em todas as situações e está sendo usada por
agentes autonomos (ex.: worms, vírus , etc.). O código pode ser encontrado em
diversas ferramentas automatizadas de varreduras e é fácil de usar.

Remediation Level: Esta métrica serve é um fator importante para priorizar a remediação. A
princípio, uma vulnerabilidade não tem um patch de correção quando é divulgada. Soluções
de contorno ou hotfixes podem oferecer uma remediação temporária até que um patch
oficial ou atualização seja lançada. Cada um desses estágios representam uma pontuação
temporal, diminuindo a urgência da remediação de acordo com que ela chega ao final.
 Official Fix (O): Uma solução completa (patch ou upgrade) do fornecedor está
disponível.
 Temporary Fix (T): Existe uma solução oficial, mas temporária para o problema. Isto
inclui hotfix temporários, ferramentas ou soluções de contorno.
 Workaround (W): Existe uma solução não oficial criada por terceiros. Em alguns
casos, os usuários afetados pela tecnologia irão criar um patch por conta própria ou
meios para mitigar a vulnerabilidade.
 Unavailable (U): Não existe uma solução ou é impossível de aplicar.
Report Confidence: Essa métrica mede o grau de confiança na existência da vulnerabilidade
e a credibilidade dos detalhes técnicos divulgados. Às vezes, apenas a existência de
vulnerabilidades é divulgada, mas sem detalhes específicos. Por exemplo, um impacto pode
ser reconhecido como indesejável, mas a causa raiz pode não ser conhecida. A
vulnerabilidade pode mais tarde ser corroborada por pesquisas que sugerem onde a
vulnerabilidade pode estar, embora a pesquisa possa não ser certa. Finalmente, uma
vulnerabilidade pode ser confirmada por meio do reconhecimento pelo autor ou fornecedor
da tecnologia afetada. A urgência de uma vulnerabilidade é maior quando se sabe que existe
uma vulnerabilidade com certeza. Essa métrica também sugere o nível de conhecimento
técnico disponível para possíveis invasores.
 Unknown (U): Há relatos de impactos que indicam que uma vulnerabilidade está
presente. Os relatórios indicam que a causa da vulnerabilidade é desconhecida ou os
relatórios podem diferir na causa ou nos impactos da vulnerabilidade. Os repórteres
não têm certeza da verdadeira natureza da vulnerabilidade, e há pouca confiança na
validade dos relatórios ou se uma pontuação básica estática pode ser aplicada, dadas
as diferenças descritas. Um exemplo é um relatório de bug que observa que uma
falha intermitente, mas não reprodutível, onde ocorre com evidências de corrupção
de memória sugerindo que a negação de serviço ou possíveis impactos mais sérios
podem acontecer.
 Reasonable (R): Detalhes significativos são publicados, mas os pesquisadores não
têm total confiança na causa raiz ou não têm acesso ao código-fonte para confirmar
completamente todas as interações que podem levar ao resultado. Existe uma
confiança razoável, no entanto, o bug é reproduzível e pelo menos um impacto é
capaz de ser verificado (Provas de prova de conceito podem fornecer isso). Um
exemplo é uma descrição detalhada da pesquisa sobre uma vulnerabilidade com
uma explicação (possivelmente ofuscada) que dá garantias de como reproduzir os
resultados.
 Confirmed (C): Existem relatórios detalhados ou reproduções funcionais são possíveis
(exploits funcionais podem fornecer isso). O código fonte está disponível para
verificar independentemente das afirmações da pesquisa, ou o autor ou fornecedor
do código afetado confirmou a presença da vulnerabilidade.

Environmental
O grupo de métrica Environmental representa as características que são particulares do

ambiente do usuário ou organização. Esta métrica permite que sejam inseridos os controles
usados para mitigar as consequências, o que pode melhorar ou piorar a pontuação. Estas
métricas são especificadas pelas organizações dos usuários finais porque são mais capazes
de avaliar o impacto potencial de uma vulnerabilidade em seu próprio ambiente de
computação.
Figura 27 CVSS 3 Environmental
Requisitos de segurança
Essas métricas permitem que o analista personalize a pontuação do CVSS, dependendo da
importância do ativo de TI afetado para a organização de um usuário, medida em termos de
Confidencialidade, Integridade e Disponibilidade. Ou seja, se um ativo de TI suporta uma
função de negócios para a qual a Disponibilidade é mais importante, o analista pode atribuir
um valor maior à Disponibilidade em relação à Confidencialidade e à Integridade. Cada
requisito de segurança tem três valores possíveis: Low, Medium e High.
O efeito total sobre a pontuação Environmental é determinado pelas métricas de impacto
Base modificada correspondentes. Ou seja, essas métricas modificam a pontuação

Environmental reponderando as métricas de impacto de Confidencialidade, Integridade e
Disponibilidade modificadas. Por exemplo, a métrica impacto de confidencialidade
modificada (MC) aumentou o peso se o Requisito de Confidencialidade (CR) for High. Da
mesma forma, a métrica de impacto de Confidencialidade Modificada diminuiu o peso se o
Requisito de Confidencialidade for Baixo. A ponderação da métrica de impacto de
Confidencialidade Modificada é neutra se o Requisito de Confidencialidade for Médio. Esse
mesmo processo é aplicado aos requisitos de integridade e disponibilidade.
Observe que o Requisito de Confidencialidade não afetará a pontuação Environmental se o
impacto da confidencialidade (Base Modificada) estiver definido como None. Além disso,
aumentar o Requisito de Confidencialidade de Médio para Alto não alterará a pontuação
Environmental quando as métricas de impacto (Base Modificada) estiverem definidas como
Alta. Isso ocorre porque a sub-pontuação de impacto modificada (parte da pontuação da
Base Modificada que calcula o impacto) já está no valor máximo de 10.
 Not Defined (X): Atribuir este valor à métrica não influenciará a pontuação. É um
sinal para a equação para pular essa métrica.
 b A perda de [Confidencialidade / Integridade / Disponibilidade] provavelmente terá
um efeito adverso catastrófico sobre a organização ou indivíduos associados à
organização (ex.: funcionários, clientes).
 Medium (M): A perda de [Confidencialidade / Integridade / Disponibilidade] pode ter
um efeito adverso grave na organização ou nos indivíduos associados à organização
(ex.: funcionários, clientes).
 Low (L): A perda de [Confidencialidade / Integridade / Disponibilidade]
provavelmente terá apenas um efeito adverso limitado na organização ou nos
indivíduos associados à organização (ex.: funcionários, clientes).
Métricas Base Modificadas
Essas métricas permitem que o analista ajuste as métricas Base de acordo com as
modificações existentes no ambiente do analista. Ou seja, se um ambiente tiver feito
alterações gerais no software afetado que difiram de maneira a afetar sua Exploitability,
Scope ou Impact, o ambiente poderá refletir isso por meio de uma pontuação Environmental
apropriadamente modificada.
O efeito total sobre a pontuação Environmental é determinado pelas métricas de base
correspondentes. Ou seja, essas métricas modificam a pontuação Environmental
reatribuindo os valores de métricas (Base), antes de aplicar os Requisitos de Segurança
(Environmental). Por exemplo, a configuração padrão para um componente vulnerável pode
ser a execução de um serviço de escuta com privilégios de administrador, para o qual um
comprometimento pode conceder a um invasor impactos de Confidencialidade, Integridade
e Disponibilidade todos altos. No entanto, no ambiente do analista, esse mesmo serviço de
Internet pode estar sendo executado com privilégios reduzidos. Nesse caso, a
Confidencialidade Modificada, a Integridade Modificada e a Disponibilidade Modificada
podem ser definidas como Baixa.
A intenção dessa métrica é definir as atenuações em vigor para um determinado ambiente.
É aceitável usar as métricas modificadas para descrever situações que aumentam a
pontuação básica. Por exemplo, a configuração padrão de um componente pode ser exigir

privilégios altos (PR: High) para acessar uma função específica, mas no ambiente do analista,
pode não haver privilégios necessários (PR: None). O analista pode definir MPR: None para
refletir essa condição mais séria para o ambiente. Cada métrica ambiental modificada tem
os mesmos valores que sua métrica base correspondente, além de um valor de não definido.
 Modified Attack Vector (MAV)
 Modified Attack Complexity (MAC)
 Modified Privileges Required (MPR)
 Modified User Interaction (MUI)
 Modified Scope (MS)
 Modified Confidentiality (MC)
 Modified Integrity (MI)
 Modified Availability (MA)
Exercícios
Defina as métricas e calcule o Base Score das vulnerabilidades descritas abaixo:
1) XSS no phpMyAdmin
a. Vulnerabilidade: As vulnerabilidades de cross-site scripting (XSS) refletidas
estão presentes na página tbl_gis_visualization.php no phpMyAdmin 3.5.x,
antes da versão 3.5.8. Isso permite que invasores remotos injetem JavaScript
ou HTML arbitrários por meio dos parâmetros (1) visualizationSettings [width]
ou (2) visualizationSettings [height].
b. Ataque: Uma exploração bem-sucedida exige que um invasor realize o
reconhecimento do sistema que está executando o software phpMyAdmin
vulnerável para determinar um nome de banco de dados válido e obter um
token de sessão válido. O invasor constrói uma URL para o servidor da Web
que executa o software phpMyAdmin vulnerável que contém esse nome e
token do banco de dados. Um dos dois parâmetros injetáveis é adicionado à
URL com seu valor definido para o código malicioso que o atacante deseja
que a vítima execute. O invasor distribui esse URL e incita a vítima a clicar
nele, por exemplo, enviando o URL em e-mails ou adicionando-o a um site
legítimo. Se uma vítima clicar no URL, o código malicioso será executado no
navegador da vítima. O código malicioso só é capaz de acessar as informações
associadas ao site que executa o software phpMyAdmin vulnerável devido às
restrições da SOP (Política de mesma origem) nos navegadores da web. O
phpMyAdmin, por padrão, define o sinalizador HttpOnly em seus cookies,
impedindo que o JavaScript acesse os cookies do navegador da Web que
limitam o impacto geral desse ataque.
2) SQL injection no MySQL
a. Vulnerabilidade: Uma vulnerabilidade no banco de dados do MySQL Server
poderia permitir que um usuário remoto e autenticado injetasse um código
SQL que executasse a funcionalidade de replicação do MySQL com altos
privilégios. Um ataque bem-sucedido poderia permitir que qualquer dado em
um banco de dados MySQL remoto fosse lido ou modificado.

b. Ataque: Um atacante exige uma conta no banco de dados alvo MySQL com o
privilégio de modificar identificadores fornecidos pelo usuário, como nomes
de tabelas. A conta deve estar em um banco de dados que está sendo
replicado para um ou mais outros bancos de dados MySQL. Um ataque
consiste em fazer login usando a conta e modificar um identificador para um
novo valor que contenha um caractere de aspas e um fragmento de SQL mal-
intencionado. Este SQL será posteriormente executado como um usuário
altamente privilegiado no(s) sistema(s) remoto(s). O SQL mal-intencionado é
injetado nas instruções SQL que fazem parte da funcionalidade de replicação,
impedindo que o invasor execute instruções SQL arbitrárias.
3) Falha no protocolo SSLv3
a. Vulnerabilidade: O protocolo SSL 3.0, usado no OpenSSL através de 1.0.1i e
outros produtos, usa preenchimento CBC não-determinístico, o que torna
mais fácil para o invasor obter dados em texto plano por meio de um ataque
oracle padding, também conhecido como "POODLE".
b. Ataque: Um cenário de ataque típico é que a vítima visitou um servidor da
Web e o navegador da Web agora contém um cookie que um invasor deseja
roubar. Para um ataque bem-sucedido, o invasor deve poder modificar o
tráfego de rede entre a vítima e este servidor da Web, e tanto a vítima quanto
o sistema devem estar dispostos a usar o SSL 3.0 para criptografia. Um ataque
típico começa quando o atacante induz a vítima a visitar um site contendo
código malicioso que é executado no navegador da vítima. As restrições da
mesma política de origem (SOP) nos navegadores da Web impedem que esse
código acesse diretamente o cookie que o invasor está tentando roubar, mas
solicitações HTTP que o código envia ao servidor da web automaticamente
adicionam o cookie, e esse comportamento é usado no ataque. O código
malicioso envia uma solicitação HTTP que adivinha o valor do primeiro byte
do cookie e posiciona esse byte em um local específico. O invasor modifica a
solicitação HTTP criptografada de forma que esse byte seja usado como um
valor de preenchimento. Se o servidor aceitar a solicitação modificada, o
valor adivinhado estará correto; se não, o código adivinha um valor diferente
em uma nova solicitação. Este processo é repetido até que todo o cookie seja
divulgado.
4) Manipulação a partir do sistema Guest no Host pelo VMWare
a. Vulnerabilidade: Devido a uma falha na função de manipulador dos
comandos RPC, é possível manipular os ponteiros de dados dentro do
processo do Virtual Machine Executable (VMX). Essa vulnerabilidade pode
permitir que um usuário em uma Máquina Virtual Visitada trave o processo
VMX, resultando em uma negação de serviço (DoS) no host ou
potencialmente executar código no host.
b. Ataque: Uma exploração bem-sucedida exige que um invasor tenha acesso a
uma máquina virtual convidada (VM). A VM Guest precisa ser configurada
para ter 4 GB ou mais de memória. O invasor teria que criar uma chamada
RPC remota especialmente criada para explorar o processo VMX. O processo
VMX é executado no VMkernel, que é responsável por manipular E / S para
dispositivos que não são críticos para o desempenho. Também é responsável
pela comunicação com interfaces de usuário, gerenciadores de instantâneos e

console remoto. Cada máquina virtual possui seu próprio processo VMX, que
interage com os processos do host por meio do VMkernel. O invasor pode
explorar a vulnerabilidade para travar o processo VMX, resultando em DoS do
host ou potencialmente executar código no sistema operacional host.
5) Apache Tomcat XML
a. Vulnerabilidade: O Apache Tomcat 4.1.0 a 4.1.39, 5.5.0 a 5.5.27 e 6.0.0 a
6.0.18 permite que aplicativos da web substituam um analisador XML usado
para outros aplicativos da Web, o que permite que os usuários locais leiam ou
modifiquem o ( 1) arquivos web.xml, (2) context.xml ou (3) tld de aplicativos
da Web arbitrários por meio de um aplicativo criado que é carregado antes
do aplicativo de destino.
b. Ataque: Essa vulnerabilidade do Tomcat permite que um aplicativo da Web
faça referência a um analisador de XML em vez de usar o analisador de XML
do Apache padrão. O invasor deve remover todos os aplicativos da Web
existentes, incluindo os do servidor / aplicativos da Web, e instalar um
aplicativo da Web com um analisador XML armazenado em WEB-INF / lib.
Isso fará com que o Tomcat use o novo analisador XML para processar todos
os arquivos web.xml, context.xml e tld de outras aplicações web. Se esse
analisador XML não padrão for substituído por um interpretador mal-
intencionado, o conteúdo do XML do aplicativo da Web da vítima poderá ser
divulgado, a JSP resultante poderá ser corrompida (se compilada) ou
possivelmente até mesmo usada como arma para novos ataques.
Existem duas maneiras diferentes que esse ataque pode se manifestar.
Primeiro, um usuário local privilegiado poderia simplesmente substituir o
analisador XML não-Apache por uma variante mal-intencionada. A segunda é
que um invasor pode usar engenharia social e interação com o usuário para
injetar o analisador XML malicioso no sistema. Vamos marcar para o primeiro.

8. AVALIAÇÃO
Perguntas
1) Em qual das fases descritas abaixo é realizado a identificação de vulnerabilidades no

sistema alvo?
a. Reconhecimento
b. Escaneamento
c. Exploração
d. Pós-Exploração
2) Qual metodologia usada para realizar testes de invasão em aplicações Web com viés
inicialmente black-box?
a. PTES
b. PCI DSS
c. OWASP Testing Guide
d. NIST 800-115
3) O time de segurança está usando o nmap e questiona sobre o “script engine” da
ferramenta. Qual opção de comando pode ser usada para invocar o nmap scripting
engine?
a. -sS
b. -sT
c. --script
d. -sU
4) Um invasor ganhou acesso a um sistema interno. Usando o Metasploit, ele acessou e
atacou outros sistemas internos. Qual dos termos seguintes melhor descreve a ação
realizada?
a. Attack splitting
b. Pivoting
c. Attack swinging
d. Hinging
5) Qual é a diferença entre o ataque de dicionário e o ataque híbrido?
a. Ataques de dicionário é baseado somente em wordlists, enquanto que o ataque
híbrido faz uso tanto de wordlists como de tabelas rainbow.
b. Ataques de dicionário é baseado somente em wordlists, enquanto que o ataque
híbrido usa uma variedade de letras, números e caracteres especiais.
c. Ataques de dicionário é baseado somente em wordlists, enquanto que o ataque
híbrido substitui números e símbolos dentro das palavras.
d. Ataques híbridos e de dicionários são a mesma coisa.
6) Analise a figura do ataque abaixo e informe qual é o nome do ataque

a. Cross-Site Scripting
b. SQL Injection
c. Path Traversal
d. Remote File Inclusion
7) “É o processo de identificação de falhas nos sistemas de computadores, redes e canais de
comunicação. Ele é executado como parte da auditoria e também para defender os
sistemas de novos ataques. As falhas são identificadas, classificadas e relatadas às
autoridades para que medidas necessárias possam ser tomadas para corrigi-las e proteger
a organização.” De qual tipo de teste estamos falando?
a. Teste de Invasão
b. Enumeração
c. Escaneamento de Redes
d. Análise de Vulnerabilidades
8) Um desenvolvedor de aplicações web deseja realizar testes em sua nova aplicação a fim de
identificar falhas de segurança. Qual dos seguintes métodos de testes de inserção variada
de dados usando payloads gerados aleatoriamente a fim de quebrar o programa?
a. Burp Suite
b. OWASP ZAP
c. Fuzzing
d. CSRF
9) Como se chama o meio por onde um atacante tira vantagem da falha do sistema,
aplicação, ou serviço para atacá-los e obter um resultado que não era esperado pelo
desenvolvedor (ex.: buffer overflow, SQL injection, erros de configuração, etc.)?
a. Payload
b. Exploit
c. Shellcode
d. Module
10) “Quando um invasor faz com que o sistema alvo envie uma conexão de volta para a
máquina atacante, a qual está esperando por uma conexão de entrada, neste caso, nossa
máquina atacante está com uma porta aberta e escutando por uma conexão vinda da
nossa máquina alvo e é mais provável de ser realizada com sucesso.”
a. Bind shell
b. Shellcode
c. Payload
d. Reverse shell

11) Qual das ferramentas não é usada para identificar vulnerabilidades em aplicações Web?
a. ZAP
b. Burp Suite
c. Arachni
d. p0f
12) Qual flag é usada para não enviar ping durante uma varredura com o nmap?
a. -sT
b. -A
c. -sS
d. -Pn
13) Qual dos seguintes causa um potencial quebra de segurança?
a. Vulnerabilidade
b. Ameaça
c. Exploit
d. Zero day
14) Um ethical hacker está visitando o site da empresa alvo e depois parte para as redes
sociais e sites de vagas de emprego procurando informações e construindo um perfil sobre
a empresa. Qual dos seguintes melhor descreve essa atividade?
a. Coleta de informações ativa
b. Internet footprinting
c. Sniffing
d. Coleta de informações passiva
15) Qual dos itens seguintes descreve o TCP three-way handshake?
a. SYN, ACK, SYN/ACK
b. SYN, SYN/ACK, ACK
c. ACK, SYN/ACK, SYN
d. ACK, ACK/SYN, SYN
16) Leia a vulnerabilidade e o ataque realizado para calcular as métricas e definir seu Base
Score no CVSS 3:
“O Bluetooth Stack 2.1 no Microsoft Windows Vista SP1 e SP2 e Windows 7 Gold e SP1 não
impede o acesso a objetos na memória que (1) não foram inicializados corretamente ou (2)
foram excluídos, o que permite que atacantes remotos executem código arbitrário via
pacotes Bluetooth criados, também conhecidos como "Vulnerabilidade de pilha do
Bluetooth". A vulnerabilidade pode permitir a execução remota de código se um invasor
enviar uma série de pacotes Bluetooth especialmente criados para um sistema afetado.
Esta vulnerabilidade afeta apenas sistemas com capacidade Bluetooth. O invasor precisa
primeiro obter o endereço Bluetooth de 48 bits do sistema, que não é "detectável" por
padrão nas versões afetadas do Windows. Se o sistema fosse "detectável", responderia às
consultas do SDP do invasor com seu endereço Bluetooth. Mas, no estado padrão, um
invasor precisa obter seu endereço Bluetooth de outra forma - seja usando a força bruta
ou extraindo-a do tráfego Bluetooth capturado por via aérea. O invasor precisaria estar na
mesma proximidade da máquina de destino para enviar e receber transmissões de rádio
dentro do espectro de rádio Bluetooth. Uma vez explorada, o atacante pode executar
código arbitrário. O invasor pode instalar programas; visualizar, alterar ou excluir dados;
ou crie novas contas com direitos totais de usuário.”
a. CVSS:3.0/AV:A/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H – 8.4
b. CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H – 8.2
c. CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:H – 8.9
d. CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H – 8.8

9. BIBLIOGRAFIA
Albuquerque, D. M. (19 de 07 de 2016). Escaneando portas com Nmap. Fonte: Diego
Macêdo - Um pouco de tudo sobre TI:
https://www.diegomacedo.com.br/escaneando-portas-com-nmap/
Albuquerque, D. M. (26 de 09 de 2016). Introdução ao Metasploit Framework. Fonte: Diego

Macêdo - Um pouco de tudo sobre TI:
https://www.diegomacedo.com.br/introducao-ao-metasploit-framework/
Albuquerque, D. M. (04 de 10 de 2016). Mapa Mental de Redes e Segurança da Informação

– Scanner Nmap. Fonte: Diego Macêdo - Um pouco de tudo sobre TI:
https://www.diegomacedo.com.br/mapa-mental-de-redes-e-seguranca-da-
informacao-scanner-nmap/
First. (s.d.). Common Vulnerability Scoring System SIG. Fonte: First - Improving Security
Together: https://www.first.org/cvss/
Guimaraes, B., & Stampar, M. (09 de 2018). Automatic SQL injection and database takeover
tool. Fonte: SQLMap: http://sqlmap.org/
Kali. (s.d.). Fonte: Kali: https://www.kali.org/
Kali. (s.d.). Tools. Fonte: Kali: https://tools.kali.org/
Kennedy, D., J. O., & D. K. (2011). Metasploit: The Penetration Tester's Guide. São Francisco:
No Starch Press.
Laskos, T. (09 de 2018). Web Application Security Scanner Framework. Fonte: Arachni
Scanner: http://www.arachni-scanner.com/
Lyon, G. (2009). Exame de redes com NMAP. Rio de Janeiro: Ciência Moderna.
Openwall. (s.d.). John the Ripper password cracker. Fonte: Openwall:

https://www.openwall.com/john/
OWASP. (09 de 2018). Zed Attack Proxy Project. Fonte: OWASP:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Portswigger. (09 de 2018). Burp Suite Editions. Fonte: Portswigger:

https://portswigger.net/burp
Rapid7. (15 de 08 de 2018). Metasploitable 2. Fonte: Metasploitable Help:

https://metasploit.help.rapid7.com/docs/metasploitable-2
Rapid7. (s.d.). Metasploit. Fonte: Rapid7: https://www.rapid7.com/products/metasploit/
RED HAWK. (09 de 2018). Fonte: Github: https://github.com/Tuhinshubhra/RED_HAWK
Skipfish. (09 de 2018). Fonte: Github: https://github.com/spinkham/skipfish


Walker, M. (2017). CEH Certified Ethical Hacker All-in-One Exam Guide. Estados Unidos:
McGraw-Hill.
Weidman, G. (2014). Testes de Invasão: Uma introdução prática ao hacking. São Paulo:
Novatec.
Zero Security. (09 de 2018). Sn1per - Automated Pentest Framework for Offensive Security
Experts. Fonte: Xero Secutiy: https://xerosecurity.com/

Apostila de Teste de Invasao em Redes e Sistemas

Enviado por

Direitos autorais:

Formatos disponíveis

Apostila de Teste de Invasao em Redes e Sistemas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila de Teste de Invasao em Redes e Sistemas

Enviado por

Direitos autorais:

Formatos disponíveis

TESTE DE INVASÃO EM REDES E

UNICIV – Centro de Inovação Vincit

TESTE DE INVASÃO EM REDES E SISTEMAS

PROF. ESP. DIEGO MACÊDO

08/08/2018 Teste de invasão em redes e sistemas 1

Prof. Esp. Diego Macêdo

08/08/2018 Teste de invasão em redes e sistemas 2

Prof. Esp. Diego Macêdo

Prof. Esp. Diego Macêdo

Teste de invasão/pentetração ou pentest é a simulação de ataques reais em ativos para

Os testes podem ser feitos em:

 Garantir que estão todos alinhados sobre os testes;

08/08/2018 Teste de invasão em redes e sistemas 4

Prof. Esp. Diego Macêdo

 Quais os sistemas que o nosso alvo utiliza?

Nesta etapa, começamos a descobrir ativamente as vulnerabilidades para determinar quão

Sempre durante esta fase, os pentesters rodam escaneres de vulnerabilidades, os quais

Algumas informações extras:

Prof. Esp. Diego Macêdo

Durante a fase de pós-exploração, coletamos informações sobre o sistema atacado, olhamos

08/08/2018 Teste de invasão em redes e sistemas 6

Prof. Esp. Diego Macêdo

Veja o link (https://github.com/juliocesarfort/public-pentesting-reports) para obter algumas

08/08/2018 Teste de invasão em redes e sistemas 7

Prof. Esp. Diego Macêdo

OWASP Testing Guide v4

Mais informações podem ser encontradas em

O modelo de teste consiste em:

 Testador: quem realiza as atividades de teste

O teste é dividido em duas fases:

Fase 1 - Modo passivo

Fase 2 – Modo ativo

08/08/2018 Teste de invasão em redes e sistemas 8

Prof. Esp. Diego Macêdo

O “Technical Guide to Information Security Testing and Assessment” tem o objetivo de

Figura 1 Fases do Teste de Invasão no NIST 800-115

08/08/2018 Teste de invasão em redes e sistemas 9

Prof. Esp. Diego Macêdo

Esta metodologia pode ser vista em:

A metodologia do PCI DSS para pentest chama-se “Penetration Testing Guidance”. É um

 Componentes do teste de invasão;

A metodologia é composta pelas seguintes fases:

 Pré-Compromisso: Escopo, documentação, regras (janela, comunicação, etc.),

08/08/2018 Teste de invasão em redes e sistemas 10

Prof. Esp. Diego Macêdo

Esta metodologia pode ser vista em:

A metodologia “Penetration Testing Execution Standard” consistema de 7 seções principais:

Prof. Esp. Diego Macêdo

Figura 3 Estabelecimento de conexão TCP - 3 way handshake

08/08/2018 Teste de invasão em redes e sistemas 12

Prof. Esp. Diego Macêdo

Nmap done: 1 IP address (1 host up) scanned in 25.47 seconds

Prof. Esp. Diego Macêdo

Service detection performed. Please report any incorrect results at

Prof. Esp. Diego Macêdo

Nmap done: 1 IP address (1 host up) scanned in 55.40 seconds

Nmap done: 1 IP address (1 host up) scanned in 5.49 seconds

08/08/2018 Teste de invasão em redes e sistemas 15

Prof. Esp. Diego Macêdo