Jump to content
  • Sniffing com o Wireshark

       (0 reviews)

    Fernando Mercês
     Share

    O Wireshark é um dos sniffers eanalisadores de tráfego de rede mais conhecidos atualmente. Ficou muito famoso com seu antigo nome, Ethereal. Além de ter uma ótima interface gráfica, também possui uma interface em linha de comando muito poderosa. Neste artigo vamos ver como são frágeis os sistemas de login em texto puro. Sniffaremos uma tentativa de login num servidor FTP e num site HTTP, que inclusive, é o nosso. :) 

    Um sniffer coloca a interface de rede da máquina onde está instalado em modo promíscuo, neste modo a interface capturará qualquer pacote que receba, mesmo os não destinados a ela. Normalmente as interfaces de rede descartam os pacotes que não são destinados à elas. É o famoso broadcasting de pacotes.

    Há também sniffers que não colocam a interface em modo promíscuo (para não serem detectados) mas neste caso, a máquina com o sniffer instalado tem que ficar entre os comunicantes e não só na mesma estrutura de rede.

    Outro detalhe é que um hub sempre manda o pacote que recebe por uma porta para todas as outras portas, o que facilita o sniffing. Já os switchs, não fazem isso (na verdade fazem só na primeira vez em que são ligados na rede e estão escrevendo sua tabela ARP. Depois mantêm tal tabela até ser desligado da energia). Mas não é impossível sniffar numa rede só com switchs, só é mais difícil.

    O primeiro passo é saber onde instalar o Wireshark. Este passo é muito importante pois definirá o sucesso na captura de pacotes. Atente para as disposições da máquina onde estará o Wireshark. Se for uma rede Ethernet concentrada por um hub, a máquina que rodará o Wireshark poderá ficar em qualquer lugar, basta ser conectada ao hub:

    hub.jpg.c7c97ed14aa3c9a515c230ca55463ac7.jpg

    Já que o hub envia todo o tráfego em broadcast, qualquer máquina recebe todo o tráfego da rede, então basta que a interface de uma delas esteja em modo promíscuo (Wireshark instalado e rodando) para que o sniffing tenha sucesso.

    Se o concentrador central de sua rede for um switch, você poderá colocar um hub entre o servidor e o switch e conectar uma máquina com o Wireshark neste hub. Assim, toda comunicação entre servidor e rede passará pela máquina com o Wireshark. Veja a imagem a seguir:

    switch.jpg.30fe316db54e54fbf04c88ea36048046.jpg

    Há outras maneiras de se fazer o sniffing com switchs, principalmente se o switch for configurável (que possibilita port spanning). Mas deixaremos tal discussão para outra hora. Pode-se discutir sobre assunto em nosso fórum também.

    Instalação do Wireshark

    Depois de escolhida a máquina onde será instalado o Wireshark, vamos para sua instalação, que pode ser feita de várias maneiras (baixando e compilando seu código-fonte, baixando sua instalação, instalando via repositório para sistemas baseados em Linux, etc).

    Como sempre, utilizei o Ubuntu para escrever este tutorial. No Ubuntu a instalação é fácil, basta comandar:

    $ sudo apt-get install wireshark

    Abra o Wireshark e clique no primeiro botão, entitulado "List available capture interfaces...". A janela que abrir mostrará uma lista com as interfaces de rede da máquina. Aqui a minha disposição na rede é como mostra a figura abaixo:

    rede.jpg.418f6fa07058cf01421524a4103a8b86.jpg

    Perceba que tenho o Wireshark instalado na máquina que dá acesso ao servidor. As outras duas máquinas estão conectadas ao servidor principal através dela.

    Captura dos pacotes

    Uma das máquinas tem o IP 192.168.0.23, e é através dela que vou acessar a internet e abrir um site FTP e um HTTP para que a máquina com o Wireshark capture os pacotes de tais conexões.

    Voltando ao Wireshark, escolhi a minha conexão eth1 (192.168.0.5) que é a placa de rede da máquina onde o Wireshark está instalado, que está ligada ao switch do esquema acima.

    list.png.f817acf183c990fb8456c51e04c28b57.png

    Ao clicar em "Start", inicia-se a captura dos pacotes. Então, a partir da máquina 192.168.0.23, acessei o site FTP da Asus (ftp.asus.com) para uma tentativa de login. Fui pelo próprio comando FTP do Windows 98:

    c:\> ftp ftp.asus.com

    E inseri o nome de usuário fernando e password 3966lop98. Obviamente recebi um erro de falha no login. Neste momento podemos clicar no botão Stop (quarto botão da barra do Wireshark).

    Vamos analisar o que o Wireshark capturou:

    ftpasus1.thumb.png.f9e64ebcb241dd23f570888968885fa1.png

    Perceba que no pacote de número 14, há menção ao meu nome de usuário no comando USER do FTP. É importante conhecer o protocolo que será analisado para obter bons resultados com o sniffing.

    No pacote 16 o servidor da Asus me informa que preciso informar um password. E nos pacotes 18 e 19, abro uma conexão TCP e envio meu password com um comando PASS, respectivamente.

    Veja que o argumento do comando PASS é 3966lop98, que é justamente o password que informei através da máquina 192.168.0.23!

    O protolo FTP transmite os comandos e argumentos em texto puro. É extremamente inseguro e em seu lugar é recomendável utilizar o SFTP (Secure File Transfer Protocol).

    Claro que foi uma transmissão pequena e premeditada. Se fôssemos analisar diante de vários milhares de pacotes, seria difícil achar manualmente o pacote que se relaciona com o login. Para isso existem os filtros personalizados e montados com expressões regulares pelo próprio Wireshark. Usaremos um filtro no próximo sniffing, que será HTTP.

    Sniffing em login do Mente Binária

    Agora vamos acessar um site a partir da máquina 192.168.0.23 para analisarmos os pacotes. Seguindo a mesma lógica do item anterior, vamos capturar os pacotes até que o login seja efetuado. Loguei com um usuário. Vamos descobrir quem é (e sua senha) através do Wireshark.

    A análise de pacotes retornou 742 pacotes até eu clicar em Stop. Não vamos olhar um a um e sim usar um filtro.

    No campo "Filter", digite: "http matches POST" (sem aspas, respeitando a caixa). E clique em "Apply".

    Vamos ver o resultado:

    mb.thumb.png.a51d27a1436ebd32c58ff9e18c2e3848.png

    Veja que filtramos só para pacotes HTTP que contenham o comando POST. Este é um comando de formulário HTTP (comumente usado em logins). É o comando dado pelo botão "Enviar" do nosso site. No pacote de número 150, vemos o nome de usuário e a senha sendo enviados para o servidor de nosso site!

    Conclusão

    Espero que o propósito deste artigo tenha sido atingido: mostrar que alguns protocolos são facilmente vulneráveis. Com um rápido sniffing, podemos reunir informações que seriam suficientes para um invasor se apossar de um conta da vítima. Teste o Wireshark em sua rede, veja como ele se comporta capturando pacotes HTTPS, SFTP, SSH, etc, que são protocolos seguros. Veja que as informações estarão encriptadas.


    Revisão: Leandro Fróes
     Share


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By Jordan Bonagura
      Este artigo objetiva demonstrar, de maneira simplificada, diferentes abordagens para interceptação e captura de dados de tráfego de rede originários de um dispositivo iPhone, da Apple. Na verdade o iPhone não é o único dispositivo sujeito a estas abordagens, assim como as estratégias aqui apresentadas não são as únicas capazes de realizar tais interceptações, então é possível usar este conteúdo para muitas outras aplicações, mas vou focar no iPhone por agora. 🙂
      A maneira mais simples de capturar o tráfego de rede de um iPhone é utilizando um servidor proxy. Na primeira parte deste artigo, adotaremos o Burp Suite para exemplificar este funcionamento. Após a coleta dos dados, analisaremos os pacotes de uma aplicação específica e a suas conexões com serviços web.
      Caso o objetivo seja uma análise mais detalhada do tráfego de uma aplicação que utilize outras tipos de comunicação que não somente requisições web, podemos diversificar a estratégia e utilizar uma interface de rede virtual (RVI), conforme demonstraremos na segunda parte deste artigo.
      Parte 1 - Utilizando um servidor proxy - Burp Suite
      Quando mencionamos a utilização de um servidor proxy, estamos basicamente nos referindo a interceptar e analisar solicitações relacionadas ao protocolo HTTP (HyperText Transfer Protocol), seja este com a camada de segurança TLS (Transport Layer Security) ou não.
      Algumas das aplicações que temos em nossos smartphones ainda utilizam somente o protocolo HTTP, o que significa dizer que os dados trafegam na forma de texto puro, ou seja, sem qualquer criptografia, fazendo com que informações sensíveis fiquem totalmente expostas a qualquer atacante que adotar técnicas de interceptação.
      Para configuração de nosso proxy o primeiro passo é abrirmos o Burp Suite. Por padrão, a interface em que ele escuta é a local (127.0.0.1) na porta 8080, conforme podemos verificar na imagem abaixo:

      Figura 1 - Interface padrão de escuta do Burp Suite
      No Burp Suite, toda captura está por padrão relacionada a máquina local, porém para executarmos nossa estratégia de interceptação dos dados que chegarão ao nosso servidor por meio do iPhone, precisaremos adicionar o IP interno da máquina local no campo Specific address:

      Figura 2 - Mudando a interface de escuta do Burp Suite
      Veja que neste caso adotamos o endereço IP 192.168.1.102 e a porta 8081.
      Uma vez o Burp Suite configurado, vamos ao iPhone:

      Figura 3 - Habilitando o uso de um servidor proxy no iPhone
      Perceba que o endereço IP associado ao iPhone não tem relação alguma com o servidor proxy, porém é óbvio que terão que estar na mesma rede para que o tráfego possa ser capturado. 😉

      Figura 4 - Configurações de proxy no iPhone
      Assim que finalizamos a configuração do iPhone para utilizar o Burp Suite como o nosso servidor proxy, já podemos ver alguns pacotes. Isso ocorre pois diversas aplicações ficam rodando em background, normalmente atualizações, updates de e-mails, entre outros.
      Abaixo temos um exemplo de pacote interceptado com o método POST do HTTP em conexão com o office365.com para atualização de e-mail. Reparem que o DeviceType já é identificado como sendo um iPhone.

      Figura 5 - Tráfego recebido pelo Burp Suite
      Para demonstração foi utilizado um aplicativo real da área da saúde, mais precisamente de uma empresa de assistência médica. Por questões éticas, ocultei os dados.
      Podemos analisar que quando abrimos o aplicativo em nosso smartphone, já são executadas chamadas à API num servidor para troca de informações e com isto já visualizamos os pacotes conforme imagem abaixo:

      Figura 6 - Chamadas à API capturadas pelo Burp Suite
      Apesar de ser uma aplicação de necessidade de alto nível de sigilo de informações, os dados são trafegados em texto puro, ou seja, sem nenhuma criptografia envolvida. 😞
      Conforme podemos verificar na imagem abaixo, não estamos ainda falando de credenciais de acesso, mas de todo modo são dados sensíveis, como por exemplo o número de beneficiário e telefone.

      Figura 7 - Dados sensíveis exibidos no Burp Suite
       
      Infelizmente, nesta aplicação não só os dados sensíveis anteriormente destacados são trafegados em texto plano, mas as credenciais de acesso (usuário e senha) também. Veja:
       
      Figura 8 - Credenciais em texto plano capturadas pelo Burp Suite
      Isso significa dizer que se um atacante estiver na conectado na mesma rede que nós, por exemplo uma rede wifi aberta (sem criptografia) de aeroporto, cafeteria e afins, e estivesse rodando um analisador de tráfego como este, poderia ter acesso à nossas credenciais como nome de usuário e senha. 😬
      Parte 2 - Utilizando uma interface de rede virtual (RVI) - Wireshark
      Uma outra abordagem que pode ser as vezes mais interessante é poder analisar todo o tráfego de rede que ocorre entre o dispositivo iPhone e os servidores das aplicações, agora não mais focado somente em aplicações e requisições web (HTTP), mas sim em diferentes protocolos, como por exemplo o bom e velho MSN para fins de aprendizagem, onde é possível analisar os pacotes MSNP trafegando pela rede, bem como conexões com outros dispositivos mais simples que utilizam o protocolo SNMP, por exemplo. Não há limites. 🙂
      Iniciamos com a conexão do nosso iPhone via USB ao computador que rodará o Wireshark para a coleta dos dados. Na sequência, realizaremos a criação da RVI (Remote Virtual Interface) onde necessitaremos passar como parâmetro o UUID (Universal Unique Identifiers) do iPhone. Vale lembrar que é possível obter o UUID com qualquer sistema operacional, já para criar a RVI executei o teste somente em macOS. Deixo para você verificar se é possível fazê-lo em outros sistemas, caso queira.
      Pelo próprio Finder do macOS é possível descobrir o UUID do aparelho, basta clicar no nome do dispositivo conectado e surgirá a informação conforme imagem abaixo:

      Figura 9 - UUID exibido no Finder
      Tendo o UUID do aparelho e estando este conectado, se faz necessário ativar a interface virtual (RVI), através do seguinte comando:

      Figura 10 - Criando uma RVI no shell do macOS
      Após recebermos a mensagem de sucesso como acima, estamos com a interface ativada e então poderemos seguir para a abertura do analisador de tráfego de rede Wireshark e selecionar a interface rvi0.

      Figura 11 - Escolha da interface para captura no Wireshark (no macOS)
      Nesta abordagem, e até para fins de comparação com a anterior, adotamos o mesmo aplicativo da área da saúde e aplicamos um filtro básico ip.src == 192.168.1.23 para facilitar a visualização somente de pacotes que têm o IP de origem do iPhone.
      É possível visualizarmos protocolos de diferentes camadas do modelo OSI. Neste exemplo, temos protocolos da camada de transporte (TCP) como também da camada de aplicação (HTTP) como pode ser visto na imagem abaixo:

      Figura 12 - Pacotes capturados pelo Wireshark
      Analisando somente os pacotes HTTP, é possível analisar as mesmas informações que visualizamos anteriormente no Burp Suite.
      Portanto, se abrirmos o conteúdo de nosso pacote selecionado, teremos também todas as informações de credenciais anteriormente demonstradas, conforme imagem abaixo:
       
      Figura 13 - Credenciais em texto plano capturadas pelo Wireshark
      Conclusão
      Pudemos verificar que existem diferentes abordagens em relação a captura de tráfego de dados de um iPhone. Na primeira parte, demonstramos a técnica com a adoção de um servidor proxy (Burp Suite), onde foi possível analisar os pacotes relacionados a requisições web. Esta técnica é de mais fácil implementação, porém muitas vezes limitada, pois como discutimos anteriormente trabalha basicamente com protocolos HTTP/HTTPS.
      Já na segunda parte, demonstramos uma análise de maior amplitude onde foi possível verificar que protocolos de diferentes camadas também podem ser analisados, portanto, a depender do objetivo almejado e/ou da forma de comunicação da aplicação, esta abordagem pode ser mais adequada.
      Vale lembrar que ambas as técnicas são complementares, portanto, dependendo do objetivo final de análise da aplicação, ambas podem ser combinadas.
      O caminho das pedras para a configuração do ambiente de captura está aí, agora é contigo em seguir para a análise aprofundada de suas aplicações. 🤗
      Stay Safe!
    • By Fernando Mercês
      Tecnologias e Redes de Computadores / Vanderlei de Freitas Junior; Guilherme Rodrigues de Campos; Vitória Rodrigues dos Santos (Orgs.).
      – 5. Ed. -- Sombrio: Instituto Federal Catarinense, 2019.
      317 f.:il. color.
      ISBN: 978-85-5644-044-0
      1. Redes de Computadores. 2. Tecnologia da Informação e Comunicação.I. Freitas Junior, Vanderlei de. II. Rodrigues de Campos, Guilherme. III. Rodrigues dos Santos, Vitória. IV. Instituto Federal Catarinense. V. Título.
    • By void_
      https://bookauthority.org/books/new-networking-books
      E aí, concordam com a lista acima? Confesso que muitos títulos me chamaram a atenção, mas antes de fazer algum movimento imprudente ($$), gostaria de ouvir alguma opinião de alguém que possa ter tido a oportunidade de ter comprado, lido, analisado, etc., um ou mais dos títulos da lista. Se alguém puder fornecer algum pdf, mesmo que seja prévia, também serei grato.
      P.S: Os livros de C e Python particularmente me interessaram...
    • By void_
      Alguém já experimentou esses simuladores/emuladores de redes como GNS, Imunes, etc.?
      Caso positivo, poderiam me dizer se vale a pena usá-los para estudos e testes e, caso sim (mais uma vez), poderiam me recomendar algum em particular?
      Encontrei alguns nomes que me interessaram nessa lista, mas sinceramente não sei por qual me decidir.
      Desde já, muito obrigado ?
      P.S: Mininet é facilmente encontrado com o apt-cache. Pode ser um ponto de partida, mas vou esperar a opinião de vocês.
    • By AndreAlves
      Um pouco depois das revelaçōes de Edward Snowden sobre monitoração generalizada da internet por entidades governamentais, a IETF (Internet Engineering Taskforce - uma comunidade de gente interessada na engenharia da internet) criou um grupo de trabalho para rever a privacidade do DNS e o nomeou "DPRIVE" - abreviação para DNS Privacy.
      Pensar em jeitos de tornar as resoluçōes deste protocolo tão fundamental menos manipuláveis e mais secretas sem perder muita velocidade é o abacaxi que foi dado a esse grupo, que tem trabalhado bastante e gerado alguns frutos.
      Mais recentemente um deles ficou mais conhecido entre nós quando a Cloudflare lançou um serviço de DNS focado em privacidade e rapidez e anunciou suporte a uma das propostas do IETF para DNS seguro-privado-rápido , o DOH (DNS over HTTPS), que dá nome à este artigo.
      A sacada do DOH é possibilitar queries (consultas) DNS criptografadas (tchau entidades governamentais tentando espionar ?) que são difíceis de diferenciar de outros tráfegos criptofragados (tchau provedores tentando fazer bandwith throttling ou traffic shaping).
      Mas afinal, como isto funciona?
      Basicamente as queries DNS se tornam um request HTTP do tipo POST ou GET para uma URL definida pelo serviço de DNS. Essas requests são trafegadas dentro de uma sessão TLS e formatadas como JSONs codificados em base64. No JSON temos os campos definindo o tipo do registro a ser consultado (A, CNAME, AAA, etc).
      Para visualizar aqui vai um exemplo de solicitação de uma query para resolver o nome www.exemplo.com usando o método POST, tirado direto do rascunho da RFC:
      :method = POST :scheme = https :authority = dnsserver.example.net :path = /dns-query accept = application/dns-udpwireformat content-type = application/dns-udpwireformat content-length = 33 E o conteúdo de 33 bytes da query:
      00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 Não é lindo? Sim é. Mas se você quiser usar por enquanto terá que se aventurar. Um dos poucos (único?) navegadores que suporta este recurso é o Firefox em sua versão Nightly (sai um novo release toda noite!). Para configurar, os passos são:
      Digite about:config na barra de endereços e pressione [ENTER]. Altere o valor dos seguintes parâmetros de acordo: netowrk.trr.bootstrapAddress: 1.1.1.1 network.trr.uri: https://mozilla.cloudflare-dns.com/dns-query network.trr.mode: 2 (usa DOH primariamente, mas faz fallback pro DNS atual) Outros projetos utilizando DOH estão surgindo no Github. O DNS-over-HTTPS proxy, por exemplo, cria um proxy de modo que as consultas DNS sejam redirecionadas para o serviço do Google que suporta DOH.
      O mais legal é que a preocupação com privacidade e liberdade individual continuará a resultar em mais projetos como este para salvar nossa internet de quem se acha dono dela. ?
      Se você ficou interessado, dá uma pesquisada nos outros candidatos a DNS seguro:
      DNS over TLS (RFC 7858) DNS over DTLS (RFC 8094) DNS over QUIC (ID-draft) DNS over DNSCrypt (independente) DNS over TOR (independente)
×
×
  • Create New...