Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ROTEIRO PARA REALIZAÇÃO DE TESTES DE PENETRAÇÃO EM
CENÁRIOS TURN-KEYS
Área de Segurança de Informações
por
Odilo Schwade Junior
Fabrício Bortoluzzi, M. Sc.
Orientador
Itajaí (SC), novembro de 2010
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ROTEIRO PARA REALIZAÇÃO DE TESTES DE PENETRAÇÃO EM
CENÁRIOS TURN-KEYS
Área de Segurança de Informações
por
Odilo Schwade Junior
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientador: Fabrício Bortoluzzi, M. Sc.
Itajaí (SC), novembro de 2010
ii
AGRADECIMENTOS
A entrega deste projeto finaliza o percurso de um caminho que vem sido percorrido durante
cinco anos. Os meses de estudo, sem as pessoas aqui mencionadas, não seriam passados com tanta
alegria e ensinamentos como foram.
Minha mãe, em especial, foi a pessoa que esteve sempre ao meu lado. Agüentando as crises
de mal humor, as noites sem dormir, entre outros inconvenientes que vieram durante este caminho.
Sempre nos ajudamos em todos os momentos que passamos e sempre serei eternamente grato por
todos seus ensinamentos que moldaram a pessoa que sou hoje. Obrigado, te amo mãe.
Agradeço com muito carinho, Tio Juca e Tia Adri que me passaram muitos ensinamentos e
sempre colaboraram para que eu chegasse a este momento. A minha prima-irmã e melhor amiga
Julia que me aturou varias vezes, na maioria delas reclamando, mas sempre esteve comigo
demonstrando seu apoio e me alegrando nos momentos difíceis. Ao Tio André que me aconselhou
corretamente em diversas situações, que com certeza nunca esquecerei. Obrigado Tio Sandro, que
sempre me ajudou estando por perto nos momentos em que precisei. Agradeço meus avós maternos
Vô Antonio e Vó Ana, Tia Ana Paula, Tio Lucas e Tia Mariana.
Agradeço, Pai e Scheila, pelo esforço e apoio que me deram durante todos esses anos,
mesmo estando a mais de mil quilômetros de distancia. Meu mano, Fê que sempre se interessou
pelo meu caminho na faculdade, sempre pedindo como andava meu TCC. A meus avós paternos,
Vô Ivo e Vó Laura e a todos meus tios e primos.
Um agradecimento muito especial a Ana Cláudia Minela, ―élêéfe‖, minha melhor amiga que
sempre esteve comigo, que conversou durante as madrugadas de estudo, aconselhou, cobrou,
comemorou e me deu forças para continuar e cumprir este objetivo. Com certeza sem ela, muitas
coisas teriam ficado para trás.
Agradeço a meu amigo, mestre, professor e orientador Fabrício, que colaborou muito
durante a faculdade, proporcionando oportunidades, conselhos e a visão da área que me interessou
profissionalmente. Obrigado ao Prof. Luca, Marlei e demais colaboradores da UNIVALI. Um
obrigado aos colegas Felipe, Fernando, Lennon, Alexandre, Antonio e Romulo pela suas
participações e amizades durante a maioria do tempo que passamos na academia.
Agradeço a Deus, pela oportunidade que me proporcionou.
Esta etapa está sendo finalizada, porém é apenas uma porta que se abre para novos desafios.
Muito obrigado.
“All you need is love..” (The Beatles – 1967).
iii
“You may say, I'm a dreamer
But I'm not the only one
I hope some day
You'll join us
And the world will be as one!”
(John Lennon, 1971)
iv
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. vi
LISTA DE FIGURAS ............................................................................... vii
LISTA DE TABELAS ............................................................................... ix
RESUMO ..................................................................................................... x
ABSTRACT ................................................................................................ xi
1 INTRODUÇÃO .................................................................................... 12
1.1 PROBLEMATIZAÇÃO ................................................................................... 14
1.1.1 Formulação do Problema ............................................................................... 14
1.1.2 Solução Proposta ............................................................................................. 15
1.2 OBJETIVOS ...................................................................................................... 15
1.2.1 Objetivo Geral ................................................................................................. 15
1.2.2 Objetivos Específicos ...................................................................................... 15
1.3 METODOLOGIA .............................................................................................. 16
1.4 ESTRUTURA DO TRABALHO ..................................................................... 16
2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 17
2.1 SEGURANÇA DE INFORMAÇÕES .............................................................. 17
2.1.1 Confidencialidade ........................................................................................... 18
2.1.2 Integridade ....................................................................................................... 18
2.1.3 Disponibilidade ................................................................................................ 19
2.1.4 Alvos de proteção ............................................................................................ 19
2.1.5 Ameaças ........................................................................................................... 21
2.1.6 Tipos de atacantes ........................................................................................... 21
2.1.7 Tipos de ataques .............................................................................................. 23
2.1.8 Formas de prevenção de ataques ................................................................... 28
2.2 ESTATÍSTICAS ................................................................................................ 31
2.3 TESTE DE PENETRAÇÃO ............................................................................. 35
2.3.1 Levantamento de Informações ou Reconhecimento .................................... 36
2.3.2 Identificação de vulnerabilidades .................................................................. 38
2.3.3 Verificação de vulnerabilidades .................................................................... 41
2.3.4 Obter acesso privilegiado ............................................................................... 42
2.3.5 Manter acesso .................................................................................................. 43
2.3.6 Limpar as evidências ...................................................................................... 45
3 PROJETO ............................................................................................. 46
3.1 CENÁRIOS TURN-KEYS ............................................................................... 46
3.2 AMBIENTE DE EXECUÇÃO ......................................................................... 50
3.3 ROTEIRO DE PENTESTING ......................................................................... 52
v
4 DESENVOLVIMENTO DO ROTEIRO DE TESTES DE
PENETRAÇÃO ........................................................................................ 53
4.1 FLUXOGRAMA DO ROTEIRO PROPOSTO ............................................. 53
4.2 ROTEIRO DE TESTE DE PENETRAÇÃO .................................................. 55
4.2.1 Identificação de vulnerabilidades .................................................................. 55
4.2.2 Verificação e exploração das vulnerabilidades ............................................ 58
4.2.3 Obter acesso privilegiado ............................................................................... 61
5 CONCLUSÕES .................................................................................... 64
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 66
GLOSSÁRIO ............................................................................................. 72
A ROTEIRO DE TESTE DE PENETRAÇÃO CENÁRIO PWNOS . 75
A.1 IDENTIFICAÇÃO DE VULNERABILIDADES............................................ 75
A.1.1 Varredura com NMap..................................................................................... 75
A.1.2 Varredura com Nessus .................................................................................... 80
A.1.3 Análise do serviço Webmin ............................................................................ 81
A.2 VERIFICAÇÃO E EXPLORAÇÃO DAS VULNERABILIDADES ............ 82
A.2.1 Vulnerabilidade OpenSSH/OpenSSL ............................................................ 82
A.2.2 Vulnerabilidade Webmin ............................................................................... 83
A.2.3 Explorando as vulnerabilidades encontradas para obter acesso ao sistema
84
A.3 OBTENDO ACESSO PRIVILEGIADO AO SISTEMA ............................... 87
B ROTEIRO DE TESTE DE PENETRAÇÃO CENÁRIO DE-ICE
NIVEL 1 ..................................................................................................... 89
B.1 IDENTIFICAÇÃO DE VULNERABILIDADES ............................................ 89
B.1.1 Varredura com NMap ..................................................................................... 90
B.2 VERIFICAÇÃO E EXPLORAÇÃO DAS VULNERABILIDADES ............ 95
B.3 OBTENDO ACESSO PRIVILEGIADO AO SISTEMA .............................. 101
C ROTEIRO DE TESTE DE PENETRAÇÃO CENÁRIO DE-ICE
NIVEL 2 ................................................................................................... 103
C.1 IDENTIFICAÇÃO DE VULNERABILIDADES.......................................... 103
C.1.1 Varredura com NMap................................................................................... 103
C.1.2 Varredura com Nessus .................................................................................. 105
C.1.3 Analisando as informações das páginas do servidor Apache .................... 106
C.2 VERIFICAÇÃO E EXPLORAÇÃO DAS VULNERABILIDADES .......... 108
C.2.1 Utilizando a técnica Fuzz testing .................................................................. 108
C.3 OBTENDO ACESSO PRIVILEGIADO AO SISTEMA ............................. 114
D FLUXOGRAMA DE ROTEIRO DE TESTE DE PENETRAÇÃO
118
vi
LISTA DE ABREVIATURAS
CIDR Classless Inter-Domain Routing
CGI Common Gateway Interface
DHCP Dynamic Host Configuration Protocol
DLL Dynamic-link library
DNS Domain Name System
FTP File Transfer Protocol
HTTP Hypertext Transfer Protocol
ICMP Internet Control Message Protocol
IDS Intrusion Detection System
IMAP Internet Message Access Protocol
IP Internet Protocol
IPS Intrusion Prevention System
J2EE Java 2 Enterprise Edition
LAN Local Area Network
MAC Media Access Control PDF Portable Document Format
POP3 Post Office Protocol
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SO Sistema Operacional
SQL Structed Query Language
SSH Secure Shell
TCC Trabalho de Conclusão de Curso
TCP Transmission Control Protocol
TI Tecnologia de Informação
UDP User Datagram Protocol
UNIVALI Universidade do Vale do Itajaí
VNC Virtual Network Computing
vii
LISTA DE FIGURAS
Figura 1. Total de incidentes reportados ao CERT.br por ano ........................................................... 12
Figura 2. Tentativa de Phishing tentando passar-se pelo Banco Bradesco ........................................ 27 Figura 3. Vulnerabilidades em extensões para navegadores web ...................................................... 33 Figura 4. Índice de incidentes reportados ao CSI ............................................................................... 34 Figura 5. Comando whois no endereço www.univali.br .................................................................... 38 Figura 6. Opções do Nmap para passar através de Firewall e IDS, entre outros ............................... 39
Figura 7. NMap identificando serviços .............................................................................................. 40 Figura 8. Tunel SSH sem detecção de mecanismos de defesa ........................................................... 44 Figura 9. Damn Vulnerable Linux ..................................................................................................... 47 Figura 10. WebGoat vulnerabilidades web ........................................................................................ 48 Figura 11. PnwOS iniciado ................................................................................................................ 49
Figura 12. Projeto Hackerdemia ......................................................................................................... 49 Figura 13. Laboratório de Testes ........................................................................................................ 51
Figura 14. Backtrack Linux com a ferramenta Metasploit ................................................................. 52 Figura 15. Fluxograma do roteiro ...................................................................................................... 54 Figura 16. Varredura em faixa de IPs ................................................................................................ 55 Figura 17. Exemplo varredura com CIDR. ........................................................................................ 56
Figura 18. Varredura específica em IP ............................................................................................... 56 Figura 19. Configuração plugins Nessus ............................................................................................ 57
Figura 20. Relatório de varredura do Nessus ..................................................................................... 57 Figura 21. Módulo de busca do Exploit-DB (2010) ........................................................................... 59 Figura 22. Módulo de busca do Inj3ct0r (2010) ................................................................................. 59
Figura 23. Busca de exploit no Metasploit ......................................................................................... 60 Figura 24. Exploit-DB (2010) busca por exploits para escalonamento de privilégios ....................... 62
Figura 25. Inj3ct0r (2010) busca por "Local Root Exploit" ............................................................... 63 Figura 26. Varredura em rede com NMap ......................................................................................... 75
Figura 27. NMap encontra maquina ativa .......................................................................................... 76 Figura 28. NMap com alguns parâmetros opcionais .......................................................................... 76 Figura 29. Retorno da varredura do NMap mostrando serviços e versões ........................................ 77
Figura 30. Página inicial disponibilizada na máquina alvo. ............................................................... 77 Figura 31. Formulário mostrado na iteração com o site hospedado na máquina alvo ....................... 78
Figura 32. Erro de função include() do PHP ...................................................................................... 79 Figura 33. Arquivo /etc/passwd incluído na página ........................................................................... 79 Figura 34. Relatório do Nessus indicando vulnerabilidade de alto risco no serviço SSH ................. 80
Figura 35. Detalhes da vulnerabilidade no OpenSSH/OpenSSL gerada pelo Nessus ....................... 81 Figura 36. Interface de autenticação do serviço Webmin .................................................................. 82 Figura 37. Modulo Webmin/file_disclosure do Metasploit ............................................................... 84 Figura 38. Retorno do conteúdo do arquivo /etc/shadow pelo exploit do Webmin ........................... 85
Figura 39. Arquivo configuração OpenSSH ...................................................................................... 85 Figura 40. Retorno do conteúdo da chave pública do usuário "obama" através do Metasploit ......... 86 Figura 41. Encontrado chave publica do usuário ―obama‖ ................................................................ 86
Figura 42. Acesso remoto do usuário ―obama‖ ao sistema ................................................................ 87 Figura 43. Obtido acesso privilegiado ao sistema .............................................................................. 88 Figura 44. Varredura de rede com o NMap ....................................................................................... 90 Figura 45. Resultado da varredura a uma faixa de IPs ....................................................................... 90 Figura 46. Varredura especifica a maquina alvo ................................................................................ 91
viii
Figura 47. Pagina inicial da maquina 192.168.1.100 ......................................................................... 92 Figura 48. Lista de e-mails ................................................................................................................. 93
Figura 49. Lista de e-mails e possíveis usuários de sistema para cada colaborador .......................... 94 Figura 50. Falha ao conectar ao serviço FTP ..................................................................................... 95 Figura 51. Usuário "bbanter" possui senha igual ao login ................................................................. 96 Figura 52. Acesso remoto obtido com o usuário "bbanter" ............................................................... 97 Figura 53. Conteúdo do arquivo /etc/passwd ..................................................................................... 98
Figura 54. Conteúdo do arquivo /etc/group ....................................................................................... 99 Figura 55. Senha do usuário "aadams" é encontrada ....................................................................... 100 Figura 56. Acesso remoto com o usuário "aadams" ......................................................................... 100 Figura 57. Conteúdo do arquivo /etc/shadow ................................................................................... 101 Figura 58. John The Ripper quebra a senha do usuário ―root‖ ........................................................ 102
Figura 59. Acesso do usuário ―root‖ ................................................................................................ 102 Figura 60. NMap varrendo a rede 192.168.2.1-255 ......................................................................... 103
Figura 61. Máquinas ativas reconhecidas pela varredura do NMap ................................................ 104 Figura 62. Varredura especifica nos IPs finais 100 e 101 ................................................................ 105 Figura 63. Resultado da análise do Nessus ...................................................................................... 106 Figura 64. Vulnerabilidades de alto risco encontradas pelo Nessus ................................................ 106
Figura 65. Lista de e-mails da empresa fictícia ................................................................................ 107 Figura 66. Página com documentos internos ................................................................................... 108
Figura 67. JBroFuzz testando diretórios web pessoais .................................................................... 109 Figura 68. Diretórios encontrados pelo JBroFuzz ............................................................................ 109 Figura 69. Nikto encontra diretório oculto .ssh ................................................................................ 110
Figura 70. Diretório ―.ssh‖ do usuário contendo chaves públicas ................................................... 111 Figura 71. Configurações de chaves públicas e acesso remoto ao sistema ...................................... 112
Figura 72. Conteúdo do arquivo /etc/passwd ................................................................................... 113 Figura 73. Conteúdo do arquivo /etc/group ..................................................................................... 113 Figura 74. Email enviado com senha em texto plano ...................................................................... 115
Figura 75. Mensagem de e-mail automática de lembrete de senha do usuário "pirrip" ................... 115 Figura 76. Arquivo /etc/shadow alterado ......................................................................................... 116
Figura 77. Acesso com usuário ―root‖ obtido .................................................................................. 117
Figura 78 – Fluxograma: Identificação de Vulnerabilidades ........................................................... 118 Figura 79 - Fluxograma: Verificação e exploração de Vulnerabilidades ......................................... 119 Figura 80 - Fluxograma: Obter acesso privilegiado ao sistema ....................................................... 120
ix
LISTA DE TABELAS
Tabela 1. Atividade maliciosa por país .............................................................................................. 31
x
RESUMO
SCHWADE JUNIOR, Odilo. Roteiro para realização de testes de penetração em cenários turn-
keys. Itajaí, 2010. 117 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–
Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2010.
O crescente aumento em incidentes reportados do mundo digital é considerado significativo com a
dependência que o uso de tecnologias traz a todos seus usuários. As atividades rotineiras são cada
vez mais realizadas com o uso de sistemas e da Internet. Os hackers utilizam o avanço das
tecnologias e da sua dependência para sofisticar seus métodos para acesso não autorizado a
informações. Estratégias de negócio estão em jogo, à confiança de um usuário ou de um cliente.
Diferentes tipos de ataques continuam a surgir e seus métodos de execução se tornam mais
aprimorados. Os profissionais que pretendem manter as premissas da segurança de informações
utilizam técnicas para tentar sustentar seus ambientes tecnológicos livres de ameaças, porem sempre
convivemos com o risco de comprometimento pelo ataque de um hacker. Este trabalho é demonstra
as etapas de execução de um teste que pode analisar as vulnerabilidades e ameaças que um
ambiente pode conter. Através do teste de penetração, um administrador de sistemas consegue
buscar por falhas em sua rede de computadores ou sistema computacional e propor uma solução
para que não seja vitima de um ataque e prejudique as informações armazenadas e transmitidas.
Palavras-chave: Teste de penetração. Segurança de informações. Hacker ético.
xi
ABSTRACT
The numbers of reported incidents on the cyber-world have been increased considering the
dependency of the use of technology by all the users. The daily activities are more often realized
using systems and the internet. Hackers use the evolution of technology and it dependency to
sophisticate the methods to gain unauthorized access to information. Business strategies and
costumer trust are compromised. Different kinds of attacks have been shown and the
implementation method becomes more refined. Professionals who try to keep the information
security using techniques to keep his technological environment free from threats, but there will be
always risks posed by hackers. This project demonstrate the phases to running a test that can
analyze the vulnerabilities and threats that an environment can contain. With the penetration
testing a System Administrator can look deeper for flaws in his network or information system and
find a solution to not become the next victim of an attacker that can compromise the information
stored and transmitted on his infrastructure.
.
Keywords: Penetration Testing. Information Security. Ethical Hacker.
1 INTRODUÇÃO
A necessidade por segurança de informações é almejada em todos os sistemas
computacionais. A tendência de interconexão entre sistemas e a dependência do uso da Internet
como meio de transporte acabam por expor as informações a inúmeras ameaças, como o roubo,
invasão e a danificação dos dados. Quanto mais valiosa é uma informação, mais atraente ela passa a
ser para o hacker mal intencionado.
Segundo estatísticas os incidentes de varredura de portas, recusa de serviços, invasão por
worms e por ataques automatizados praticamente dobram a cada ano desde 1999. No ano passado,
mais de 358 mil tentativas de ataques foram registradas (CERT.br, 2010).
Figura 1. Total de incidentes reportados ao CERT.br por ano
Fonte: Adaptado de CERT.br (2010)
Este cenário deixa evidente a necessidade de se empregar práticas para evitar que eventuais
falhas nos componentes de redes, sistemas e comportamento pessoal comprometam a inteireza das
informações hospedadas nas infra-estruturas de computação.
Foram definidas cinco propriedades que devem ser observadas no trato de informações
(LANDWEHR, 2001):
Confidencialidade: garantir que a informação digital está protegida e não pode ser acessada
sem autenticação adequada;
3107 5997 1230125092
5460775722 68000
197892
160080
222528
358343
0
50000
100000
150000
200000
250000
300000
350000
400000
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
Incidentes
13
Integridade: garantir que a informação digital não pode ser modificada sem autenticação
adequada;
Disponibilidade: garantir que a informação digital está disponível e acessível aos usuários
legítimos sempre que necessário;
Autenticação: garantir que o indivíduo é quem ele afirma ser; e
Não repúdio: garantir que um terceiro independente registrou a ocorrência de uma transação
ou evento.
Existem diversas formas de colocar a segurança de informações em prática. A montagem de
firewalls é interessante no bloqueio das conexões indesejadas entre uma rede de computadores e o
enlace de acesso à Internet. Os antivírus objetivam evitar danos aos sistemas operacionais e
documentos de trabalho dos computadores. Os sistemas de detecção de intrusões alertam quando
uma atividade suspeita é detectada. Os potes de mel (do inglês: honeypots) oferecem sistemas
simulados, propositalmente inseguros, para que seja possível observar o comportamento de um
atacante frente ao sucesso de uma invasão. Por fim, a política de segurança é o instrumento
gerencial que formaliza como deve ser o comportamento humano dos colaboradores de uma
organização quando manipulam informações em sua rotina de trabalho.
Cada uma destas ferramentas de segurança cumpre com uma ou mais propriedades da
segurança de informações. Por exemplo, o detector de intrusões tenta evitar violações da premissa
de disponibilidade quando alerta o administrador de que uma tentativa de ataque de recusa de
serviços está iniciando, ou ainda, o antivírus impede violação da premissa de integridade quando
detecta a atividade de um vírus de macro em um documento do editor de textos.
Uma prática mais recente que vem se tornando comum para os administradores de rede é o
teste de penetração (do inglês: penetration test, ou abreviadamente pentest, pentesting). O pentest
consiste em uma série de testes realizados pelo administrador de redes com o objetivo de tentar
invadir seus próprios sistemas em busca das mesmas falhas que um intruso exploraria.
Um teste de penetração pode ser considerado bom se ele consegue desvendar falhas em um
sistema antes que um intruso realmente mal intencionado obtenha sucesso. O roteiro de pentesting
pretende guiar a execução de um teste de penetração em cenários pré-programados, conhecidos por
turn-keys. A técnica de pentest alinhada com a infra-estrutura de uma organização pode contribuir
indiretamente para a preservação de todas as cinco premissas de segurança de informações.
14
1.1 PROBLEMATIZAÇÃO
A demonstração do cenário atual do uso de tecnologias faz com que os usuários dependentes
motivem-se a preocupar-se com a segurança das informações transmitidas nas redes e sistemas de
computadores.
Com opção de testes de penetração em sistemas, o administrador de redes é capaz de utilizar
técnicas para encontrar um foco de ameaça antes que um intruso mal intencionado seja capaz de
realizar um ataque. Este projeto propõe um roteiro para realização de testes de penetração para
compreender o funcionamento da técnica em ambientes vulneráveis. O pentesting alinhado com as
praticas de segurança de infra-estrutura tornam os ambientes tecnológicos capazes de suportar
incidentes causados por um atacante.
1.1.1 Formulação do Problema
Os sistemas e redes computacionais são cada vez mais importantes para o armazenamento,
processamento e transmissão das informações. A maioria das atividades profissionais é realizada
através do trabalho em documentos contendo estratégias ou informações de clientes, por exemplo.
Extratos bancários são visualizados em computadores pessoais conectados a internet. A
dependência ilustrada nestes eventos requer cuidados com as informações, afinal não é desejado que
um intruso, sem autorização, visualize movimentações financeiras ou estratégias de um negócio.
Para verificar falhas, há a estratégia de se testar a infra-estrutura em busca de
vulnerabilidades que possam ser utilizadas para realização dos ataques e reconhecer se ela é capaz
de servir de meio para uma invasão. A técnica chamada de pentesting é conhecida por conseguir
demonstrar aonde uma vulnerabilidade pode se tornar uma ameaça.
Para obter sucesso, o administrador de redes precisa conhecer os diferentes métodos para se
executar um pentest e como ele se comporta nos ambientes de TI. Cada infra-estrutura e sistema
computacional têm suas particularidades, assim é necessário compreender as técnicas que são
utilizadas para poder prever as maneiras que um atacante poderia explorar uma falha e adequá-las a
cada ambiente.
15
1.1.2 Solução Proposta
A proposta deste projeto é estudar as etapas para execução de um teste de penetração e como
estes se comportam nos ambientes tecnológicos. A definição do roteiro terá base nas principais
ameaças e vulnerabilidades encontradas em sistemas computacionais simulados por cenários turn-
keys. Este projeto também pretende ter fins didáticos para administradores de redes e pesquisadores
da área de segurança de informação.
1.2 OBJETIVOS
Os objetivos deste trabalho serão atingidos através do cumprimento de um objetivo geral e
cinco objetivos específicos.
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é elaborar um roteiro para a realização de testes de
penetração em redes de computadores e sistemas computacionais baseado em cenários turn-keys.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
1. Pesquisar e realizar uma revisão bibliográfica sobre a área de segurança de informações em
geral e a de testes de penetração em específico.
2. Identificar as vulnerabilidades que ameaçam as redes de computadores e sistemas
computacionais.
3. Elaborar um roteiro dos testes de penetração.
4. Testar a aderência do roteiro de testes em cenários turn-keys.
5. Documentar o trabalho de conclusão de curso e divulgar os resultados obtidos através de um
artigo científico.
O cumprimento dos objetivos específicos propostos deve permitir que o objetivo geral seja
alcançado com extrema satisfação, tornando a realização deste trabalho de pesquisa uma fonte de
consulta para administradores de redes, acadêmicos, professores e comunidade de tecnologia em
geral.
16
1.3 Metodologia
Para que os objetivos deste projeto sejam alcançados, opta-se pela realização de um
levantamento bibliográfico sobre os conceitos de Segurança de Informações, a fim de se identificar
os tipos de ameaças e vulnerabilidades que uma rede de computadores ou sistema computacional
pode conter. Também se faz necessário um estudo dos tipos de ataques e dos perfis de indivíduos
que os realizam.
Um estudo estatístico de vulnerabilidades foi proposto para identificar os focos de incidentes
recentes, compreendendo ainda mais as novas ameaças aos ambientes tecnológicos.
O estudo do teste de penetração terá papel fundamental para, posteriormente, desenvolver
um roteiro que será aplicado a cenários turn-keys simulando sistemas reais vulneráveis, permitindo
a observação da exploração de uma vulnerabilidade como um intruso mal intencionado faria,
comprometendo as informações de uma organização.
1.4 Estrutura do trabalho
Esta pesquisa está dividida em 5 partes: Introdução, Fundamentação Teórica, Projeto,
Desenvolvimento do Roteiro de Teste de Penetração e Conclusões. Na Introdução são abordados
brevemente os conceitos de segurança de informações, uma amostra dos incidentes digitais
reportados ao comitê gestor da internet no Brasil e brevemente os objetivos de um teste de
penetração e deste projeto.
A Fundamentação Teórica aprofunda os conceitos de segurança de informações. Expõe os
perfis dos atacantes e dos principais ataques além de uma estatística dos principais incidentes
reportados por entidades de segurança digital. Os conceitos de um pentesting são abordados para
posterior definição de um roteiro. Na parte de Projeto são demonstrados os cenários turn-keys e
determinado as etapas de roteiro para realização de um teste de penetração, como e onde este será
aplicado.
Na parte de Desenvolvimento do roteiro de teste de penetração, foi realizada a análise dos
roteiros gerados para cada cenário turn-key e gerado um fluxograma e um roteiro de similaridades
de ações realizadas, gerando por fim um roteiro genérico. Na parte de Conclusões, foram expostas
as considerações finais a respeito do trabalho e recomendações para trabalhos futuros.
17
2 FUNDAMENTAÇÃO TEÓRICA
A tecnologia da informação transformou a rotina de trabalho das pessoas de tal forma que
seu uso tornou-se imprescindível mesmo para realização das tarefas mais triviais. Utilizando os
recursos que a computação proporciona, a simplicidade de utilização dos sistemas e a comodidade
de realizar algumas tarefas tornam a tecnologia uma dependência.
Com a dependência tecnológica, são armazenadas nos recursos computacionais informações
pessoais, confidenciais que requerem certo cuidado. Indivíduos passam seus dias buscando acessar
essas informações confidenciais sem permissão, muitas vezes por curiosidade, mas também para
ganhos financeiros. Esta dependência tecnológica faz emergir uma das principais preocupações
naturais do homem: a sua segurança (BORTOLUZZI, 2004).
Esta é a abordagem da revisão, aprofundando-se na subárea de penetration testing.
Demonstrando as ameaças à segurança, técnicas já utilizadas para conter essas ameaças e por fim
como utilizar as técnicas de pentesting para testar as vulnerabilidades que possam ser exploradas
por um hacker mal intencionado.
2.1 Segurança de Informações
Segundo a International Organization for Standardization (ISO, 2005) a informação é um
ativo importante, é essencial para os negócios de uma organização e, como conseqüência, necessita
ser adequadamente protegida. Com os sistemas cada vez mais interconectados, as informações são
expostas a uma grande variedade de ameaças e vulnerabilidades.
Um sistema é definido como seguro quando as informações que ele armazena e transporta
são acessíveis por todas as pessoas que possuem autorização para tal. Já se o usuário consegue
alterar um sistema para que ele permita acessos que deveriam ser negados, então este sistema é
denominado inseguro (BISHOP, 2003).
A segurança de informações é baseada em três principais premissas (LEHTINEN, 2006):
Confidencialidade;
Integridade; e
Disponibilidade.
18
Os dados são considerados confiáveis se eles são mantidos de forma obscura para todos, mas
pessoas autorizadas conseguem acessá-los. Dados tem integridade quando permanecem idênticos
aos seus estados quando o ultimo usuário autorizado a manuseá-los, parou de utilizá-los. São
considerados disponíveis quando são acessíveis a usuários autorizados quando desejado
(LEHTINEN, 2006).
2.1.1 Confidencialidade
Um sistema seguro é aquele que não autoriza que a informação seja exposta para aqueles
que não têm acesso autorizado a esta (LEHTINEN, 2006). A necessidade de manter a informação
como segredo vem do uso de computadores em áreas de risco como no governo ou empresas
(BISHOP, 2002). Pode-se exemplificar esta afirmação fazendo uma analogia com o que acontece
no exército, onde somente alguns cargos de alta patente têm acesso a informações privilegiadas,
como coronéis e generais, diferente de soldados que possuem um cargo de baixa patente que não os
qualifica para o acesso a tais informações. Também, no mundo dos negócios, empresas guardam
suas informações como estratégias de negócio ou dados de clientes, pretendendo que estas não
sejam acessadas por quem não tem autorização, arriscando-se a danos em sua reputação e até
prejuízos financeiros.
Outra preocupação com a confidencialidade é a proteção do fluxo de tráfego contra a
análise. Isto faz que um intruso não consiga observar a origem e o destino, a freqüência, o tamanho
e outras características do tráfego em um sistema de comunicação (STALLINGS, 2008). Um
atacante não deve ser capaz de interceptar uma mensagem e lê-la (ZWICKY, 2000).
2.1.2 Integridade
Um sistema computacional seguro deve preservar continuamente a integridade das
informações mantidas nele. Isto significa que o sistema não deve permitir a corrupção das
informações ou o acesso não autorizado a estas, seja ele por má intenção ou acidentalmente,
expondo-as a modificações (LEHTINEN, 2006).
Esta premissa visa assegurar também a veracidade dos dados (o conteúdo da informação) e a
integridade da origem (a fonte dos dados, também chamada de autenticação). A fonte da informação
deve sustentar sua precisão na credibilidade e na confiança que as pessoas colocam na informação
(BISHOP, 2002).
19
Os mecanismos de integridade são divididos em duas classes (BISHOP, 2002):
Mecanismos de prevenção: procuram manter a integridade das informações,
bloqueando as tentativas não autorizadas de alterar os dados ou qualquer tentativa de
modificação não autorizada as informações.
Mecanismos de detecção: não tentam prever violações de integridade, mas sim
reportar que a integridade dos dados já não é mais confiável. Normalmente analisam
eventos do sistema (ações de usuários ou sistemas) tentando detectar anomalias.
A diferença entre os dois mecanismos é que enquanto o mecanismo de prevenção procura
bloquear modificações das informações, o mecanismo de detecção serve como informante ao
administrador de redes ao detectar alguma ação irregular nas informações.
2.1.3 Disponibilidade
Disponibilidade refere-se à capacidade de utilizar as informações ou os recursos desejados
(BISHOP, 2002). Um sistema de computação deve manter a informação disponível para os
usuários, isto significa que, desde o hardware até o software, deve ser mantido trabalhando de forma
eficiente e que o sistema seja capaz de recuperar-se rapidamente e completamente se algum desastre
ocorrer (LEHTINEN, 2006).
O principal aspecto da disponibilidade para a segurança é que algum individuo pode
deliberadamente negar o acesso aos dados ou a um serviço, tornando-o indisponível (BISHOP,
2002). Isto fica bem visível quanto à recusa de serviço (do inglês, Denial of Service,
abreviadamente DoS), onde massivos envios de pacotes podem desabilitar um serviço, como por
exemplo um servidor web. Os ataques de DoS serão descritos adiante.
Disponibilidade é também um aspecto de confiabilidade, bem como do projeto do sistema
computacional, pois um sistema indisponível é tão ruim como não ter um sistema (BISHOP, 2002).
2.1.4 Alvos de proteção
Estar seguro é estar livre de ameaças (LANDWEHR, 2001). Para manter a segurança das
nossas informações devemos ter em mente o que devemos proteger. Quando se está conectado a
internet coloca-se três objetos em risco (ZWICKY, 2000):
20
Dados: A informação contida nos computadores;
Recursos: os computadores e seus poderes de processamento ou armazenamento,
largura de banda, etc.; e
Reputação.
Como abordado anteriormente, é habitual usuários manterem várias informações em seus
computadores pessoais ou que utilizam para trabalho. É possível entender que se um invasor obtiver
sucesso em um ataque a uma dessas máquinas, as informações contidas nesses computadores
estarão comprometidas. Essas informações podem ser secretas, como por exemplo, planos de
negócio de uma empresa, o que pode trazer um alto risco ao cair nas mãos de pessoas indesejadas.
As pessoas tendem a focar sobre os riscos associados a segredos, e é verdade, pois esses geralmente
são os altos riscos (ZWICKY, 2000).
Os servidores de banco de dados são serviços que armazenam as informações em uma infra-
estrutura tecnológica, considerado assim um alvo atrativo para atacantes. Ao obter acesso
privilegiado, um intruso é capaz de manipular as estrutura de dados para encontrar as informações
que está em busca.
Se um atacante tem acesso privilegiado dentro da rede de trabalho local de uma empresa, ele
naturalmente está em uma posição muito mais vantajosa para seus ataques. Pode realizar varreduras
na velocidade do barramento local, pode tentar autenticar-se através de força bruta e muitas vezes
obtêm acesso a portas de conexão que de outro modo estariam filtradas por um firewall.
Mesmo se as informações não forem secretas, haverá conseqüências caso sejam destruídas
ou modificadas, e o custo poderá ser maior do que o suportável. Mas o mais grave é a perda de
confiança dos utilizadores, do cliente ou de um investidor nos seus sistemas e dados e,
conseqüentemente, a perda de confiança em sua organização, afetando sua reputação (ZWICKY,
2000).
Dependendo do negócio da organização, o acesso não autorizado as informações pode trazer
várias conseqüências, incluindo altos custos para recuperação de um dado modificado, perdas de
clientes e em últimos casos o fim da mesma. Como será descrito adiante, a motivação do intruso
para realização do ataque, pode ser objetivada pelo conteúdo da informação que este busca.
21
2.1.5 Ameaças
Uma vulnerabilidade é um ponto onde o sistema é suscetível a ataque já uma ameaça é um
possível perigo ao sistema. Esse perigo pode ser uma pessoa (cracker ou espião), um objeto (uma
peça defeituosa do equipamento), ou um até evento natural (fogo ou enchente) que pode explorar
uma vulnerabilidade dos sistemas (LEHTINEN, 2006).
Uma ameaça é uma potencial violação de segurança. Não é necessário realmente ocorrer
uma violação para que haja uma ameaça. O fato de que a violação poder ocorrer significa que as
ações que poderiam causar essa ocorrência devem ser protegidas (BISHOP, 2002).
A segurança de computadores se preocupa em identificar vulnerabilidades em sistemas e
protegê-las contra as ameaças (LEHTINEN, 2006).
2.1.6 Tipos de atacantes
A classificação dos atacantes é identificada da seguinte forma (ZWICKY, 2000):
Aventureiros: pessoas entediadas que buscam por diversão. Invadem sistemas
pensando que você tem interesse nos dados, ou porque seria divertido usar os
computadores sem ter o acesso autorizado ou até por não terem nada melhor pra
fazer. São curiosos, normalmente não modificam ou comprometem as informações a
qual tiveram acesso;
Vândalos: hackers que invadem sistemas realmente para causar danos. Fazem isso
normalmente pelo prazer de destruir ou até por não gostar dos princípios do alvo e
para demonstrarem seu desgosto por este;
Competidores: atacantes que competem entre si tentando invadir o maior número de
sistemas. Quanto maior for a dificuldade ou a reputação do sistema invadido mais
pontos conseguem. É nesta classificação que entram os conhecidos por script
kiddies, que são iniciantes que utilizam programas escritos por hackers mais
experientes, ainda assim tornam-se ameaças a sistemas considerados inseguros; e
Espiões profissionais: são atacantes que possuem um grande conhecimento,
normalmente maior do que os outros já citados. Tem a capacidade de criar suas
próprias ferramentas para suceder o ataque e o roubo da informação deve acontecer
sem deixar rastros. É raro acontecer à espionagem computacional por conta dos
22
vastos recursos para proteção dos dados, mas um espião profissional pode ser
contratado por uma empresa para conseguir informações de uma concorrente.
É certo que, para cada tipo de atacante existe um nível de proteção adequado. A
problemática está centrada no valor da informação. Quanto mais valiosos forem os dados, mais
hackers estarão interessados em obtê-los e maior será a presença dos espiões profissionais entre
eles. Então, é preciso haver mais e melhores mecanismos de segurança para proteção dessas
informações (BORTOLUZZI, 2004).
Ainda na linguagem do mundo da computação hackers são classificados da seguinte forma
(AMAN, 2006):
Black Hats (traduzido do inglês, Chapeis Pretos): são intrusos que identificam e
exploraram vulnerabilidades nos sistemas e redes de computadores, na maioria das
vezes com intenções maliciosas. Entre eles há dois extremos: script kiddies e
crackers. O cracker é apto a desenvolver ferramentas de invasão ou causadoras de
danos, pois possuem grande conhecimento de informática, enquanto o script kiddie
faz o uso destas ferramentas, geralmente inconscientes de como elas realmente
funcionam e como elas podem afetar um sistema. Desta forma são considerados os
hackers do mal; e
White Hats (traduzido do inglês, Chapeis Brancos): são os hackers do bem, que
usam seus conhecimentos para desenvolver e aplicar novas formas de defesas contra
os ataques dos Black Hats. Enquanto os Black Hats criam novas ferramentas e
técnicas para invasão os White Hats respondem com as formas de bloqueio dos
ataques. É neste grupo que se espera que os administradores de redes e sistemas se
encontrem.
A diferença entre os dois grupos é a permissão (WILHELM, 2010). Enquanto os Black Hats
não possuem permissão para invadir um sistema e o fazem, os White Hats procuram identificar as
vulnerabilidades que seu inimigo pode utilizar para atacar seus ambientes. Nesta simbologia, os
profissionais de pentesting vestem o chapéu branco.
23
2.1.7 Tipos de ataques
O objetivo deste capítulo é expor brevemente os tipos de ataques que ameaçam as infra-
estruturas de TI e os usuários de computadores. Entre eles estão os ataques de negação de serviço,
worms, vírus, trojans, engenharia social e invasão.
Ataques DoS e DDoS
O ataque de negação de serviço (do inglês, denial of service, ou abreviadamente DoS) ou o
ataque de negação de serviço distribuído (do inglês, distributed denial of service, abreviadamente
DDoS) é a tentativa de um hacker impedir usuários legítimos de acessarem um serviço,
normalmente esgotando os recursos do servidor que o hospeda fazendo com que este fique
indisponível para acesso dos usuários. O recurso alvo do ataque pode ser largura de banda,
capacidade de processamento, memória, capacidade de armazenamento em disco ou até a
combinação de todos (MEHMUD; ZNATI, 2009).
Noticias sobre ataques sincronizados contra servidores de grandes empresas da área de TI
mostram que os ataques de DoS podem paralisar os serviços de internet por várias horas. Proteger-
se contra ataques de DoS é muito difícil se um invasor começa seu ataque invadindo vários
computadores desprotegidos em todo o mundo, utilizando-os como computadores zumbis para
executar um ataque sincronizado a um alvo (TÓTH; HORNÁK; TÓTH, 2008). Pode-se notar que
este é um cenário de ataques de negação de serviço distribuído, onde o invasor consegue tomar
posse de diversas máquinas conectadas a internet, infectadas pelo próprio, tornando-as assim parte
de uma rede de zumbis (também conhecidas por botnets) tendo em mãos uma grande quantidade de
recursos para tornar um alvo indisponível.
Os ataques de DoS e DDoS são classificados em três básicas categorias básicas (LEVINE;
KESSLER, 2002):
O primeiro tipo visa tornar os computadores e as redes indisponíveis, limitando os
recursos que são essenciais para que estes possam operar. Recursos que podem ser
capacidade de processamento, memória, largura de banda, acesso a outras redes de
computadores e até recursos ambientais como ar fresco para refrigeração ou energia;
24
O segundo pretende alterar informações de configuração. Isso porque computadores
configurados de modo inadequado ou até com pouca capacidade podem falhar ou
operar de maneira não desejada; e
Por último, os ataques físicos que podem destruir ou alterar os componentes de redes
ou computadores. Para se precaver destes é necessário uma política de segurança
física, para proteção da infra-estrutura de TI.
O primeiro ataque de negação de serviço reportado foi chamado de Email Bombing. Um
usuário recebeu inúmeras mensagens de e-mail esgotando assim a capacidade de armazenamento do
servidor. Além de esgotar o espaço em disco, o ataque pode retardar a entrega de mensagens e
causar sobrecarga no servidor de correio eletrônico, comprometendo a disponibilidade do serviço
para os usuários (LEVINE; KESSLER, 2002).
Outra variação dos ataques de recusa de serviço é o Buffer Overflow, onde um hacker
explora um espaço alocado não verificado em um programa e substitui o código do programa pelo
seu próprio. Quando o programa sobrescrito executa o código alterado provoca o efeito de alteração
do funcionamento do sistema como o atacante pretendia ou causa a finalização do programa,
tornando-o indisponível (DONALDSON, 2002).
Os ataques de negação de serviço são inteiramente destinados a impedir o usuário de utilizar
os seus recursos computacionais (ZWICKY, 2000).
Vírus, Worms e Cavalos de Tróia
Vírus de computadores, programas cavalos de tróia e worms são uma grande preocupação
para os usuários de computadores. Esse tipo de ataque vem custando milhões de dólares por ano
para empresas e instituições governamentais (NEUBAUER; HARRIS, 2002).
Um vírus de computador é um programa que se insere em um ou mais arquivos (programas
hospedeiros) e executa alguma ação maliciosa (BISHOP, 2002). O vírus entra em ação somente
quando o programa hospedeiro é executado (LEHTINEN, 2006).
Os vírus de computadores se espalham pelo sistema infectado, indo da memória pra o disco
rígido ou de um pendrive para a memória e assim por diante. Ele degrada o desempenho do sistema,
além de outros danos que pode causar como, por exemplo, a exclusão de dados (LEHTINEN,
25
2006). O uso de softwares antivírus é uma das maneiras de se precaver contra vírus, mantendo-o
sempre atualizado com o banco de dados do desenvolvedor.
Um vírus de computador infecta outros programas. O worm, uma variante do vírus, é um
programa que se espalha entre diferentes computadores, criando cópias de si mesmo em cada um
(BISHOP, 2002).
O worm é capaz de se propagar automaticamente através de redes, enviando cópias de si
mesmo de computador para computador. Diferente do vírus, o worm não embute cópias de si
mesmo em outros programas ou arquivos e não necessita ser explicitamente executado para se
propagar. Sua propagação se dá através da exploração de vulnerabilidades existentes ou falhas na
configuração de softwares instalados em computadores (CERT, 2006).
Então ao contrário de um vírus, que se anexa a um programa hospedeiro, um worm mantém
a sua independência, e não modifica outros programas. Como um vírus, no entanto, um worm pode
incluir instruções maliciosas que causam dano ou mal, além de qualquer inconveniente que pode
causar com a mobilização dos recursos da rede para que ele se mantenha e reproduza (LEHTINEN,
2006).
Lembrando a mitologia clássica de Homero a obra Ilíada, o programa de código malicioso
Cavalo de Tróia (do inglês, Trojan Horse, ou abreviadamente trojan), é um fragmento de código
escondido dentro de um programa que executa uma ação disfarçadamente (LEHTINEN, 2006).
O trojan é normalmente recebido como um "presente" (por exemplo, cartão virtual, álbum
de fotos, protetor de tela, jogo, etc.), que além de executar funções para as quais foi aparentemente
projetado, também executa outras funções normalmente maliciosas e sem o conhecimento do
usuário (CERT, 2006).
Um trojan inteligente, não vai deixar vestígios de sua presença, pode permanecer por tempo
indefinido em um software confiável e pode até ser programado para se autodestruir antes de ser
detectado (LEHTINEN, 2006).
26
Engenharia Social
O termo ―engenharia social‖ ganhou uma grande atenção na comunidade de TI sendo
conhecido por um processo social/psicológico onde um indivíduo consegue obter informações de
outro individuo sobre uma organização alvo (THORNBURGH, 2004).
A engenharia social pode ser considerada como ―ataque contra pessoas‖ ou a exploração do
fator humano (LAFRANCE, 2004). Tornou-se muito conhecida com o famoso hacker e hoje
consultor de segurança Kevin David Mitnick.
A engenharia social usa a influência e a persuasão para enganar as pessoas e convencê-las de
que o engenheiro social é alguém que na verdade ele não é, ou pela manipulação. Como resultado, o
engenheiro social pode aproveitar-se das pessoas para obter as informações com ou sem o uso da
tecnologia (MITNICK, 2003).
Este ataque é derivado de uma característica humana: a confiança. As pessoas têm tendência
em simpatizar com alguém que alega estar com problemas ou diz ser uma pessoa de confiança, sem
verificar a credibilidade desta informação. Um engenheiro social sabe e prevê que isso o ajuda no
ataque (KEE, 2008).
Este cenário de ataque é também muito visto hoje, nas redes de computadores, com uma
variante chamada phishing. O phishing é uma mensagem não solicitada que se passa por
comunicação de uma instituição conhecida, como um banco, empresa ou site popular, e que procura
induzir usuários ao fornecimento de dados pessoais e financeiros. Inicialmente, este tipo de
mensagem induzia o usuário ao acesso a páginas fraudulentas na Internet. Atualmente, o termo
também se refere à mensagem que induz o usuário à instalação de códigos maliciosos, além da
mensagem que, no próprio conteúdo, apresenta formulários para o preenchimento e envio de dados
pessoais e financeiros (CERT, 2006).
O engenheiro social cria uma mensagem ou página tentando ao máximo se assemelhar ao
remetente forjado, o que faz com que as pessoas confiem no conteúdo. Como pode ser visto na
Figura 2.
27
Figura 2. Tentativa de Phishing tentando passar-se pelo Banco Bradesco
O atacante supõe que o usuário possui uma conta no Banco Bradesco e espera que o usuário
clique no link proposto que o levará para um site falso onde o atacante pretende conseguir
informações sobre a conta da vítima. Para usuários leigos isto é um grande problema, pois um
ataque de phishing pode comprometer o computador utilizado ou até disponibilizar informações
confidenciais para o atacante.
Invasão
Os ataques mais comuns a sistemas são as invasões, com uma invasão o atacante está
habilitado a usar o sistema comprometido se passando pelo usuário legítimo (ZWICKY, 2000). A
invasão é um ataque bem sucedido que resulte no acesso, manipulação ou destruição de
informações em um computador (CERT, 2006).
Existe três tipos principais de um atacante conseguir invadir um sistema (WILSON, 2001):
Invasão física: quando um atacante tem acesso físico ao sistema. Podendo utilizar
técnicas para se tornar administrador do sistema ou até desmontar o computador
para, por exemplo, obter acesso aos arquivos do disco rígido através de outro
computador.
28
Invasão de sistemas: também conhecido como escalonamento de privilégios, quando
o usuário possui uma conta no sistema e utiliza técnicas para se tornar administrador.
Se o sistema não se mantém atualizado, há uma grande chance de um atacante
utilizar uma falha conhecida para conseguir privilégios adicionais de administrador
em sua conta.
Invasão remota: consiste em um atacante invadir o sistema remotamente através da
internet, normalmente o invasor começa sem privilégios especiais. Um Sistema
Detector de Intrusões tem sua principal preocupação com esse tipo de ataque.
Os invasores podem utilizar desde ataques de engenharia social, simples adivinhação (tentar
nome de usuários e senhas até encontrar o correto), ou até utilizando de falhas de softwares para
conseguir acesso sem precisar de credenciais (ZWICKY, 2000).
2.1.8 Formas de prevenção de ataques
Os administradores de redes e sistemas computacionais utilizam várias técnicas para
prevenção de incidentes em seus ambientes tecnológicos. Os Sistemas de Detecção de Intrusão (do
inglês Instrusion Detection System, abreviadamente IDS) contêm regras que detectam anomalias em
sistemas e alertam o administrador de sistemas. O firewall é um serviço que, também através de
regras, consegue bloquear conexões indesejadas.
As políticas de segurança são documentos que pretendem fornecer direção e apoio
gerenciais para a segurança de informações. Divulgada a todos os colaboradores uma política de
segurança deve declarar o comprometimento da gerência e estabelecer a abordagem da organização
quanto à gestão da segurança de informações (ISO, 2005).
Sistemas detectores de intrusão
Sistemas detectores de intrusão são aplicações distribuídas que analisam eventos em uma
rede para identificar anomalias (KEMMERER, 2005). Os IDSs devem ser precisos, adaptáveis e
extensíveis (LEE; STOLFO, 2000).
Quando um IDS é devidamente implantado, ele pode fornecer alertas indicando que um
sistema está sob ataque, mesmo se aquele sistema não está vulnerável para aquele ataque específico
29
(MCHUGH; CHRISTIE; ALLEN, 2000). Estes alertas podem ajudar a propor soluções para
resistência de um tipo de ataque.
Um IDS ainda pode servir para testar a configuração de outros mecanismos de segurança
como o um firewall (MCHUGH; CHRISTIE; ALLEN, 2000).
Firewall
Nas redes computacionais, os firewalls atuam como a linha de frente na defesa contra
trafego malicioso e indesejado (SALAH, SATTAR, et al., 2009). O firewall é um componente ou
um conjunto de componentes que restringe o acesso entre uma rede protegida e a internet ou entre
outros conjuntos de redes (ZWICKY, 2000).
Segundo Cheswick (2005), firewall é uma coleção de componentes colocados entre duas
redes que, atuando em conjunto, possui as seguintes propriedades:
Todo tráfego de dentro para fora e vice-versa deve passar através do firewall;
Apenas o tráfego autorizado, como os definidos pela política de segurança local,
terão permissão para passar; e
O firewall deverá ser imune a penetração.
Isso faz com que o firewall seja o limitador entre uma rede outra, principalmente entre uma
rede local e a Internet. Entretanto um firewall não pode proteger a rede de computadores das
seguintes situações (BORTOLUZZI, 2004):
Funcionários mal intencionados, pois o firewall não é ponto de choque em conexões
com origem e destino na própria LAN;
Novas ameaças: uma vez que a configuração do firewall é estática, novas ameaças
irão requerer novas filtragens e até que isso aconteça, outros mecanismos devem
suprir tal deficiência; e
Vírus e conteúdo da camada de aplicação: o firewall se restringe à análise do
endereço IP e das portas lógicas, ele não pode impedir o alastramento de vírus e
similares.
30
O firewall examina as requisições a rede e decide se pode ser feita através de testes baseados
em regras. Se a requisição pode ser aceita, ela é feita, caso contrário é recusada (STAMP, 2006). Os
sistemas de firewalls são comuns em infra-estruturas de redes, seu uso por administradores de redes
faz com que apenas tráfego autorizado seja transmitido. Entretanto, outra ferramenta utilizada para
manter a segurança das informações é a política de segurança.
Políticas de segurança
A principal finalidade de uma política de segurança é estabelecer uma direção, uma teoria
que uma organização quer alcançar que pode ser discutida em documentos de diferentes
quantidades de legibilidade (ZWICKY, 2000).
Deve ser estabelecida uma política clara, alinhada com os objetivos do negócio e que
demonstre apoio e comprometimento com a segurança da informação por meio da publicação e
manutenção de uma política de segurança da informação para toda a organização (ISO, 2005).
Uma política de segurança deve basicamente conter (ZWICKY, 2000):
Explicações: deve ser explicita e compreensiva sobre o porquê estas decisões estão
sendo tomadas;
Responsabilidades: deve definir as expectativas e responsabilidades de todos os
colaboradores;
Linguagem casual: importante que a política seja escrita de forma amigável e
compreensível;
Autoridade: deve especificar quem tem autoridade para tomar uma decisão ou fazer
uma indicação;
Prever exceções: uma política pode não cobrir um evento futuro, portanto deve se
especificar as ações que serão tomadas para uma exceção;
Previsão de revisões: podem ocorrer mudanças na organização a qual a política não
abrange, sendo necessária uma revisão; e
Questões específicas de segurança: quem tem direito de acesso, como pode perder e
ganhar direito a acesso, como os dados financeiros serão protegidos, qual o método
para conter vírus em computadores pessoais, entre outros.
31
2.2 Estatísticas
O crescimento do acesso a Internet e da tecnologia trás um número elevado de incidentes no
mundo inteiro. Os kits de ferramentas dos criminosos estão evoluindo rapidamente para utilizar
novas tecnologias que aumentam a sofisticação do ataque — deixando até mesmo os usuários mais
experientes alheios aos riscos (MCAFEE, 2010).
O relatório de atividades maliciosas de Symantec (2010) demonstra que muitas dessas
atividades estão no nível de aplicação, passando de arquivos PDF infectados até vulnerabilidades
encontradas em browsers. O relatório foi baseado em sistemas de segurança mantidos pela empresa.
As informações dos países com maiores atividades maliciosas são baseadas em ataques
identificados por IDSs, IPSs ou firewalls. A Tabela 1 foi criada a partir de métricas de análise de
atividades maliciosas por país, ataques baseados na web, países de origem dos ataques baseados na
web, violação de dados que poderiam levar ao roubo de identidade por setor, violação de dados que
poderiam levar ao roubo de identidade por causa, computadores infectados por bots e ameaça de
atividade (proteção e mitigação).
Tabela 1. Atividade maliciosa por país
Ranking Global
País
Porcentagem Rank de atividades 2009
2009 2008 2009 2008 Código
Malicioso Zumbis de
Spam Hospedeiros
de Phising Bots
Origem de
ataques 1 1 USA 19% 23% 1 6 1 1 1 2 2 China 8% 9% 3 8 6 2 2 3 5 Brasil 6% 4% 5 1 12 3 6 4 3 Alemanha 5% 6% 21 7 2 5 3 5 11 Índia 4% 3% 2 3 21 20 18 6 4 Reino Unido 3% 5% 4 19 7 14 4 7 12 Rússia 3% 2% 12 2 5 19 10 8 10 Polônia 3% 3% 23 4 8 8 17 9 7 Itália 3% 3% 16 9 18 6 8
10 6 Espanha 3% 4% 14 11 11 7 9
Fonte: Adaptado de Symantec (2010).
Identifica-se que os Estados Unidos e a China mantêm-se no topo da tabela. São
considerados os países com mais atividades maliciosas no mundo. O Brasil passou da quinta
posição para a terceira. Isto ocorre pelo fato do crescimento da infra-estrutura de internet e do uso
de banda larga no país. Mas outro fato possível foi o worm Downadup (também conhecido como
32
Conficker), que infectou um grande numero de computadores no mundo inteiro no final de 2008 e
inicio de 2009, o Brasil foi considerado um dos mais afetados pelo worm (SYMANTEC, 2010).
Outro fator que elevou a posição do Brasil é que o país é uma grande fonte de códigos
maliciosos que roubam informações bancárias, os programas que tiveram mais sucesso continuam
ativos e fazendo o papel para qual foram projetados (SYMANTEC, 2010).
Até março desse ano, foram reportados ao CERT.br (2010) mais de 28 mil incidentes, a
maioria varreduras (do inglês, scan), que são utilizadas por hackers para identificar potenciais
alvos. Com as técnicas de scan um atacante consegue identificar os serviços habilitados em um
computador e com isso tem a possibilidade de ligar uma vulnerabilidade a este serviço para uma
tentativa de ataque (CERT, 2006). As portas mais atingidas são à porta 22, do protocolo SSH, e a
porta 25 do protocolo SNMP (CERT.br, 2010).
Segundo Symantec (2010), na América Latina o Brasil foi o país ficou com a liderança do
grupo de computadores infectados por bots (computador que compõe uma botnet) com 54% do
total. O Brasil também foi considerado pela empresa de segurança Kaspersky como um país ―rico‖
em trojans que roubam informações bancárias, tendo uma complexa forma de ataque que rouba
dados de sites de redes sociais, incapacita ações do software antivírus e por fim, monitora atividades
em sites bancários colhendo dados necessários para o atacante (BESTUZHEV, 2009).
Os ataques de DDoS também mostram seus efeitos, em Julho do ano passado, diversos sites
do governo americano foram alvos e ficaram indisponíveis (GOODIN, 2009). Também no final de
2009 grandes empresas americanas como a Amazon e a Wal-Mart, entre outras, foram vitimas de
ataques de recusa de serviço tendo seus sites e serviços indisponíveis dois dias antes do Natal, um
período de muitos acessos nos sites das vitimas (KRAZIT, 2009).
O Instituto SANS registra anualmente uma lista das principais vulnerabilidades em sistemas.
No ano de 2009 a empresa Microsoft foi responsável pela grande maioria, a maior parte encontrada
em programas do pacote Office. A Adobe também participa da lista, com várias vulnerabilidades
em softwares como o Adobe Acrobat e Adobe Reader. Muitas vulnerabilidades também foram
encontradas no Java da Oracle, que completa a lista (SANS, 2009).
O SANS também lista as principais vulnerabilidades onde o código para exploração é
disponibilizado antes da correção da falha, também conhecido como vulnerabilidade de dia zero (do
33
inglês zero-day vulnerability). A capacidade de execução de códigos remotos pelos atacantes foi
encontrada principalmente em softwares das empresas Microsoft e Adobe (SANS, 2009).
A Symantec (2010) relatou que no ano de 2009 foram registradas 321 vulnerabilidades em
extensões utilizadas em navegadores da internet. Essas extensões permitem que os navegadores
exibam páginas com conteúdo multimídia adicional. Fazem parte o Adobe Reader, Adobe Flash
Player, Apple QuickTime, Microsoft ActiveX, Java SE entre outros. Conforme o gráfico mostrado
na Figura 3 é possível identificar que a maioria das vulnerabilidades foram encontradas na
tecnologia ActiveX, seguida pela Java SE.
Figura 3. Vulnerabilidades em extensões para navegadores web
Fonte: Adaptado de Symantec (2010).
Pode-se observar que as aplicações do lado cliente vêem sendo muito afetadas. Os
incidentes reportados são a maioria de programas utilizados em atividades rotineiras e que podem
carregar uma vasta quantidade de informações. No Brasil, os programas de código malicioso que
roubam informações bancárias tem tido um grande sucesso, este que pode trazer várias
conseqüências a uma vitima.
Do lado servidor, recentemente, a Apache Foundation, responsável pelo servidor web
Apache que contêm 53,84% da utilização mundial segundo o site Netcraft (2010), foi vitima de um
ataque onde o intruso obteve acesso privilegiado a um de seus servidores e acesso limitado a certo
número de senhas que foram comprometidas (APACHE, 2010).
ActiveX43%
Java SE26%
QuickTime8%
Adobe Flash Player7%
Adobe Reader15%
Extensões da Mozilla1%
Vulnerabilidades em extensões para navegadores
34
No final do ano passado, um ataque comprometeu várias contas de serviços de e-mail do
Google, Hotmail e Yahoo. Os usuários e senhas ficaram comprometidos e foi sugerido que os
utilizadores alterassem suas credenciais de autenticação (COMPUTERWORLD, 2009).
O relatório anual de CSI (2009) demonstra que quase 65% dos participantes reportaram
incidentes com malwares. Muitos também foram vitimas de roubos de dispositivos como laptops e
celulares, além de danos causados por colaboradores internos das organizações. Como demonstra a
Figura 4.
Figura 4. Índice de incidentes reportados ao CSI
Fonte: Adaptado de CSI (2009)
Vários dos incidentes reportados são softwares e serviços utilizados no dia-a-dia por
usuários e organizações. A exploração destes recursos por um atacante demonstra que vários
usuários de computadores estão vulneráveis a ataques que vão desde usuários infectados para
utilização de computadores em botnets até para causar danos a empresas. Esses ataques podem ser
previstos por um administrador de redes utilizando técnicas como o pentesting e os usuários podem
tentar proteger-se através da utilização de softwares antivírus atualizados e também a atualização de
seus programas e sistemas operacionais.
64.30%
42.20%
29.70% 29.20%
20% 17.30%
7.60%
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
Infectados por Malware
Roubo de dispositivos
Abusos de colaboradores
internos
DoS Fraudes financeiras
Captura de senhas
Exploração de redes WiFi
Reportaram tipo de incidente
35
2.3 Teste de Penetração
Chamado Penetration Testing ou Ethical hacking a invasão do seu próprio sistema para
observar o quanto seguro ele está. Isto requer uma análise detalhada das ameaças e dos potenciais
invasores a um sistema (BISHOP, 2007).
O pentest é um método para avaliar a segurança dos sistemas de informação de uma
organização simulando um ataque. Seu objetivo é sondar e identificar falhas de segurança em
sistemas de informação, tais como uma aplicação bancária on-line, a rede da infra-estrutura, ou até
mesmo as instalações físicas de uma organização (DANHIEUX; WOUTER, 2006).
O teste deve ser autorizado e agendado. É um processo de utilização de vulnerabilidades
conhecidas para tentativa de invasão de um ambiente. Ele pode ser conduzido internamente, como
na tentativa de acesso físico a organização, ou externamente através da conexão da organização
com a internet (BRADEN, 2003).
Exemplos de uma invasão bem-sucedida seria a obtenção de documentos confidenciais,
listas de preços, dados e informações privilegiadas. O que difere um profissional em pentesting de
um intruso é a permissão. Um pentester terá autorização para executar um teste de penetração
(NORTHCUTT, et al., 2006).
O objetivo principal de um teste de penetração é aumentar a segurança dos recursos
computacionais que estão sendo testados (NORTHCUTT, et al., 2006).
Os testes de penetração podem ser considerados como um projeto dentro de uma
organização. Os projetos de pentesting devem ser desenvolvidos utilizando processos eficazes e
reprodutíveis para introduzir melhorias, cumprir os objetivos de negócio, melhorar a qualidade e
aumentar a rentabilidade (WILHELM, 2010).
A execução de um pentest segundo Wilhelm (2010), baseando-se nas formas de invasão por
hackers, deve passar pelas seguintes fases:
levantamento de informações ou reconhecimento: o primeiro passo para realização
de um pentest e sem dúvida o mais importante. Após a conclusão desta fase o
pentester deve ter um mapa detalhado do alvo e compreender a quantidade de
esforço necessária para conduzir uma avaliação completa;
36
Identificação de vulnerabilidades: esta fase pretende examinar o alvo mais
profundamente do que a primeira, mas serão utilizadas as informações encontradas
previamente para identificar possíveis ameaças e vulnerabilidades no alvo;
Verificação das vulnerabilidades: este passo pretende identificar qual vulnerabilidade
é real buscando ferramentas para explorá-las. É também a fase onde a
vulnerabilidade é explorada;
Obter acesso privilegiado: o objetivo desta fase é passar de uma simples invasão
através da exploração de uma vulnerabilidade para o total comprometimento de uma
rede de computadores ou sistema. A ação a ser feita é passar de um usuário com
ações restritas para um usuário que possui ações privilegiadas no sistema afetado.
Manter acesso: esta etapa preocupa-se com a possibilidade de conservar o privilégio
de acesso ao sistema invadido; e
Limpar as evidências: preocupa-se em não deixar rastros de que uma exploração de
vulnerabilidades aconteceu e o alvo foi comprometido. O objetivo é cobrir todas as
provas de que as fases anteriores foram executadas com sucesso.
Ao se analisar as etapas de execução de um pentesting é possível visualizar que ações um
hacker pode realizar para comprometer um alvo. A maneira com que um pentester executa um teste
de penetração é pretendendo visualizar as maneiras que um atacante usaria para chegar aos seus
objetivos, porém o pentester tem a permissão para realizar esses métodos, diferente do intruso mal
intencionado.
2.3.1 Levantamento de Informações ou Reconhecimento
O reconhecimento do alvo é a primeira etapa para a execução de um teste de penetração.
Com ele o pentester consegue iniciar a compreensão da estrutura do alvo e estudar as diferentes
maneiras para quebrar a segurança e obter acesso a informações. Essa fase pode ser segmentada em
dois tipos diferentes (WILHELM, 2010):
Reconhecimento passivo: o pentester procura por informações do alvo sem conectar-
se diretamente com ele. Normalmente são buscadas informações corporativas.
Incluindo a propriedade, quem e quantos são os colaboradores, a localização do alvo,
37
as plantas físicas da estrutura, entre outros. Dependendo dos objetivos do pentest o
profissional procura as informações necessárias para formular o teste; e
Reconhecimento ativo: destina-se apenas a compreender melhor o alvo e aprimorar
as informações conseguidas com o reconhecimento passivo. Deve-se conectar ao
alvo somente com sistemas e serviços que há permissão explicita para se comunicar.
No reconhecimento passivo o pentester não tem nenhuma comunicação com o alvo. Realiza
pesquisas em sites de busca e analisa as informações retornadas, procura por nomes de funcionários
principalmente de cargos elevados, examina possíveis sites pessoais de colaboradores, entre outros.
No final desta o pentester terá informações que podem ser valiosas sem ao menos ter visitado o alvo
(WILHELM, 2010).
Diferente do anterior, no reconhecimento ativo, o pentester pode utilizar ferramentas para
reconhecimento da infra-estrutura da empresa. Identificar usuários de sistemas, credenciais de
contas de e-mails, versão do servidor DNS, informações que podem carregar vulnerabilidades por
versões desatualizadas, por exemplo (WILHELM, 2010). A engenharia social é muito eficaz e seu
estudo é profundo, fora do escopo deste trabalho.
A atividade de reconhecimento do alvo pode ser feita desde a utilização da ferramenta Ping
até a procura por informações no lixo da organização (técnica conhecida em inglês como Dumpster
Diving) (TILLER, 2005).
Diversas informações podem ser resgatadas com a utilização de sites de busca, sites que
guardam versões anteriores de paginas como Archive.org (2010) e informações estatísticas que
podem ser encontradas em sites como Netcraft.com (2010). Além de outras ferramentas como o
nslookup, por exemplo, para busca informações do DNS de sites, comum em sistemas Windows e
Linux (WILHELM, 2010), ferramentas como o whois, traceroute e o Nmap (2010).
Esta etapa não faz uma busca de informações detalhadas, somente um mapeamento da rede e
reconhecimento do alvo, porém nas próximas etapas é possível identificar vários dados como os
serviços que rodam nas redes (WILHELM, 2010).
A maioria das informações que é obtida está disponível gratuitamente e deve ser alcançada
de forma legal. No entanto, muitas organizações monitoram quem tenta obter esses dados, pois isso
pode indicar uma tentativa de ataque (KLEVINSKY; LALIBERTE; GUPTA, 2002).
38
Figura 5. Comando whois no endereço www.univali.br
Fonte: Registro.br (2010)
Como demonstrado na Figura 5, podemos adquirir dados como responsável pela entidade,
servidores DNS e seus respectivos IPs, endereço, telefone, entre outros, simplesmente utilizando
ferramentas disponíveis de forma gratuita e legal, como no exemplo através do site de registro de
domínios para Internet do Brasil.
2.3.2 Identificação de vulnerabilidades
Esta fase é levada de uma forma mais agressiva do que a fase de reconhecimento, agora
interagindo com os sistemas e os elementos de redes para conseguir o máximo de informação
possível (TILLER, 2005). As informações recolhidas nessa fase serão usadas para moldar o ataque,
comunicando-se diretamente com o alvo com a finalidade de identificar possíveis ameaças e
vulnerabilidades. Nesta fase não é feita nenhuma exploração de uma vulnerabilidade (WILHELM,
2010).
Para entender as vulnerabilidades que existem em um alvo, precisamos saber mais detalhes
sobre os sistemas operacionais (abreviadamente, SO) de um servidor, os serviços que estão rodando
39
e as versões de aplicativos. Com isso pode-se fazer buscas em bancos de dados de vulnerabilidades
para determinar se o SO destino pode ser vulnerável a um ataque (WILHELM, 2010).
Devem-se utilizar maneiras para identificação, interagindo com o alvo, que passe através de
firewalls ou roteadores que filtram pacotes. A ferramenta Nmap (2010) contém várias opções que
podem ser usadas para conseguir muitas informações de um sistema, com passagem através de
programas que filtram pacotes (TILLER, 2005), como mostrado na Figura 6.
A varredura de portas (do inglês, Port Scanning) é um dos métodos utilizados para buscar
informações nesta etapa. Quando se realiza uma varredura de portas pretende-se verificar a
existência de um sistema alvo e a obtenção de uma lista de canais de comunicação (portas) que
estão abertas e aceitando conexões (WILHELM, 2010).
A verificação de existência de um sistema alvo pode ser feita utilizando a partir de
testadores como o ping. O Nmap (2010) possui diferentes opções para fazer esta verificação
justamente porque muitas redes bloqueiam o ping e outros utilitários que exploram o protocolo de
rede ICMP. Após identificar atividade do sistema alvo o próximo passo é identificar as portas
abertas, fechadas ou que estão sendo filtradas (WILHELM, 2010).
As varreduras de portas ocorrem na camada de transporte, notadamente nos protocolos UDP
e TCP. A maioria das vulnerabilidades explora falhas no TCP, como em servidores web, bancos de
dados, aplicações para transferência de arquivos, e outros (WILHELM, 2010). O maior exemplo de
uso do UDP é o serviço de DNS. A varredura de portas pode ser feita com diferentes opções da
Figura 6. Opções do Nmap para passar através de Firewall e IDS, entre outros
Fonte: o autor (2010).
40
ferramenta NMap ou da ferramenta Netcat (2010). Ainda há uma lista de várias ferramentas
disponíveis em Sectools.org (2010).
Após obter uma lista de portas abertas a conexão, pode-se tentar descobrir o sistema
operacional que está sendo executado no alvo. A maioria das aplicações que exploram
vulnerabilidades são escritas para sistemas operacionais específicos, o que torna o descobrimento
do SO uma ferramenta essencial para identificar possíveis vulnerabilidades no alvo (WILHELM,
2010). O NMap possui opção para descobrir um sistema operacional, porém nem sempre é possível
chegar ao resultado. O uso de diferentes ferramentas pode se tornar fundamental, como Xprobe2
(2010).
No caso de não obter sucesso ao tentar descobrir um sistema operacional, uma análise dos
serviços ativos na maquina alvo pode identificar pontos que nos levam ao sistema operacional
(WILHELM, 2010). A próxima etapa da identificação de vulnerabilidades é o descobrimento de
serviços que estão rodando no alvo.
Identificando os serviços que estão rodando em um sistema pode-se aprimorar as
informações para reconhecimento de vulnerabilidades, a ferramenta NMap possui opções que
lançam ao alvo requisições para retorno de portas que são normalmente utilizadas por serviços
(WILHELM, 2010).
A Figura 7 demonstra as portas que estão aceitando conexões e os serviços que estão ativos.
É possível também utilizar conexões diretas com as portas encontradas anteriormente e analisar o
que elas retornam quando se é enviado dados aleatórios (WILHELM, 2010).
Figura 7. NMap identificando serviços
41
Após encontrar os serviços ativos no alvo, as portas abertas para conexões e possivelmente o
sistema operacional, deve-se buscar vulnerabilidades conhecidas nas informações que foram
levantadas. Pode-se utilizar bancos de dados de vulnerabilidades como em NVD-US (2010),
SecurityFocus (2010) entre outros. A próxima etapa utilizará as informações conseguidas nesta fase
para realizar os ataques e explorar uma vulnerabilidade.
2.3.3 Verificação de vulnerabilidades
Nesta etapa as informações recolhidas anteriormente servirão de base para efetuar o ataque
ao alvo. Os dados de sistema operacional utilizado e versão do serviço que possa conter uma
vulnerabilidade são de grande ajuda nesta fase. A identificação das vulnerabilidades ajuda os
administradores de redes a melhorar a segurança de seus ambientes de TI e compreender o risco e o
quanto perigoso pode ficar se existir uma forma para explorar essas vulnerabilidades (WILHELM,
2010).
Exploração é identificar a vulnerabilidade e usá-la para ter acesso, obter informações ou
estabelecer uma base para outros ataques (TILLER, 2005). Existem diversos sites que contêm
repositórios de exploits como Inj3ct0r (2010) e The Exploit Database (2010). Pode-se utilizar a
ferramenta de busca dos sites com informações de vulnerabilidades encontradas nas etapas
anteriores para verificação de um programa que a explora (WILHELM, 2010).
Antes de explorar uma vulnerabilidade no alvo aconselha-se que esta seja testada em um
sistema de testes, pois é possível que ocorra problemas com o exploit (programa que explora uma
vulnerabilidade) comprometendo as informações de um sistema. Propõe-se também analisar o
código do programa para maior compreensão (WILHELM, 2010).
Em um ataque um hacker sempre tenta manter-se anônimo, evitando a detecção através de
técnicas especificas para burlar as ferramentas que são utilizadas para detectá-los. Compreendendo
que muitos objetivos e táticas usadas por intrusos devem ser incluídas em um projeto de pentesting
evitar a detecção é altamente recomendável para um pentester (TILLER, 2005).
Existem diversas ferramentas que podem automatizar uma exploração como Metasploit
(2010) que contêm mais de 500 exploits além de 260 módulos auxiliares. Por ser software livre a
ferramenta tem grande possibilidade de ser utilizada para cumprir com o objetivo deste projeto.
42
Outras ferramentas estudadas são de um custo elevado e por tanto não serão estudadas e aplicadas
ao roteiro proposto.
Para explorar vulnerabilidades na web existem vários métodos, como a injeção de códigos
SQL (do inglês, SQL Injection), Cross-site Scripting (também conhecido por XSS), entre outras. No
SQL Injection o atacante executa comandos de banco de dados explorando uma validação
insuficiente do fluxo de dados do usuário para o banco de dados. No XSS o atacante executa código
malicioso no computador da vitima aproveitando-se da validação insuficiente de códigos que
retornam HTML (KIEYZUN, et al., 2009).
Ambos os ataques acontecem por vulnerabilidades na validação de códigos escritos por
programadores. Como já descrito anteriormente, se um atacante obtêm acesso a um banco de dados
pode modificar informações para que consiga novamente este acesso a outro momento, pode
comprometer os negócios de uma empresa, conseguir dados de um cliente, entre outros. O custo
pode ser muito alto.
Ao obter sucesso em um ataque, o acesso ao sistema invadido pode ter sido mantido com
usuários que não tem privilégio para executar diversas funções administrativas. A próxima fase é
passar de uma invasão para o comprometimento total do sistema, obtendo acesso privilegiado.
2.3.4 Obter acesso privilegiado
Se um atacante consegue acesso a um sistema, mesmo que limitado, pode ser capaz de
explorar vulnerabilidades que são acessíveis somente com um usuário autenticado, as defesas
externas são muito maiores quanto às internas (WILHELM, 2010). Se for possível ganhar qualquer
acesso ao sistema, mesmo com o nível de privilégios reduzidos, fica visível o que a capacidade de
comprometer um sistema é muito maior.
Ao conseguir acesso ao sistema através de um exploit, o atacante já está habilitado a buscar
diversas informações que podem ser sigilosas como dados financeiros, estratégias de negócio,
informações de configurações, registros pessoais, etc.. Se um pentester chegar a esta fase, pode-se
considerar o sucesso do teste de penetração (WILHELM, 2010).
Em um sistema invadido, também é possível o conseguir mais informações sobre o sistema,
como versões de serviços que não foram encontradas nas etapas anteriores que podem conter uma
vulnerabilidade (WILHELM, 2010). Conhecidos como Local Exploits e Exploits para
43
escalonamento de privilégios (do inglês, Privilege Escalation Exploit) os programas utilizados após
conseguir acesso a máquina e que exploraram uma vulnerabilidade para conseguir acesso
privilegiado ao sistema (KLEVINSKY, LALIBERTE e GUPTA, 2002).
Utilizando o sistema, um atacante tem acesso a arquivos que contem usuários e senhas. Em
sistemas Unix o arquivo /etc/shadow contém as credenciais de usuários criptografadas. Um atacante
pode utilizar um programa para quebrar a criptografia das senhas, como John The Ripper (2010).
Para conseguir credenciais é possível também a utilização de um monitor e analisador de tráfego
(conhecidos por, sniffers) para capturar requisições que possam ter usuários e senhas
(KLEVINSKY, LALIBERTE e GUPTA, 2002). Um exemplo é Wireshark (2010).
Ao conseguir o acesso privilegiado o atacante tem a capacidade de utilizar o sistema com
um usuário com ações administrativas, podendo ler, escrever e executar operações que podem
comprometer as informações. É possível também, a instalação de ferramentas para manter acesso
ao sistema para um posterior retorno ao ambiente comprometido.
2.3.5 Manter acesso
Se o sistema comprometido é reiniciado ou perder a conectividade com a internet, o acesso
remoto é perdido. Repetir toda a fase de exploração de uma vulnerabilidade pode custar tempo, e
um atacante provavelmente não gostaria de refazer esta etapa e correr o risco de ser detectado
(WILHELM, 2010).
A maioria das invasões começa utilizando a exploração de uma vulnerabilidade para
conseguir acesso privilegiado e instalar um backdoor (em português, ―porta dos fundos‖) para o
atacante poder retornar com muito mais facilidade e sem ser detectado (TILLER, 2005).
O uso de backdoors é comum em um teste de penetração e em uma invasão. Muitas vezes
existe a necessidade de encontrar maneiras para contornar os obstáculos de defesa como firewalls
ou listas de controles de acesso. Um backdoor pode passar por todos esses métodos de defesa,
mantendo o alvo comprometido (WILHELM, 2010).
É possível a configuração para que um programa, como Netcat (2010), fique aguardando por
uma conexão e, quando esta é feita, abra um terminal de linha de comando (conhecido por Shell).
Porém a maioria faz a utilização de uma configuração que faz com que o sistema comprometido
44
inicie uma conexão com o computador do atacante ou do pentester, esta técnica é conhecida por
Reverse Shell (WILHELM, 2010). Porém isto pode ser detectado por um IDS.
Para driblar a detecção por um possível IDS, pode ser feita a configuração de um túnel
criptografado, como demonstra a Figura 8. O Secure Shell (abreviadamente, SSH), comum em
sistemas Unix, é um protocolo que utiliza criptografia para acesso a computadores remotos,
permitindo execução de comandos, transferência de arquivos, entre outros (CERT, 2006).
O túnel SSH permite que seja transferido, para o computador comprometido, malwares e
outros exploits sem ser detectado, pois todo o tráfego entre o sistema de ataque e a vitima é
criptografado (WILHELM, 2010). Existem diversas opções além do SSH de tuneis criptografados,
como Cryptcat (2010) e Proxytunnel (2010).
A utilização de rootkits também é feita por atacantes. Rootkits são programas que contém
uma coleção de ferramentas para ataques. Algoritmos e bases de dados com conhecimentos sobre os
métodos e mecanismos de ataques totalmente automatizados. Com seu uso é possível conseguir
acesso privilegiado, a instalação de vários pacotes desde backdoors até programas que protegem o
sistema contra outros atacantes (KÜHNHAUSER, 2004).
Para explorar com sucesso um sistema completamente, precisamos ser discretos e evitar a
detecção. Nesta fase já foram ultrapassados os mecanismos de defesa, o próximo desafio é não
deixar que um administrador de sistemas detecte a presença no sistema comprometido (WILHELM,
2010).
Figura 8. Tunel SSH sem detecção de mecanismos de defesa
Fonte: Adaptado de Wilhelm (2010).
45
2.3.6 Limpar as evidências
Em um teste de penetração normalmente não é feita a esta etapa, porém os atacantes que
comprometem um sistema e pretendem voltar posteriormente podem utilizar técnicas para cobrir os
rastros de sua presença, um pentesting pode realizar esta etapa pretendendo verificar até que ponto o
hacker consegue chegar (WILHELM, 2010).
Os administradores de redes podem examinar arquivos de logs, instalar aplicativos para
analisar a presença de malwares, configurar programas para monitoração do fluxo de dados ou
verificar os processos buscando alguma anomalia em seus sistemas (WILHELM, 2010).
Existem dois tipos de logs, os gerados pelo sistema e os gerados por aplicações, porem
servem para os dois as mesmas possibilidades. As duas possibilidades para cobrir rastros de logs
são apagar ou editar. Se for apagado, é certo que não terá registros de atividades no sistema, porém
um administrador de redes ainda pode suspeitar. A utilização de logs também é para verificação do
status do sistema ou de uma aplicação, e um log faltante é uma atividade anômala no sistema.
Deixando assim a suspeita da presença (WILHELM, 2010).
Já se a opção for editar os logs, é possível alterar os arquivos que contem os rastros. Uma
vez que já existe o acesso privilegiado ao sistema, há a capacidade de modificação de qualquer
arquivo. Com isto pode-se esconder a presença e a atividade, se assumir que todos os dados
necessários foram modificados (WILHELM, 2010).
Também há a possibilidade de ocultar os arquivos modificados, como por exemplo, o de
configuração do túnel SSH. Alterando o nome ou o diretório pode não evitar a detecção, mas atrasá-
la (WILHELM, 2010).
Uma análise forense também pode ser feita posteriormente e assim detectada a invasão,
porém foge do escopo desta revisão bibliográfica abranger técnicas anti-forense.
3 PROJETO
A fundamentação teórica sobre os conceitos segurança de informações e pentesting
proporcionou a identificação dos objetivos de um intruso ao invadir um sistema e de como é
possível utilizar técnicas para reconhecer uma vulnerabilidade antes que seja explorada. Nesta etapa
deste objeto de pesquisa, foram definidas as diretivas do roteiro para realização de um teste de
penetração em cenários turn-keys.
Portanto, conforme abordado na seção 2.3, um pentesting fornece técnicas e ferramentas
para reconhecer vulnerabilidades antes que um intruso mal intencionado explore-a e comprometa as
informações. Sendo assim, este projeto de pesquisa aplica os conceitos estudados estabelecendo um
roteiro para executar um teste de penetração. Os resultados foram analisados e documentados para
publicação em forma de um artigo cientifico.
3.1 Cenários Turn-keys
Os cenários turn-keys são conhecidos por coleções de pacotes que estão prontos para uso.
Com o surgimento destes cenários é possível aprender as técnicas de pentesting com maior
segurança sem correr o risco de comprometer informações de sistemas e infra-estruturas reais.
A maioria dos cenários foca em um aspecto particular de um pentest, como ataques baseados
na web, ataques a sistemas operacionais Linux, ataques que exploram vulnerabilidades de
aplicações e configurações entre outros. Sendo assim serão utilizados diferentes cenários para
aplicação do roteiro.
Foram encontrados cinco cenários disponíveis:
Damn Vulnerable Linux (2010): distribuição Linux com diversas vulnerabilidades do
sistema operacional;
WebGoat (2010): aplicação web J2EE com vulnerabilidades de aplicações web;
De-ICE.net (2010) PenTest Project: diversos LiveCDs com simulação de servidores
com vulnerabilidades em aplicações e configurações;
pWnOS (2008): várias vulnerabilidades de aplicações e sistema operacional; e
47
Hackerdemia (2007): vulnerabilidades de aplicações, configurações e web.
Vários dos projetos foram descontinuados, mas ainda é possível utilizar as técnicas de
pentesting nos cenários. A execução do roteiro terá prioridade para cenários turn-keys atualizados.
Abaixo são demonstradas algumas imagens dos cenários encontrados, como o Damn Vulnerable
Linux (2010).
A Figura 9 representa a interface do cenário turn-key Damn Vulnerable Linux (2010). Uma
distribuição Linux modificada para estudos de testes de penetração. Contem várias
vulnerabilidades, especialmente do sistema operacional Linux e seus aplicativos.
A Figura 10 demonstra uma etapa de exploração de vulnerabilidades da web no cenário
turn-key WebGoat (2010). O cenário provê o uso de SQL Injection, XSS entre outras técnicas em
aplicações vulneráveis.
Figura 9. Damn Vulnerable Linux
Fonte: Damn Vulnerable Linux (2010)
48
O WebGoat é apresentado em forma de lições baseadas em níveis de dificuldade. Conforme
é obtido sucesso em uma lição, as técnicas começam a ficar mais complexas. O objetivo do cenário
é demonstrar as vulnerabilidades que podem conter em uma aplicação web, que normalmente é
explorada através da não validação do código de programação.
O cenário De-ICE.net (2010) contêm diferentes níveis de vulnerabilidades. São diferentes
LiveCDs divididos entre Nível 1 e Nível 2, onde a cada nível a dificuldade para encontrar formas de
obter acesso privilegiado aumenta.
O cenário PnwOS (2008) foi desenvolvido para começar os desafios desde a ativação do
sistema seu principal demonstrativo é obter acesso privilegiado ao sistema.
Figura 10. WebGoat vulnerabilidades web
Fonte: WebGoat (2010)
49
Baseado na distribuição Linux Ubuntu (2010), o cenário faz com que as habilidades sejam
testadas desde o inicio, como demonstrado na Figura 11, onde não é disponibilizado usuário e senha
para autenticação no sistema.
O projeto Hackerdemia é uma modificação da distribuição Linux Slax (2010) que através de
lições o usuário vai desenvolvendo habilidades em pentesting com vulnerabilidades em aplicações
do sistema Linux.
Figura 11. PnwOS iniciado
Figura 12. Projeto Hackerdemia
50
Como demonstrado na Figura 12, o Hackerdemia oferece uma interface para utilização do
cenário onde encontra-se tutoriais para configuração, algumas informações sobre o projeto e as
lições sobre pentesting.
Diferentes cenários foram utilizados, com diferentes vulnerabilidades. Com o uso de
cenários variados também é possivel compreender a utilização de pentesting para encontrar falhas
em aplicações locais, em vulnerabilidades da web e de más configurações. O objetivo é explorar o
máximo de vulnerabilidades disponiveis em cada cenário, podendo compreender o comportamento,
como o ataque é feito e formas de prevenção. Os cenários escolhidos para realizar os testes foram:
pWnOS;
De-ICE.net (2010) PenTest Project Nível 1; e
De-ICE.net (2010) PenTest Project Nível 2.
As escolhas foram baseadas em cenários que propunham um desafio para invasão. Os
demais cenários, citados anteriormente, proviam diversas informações de como realizar o pentesting
em forma de tutoriais, diferente dos cenários escolhidos onde somente disponibilizavam a
inicialização do sistema operacional e após eram requisitados os dados para autenticação. Com essa
caracteristica, os três cenários escolhidos simulavam verdadeiramente os ambientes em que hackers
tentam comprometer as informações.
3.2 Ambiente de execução
A execução do roteiro ocorreu utilizando recursos próprios. A instalação de cenários foi
realizada em máquinas virtuais utilizando VMware Workstation (2010), como demonstrado no
diagrama da Figura 13.
51
Como demonstrado na Figura 13, o ambiente virtual é composto por uma máquina para ser
alvo e outra para simular o pentester. Na máquina alvo estavam ativos os cenários turn-keys. Na
máquina pentester estava ativo o sistema operacional Backtrack Linux (2010), como mostra na
Figura 14, que contêm diversas ferramentas para realizar um pentesting. Por questões de
desempenho, algumas ações foram realizadas fora do ambiente virtual.
Figura 13. Laboratório de Testes
Fonte: o autor (2010).
52
O Backtrack (2010) é uma distribuição Linux modificada para utilização em testes de
penetração. O pentester tem a sua disposição diversas ferramentas. Como demonstrado na Figura 14
a ferramenta Metasploit (2010). Seu uso será feito pela vasta quantidade de opções e de
documentação do projeto.
Para obter um melhor desempenho, os testes serão realizados utilizando um cenário turn-key
por pentesting. Após recolhimento de dados para análise será utilizada outra máquina virtual com
um cenário diferente.
3.3 Roteiro de Pentesting
Conforme abordado na Seção 2.4, existem algumas etapas para realização de um projeto de
pentesting como o reconhecimento, que pretende recolher informações sem ter contato com o alvo.
Entretanto, como o roteiro proposto será executado em cenários prontos para exploração de
vulnerabilidades, algumas etapas não serão abordadas, mas o uso na execução de um pentesting é
essencial.
Figura 14. Backtrack Linux com a ferramenta Metasploit
53
Foram definidas para o roteiro as seguintes etapas:
Identificação de vulnerabilidades: serão utilizadas ferramentas para varreduras de
porta, identificação de serviços ativos e sistema operacional, entre outros e realizada
uma busca em sites para encontrar vulnerabilidades com as informações adquiridas;
Verificação e exploração das vulnerabilidades: verificar se as vulnerabilidades são
reais buscando seus exploits e realizar os ataques; e
Obter acesso privilegiado: utilizar o acesso ao sistema para tentativa de
escalonamento de privilégio.
Com essas etapas pretende-se compreender como os testes de penetração se comportam nos
cenários propostos para posterior análise e documentação além da geração de um roteiro com
comandos, ferramentas e técnicas para realizar um pentesting.
4 DESENVOLVIMENTO DO ROTEIRO DE TESTES DE
PENETRAÇÃO
A partir das diretivas descritas na Seção 3, os testes de penetração foram realizados nos
cenários turn-keys e documentados. Conforme análise dos resultados foi possível gerar um
fluxograma a partir dos comandos, aplicativos utilizados e decisões tomadas. Também foi gerado
um roteiro genérico baseado nos testes realizados.
Cada pentesting tem suas diferenças se baseando nas características próprias de cada
ambiente, porém alguns comandos e decisões são semelhantes. Com essas semelhanças pode-se
partir do principio que para cumprir as etapas do teste é possível utilizar aplicativos e decisões
similares.
4.1 Fluxograma do Roteiro proposto
O fluxograma passa pelas etapas de pentesting sugeridas para gerar os roteiros. Cada decisão
reflete em uma ação ou contramedida que o pentester pode utilizar para cumprir seus objetivos. O
fluxograma é demonstrado na Figura 15.
54
Ide
ntifica
çã
o d
e V
uln
era
bili
da
de
s
Ve
rifica
çã
o e
exp
lora
çã
o d
e V
uln
era
bili
da
de
sO
bte
r a
ce
sso
privile
gia
do
ao
sis
tem
a
Var
redura
de
port
as e
m u
ma
rede
Var
redura
de
port
as d
e um
IP
espec
ífic
o
Anál
ise
de
vuln
erab
ilid
ades
Vuln
erab
ilid
ades
Iden
tifi
cadas
?
Dad
os
par
a
pró
xim
a
etap
a
Sim
Ver
ific
ação
de
serv
iços
(HT
TP
,
FT
P..)
Dad
os
par
a
pró
xim
a
etap
a
Busc
a-se
info
rmaç
ões
que
poss
am s
er
uti
liza
das
par
a ex
plo
rar
falh
as, co
mo
nom
es d
e usu
ário
s, e
-mai
ls,
etc.
Ver
ific
ação
de
Vuln
erab
ilid
ades
Vuln
erab
ilid
ades
são e
xplo
rávei
s?
Obtê
m-s
e ac
esso
rem
oto
?S
imA
cess
o R
emoto
obti
do
Sim
Susc
etív
el a
forç
a
bru
ta?
Não
Sim
Rec
olh
e
Info
rmaç
ões
do
Sis
tem
a
Vuln
eráv
el p
ara
esca
lonaç
ão d
e
pri
vil
égio
?
Sim
Não
Rep
osi
tóri
os
de
Explo
its
Não
Não
Ace
sso p
rivil
egia
do a
o
sist
ema
Uti
liza
ção d
e ap
lica
tivos
queb
radore
s de
senha
Uso
de
Explo
its
públi
cos,
ferr
amen
tas
de
pen
test
ing
Info
rmaç
ões
cap
azes
de
obte
r ac
esso
pri
vil
egia
do?
Sim
Não
Sim
Vuln
erab
ilid
ade
explo
rada? N
ãoS
im
Forç
a bru
ta
Não
Uti
liza
ção d
e ap
lica
tivos
queb
radore
s de
senha
ou a
lter
ações
de
confi
gura
ções
Iden
tifi
caçã
o d
e V
uln
erab
ilid
ades
capaz
es d
e obte
r ac
esso
pri
vil
egia
do
ao s
iste
ma
Explo
its
públi
cos
(Pri
vile
ge
esca
lonati
on, R
oot
Loca
l E
xplo
it)
Máq
uin
a não
vuln
eráv
el
Figura 15. Fluxograma do roteiro
55
O fluxograma mostrado na Figura 15 demonstra o processo seguido para chegar até o
objetivo de acesso privilegiado ao sistema. Nas anotações, são demonstradas dicas de técnicas e
ferramentas utilizadas durante o pentesting. Com este fluxograma pretende-se exemplificar o
caminho percorrido por um hacker ao conseguir comprometer um sistema.
Percebe-se que ao não conseguir explorar uma vulnerabilidade é possível realizar ataques de
força bruta para cumprir ao objetivo. Como já descrito, os ataques de força bruta requerem um
grande desempenho computacional para se tornarem viáveis, porém esses ataques podem causar
uma sobrecarga ao alvo o que para um administrador de sistemas pode indicar a tentativa de ataque.
4.2 Roteiro de Teste de Penetração
O roteiro demonstrado é o resultado da análise das técnicas e ferramentas utilizadas para
conseguir acesso privilegiado aos cenários turn-keys. Dentro deste roteiro encontram-se os
comandos, técnicas e decisões tomadas durante os testes de penetração realizados. Para fins
didáticos, o roteiro foi dividido entre as etapas selecionadas na Seção 3.3.
4.2.1 Identificação de vulnerabilidades
O princípio desta etapa é reconhecer os possíveis alvos e possíveis vulnerabilidades que
estes possuem para poder moldar a exploração das vulnerabilidades. Com o NMap (2010), é
possível realizar uma varredura de portas básica em redes de computadores para encontrar
máquinas ativas. Para realizar a ação basta passar como parâmetro para o aplicativo a faixa de IPs
desejada, como o exemplo demonstrado na Figura 16, onde se realiza uma varredura em IPs classe
C que vão 200.169.0.0 até 200.169.255.255.
Figura 16. Varredura em faixa de IPs
O NMap (2010) também aceita a notação CIDR definida pela RFC-1467(2010), como
demonstrando na Figura 17.
56
Figura 17. Exemplo varredura com CIDR.
A partir dos resultados trazidos pelo NMap, presume-se os possíveis alvos a partir da
quantidade de serviços disponibilizados, realizando uma varredura mais específica as máquinas
ativas. Para obter resultados concretos, propõe-se também a utilização do Nessus (2010).
O NMap possui vários parâmetros que aumentam a credibilidade das informações retornadas
após execução. Para identificar serviços e portas abertas a conexões, neste roteiro foram utilizadas
somente as opções ―-sS‖ e ―-sV‖, porém para um teste mais profundo, recomenda-se o uso de mais
opções. A Figura 18 demonstra como exemplo, o comando utilizado direcionado a um IP aleatório.
Figura 18. Varredura específica em IP
A utilização do Nessus faz com que sejam descobertas informações mais detalhadas do alvo.
Configurando a varredura direcionada a um IP ou faixa de IP, as vulnerabilidades encontradas são
cruzadas com o banco de dados do aplicativo trazendo detalhes da vulnerabilidade como seu código
CVE (2010), se esta tem um exploit público para exploração, entre outras.
O Nessus disponibiliza uma interface web para configuração e execução das varreduras. É
necessário criar uma política da varredura, onde se informam o endereço do alvo, os possíveis tipos
de vulnerabilidades que deseja checar, possíveis credenciais de autenticação em serviços, entre
outras informações que o aplicativo pode utilizar para obter os dados desejados.
57
Figura 19. Configuração plugins Nessus
A Figura 19 demonstra a seleção de possíveis vulnerabilidades que o Nessus pode cruzar
com seu banco de dados. Selecionar possíveis opções faz com que o teste seja mais específico, além
de custar menos tempo para retornar as informações desejadas.
Figura 20. Relatório de varredura do Nessus
Ao executar a varredura, o aplicativo mostra um relatório dos dados encontrados
demonstrado na Figura 20. Este relatório dinâmico faz com que seja possível checar detalhadamente
58
cada vulnerabilidade encontrada. As vulnerabilidades são divididas em níveis de risco Alto, Médio
e Baixo.
Após levantar as informações, fazem-se as verificações básicas para os serviços ativos
como, por exemplo, servidores web na porta 80 e servidores FTP na porta 21, onde é possível
interagir com informações publicas da forma que qualquer usuário poderia estar acessando.
A partir das informações levantadas, é necessário verificar as possíveis vulnerabilidades
encontradas, procurando por exploits e diferentes formas para explorá-las.
4.2.2 Verificação e exploração das vulnerabilidades
Com as informações recolhidas anteriormente verifica-se em base de dados de exploits, sites
de vulnerabilidades como, por exemplo, CVE (2010) e em ferramentas como Metasploit (2010) se
as possíveis falhas são suscetíveis a ataques que possam retornar em acesso ao servidor remoto.
Os sites Exploit-DB (2010) e Inj3ct0r (2010), listam em suas páginas principais os novos e
mais utilizados exploits disponibilizados por usuários cadastrados nos sites. Ambos contam com um
módulo de busca onde é possível realizar filtros por termos como, por exemplo, versões de serviços
encontrados na primeira etapa do roteiro. Um exemplo de busca nos sites é demonstrado na Figura
21 e Figura 22.
Com a busca na internet já se pode verificar a veracidade de uma vulnerabilidade e encontrar
códigos ou formas de explorá-las para conseguir acesso remoto ao alvo. A maioria dos exploits
contidos em bancos de dados online são escritos em linguagens de alto nível, onde pode ser
necessário compilá-los ou utilizar um interpretador instalado no sistema operacional para executá-
los.
Alguns exploits podem servir somente para ter acesso ao conteúdo de arquivos do sistema
operacional que podem servir para conseguir acesso remoto, como por exemplo, o exploit do
serviço Webmin utilizado na invasão demonstrada no Apêndice A Seção A2.
59
Figura 21. Módulo de busca do Exploit-DB (2010)
Figura 22. Módulo de busca do Inj3ct0r (2010)
60
Caso nenhum exploit retorne o objetivo de acesso remoto ao sistema, ainda existe a
possibilidade de realizar ataques de força bruta contra o alvo. Este ataque custa tempo e recursos
computacionais. Além do risco de causar uma sobrecarga no servidor remoto, pois faz diversas
tentativas, de credenciais de autenticação, por exemplo, para obter acesso.
A maioria dos ataques de força bruta são baseados em arquivos de dicionários que contem
diversas possíveis senhas e normalmente, quando se desconhece os usuários do sistema, em
usuários padrões como ―root‖, ou possíveis usuários comuns de utilização por serviços como, por
exemplo, ―www‖ em um servidor web.
Através do Metasploit (2010), que contem diversos exploits em seu banco de dados, é
possível fazer uma busca por termos encontrados anteriormente e encontrar módulos auxiliares,
payloads e exploits que quando utilizados exploram vulnerabilidades. A busca retorna de forma
simples seus resultados, como demonstrado na Figura 23.
Figura 23. Busca de exploit no Metasploit
Cada exploit do Metasploit possui algumas variáveis a serem configuradas, como por
exemplo, em exploits que buscam explorar falhas em computadores remotos é necessário configurar
uma variável ―RHOST‖ que conterá o endereço IP do host remoto. Após fazer estas configurações é
executado o comando para ativar o módulo.
61
Se não forem encontrados exploits capazes de explorar vulnerabilidades, é possível utilizar
diversos outros meios. Como demonstrado no roteiro de invasão no Apêndice C, Seção C3, foram
utilizadas as técnicas de Fuzzing, utilizando aplicativos que testavam configurações nas páginas
disponíveis pelo servidor web Apache, conseguindo informações para obter acesso remoto.
Dependendo das informações recolhidas o pentester deverá tomar a decisão das técnicas que irá
utilizar.
Caso nenhuma das técnicas utilizadas resulte em informações para cumprir o objetivo da
etapa, é possível utilizar os ataques de força bruta. Aplicativos como Hydra (2010) e John The
Ripper (2010) usam algoritmos para descobrir senhas fracas ou quebrar a criptografia, conseguindo
assim credenciais de acesso de usuários.
4.2.3 Obter acesso privilegiado
Ao conseguir o acesso não privilegiado ao sistema, o pentester deve iniciar a busca de
informações dentro do sistema. Dados como usuários, grupos e configurações de serviços podem
conter informações que possam resultar numa vulnerabilidade para aumentar os níveis de privilegio
do usuário.
Nos sites de bancos de dados de vulnerabilidades, encontram-se os exploits conhecidos por
―Local Privilege Escalonation” e ―Local Root Exploit‖ que fazem o uso de falhas para elevar
privilégios de um usuário para o modo administrativo do sistema. Como demonstrado na Figura 24
e Figura 25, uma busca nos sites com banco de dados de exploits retornam diversos scripts capazes
de obter acesso privilegiado. Basta cruzar as informações recolhidas do sistema com os resultados
para encontrar um exploit para explorar a falha.
62
Figura 24. Exploit-DB (2010) busca por exploits para escalonamento de privilégios
63
Figura 25. Inj3ct0r (2010) busca por "Local Root Exploit"
Verificando diversos diretórios do sistema, pode ser possível encontrar informações capazes
de informar a senha de acesso ao usuário administrativo. Outra forma é alterando arquivos de
configurações para fazer com que as senhas obtidas de usuários não privilegiados se tornem a senha
do usuário administrativo, como realizado na invasão do cenário turn-key em Apêndice C Seção C3.
Os ataques de força bruta podem ser feitos baseados em arquivos de configurações como
/etc/shadow nos sistemas baseados em Unix. Como realizado no roteiro descrito em Apêndice B
Seção B3, foi utilizado o conteúdo do arquivo /etc/shadow, o aplicativo John The Ripper (2010) e
um arquivo wordlist para quebrar a senha do usuário ―root‖.
Dependendo de cada informação obtida, o pentester pode utilizar diferentes técnicas para
conseguir acesso privilegiado ao sistema, deixando-o sem limites para executar ações no sistema
operacional.
64
5 CONCLUSÕES
A realização de um projeto na área de segurança de informações partiu do interesse pela área
do autor. O objetivo inicial era aprender mais sobre a área e obter experiências para especialização
após a conclusão do curso.
A revisão bibliográfica da área de segurança de informações foi de extrema importância e
satisfação. Foi possível estudar os conceitos envolvidos e brevemente o comportamento dos
indivíduos a qual a informação deve ser mantida segura, compreender as formas de ataques
utilizadas para comprometimento de informações e algumas formas de prevenção.
A obtenção de dados estatísticos mostrou o que já era previsto. Cada vez mais as
informações estão disponíveis de formas mais sofisticadas e indivíduos de má índole tentarão obter
acesso não autorizado com a evolução de seus métodos de ataques. Como visto, os atacantes podem
até utilizar o fator humano da confiança para chegar a seus objetivos. A necessidade de
profissionais capazes de conter esses fatos é totalmente visível.
A proposta inicial deste projeto era propor uma metodologia para testes de penetração,
entretanto, com a revisão bibliográfica pode-se compreender que o pentesting deve ser aplicado
como um projeto dentro de uma organização, tendo várias etapas complexas até chegar à
exploração de vulnerabilidades. Partindo deste pressuposto, resolveu-se propor um roteiro para
execução de exploração de vulnerabilidades em cenários pré-programados, oferecendo fins
didáticos práticos para este objeto de pesquisa.
É esperado que ao ler este projeto, seja possível para um interessado como o autor,
compreender os conceitos de segurança de informações e o quanto seu estudo é necessário. O leitor
ainda entenderá o conceito de pentesting, para analisar as infra-estruturas e sistemas computacionais
em busca de vulnerabilidades antes que um hacker mal intencionado comprometa as informações
transmitidas.
Com as técnicas, comandos e ferramentas utilizados nos roteiros baseados em cenários turn-
keys, é possível compreender como um teste de penetração se comporta em ambientes
computacionais de forma segura sem comprometer informações de sistemas reais. Além da
segurança, analisando os dados gerados e reproduzindo os roteiros, espera-se que o leitor seja
65
capaz, de forma didática, aprender como realizar um pentesting e o quanto esta técnica pode
colaborar com a segurança de uma infra-estrutura tecnológica.
Como sugestão de trabalhos futuros, o roteiro gerado permite a criação de um software que
seja capaz de ensinar a executar um teste de penetração e conhecer as ações que um hacker mal
intencionado executaria para comprometer as informações. Em forma de tutorial, o usuário passa
pelas etapas do pentesting conforme obtêm as informações necessárias, propondo um desafio de
chegar ao objetivo final.
É possível utilizar o roteiro para testar ambientes reais. Dessa forma, administradores de
redes podem utilizá-lo para testar as infra-estruturas tecnológicas buscando por falhas que possam
ser exploradas por um atacante.
A técnica de pentesting, aplicada aos conceitos de segurança de informações, torna um
ambiente de tecnologia mais seguro, podendo suportar ataques identificados antes que as
informações sejam ameaçadas por um hacker mal intencionado.
REFERÊNCIAS BIBLIOGRÁFICAS
AMAN, J. R. Black Hat/White Hat: an aggressive approach to the graduate computer security
course. Journal of Computing Sciences in Colleges, Chicago, v. 22, p. 52-58, dez 2006. ISSN
1937-4771.
APACHE. apache.org incident report for 04/09/2010. Apache Infrastructure Team. 2010.
Disponivel em: <https://blogs.apache.org/infra/entry/apache_org_04_09_2010>. Acesso em: 27
maio 2010.
ARCHIVE.ORG. Internet Archive. 2010. Disponivel em: <http://www.archive.org/>. Acesso em:
30 maio 2010.
BACKTRACK. Backtrack Linux. 2010. Disponivel em: <http:// www.backtrack-linux.org/>.
Acesso em: 30 maio 2010.
BASH. GNU BASH. 2010. Disponivel em: < http://www.gnu.org/software/bash/>. Acesso em: 28
set. 2010.
BESTUZHEV, D. Brazil: a country rich in banking Trojans. Securelist. 16 Oct. 2009. Disponivel
em: <http://www.securelist.com/en/analysis?pubid=204792084>. Acesso em: 27 maio 2010.
BISHOP, M. Computer security: art and science. Boston: Pearson Addison Wesley, 2002. 1136 p.
ISBN 0-201-44099-7.
BISHOP, M. What is computer security? IEEE Security & Privacy, Davis, Jan. 2003. 67-69.
BISHOP, M. About Penetration Testing. IEEE Security and Privacy, Davis, v. 5, n. 6, p. 84-87,
Nov./Dez. 2007. ISSN 10.1109/MSP.2007.159.
BORTOLUZZI, F. Aplicação da análise de causa raiz em sistemas de detecção de intrusões.
2004. 105 f. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Santa
Catarina , Florianópolis, 2004.
BRADEN, J. Penetration Testing - Is it right for you? SANS InfoSec Reading Room. 2003.
Disponivel em: <http://www.sans.org/reading_room/whitepapers/testing/penetration-testing-
you_265>. Acesso em: 27 maio 2010.
CERT. Cartilha de Segurança - Glossário. Centro de estudos, resposta e tratamento de
incidentes de segurança no Brasil. 2006. Disponivel em: <http://cartilha.cert.br/glossario/>.
Acesso em: 23 maio 2010.
CERT.BR. Centro de estudos, resposta e tratamento de incidentes de segurança no Brasil.
2010. Disponivel em: <http://www.cert.br/stats/incidentes/>. Acesso em: 24 fev. 2010.
CHESWICK, W. R. Firewalls e segurança na internet: repelindo o hacker ardiloso. 2. ed. Porto
Alegre: Bookman, 2005. ISBN 85-363-0429-4.
67
COMPUTERWORLD. Gmail, Yahoo Mail join Hotmail; passwords exposed. Computerworld,
2009. Disponivel em:
<http://www.computerworld.com/s/article/9139000/Gmail_Yahoo_Mail_join_Hotmail_passwords_
exposed>. Acesso em: 27 maio 2010.
CRYPTCAT. Cryptcat Project. 2010. Disponivel em: <http://cryptcat.sourceforge.net/>. Acesso
em: 31 maio 2010.
CSI. 14th Annual CSI Computer Crime and Security Survey. Computer Security Institute. Nova
York, p. 17. 2009.
CVE. Common Vulnerabilities and Exposures. 2010. Disponivel em:
<http://cve.mitre.org/index.html/>. Acesso em: 12 out. 2010.
CVE-2006-3392. CVE-2006-3392. 2010. Disponivel em: <http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2006-3392>. Acesso em: 12 out. 2010.
DAMN Vulnerable Linux. Damn Vulnerable Linux. 2010. Disponivel em:
<http://www.damnvulnerablelinux.org/>. Acesso em: 29 maio 2010.
DANHIEUX, P.; WOUTER, C. Penetration Testing: The Third Party Hacker. SANS Institute
InfoSec Reading Room. 2006. Disponivel em:
<http://www.sans.org/reading_room/whitepapers/testing/penetration-testing-third-party-
hacker_264>. Acesso em: 27 maio 2010.
DE-ICE.NET. De-ICE.net PenTest Project. 2010. Disponivel em: <http://heorot.net/livecds>.
Acesso em: 29 maio 2010.
DONALDSON, M. E. Inside the buffer overflow attack: mechanism, method and prevention.
InfoSec Reading Room, 3 abr. 2002. Disponivel em:
<http://www.sans.org/reading_room/whitepapers/securecode/buffer-overflow-attack-mechanism-
method-prevention_386>. Acesso em: 18 maio 2010.
DSA-1571-1. DSA-1571-1 openssl -- predictable random number generator. 2010. Disponivel
em: < http://www.debian.org/security/2008/dsa-1571>. Acesso em: 30 out. 2010.
GOODIN, D. US websites buckle under sustained DDoS attacks. The Register, 2009. Disponivel
em: <http://www.theregister.co.uk/2009/07/08/federal_websites_ddosed/>. Acesso em: 27 maio
2010.
HACKERDEMIA. Hackerdemia. 2007. Disponivel em:
<http://forums.heorot.net/viewtopic.php?f=42&t=203>. Acesso em: 29 maio 2010.
HYDRA. THC-Hydra. 2010. Disponivel em: < http://thc.org/thc-hydra/>. Acesso em: 29 out.
2010.
INJ3CT0R. Inj3ct0r - exploit database : vulnerability : 0day : shellcode. 2010. Disponivel em:
<http://inj3ct0r.com/>. Acesso em: 29 out. 2010.
68
ISO. ABNT NBR ISO/IEC 17799: 2005: código de prática para a gestão da segurança da
informação. 2. ed. Rio de Janeiro: ABNT - Associação Brasileira de Normas Técnicas, 2005. 120 p.
JBROFUZZ. JBroFuzz, 2010. Disponivel em: <http://sourceforge.net/projects/jbrofuzz/>. Acesso
em: 30 out. 2010.
JOHN the Ripper. John the Ripper password cracker, 2010. Disponivel em:
<http://www.openwall.com/john/>. Acesso em: 31 maio 2010.
KEE, J. Social Engineering: Manipulating the source. InfoSec Reading Room, 28 Abr. 2008.
Disponivel em: <http://www.sans.org/reading_room/whitepapers/engineering/social-engineering-
manipulating-source_32914>. Acesso em: 23 maio 2010.
KEMMERER, R. A. Designing and implementing a family of intrusion detection systems.
Proceedings of the 20th IEEE/ACM international Conference on Automated software
engineering, Long Beach, 11 nov. 2005.
KIEYZUN, A. et al. Automatic creation of SQL Injection and cross-site scripting attacks.
Proceedings of the 31st International Conference on Software Engineering, Vancouver, 16-24
maio 2009. 199-209.
KLEVINSKY, T. J.; LALIBERTE, S.; GUPTA, A. Hack I.T.: security through penetration testing.
1. ed. Indianapolis: Addison Wesley, v. 1, 2002. ISBN 0-201-71956-8.
KRAZIT, T. DDoS attack hobbles major sites, including Amazon. CNET news. 2009. Disponivel
em: <http://news.cnet.com/8301-30684_3-10421577-265.html>. Acesso em: 27 maio 2010.
KÜHNHAUSER, W. E. Root Kits: an operating systems viewpoint. ACM SIGOPS Operating
Systems Review, New York, v. 38, p. 12-23, jan. 2004. ISSN 0163-5980.
LAFRANCE, Y. Psychology: A Precious Security Tool. SANS InfoSec Reading Room, 9 jun.
2004. Disponivel em: <http://www.sans.org/reading_room/whitepapers/engineering/psychology-
precious-security-tool_1409>. Acesso em: 23 maio 2010.
LANDWEHR, C. E. Computer security. International Journal of Information, McLean, v. 1, 27
jul. 2001. 1-13.
LEE, W.; STOLFO, S. J. A framework for constructing features and models for intrusion detection
systems. ACM Transactions on Information and System Security (TISSEC), New York, v. 3, n.
4, p. 227 - 261, nov. 2000. ISSN 1094-9224.
LEHTINEN, R. Computer Security Basics. 2. ed. Sebastopol: O'Reilly Media, Inc., 2006. 310 p.
ISBN 0-596-00669-1.
LEVINE, D. E.; KESSLER, G. C. Denial of service attacks. In: VACCA, J. R. (Org). Computer
and Information Security Handbook. Burlington: Elsevier, Inc., 2009. ISBN 978-0-12-374354-1.
69
MCAFEE. Previsões sobre ameaças em 2010. McAfee Labs. 2010. Disponivel em:
<http://www.mcafee.com/us/local_content/reports/7985rpt_labs_threat-predict_0110_pt-
br_fnl_lores.pdf>. Acesso em: 17 maio 2010.
MCHUGH, J.; CHRISTIE, A.; ALLEN, J. Defending yourself: the role of intrusion detection
systems. IEEE Software, v. 17, n. 5, p. 42-51, set./out. 2000.
MEHMUD, A.; ZNATI, T. A Guided Tour Puzzle for Denial of Service Prevention. 2009 Annual
Computer Security Applications Conference , Pittsburgh, dez. 2009. 279-288.
METASPLOIT. Metasploit. Metasploit - penetration testing resources. 2010. Disponivel em:
<http://www.metasploit.com/>. Acesso em: 31 maio 2010.
MITNICK, K. D. A Arte de Enganar: controlando o fator humano na Segurança da Informação.
São Paulo: Pearson Education do Brasil, v. 1, 2003. ISBN 85-346-1516-0.
NESSUS. Nessus: The Network Vulnerability Scanner. 2010. Disponivel em:
<http://www.nessus.org/nessus/>. Acesso em: 30 out. 2010.
NETCAT. The GNU Netcat project. 2010. Disponivel em: <http://netcat.sourceforge.net/>.
Acesso em: 31 maio 2010.
NETCRAFT. January 2010 Web Server Survey. Netcraft. 2010. Disponivel em:
<http://news.netcraft.com/archives/2010/01/07/january_2010_web_server_survey.html>. Acesso
em: 27 maio 2010.
NEUBAUER, B. J.; HARRIS, J. D. Protection of computer systems from computer viruses: ethical
and pratical issues. Journal of Computing Sciences in Colleges, Pittsburg, v. 18, n. 1, p. 270-279,
out. 2002. ISSN 1937-4771.
NIKTO. Nikto2. 2010. Disponivel em: <http://cirt.net/nikto2/>. Acesso em: 30 out. 2010.
NMAP.ORG. Nmap Free Security Scanner For Network Exploration & Hacking, 2010.
Disponivel em: <http://nmap.org/>. Acesso em: 30 maio 2010.
NORTHCUTT, S. et al. Penetration testing: assessing your overall security before attackers do.
SANS Institute - SANS Industry Analysts Program, 2006. Disponivel em:
<http://www.sans.org/reading_room/analysts_program/PenetrationTesting_June06.pdf>. Acesso
em: 28 maio 2010.
NVD-US. National Vulnerability Database – US. 2010. Disponivel em: <http://nvd.nist.gov/>.
Acesso em: 31 maio 2010.
PROXYTUNNEL. Proxytunnel. 2010. Disponivel em: <http://proxytunnel.sourceforge.net/>.
Acesso em: 31 Maio 2010.
PWNOS. pWnOS. 2008. Disponivel em: <http://0dayclub.com/files/pWnOS%20v1.0.zip>. Acesso
em: 29 maio 2010.
70
REGISTRO.BR. Núcleo de Informação e Coordenação do Ponto br. 2010. Disponivel em:
<http://registro.br/cgi-bin/whois/>. Acesso em: 30 maio 2010.
RFC-1467. RFC 1467: Status of CIDR Deployment in the Internet. 1993. Disponivel em: <
http://datatracker.ietf.org/doc/rfc1467/>. Acesso em: 30 out. 2010.
SALAH, K. et al. Resiliency of open-source firewalls against remote discovery of last-matching
rules. Proceedings of the 2nd international conference on Security of information and
networks, Famagusta, p. 186-192, 2009. ISSN 978-1-60558-412-6.
SANS. Top Cyber Security Risks. SANS Institute. 2009. Disponivel em:
<http://www.sans.org/top-cyber-security-risks/>. Acesso em: 18 maio 2010.
SECTOOLS.ORG. Sectools.org. 2010. Disponivel em: <http://sectools.org/app-scanners.html>.
Acesso em: 31 maio 2010.
SECURITYFOCUS. SecurityFocus. 2010. Disponivel em: <http://www.securityfocus.com/>.
Acesso em: 31 maio 2010.
SLAX. Slax, 2010. Disponivel em: <http://www.slax.org/>. Acesso em: 3 jun. 2010.
STALLINGS, W. Criptografia e segurança de redes. Tradução de Daniel Vieira. 4. ed. São
Paulo: Pearson Prentice Hall, 2008. ISBN 978-85-7605-119-0.
STAMP, M. Information security: principles and practice. Hoboken: JohnWiley & Sons, 2006.
390 p. ISBN 978-0-471-73848-0.
SYMANTEC. Security Threat Report, Trends for 2009. Symantec Global Internet, Abr. 2010.
Disponivel em: <http://eval.symantec.com/mktginfo/enterprise/white_papers/b-
whitepaper_internet_security_threat_report_xv_04-2010.en-us.pdf>. Acesso em: 22 maio 2010.
THE Exploit Database. The Exploit Database. 2010. Disponivel em: <http://www.exploit-
db.com/>. Acesso em: 31 maio 2010.
THORNBURGH, T. Social engineering: the "Dark Art". Proceedings of the 1st annual
conference on Information security curriculum development, Kennesaw, 8 out. 2004. 133 - 135.
TILLER, J. S. The ethical hack: a framework for business value penetration testing. Boca Raton:
Auerbach Publications, 2005. ISBN 0-8493-1609-X.
TÓTH, E.; HORNÁK, Z.; TÓTH, G. Protection system against overload and distributed denial of
service attacks. 2008 Third International Conference on Dependability of Computer Systems
DepCoS-RELCOMEX, Szklarska Poreba, 26 jun. 2008. 195-202.
UBUNTU. Ubuntu. 2010. Disponivel em: <http://www.ubuntu.com/>. Acesso em: 3 jun. 2010.
VMWARE Workstation. VMware Workstation. 2010. Disponivel em:
<http://www.vmware.com/products/workstation/>. Acesso em: 1 jun. 2010.
71
WEBGOAT. WebGoat. 2010. Disponivel em: <http://code.google.com/p/webgoat/>. Acesso em:
29 maio 2010.
WILHELM, T. Professional penetration testing: creating and operating a formal hacking lab.
Burlington: Syngress, v. 1, 2010. ISBN 978-1-59749-425-0.
WILSON, Z. InfoSec Reading Room. SANS Institute. 2001. Disponivel em:
<http://www.sans.org/reading_room/whitepapers/hackers/hacking-basics_955>. Acesso em: 23
maio 2010.
WIRESHARK. Wireshark. 2010. Disponivel em: <http://www.wireshark.org/>. Acesso em: 31
maio 2010.
XPROBE2. Xprobe2. 2010. Disponivel em: <http://xprobe.sourceforge.net/>. Acesso em: 31 maio
2010.
ZWICKY, E. D. Building Internet firewalls. 2. ed. Sebastopol: O'Reilly & Associates, Inc., 2000.
869 p. ISBN 1-56592-871-7.
GLOSSÁRIO
Adobe Flash Player Reprodutor de multimídia e aplicações Flash.
Adobe Reader Software que permite que o usuário visualize, navegue e imprima arquivos
no formato PDF.
Java SE Ferramenta para desenvolvimento para a plataforma Java.
LiveCDs CD que contém um sistema operacional (GNU/Linux, BSD ou outro) que
não precisa ser instalada no disco rígido do usuário uma vez que o sistema
operacional completo é executado diretamente a partir do CD e da memória
RAM
Logs Termo utilizado para descrever o processo de registro de eventos relevantes
num sistema computacional. Esse registro pode ser utilizado para
restabelecer o estado original de um sistema ou para que um administrador
conheça o seu comportamento no passado. Um arquivo de log pode ser
utilizado para auditoria e diagnóstico de problemas em sistemas
computacionais.
MAC Address Endereço físico único de um dispositivo de interface de rede.
Malwares Termo genérico que se refere a todos os tipos de programa que executam
ações maliciosas em um computador. Exemplos de códigos maliciosos são
os vírus, worms, bots, cavalos de tróia, rootkits, etc..
Microsoft ActiveX Conjunto de tecnologias (software) criado pela Microsoft para facilitar a
integração entre diversas aplicações.
Nslookup Ferramenta, comum ao Windows e ao Linux, utilizada para se obter
informações sobre registros de DNS de um determinado domínio, host ou
IP.
Payload Módulos de payloads contem shellcodes que podem executar um grande
numero de tarefas dependendo da opção escolhida. No Metasploit existem
sete tipos, que incluem execução de arquivos, console interativo, execução
de comandos, injeção de DLL, injeção VNC, adicionar usuário e
Meterpreter.
Ping Comando que usa o protocolo ICMP para testar a conectividade entre
equipamentos.
Quicktime Estrutura de suporte multimídia, desenvolvida pela Apple Inc., capaz de
manipular formatos de vídeo digital, mídia clipes, som, texto, animação,
música e vários tipos de imagens panorâmicas interativas.
traceroute Consiste em obter o caminho que um pacote atravessa por uma rede de
computadores até chegar ao destinatário utilizando do protocolo ICMP.
73
whois Protocolo UDP específico para consultar informações de contato e DNS
sobre entidades na internet.
74
APÊNDICES
A ROTEIRO DE TESTE DE PENETRAÇÃO CENÁRIO PWNOS
O roteiro de teste de penetração, do cenário turn-key pwnOS, segue as etapas descritas nesse
projeto para realização de um pentesting em um ambiente computacional. O sistema inicia e
somente a tela de autenticação de usuário é mostrada. A partir deste momento, o pentester deve
utilizar técnicas para obter acesso.
As maquinas foram interligadas através de uma conexão virtual provida pelo software
VMware Workstation (2010) com as seguintes configurações:
Faixa de IP: 192.168.3.0/32
IP do Atacante: 192.168.3.105
IP da máquina alvo: 192.168.3.100
Os endereços IPs foram providos por um servidor DHCP virtual. O IP da máquina alvo foi
encontrado durante o pentesting. O sistema continha diversas vulnerabilidades com exploits
públicos o que colaborou para atingir o objetivo do roteiro.
A.1 IDENTIFICAÇÃO DE VULNERABILIDADES
Nessa etapa é iniciada a interação com o alvo de forma mais agressiva, realizando
varreduras de portas que estão abertas a conexões, serviços ativos, entre outros. Com as
informações adquiridas pode-se moldar como será feito o ataque através das vulnerabilidades
expostas.
A.1.1 Varredura com NMap
Inicia-se realizando uma varredura em uma rede com o NMap (2010), como demonstrado na
Figura 26, para buscar máquinas ativas.
Figura 26. Varredura em rede com NMap
76
Este comando inicia uma busca por máquinas ativas varrendo a faixa de IP que vai de
192.168.3.1 até 192.168.3.255. Retorna uma máquina ativa com IP 192.168.3.100 e uma prévia das
portas de serviços abertas como mostra a Figura 27.
Figura 27. NMap encontra maquina ativa
Observa-se na Figura 27 que existem cinco portas de serviços aguardando por conexões na
máquina. Com esta informação realiza-se uma varredura mais a fundo buscando os serviços que
estão rodando nessas portas, ainda utilizando o NMap com alguns parâmetros opcionais como
demonstrado na Figura 28.
Figura 28. NMap com alguns parâmetros opcionais
O resultado deste comando demonstra os serviços rodando com algumas sugestões de
versões e o sistema operacional ativo.
77
Figura 29. Retorno da varredura do NMap mostrando serviços e versões
Observa-se que na Figura 29, linha 6, que existe um serviço de acesso remoto OpenSSH
escutando na porta 22. Um servidor de páginas web Apache e interpretador da linguagem PHP na
porta 80. O serviço Samba para compartilhamento de arquivos com redes Windows nas portas 139 e
445. Por fim, o serviço Webmin para gerenciamento de servidores na porta 10000.
Com estas informações é possível verificar, com o uso de um navegador, as páginas web
servidas pela máquina.
Figura 30. Página inicial disponibilizada na máquina alvo.
78
A página inicial mostrada na Figura 30 é simples e não contêm nenhuma informação
relevante, através do botão ―Next‖ inicia-se a iteração com o site.
Figura 31. Formulário mostrado na iteração com o site hospedado na máquina alvo
Na próxima página demonstrada na Figura 31 encontra-se um formulário para entrada de
dados. Observa-se a utilização de parâmetros na URL que podem alterar o comportamento da
página. Alteram-se as informações passadas na URL esperando que haja alguma falha de validação
que possa ser utilizada para conseguir informações do sistema.
79
Figura 32. Erro de função include() do PHP
Após a remoção de um valor passado pelo parâmetro ―connect‖, como visualizado na Figura
31, é mostrado o erro de falha ao incluir um arquivo na página, utilizado na linguagem PHP através
da função include. Com esta falha, pretende-se incluir arquivos do sistema operacional que
contenham informações uteis para realizar o ataque.
Figura 33. Arquivo /etc/passwd incluído na página
80
Através da URL alterada, insere-se o caminho do arquivo /etc/passwd que contem os
usuários de sistemas baseados na plataforma Unix, neste caso o Linux. O resultado, demonstrado na
Figura 33, é a descrição dos usuários do sistema, em especial os usuários ―root‖, ―vmware‖,
―obama‖, ―osama‖ e ―yomama‖. Esses usuários possuem o interpretador de comandos BASH
(2010), demonstrando que foram adicionados ao sistema posteriormente a sua instalação. O ―root‖ é
o usuário privilegiado do sistema, padrão nas plataformas Unix. Com esta informação, já se possui
uma lista de usuários do sistema.
A.1.2 Varredura com Nessus
Ao realizar uma varredura na máquina alvo através do Nessus, verifica-se no relatório
gerado que há uma vulnerabilidade de alto risco no serviço SSH, como demonstrado na Figura 34.
Figura 34. Relatório do Nessus indicando vulnerabilidade de alto risco no serviço SSH
Além da vulnerabilidade de alto risco na porta 22, várias outras vulnerabilidades de médio e
baixo risco foram encontradas, estas que também podem ser utilizadas para conseguir acesso ou
informações da máquina alvo.
81
Figura 35. Detalhes da vulnerabilidade no OpenSSH/OpenSSL gerada pelo Nessus
O Nessus cruza os dados da vulnerabilidade encontrada com seu banco de dados,
proporcionando mais detalhes sobre a vulnerabilidade, como demonstrado na Figura 35.
A.1.3 Análise do serviço Webmin
A varredura com o NMap realizada previamente, apontou o serviço de gerenciamento de
servidores Webmin rodando na porta 10000. Utiliza-se um navegador para verificar este serviço
acessando através do IP seguido pela porta do serviço, como demonstrado na Figura 36.
82
Figura 36. Interface de autenticação do serviço Webmin
A interface de autenticação do Webmin demonstrada na Figura 36 requisita por credenciais
para acesso ao sistema. Até esta etapa, somente foram encontrados os nomes de usuários do
sistema. Realiza-se uma busca na internet, a qual resulta em várias vulnerabilidades da aplicação
Webmin. Na próxima etapa do pentesting, é verificado se estas vulnerabilidades estão presentes na
versão rodando na máquina alvo.
A.2 VERIFICAÇÃO E EXPLORAÇÃO DAS VULNERABILIDADES
A partir das informações recolhidas na etapa anterior, realizam-se buscas na internet para
concretizar a existência da vulnerabilidade na maquina alvo e explorar essa falha na tentativa de
aceso remoto ao alvo.
A.2.1 Vulnerabilidade OpenSSH/OpenSSL
A equipe de segurança do projeto Debian Linux, tornou publica a vulnerabilidade nos
serviços de OpenSSH/OpenSSL conforme a DSA-1571(2010). Chamada de ―OpenSSL –
predictable random number generator‖, esta vulnerabilidade faz com que o gerador números
aleatórios no pacote OpenSSL do Debian seja previsível.
83
Procura-se em uma base de dados de exploits, o script que faz o uso desta vulnerabilidade
para obter acesso ao sistema. No site Exploit-DB (2010) encontra-se o exploit nomeado ―Debian
OpenSSL Predictable PRNG Bruteforce SSH Exploit‖, que faz o uso de um arquivo, que contem
todas as chaves publicas possíveis de serem previstas, disponibilizado pelos criadores do
Metasploit(2010). Porem o uso de ataques de força bruta pode demorar horas e chamar atenção pela
quantidade de requisições feitas ao sistema alvo, e ainda podem-se achar meios mais fáceis na
vulnerabilidade do Webmin. Baixa-se o arquivo, que contem as chaves publicas,
―debian_ssh_rsa_2048_x86.tar.bz2‖ e o exploit publico disponibilizado para possível utilização
posterior.
A.2.2 Vulnerabilidade Webmin
Conforme encontrado no site da CVE (2010) uma vulnerabilidade encontrada no serviço
Webmin foi publicada através do código CVE-2006-3392:
O Webmin antes das versões 1.290 e o Usermin antes das versões 1.220 chamam uma
função definida por “simplify_path” antes de decodificar o HTML. Esta função permite
que um atacante tenha acesso ao conteúdo de arquivos, utilizando seqüências de códigos
“..%01", o que ignora a remoção das seqüências de caracteres “../” antes que os bytes
“%01” sejam removidos do nome do arquivo. (CVE-2006-3392).
Buscando em Exploit-DB (2010), encontra-se o script, escrito em Perl, nomeado ―Webmin <
1.290 / Usermin < 1.220 Arbitrary File Disclosure Exploit‖. O exploit utiliza a vulnerabilidade
citada acima para acesso a conteúdo de arquivos no servidor remoto. No framework Metasploit
(2010), também é encontrado o módulo que se aproveita desta falha, como demonstra a Figura 37.
As duas formas serão demonstradas posteriormente.
84
Figura 37. Modulo Webmin/file_disclosure do Metasploit
A.2.3 Explorando as vulnerabilidades encontradas para obter acesso ao sistema
Após localizar as formas de explorar a vulnerabilidade, começa a invasão a maquina alvo.
Utilizando o exploit do Webmin, é possível fazer o teste de leitura de conteúdos de arquivos do
sistema. O exploit pede como parâmetros o servidor remoto, seguido da porta que o serviço esta
rodando, o arquivo desejado e a forma de conexão (HTTP ou HTTPS). O resultado é demonstrado
na Figura 38.
85
Figura 38. Retorno do conteúdo do arquivo /etc/shadow pelo exploit do Webmin
O arquivo /etc/shadow somente tem permissões de leitura para o usuário ―root‖.Com isto
prevê-se que utilizando esta falha é possível acessar o contudo de qualquer arquivo no sistema.
Como encontrado anteriormente, a máquina alvo possui uma vulnerabilidade no serviço
OpenSSH/OpenSSL. Com a ajuda do exploit, confirma-se a possibilidade do uso desta falha
analisando o conteúdo do arquivo de configuração do serviço OpenSSH e buscando pela
configuração ativa do acesso através de chaves públicas. O resultado é demonstrado na Figura 39.
Figura 39. Arquivo configuração OpenSSH
86
Dessa forma, sabe-se que a vulnerabilidade do OpenSSH/OpenSSL identificada
anteriormente pode ser utilizada para conseguir acesso ao sistema. Para não utilizar os ataques de
força bruta, pode-se ler o conteúdo da chave pública de um usuário e buscá-la na base de chaves
públicas possíveis baixadas previamente.
Utilizando o módulo do Metasploit (2010), busca-se o conteúdo do arquivo do usuário
―obama‖ que identifica sua chave pública. O resultado é demonstrado na Figura 40.
Com o conteúdo retornado, busca-se a chave publica no pacote baixado anteriormente.
Utiliza-se o comando ―grep‖ do Linux dentro dos arquivos contidos no pacote como demonstrado
na Figura 41.
Figura 40. Retorno do conteúdo da chave pública do usuário "obama" através do Metasploit
Figura 41. Encontrado chave publica do usuário ―obama‖
87
Com a chave pública encontrada, é possível fazer à tentativa de acesso remoto a máquina
alvo. O resultado demonstrado na Figura 42 é o acesso não privilegiado do usuário ―obama‖ ao
sistema.
Figura 42. Acesso remoto do usuário ―obama‖ ao sistema
O acesso remoto ao sistema foi obtido, porém com um usuário que não tem privilégios no
sistema. A próxima etapa é obter acesso remoto privilegiado ao sistema.
A.3 OBTENDO ACESSO PRIVILEGIADO AO SISTEMA
Na etapa anterior foram exploradas as vulnerabilidades identificadas para conseguir acesso
ao sistema da máquina alvo. Para conseguir acesso privilegiado, é possível utilizar falhas do sistema
operacional que permitem que um usuário consiga alterar seu nível de privilégios.
Através de comandos do Linux é possível identificar a versão do Kernel utilizada. Com esta
informação busca-se em banco de dados de vulnerabilidades por exploits conhecidos como
―Privilege escalonation” ou ―Local Root Exploit‖. No site Exploit-DB (2010) encontra-se diversos
exploits que exploram falhas dos Kernels do Linux na versão 2.6. A versão encontrada no sistema
invadido é a 2.6.22-14, como demonstrado na Figura 31. O exploit ―Linux Kernel 2.6.17 - 2.6.24.1
vmsplice Local Root Exploit‖, encontrado no site, faz o uso da vulnerabilidade onde é possível
acessar endereços de memórias do kernel e escalonar o privilegio.
88
Faz-se o download do arquivo que deve ser enviado para a máquina invadida anteriormente,
para que com o usuário ―obama‖ seja possível escalonar seus níveis de privilégios e obter acesso ao
usuário ―root‖. Para enviar para a máquina, pode-se utilizar o comando ―scp‖, que copia arquivos de
forma remota criptografada através do protocolo SSH, juntamente com a chave pública encontrada
nas etapas anteriores.
Uma vez que o arquivo encontra-se na máquina, é necessário compilar o código C com o
comando ―gcc‖ e executá-lo. O resultado é a o acesso do usuário ―root‖ ao sistema como
demonstrado na Figura 43.
Figura 43. Obtido acesso privilegiado ao sistema
Com o acesso privilegiado ao sistema, finaliza-se o objetivo. As etapas para manter acesso
ao sistema e limpeza de evidências não abrangem este roteiro.
89
B ROTEIRO DE TESTE DE PENETRAÇÃO CENÁRIO DE-ICE
NIVEL 1
O projeto De-ICE.net Pentest LabTest foi criado para proporcionar para futuros
profissionais de segurança de informações um ambiente o qual possam testar as técnicas de
pentesting e seu comportamento simulando ambientes reais.
O roteiro de teste de penetração para o cenário De-ICE.net Nível 1, segue as etapas de um
pentesting já descritas anteriormente com o objetivo de encontrar falhas que possam levar ao acesso
privilegiado do sistema. O sistema De-ICE.net Nível 1 foi instalado em uma máquina virtual e
conectado a uma rede virtual provida pelo VMware Workstation. O sistema operacional inicia e
mostra apenas a tela de autenticação do usuário. A partir deste momento, o pentester deve utilizar
técnicas para obter acesso ao sistema.
Abaixo são demonstradas as configurações utilizadas:
Faixa de IP: 192.168.3.0/32
IP do Atacante: 192.168.3.105
IP da máquina alvo: 192.168.3.100
O IP da máquina alvo é estático e foi encontrado durante o pentesting. O sistema continha
poucas vulnerabilidades de aplicativos e serviços ativos, logo foi um teste baseado em técnicas de
força bruta.
B.1 IDENTIFICAÇÃO DE VULNERABILIDADES
Nesta etapa são realizadas varreduras de portas abertas a conexões, serviços ativos entre
outros. Busca-se o máximo de informações diretas ao alvo. Com as informações adquiridas, poderá
ser moldado o ataque após a verificação das vulnerabilidades encontradas.
90
B.1.1 Varredura com NMap
Inicia-se o teste identificando máquinas ativas em uma rede. Utilizando o NMap, passando
por parâmetro a faixa de IPs que se deseja verificar, como demonstrado na Figura 44.
Figura 44. Varredura de rede com o NMap
O resultado trazido pelo comando demonstra as maquinas e ativos de redes que responderam
a requisições feitas pelo NMap à faixa de IPs que vai de 192.168.1.1 até 192.168.1.255. Na Figura
45 é exposto o resultado de uma máquina que tende ser um possível alvo, pois contem algumas
portas abertas a conexões.
Figura 45. Resultado da varredura a uma faixa de IPs
Com essa informação descobre-se uma máquina ativa que pode ser um possível foco de
vulnerabilidades. Ainda com o NMap, realiza-se uma busca específica a máquina, passando
parâmetros que demonstram os serviços ativos. O resultado é demonstrado na Figura 46.
91
Figura 46. Varredura especifica a maquina alvo
Analisando o retorno do comando ao IP 192.168.1.100, na Figura 46, observam-se seis
portas abertas que vão da linha 9 a 14. Na linha 9, porta 21, roda um serviço FTP chamado vsftpd
que o NMap já reconhece que está com problemas. Adiante na linha 10, porta 22, o serviço de
conexão remota OpenSSH. Na linha 11, porta 25, o servidor de envio de e-mails SMTP Sendmail.
Na porta 80, linha 12, encontra-se o servidor de páginas web Apache com interpretador da
linguagem PHP. Nas linhas 13 e 14, portas 110 e 143, estão ativos os serviços para acesso de e-
mails POP3 e IMAP.
Inicia-se a verificação dos serviços encontrados buscando mais informações a respeito. A
iteração mais discreta com a máquina alvo seria inicialmente a verificação das páginas servidas pelo
serviço web Apache. Com um navegador, é acessado o servidor através do seu IP, a página inicial é
demonstrada na Figura 47.
92
Figura 47. Pagina inicial da maquina 192.168.1.100
É mostrada uma página com dados a respeito do cenário De-ICE Nível 1. Ao clicar no link
―CLICK HERE‖ é redirecionado para a página de inicio do cenário simulado, demonstrado na
Figura 48.
A página mostra informações de uma empresa fictícia além de diversos e-mails de
colaboradores. Com base de configurações de serviços de e-mail, pode-se a partir da lista mostrada
na página criar uma possível lista de usuários
93
Figura 48. Lista de e-mails
Observa-se na Figura 48 que os e-mails são formados pelo nome ou sobrenome mais uma
letra inicial do nome ou sobrenome. Dessa forma monta-se uma possível lista de usuários para cada
colaborador como demonstrado na Figura 49. Caso seja necessário algum teste posteriormente, cria-
se um arquivo texto com os possíveis usuários.
94
Figura 49. Lista de e-mails e possíveis usuários de sistema para cada colaborador
Com estes usuários pode-se fazer uma tentativa de ataque de força bruta para conseguir
acesso remoto no servidor, mas isto pode levar tempo e ainda existem algumas portas a serem
verificadas.
Na varredura de portas com o NMap, feita anteriormente, retornou uma porta em que um
serviço de FTP estava ativo mas que não era possível fazer conexão. Para conexão sem usuário e
senha aos servidores FTP público usa-se o usuário ―anonymuos‖. Pode-se tentar fazer conexão e
confirmar se é possível acessar o serviço. O retorno é demonstrado na Figura 50.
95
Figura 50. Falha ao conectar ao serviço FTP
Continuando a procura por vulnerabilidades nos serviços listados anteriormente, não foram
encontradas informações de falhas no serviço OpenSSH versão 4.3 instalada no sistema. Para o
serviço de e-mail Sendmail, famoso por diversas falhas em suas primeiras versões, na atual versão
instalada na máquina alvo também não foram encontradas vulnerabilidades.
Os demais serviços também não apresentaram vulnerabilidades nas análises, são eles o
servidor web Apache, o serviço POP3 OpenWall e o serviço IMAP UW imapd. A partir destas
informações, conclui-se que não há serviços vulneráveis capazes de serem explorados para
conseguir acesso ao sistema, restando à opção de realizar ataques de força bruta a maquina alvo
com a lista de usuários criada anteriormente.
B.2 VERIFICAÇÃO E EXPLORAÇÃO DAS VULNERABILIDADES
Como não foram encontradas vulnerabilidades para conseguir acesso ao sistema, pode-se
realizar testes de força bruta buscando senhas fracas. A partir da lista de usuários criada
anteriormente, inicia-se o teste de forma discreta, tentando buscar usuários que possuem senhas
semelhantes ou iguais ao nome de usuário do sistema e usuários sem senha.
O programa encontrado no Backtrack (2010) chamado Hydra (2010) realiza essa operação, o
retorno do comando é mostrado na Figura 51.
Observa-se que o usuário ―bbanter‖ possui a senha idêntica ao seu nome de usuário. Senhas
fracas com mesmo nome de usuário, seqüências básicas de caracteres como ―asdf‖ e ―12345‖, e
também senhas padrões de dispositivos e serviços são comuns em ambientes onde não se estipulam
claras políticas de segurança a respeito de senhas. Como no caso da máquina alvo, uma senha fraca
pode disponibilizar ao atacante acesso remoto a um servidor.
96
Figura 51. Usuário "bbanter" possui senha igual ao login
Ao descobrir a fraqueza da senha do usuário ―bbanter‖, realiza-se a tentativa de acesso
remoto ao servidor utilizando o serviço OpenSSH, o resultado é mostrado na Figura 52.
97
Figura 52. Acesso remoto obtido com o usuário "bbanter"
A partir do acesso remoto, pode-se colher informações a respeito da máquina para
posteriormente buscar acesso remoto ao sistema. Vulnerabilidades de escalonamento de privilégios
são os meios mais fáceis para chegar a este objetivo. Verifica-se a versão do Kernel do Linux, e
realiza a busca em bancos de dados de exploits. Para versão 2.6.16, como mostra na Figura 52
através do comando ―uname‖, encontrada na máquina invadida não existem exploits públicos.
Com acesso ao sistema, pode-se fazer a leitura de arquivos de configurações do sistema,
como por exemplo, o arquivo /etc/passwd que contem os usuários em sistemas Linux. Na criação da
lista de possíveis usuários anteriormente, informava no site que o colaborador Bob Banter era um
estagiário (do inglês, Intern), por este motivo deve-se ter cuidado com a tentativa de acesso a
arquivos que possam alertar que o usuário está realizando esta ação. Com o conteúdo do arquivo
passwd pode-se confirmar os reais usuários do sistema. Utiliza-se o comando ―cat‖ para mostrar na
saída padrão o conteúdo do arquivo, o resultado é mostrado na Figura 53.
Atualiza-se a lista de usuários criadas nas primeiras etapas com os usuários conseguidos na
leitura do arquivo passwd, estes são ―aadams‖, ―bbanter‖ e ―ccoffee‖. É possível observar que o
usuário FTP possui um diretório padrão /home/ftp o que pode ser o repositório de arquivos FTP.
Outro arquivo capaz de disponibilizar informações a respeito de privilégios do sistema é o
arquivo que contem as configurações de grupo /etc/group. Novamente utiliza-se o comando ―cat‖
para mostrar na saída padrão o conteúdo do arquivo. O resultado do comando é demonstrado na
Figura 54.
98
Figura 53. Conteúdo do arquivo /etc/passwd
Cruzando as informações obtidas nos arquivos /etc/passwd e /etc/group observa-se que o
usuário ―aadams‖ possui um grupo diferente dos demais usuários. No arquivo /etc/group esse
identificador de grupo (utilizado nos sistemas baseados em Unix, Group Id, abreviadamente ―gid‖)
possui ao grupo ―whell‖ ao qual o grupo ―root‖ também faz parte. Através dessa informação
conclui-se que o usuário ―aadams‖ possui privilégios para executar comandos, normalmente
configurados através do comando ―sudo‖.
Como verificado previamente, não existem vulnerabilidades capazes de escalonar os
privilégios de usuário, portanto novamente realiza-se o ataque de força bruta para descobrir a senha
do usuário ―aadams‖. Como se sabe que somente o usuário ―bbanter‖ possui uma senha fraca, na
nova tentativa será utilizado um dicionário de palavras (do termo conhecido em inglês por
wordlist). Este arquivo texto possui diversas combinações de caracteres e palavras de diversos
idiomas, ele pode ser montado de acordo com as informações conseguidas do alvo, como por
99
exemplo, localização geográfica. O arquivo utilizado chamado ―bt4-passwords‖ encontra-se na
distribuição Backtrack, dentro do diretório /pentest/passwords/wordlists/.
Figura 54. Conteúdo do arquivo /etc/group
Os ataques de força bruta podem levar horas ou até dias para serem executados, quanto
maior a capacidade computacional mais rápido as tentativas acontecem. Este ataque foi realizado da
máquina física para a máquina virtual, para não se limitar ao hardware virtual. Novamente utiliza-se
o programa Hydra (2010) juntamente com um arquivo wordlist para realizar o ataque, o resultado
do comando é demonstrado na Figura 55.
100
Figura 55. Senha do usuário "aadams" é encontrada
O Hydra retornou a senha ―nostradamus‖ para o usuário especificado. Com esta senha é
possível realizar acesso ao sistema com um usuário que possui mais privilégios que o usuário
anterior, tendo mais chances de conseguir o acesso do usuário ―root‖. Através do serviço OpenSSH
e o usuário e senha ―aadams‖ ―nostradamus‖ respectivamente, tenta-se acesso remoto ao sistema,
como demonstrado na Figura 56.
Figura 56. Acesso remoto com o usuário "aadams"
Foi obtido acesso remoto com um usuário que possui permissões do grupo ―whell‖. O
próximo passo é a partir de este acesso conseguir privilégios do usuário ―root‖ no sistema. Como
não foram encontradas vulnerabilidades para escalonamento, mantêm-se as tentativas de força bruta
como ataque principal para chegar ao objetivo.
101
B.3 OBTENDO ACESSO PRIVILEGIADO AO SISTEMA
Com o acesso do usuário ―aadams‖ é possível utilizar o comando ―sudo‖ para conseguir
acesso ao conteúdo do arquivo /etc/shadow que contem as senhas criptografadas dos usuários de
sistemas Linux. A junção do comando ―sudo‖ mais o comando ―cat‖ e a senha do usuário ―aadams‖
obtida na etapa anterior mostra o conteúdo do arquivo shadow, como demonstrado na Figura 57.
Figura 57. Conteúdo do arquivo /etc/shadow
Em um arquivo texto, coloca-se o conteúdo extraído do arquivo /etc/shadow. Neste caso já
foram encontradas as senhas dos usuários ―aadams‖ e ―bbanter‖ anteriormente e como se busca o
acesso privilegiado utiliza-se o John The Ripper (2010) para tentar quebrar a criptografia da senha
do usuário ―root‖. O resultado da utilização do John The Ripper é mostrado na Figura 58.
102
Figura 58. John The Ripper quebra a senha do usuário ―root‖
A execução do comando obteve sucesso e quebrou a senha do usuário ―root‖ se baseando
em uma wordlist passada por parâmetro e também no arquivo /etc/shadow extraído anteriormente.
Com as possibilidades encontradas pelo John The Ripper ―tarot‖ e ―tarotcoD‖, tenta-se elevar os
privilégios do usuário autenticando-se como usuário ―root‖ com o comando ―su‖. O resultado é
demonstrado na Figura 59.
Figura 59. Acesso do usuário ―root‖
Com o acesso privilegiado do usuário ―root‖, finaliza-se o objetivo deste teste de penetração.
As etapas para manter acesso e limpeza de evidencias não serão abordadas.
103
C ROTEIRO DE TESTE DE PENETRAÇÃO CENÁRIO DE-ICE
NIVEL 2
O projeto De-ICE.net Pentest LabTest foi criado para proporcionar para futuros
profissionais de segurança de informações um ambiente o qual possam testar as técnicas de
pentesting e seu comportamento simulando ambientes reais.
O roteiro de teste de penetração para o cenário De-ICE.net Nível 2, segue as etapas de um
pentesting já descritas anteriormente com o objetivo de encontrar falhas que possam levar ao acesso
privilegiado do sistema. O sistema De-ICE.net Nível 2 foi instalado em uma máquina virtual e
conectado a uma rede virtual provida pelo VMware Workstation. O sistema operacional inicia e
mostra apenas a tela de autenticação do usuário. A partir deste momento, o pentester deve utilizar
técnicas para obter acesso ao sistema.
Abaixo são demonstradas as configurações utilizadas:
Faixa de IP: 192.168.2.0/32
IP do Atacante: 192.168.2.105
IP da máquina alvo: 192.168.2.100 e 192.168.2.101
Os IPs da máquina alvo são estáticos e foram encontrados durante o pentesting. Este nível
prove a simulação de falhas de configurações de serviços.
C.1 IDENTIFICAÇÃO DE VULNERABILIDADES
Nesta etapa são realizadas varreduras de portas abertas a conexões e serviços ativos,
buscando identificar informações sobre a rede e os possíveis alvos.
C.1.1 Varredura com NMap
Inicia-se através do NMap uma varredura na rede. Demonstrada na Figura 60.
Figura 60. NMap varrendo a rede 192.168.2.1-255
104
Essa varredura identifica algumas máquinas ativas na rede, os possíveis alvos são
demonstrados na Figura 61.
Figura 61. Máquinas ativas reconhecidas pela varredura do NMap
O retorno demonstrado na Figura 61 indica duas máquinas ativas com o mesmo MAC
Address. Um primeiro IP contem diversas portas em modo de escuta aguardando por conexões
como demonstrado entre as linhas 7 e 14. No segundo IP somente a porta 80 do protocolo HTTP
está ativa. Realiza-se então uma varredura mais profunda, buscando mais informações sobre os dois
possíveis alvos ativos, o resultado é demonstrado na Figura 62.
105
Figura 62. Varredura especifica nos IPs finais 100 e 101
O retorno demonstrado na Figura 62 indica diversos serviços rodando no IP 192.168.2.100.
Inicia-se a verificação de vulnerabilidades nesses serviços.
C.1.2 Varredura com Nessus
Para ter uma abordagem mais detalhada e rápida pode-se realizar uma varredura com o
Nessus que cruza as informações adquiridas com seu banco de dados, informando as
vulnerabilidades encontradas. O retorno da análise do Nessus é demonstrado na Figura 63.
106
Figura 63. Resultado da análise do Nessus
Para verificar mais detalhes a respeito das vulnerabilidades de alto risco encontradas,
seleciona-se um dos IPs analisados. O resultado é mostrado na Figura 64.
Figura 64. Vulnerabilidades de alto risco encontradas pelo Nessus
As vulnerabilidades encontradas pelo Nessus são de versões da linguagem PHP que está
ativada através do módulo do servidor web Apache. Na próxima etapa será verificada se as falhas
demonstradas podem ser exploradas. Não foram encontradas vulnerabilidades nas versões dos
demais serviços ativos.
C.1.3 Analisando as informações das páginas do servidor Apache
Através do navegador, checa-se o conteúdo das páginas web disponíveis pelo servidor web
Apache, acessa-se primeiramente o IP 192.168.2.100. A página é demonstrada na Figura 65.
Observa-se algumas informações sobre uma empresa e uma lista de e-mails separadas por setores.
Com esses e-mails pode-se montar uma lista de possíveis usuários do sistema alvo.
107
Figura 65. Lista de e-mails da empresa fictícia
Verifica-se também a página servida pelo servidor web mantido no IP 192.168.2.101. O
resultado é demonstrado na Figura 66. Observa-se que a página exibe links para arquivos de
políticas e padrões da empresa, ou seja, um servidor web para download de arquivos através do
protocolo HTTP.
Na próxima etapa serão verificadas as vulnerabilidades encontradas e possíveis métodos de
acesso remoto ao sistema.
108
Figura 66. Página com documentos internos
C.2 VERIFICAÇÃO E EXPLORAÇÃO DAS VULNERABILIDADES
Nesta etapa será checada a veracidade das possíveis vulnerabilidades e se há formas para
explorá-las. Anteriormente foram indicadas pelo Nessus vulnerabilidades na linguagem PHP,
procura-se em bancos de dados de exploits scripts que possam explorar essas falhas. No site
Exploit-DB(2010) nenhum script foi encontrado.
C.2.1 Utilizando a técnica Fuzz testing
Como verificado anteriormente, existe um servidor web rodando em ambos os IPs. Pode-se
utilizar a técnica conhecida como Fuzzing (Fuzz testing, traduzido literalmente para teste de
difusão), que testa falhas de softwares, serviços e má configuração buscando informações que não
deviam ser disponibilizadas utilizando injeção de dados malformados ou semi-malformados de
forma automatizada. No caso do serviço web rodando no servidor 192.168.2.101, pode-se utilizar a
lista de usuários criada anteriormente para checar a existência de pastas pessoais disponíveis para
acesso através do protocolo HTTP.
O Backtrack(2010) possui o aplicativo JBroFuzz (2010), mas por motivos de performance, o
aplicativo foi utilizado na máquina física. Utilizando a busca por diretórios web insere-se a lista dos
possíveis usuários e ainda alguns possíveis usuários administrativos como ―root‖ e ―admin‖. Para
109
cada usuário inserido na lista de testes, coloca-se em frente ao usuário o caractere ―~‖ que é
utilizada pelos servidores web para indicar um diretório web de um usuário do sistema.
O JBroFuzz fará uma requisição a cada possível página de usuário, como por exemplo:
"http://192.168.2.101/~admin" e retornará um código de retorno do protocolo HTTP. Código HTTP
200 caso existe e 404 caso contrário. O resultado é demonstrado na Figura 67.
Figura 67. JBroFuzz testando diretórios web pessoais
O retorno do teste é que existem quatro diretórios web pessoais que são detalhados na Figura
68. Esses diretórios podem conter arquivos pessoais que possam armazenar informações sobre o
sistema alvo.
Figura 68. Diretórios encontrados pelo JBroFuzz
110
Com as informações obtidas, atualiza-se a lista de usuários para caso necessite realizar um
teste de força bruta, somente os usuários que tenham vestígios de pertencerem ao sistema sejam
testados.
Verificam-se, através do navegador web, os diretórios web encontrados buscando arquivos
dos usuários disponibilizados erroneamente pelo servidor web. Checando as páginas, nenhum
arquivo é disponibilizado, porem há a possibilidade de existir diretórios ocultos ou ainda falhas que
possam informar meios de acesso ao sistema.
Para continuar os testes buscando por falhas de configuração do serviço Apache, utiliza-se a
ferramenta Nikto (2010) que testa vários diretórios padrões do sistema que possam estar
disponíveis, além de arquivos maliciosos, scripts CGIs vulneráveis, versões desatualizadas de
aplicativos entre outras funcionalidades. O comando deve ser executado para todos os usuários
encontrados anteriormente. O resultado mais significativo é demonstrado na Figura 69.
Figura 69. Nikto encontra diretório oculto .ssh
111
A mensagem na Figura 69 informa que foi possível acessar o diretório ―.ssh‖ do diretório
pessoal do usuário ―pirrip‖, o que não deveria ser acessível via web. Este diretório contem os
arquivos de configurações de acesso remoto do usuário. Utilizando o navegador pode-se acessar a
URL indicada e visualizar arquivos de chaves públicas para acesso remoto ao serviço OpenSSH,
como demonstra a Figura 70.
Figura 70. Diretório ―.ssh‖ do usuário contendo chaves públicas
Com estes arquivos pode-se utilizar um usuário qualquer para se passar pelo usuário ―pirrip‖
e acessar o servidor remotamente. É realizado o download dos arquivos que devem ser colocados no
diretório ―.ssh‖ da pasta local do usuário, como demonstrado na Figura 71. O serviço de acesso
remoto requer que as permissões especiais sejam especificadas para os arquivos, como
demonstradas nas linhas 6 a 12.
Feita as configurações, faz-se a tentativa de acesso remoto utilizando o usuário ―pirrip‖.
Dependendo das configurações do servidor remoto, a autenticação através de chaves públicas pode
não requisitar senha.
112
Figura 71. Configurações de chaves públicas e acesso remoto ao sistema
Observa-se que o acesso remoto ao servidor foi obtido pelo usuário ―pirrip‖. A partir desse
momento pode-se interagir com o sistema buscando mais informações a respeito para obter acesso
privilegiado.
Inicia-se verificando o conteúdo do arquivo /etc/passwd, para verificar os usuários
pertencentes ao sistema. O conteúdo do arquivo é demonstrado na Figura 72. Com o retorno obtido,
altera-se o arquivo de possíveis usuários criado anteriormente com os dados reais do sistema. Caso
seja necessário realizar algum ataque de força bruta ou que requisite nomes de usuários a listagem
estará atualizada.
113
Figura 72. Conteúdo do arquivo /etc/passwd
Também é possível visualizar o conteúdo do arquivo /etc/group, para identificar as
permissões de grupos dos usuários do sistema. O conteúdo do arquivo é demonstrado na Figura 73.
Figura 73. Conteúdo do arquivo /etc/group
114
Cruzando as informações obtidas com os arquivos /etc/passwd e /etc/group verifica-se que o
usuário ―pirrip‖ pertence ao grupo ―wheel‖ o qual o grupo ―root‖ também está incluído. Com esta
informação, espera-se que o usuário possa utilizar comandos como o ―sudo‖, porém para utilizar
este comando necessita-se a senha do usuário que é desconhecida.
Deve-se buscar formas de obter a senha do usuário para chegar ao objetivo do teste de
invasão que é obter acesso privilegiado ao sistema. Para isto pode-se utilizar os ataques de força
bruta, ferramentas para análise de tráfego, entre outros.
C.3 OBTENDO ACESSO PRIVILEGIADO AO SISTEMA
Existem diversas formas de conseguir acesso de usuário privilegiado ao sistema, como por
exemplo, a utilização de exploits que exploram falhas no sistema operacional. Também se pode
analisar o trafego de rede buscando credenciais trocadas durante a comunicação.
Uma forma muito utilizada para conseguir informações é a engenharia social, que utiliza
formas para fazer com que uma pessoa informe os dados, muitas vezes se passando por algum
individuo ou enviando e-mails fraudulentos imitando sites verdadeiros como de instituições
financeiras.
O fator humano é muito vulnerável a falhas se as políticas de uma organização não são bem
estipuladas e demonstradas de forma clara para seus colaboradores. No caso do cenário atual, foram
encontradas dentro da pasta /var/mail e-mails enviados pelos colaboradores que continham senhas
de usuários e informações pessoais.
Ainda com o usuário ―pirrip‖ tem-se acesso ao conteúdo do arquivo ―/var/mail/pirrip‖ que
contem as mensagens de e-mails do usuário. Em uma mensagem enviada pelo usuário "magwitch"
com o assunto "havisham" informa que as credenciais de acesso do usuário ―havisham‖ ao sistema
foram criadas, a senha definida foi "changeme" e que esta deve ser alterada, conforme demonstra a
Figura 63.
115
Figura 74. Email enviado com senha em texto plano
Como visto anteriormente nas informações recolhidas, o usuário "havisham" pertence à
Estella Havisham, que não tem acesso privilegiado. Observa-se que a senha é passada de forma
insegura, como texto plano (do inglês, plain text).
Adiante nas mensagens de e-mails do usuário ―pirrip‖, é observado um e-mail automático
para lembrete de credenciais, onde a senha do usuário é novamente passada em plain text. Como
mostra a Figura 64, a senha do usuário ―pirrip‖ foi identificada como ―0l1v3rTw1st‖.
Figura 75. Mensagem de e-mail automática de lembrete de senha do usuário "pirrip"
116
Com a identificação da senha do usuário, pode-se executar ações privilegiadas através do
comando ―sudo‖. Pode-se alterar o arquivo /etc/shadow fazendo com que a senha criptografada do
usuário ―pirrip‖ seja a mesma do usuário ―root‖. Com um editor de texto, como por exemplo, o
―vi‖, altera-se o arquivo /etc/shadow e ao solicitar a senha utiliza-se a credencial ―0l1v3rTw1st‖
adquirida anteriormente. A alteração a ser feita é copiar a linha correspondente ao usuário ―pirrip‖
alterando o nome do usuário para ―root‖. O conteúdo do arquivo alterado é demonstrado na Figura
76.
Figura 76. Arquivo /etc/shadow alterado
117
Observa-se na Figura 76 que as linhas 1 e 22 possuem a mesma senha criptografada mas
para usuários diferentes. Com estas alterações pode-se alterar o nível de privilégios realizando
autenticação do usuário ―root‖ com o comando ―su‖, o resultado é demonstrado na Figura 77.
Figura 77. Acesso com usuário ―root‖ obtido
Com o acesso privilegiado do usuário ―root‖ obtido é alcançado o objetivo deste roteiro para
o cenário. As etapas para manter acesso ao sistema e limpeza de evidencias fogem do escopo deste
roteiro.
118
D FLUXOGRAMA DE ROTEIRO DE TESTE DE PENETRAÇÃO
Identificação de Vulnerabilidades
Varredura de
portas em uma
rede
Varredura de
portas de um IP
específico
Análise de
vulnerabilidades
Vulnerabilidades
Identificadas?
Dados para
próxima
etapa
Sim
Verificação de
serviços (HTTP,
FTP..)
Dados para
próxima
etapa
Busca-se informações que possam ser
utilizadas para explorar falhas, como
nomes de usuários, e-mails, etc.
Figura 78 – Fluxograma: Identificação de Vulnerabilidades
119
Verificação e exploração de Vulnerabilidades
Verificação de
Vulnerabilidades
Vulnerabilidades
são exploráveis?
Obtêm-se acesso
remoto?SimAcesso Remoto
obtidoSim
Suscetível a força
bruta?Não
Sim
Repositórios de Exploits
Não
Não
Utilização de aplicativos
quebradores de senha
Uso de Exploits públicos,
ferramentas de pentesting
Máquina não
vulnerável
Figura 79 - Fluxograma: Verificação e exploração de Vulnerabilidades
120
Obter acesso privilegiado ao sistema
Recolhe
Informações do
Sistema
Vulnerável para
escalonação de
privilégio?
Sim
Não
Acesso privilegiado ao
sistema
Informações capazes de
obter acesso privilegiado?
Sim
Não
Sim
Vulnerabilidade
explorada?
NãoSim
Força bruta
Não
Utilização de aplicativos
quebradores de senha ou alterações
de configurações
Identificação de Vulnerabilidades
capazes de obter acesso privilegiado
ao sistema
Exploits públicos (Privilege
escalonation, Root Local Exploit)
Máquina não
vulnerável
Figura 80 - Fluxograma: Obter acesso privilegiado ao sistema
