Introdução ao Wireshark: Detecção e captura de tráfego em redes

A captura de tráfego em redes pode trazer informações úteis de outras máquinas conectadas nela. Em um pentest interno, podemos simular uma ameaça interna ou um atacante que tenha descoberto uma brecha no perímetro, capturando o tráfego de outros sistemas na rede e pode nos dar informações adicionais interessantes (inclusive usuários e senhas) que podem nos ajudar na fase de exploração. O problema de capturar o tráfego é a quantidade de dados que pode ser produzido. Pouco tempo de captura em uma rede pode inundar o Wireshark com dados que tornam difícil a vida do pentester em descobrir o que realmente é útil. Veremos a seguir como manipular uma rede para pegar acesso ao tráfego que não conseguimos ver.

Relembrando conceitos de redes antes de capturar tráfego

Se você achar que uma rede utiliza hubs ao invés de switches, capturar tráfego não direcionado para a sua máquina será fácil, porque quando um hub de rede recebe um pacote, ele repassa para todas as portas, deixando cada dispositivo decidir se o pacote pertence a ele mesmo. Em uma rede com hub, captura o tráfego de outro é fácil como usar o modo promiscuous em todas as interfaces do Wireshark. Isto faz com que o Network Interface Controller (NIC) pegue tudo o que ele ver, o que em uma rede com hub será todos os pacotes.

Diferente dos hubs, switches enviam tráfego somente para os sistemas de forma direcionada, então em uma rede com switch, não seremos capazes de ver, por exemplo, todo o tráfego de um canto para outro sem manipular a rede fazendo com que envie para nós o tráfego. Maioria das redes que você encontra em pentests provavelmente serão com switches, mesmo com dispositivos legados que se dizem hubs, poderão ter funcionalidades de switch.

Redes virtuais atuam como hubs, porque todas as máquinas virtuais compartilham um único dispositivo físico. Se você capturar o tráfego em modo promiscuous em uma rede virtual, você será capaz de ver o tráfego de cada uma das máquinas virtuais, assim como da máquina host, mesmo que esteja utilizando um switch no lugar de um hub em seu ambiente físico. Para simular uma rede não virtualizada, nós desativaremos o modo promiscuous de todas as interfaces no Wireshark, o que significa que teremos um pouco mais trabalho para capturar o tráfego de uma máquina virtual como alvo.

Usando o Wireshark

Wireshark é uma analisador de protocolos de rede de forma gráfica, que nos permite aprofundar em cada pacote que se move em uma rede. Wireshark pode ser usado para capturar pacotes Ethernet, wireless, bluetooth e outros tipos de tráfego. Ele pode decodificar diferentes protocolos que ele vê, então você poderá, por exemplo, reconstruir o áudio de uma ligação Voice over IP (VoIP). Veremos o básico de como capturar e analisar o tráfego com esta ferramenta.

Capturando o tráfego

Começaremos iniciando o Wireshark para capturar nossa rede local. Inicie o Wireshark no Kali como root usando o comando abaixo. Clique para continuar em qualquer alerta que você possa receber sobre usar o Wireshark como root.

root@kali:~# wireshark

Diga ao Wireshark para capturar na interface da rede local (eth0) selecionando a opção Capture > Options. Clique em Manage Interfaces… e deixe marcado apenas a interface eth0, como mostrado na figura abaixo e clique em Ok.

Wireshark - Manage Interfaces - eth0

Wireshark – Manage Interfaces – eth0

Na tela Options, lembre-se de desmarcar a opção Enable promiscuous mode on all interface para simular um ambiente físico com switch. Feche o menu Options.

Wireshark - Capture Options

Wireshark – Capture Options

Finalmente, clique em Capture > Start para começar a captura do tráfego, ou clique no símbolo azul do lado esquerdo. Veja a figura:

Wireshark - Capture Start

Wireshark – Capture Start

Para ficar mais claro um tráfego que podemos capturar em uma rede com switch, vamos fazer uma conexão FTP com o servidor público da Adobe (ftp.adobe.com), utilizando o usuário anonymous e senha ftpuser@adobe.com. Abra um terminal do Kali e execute a sequência de comandos em amarelo. Veja que na tela do Wireshark por trás, ele estará capturando o tráfego da conexão.

Wireshark - Capturando tráfego FTP

Wireshark – Capturando tráfego FTP

Você poderá ver os pacotes no Wireshark de um sistema com o endereço IP da sua máquina para o servidor ftp da Adobe, e vice versa, onde na coluna Protocol está como FTP. O Wireshark está capturando o tráfego que está se movendo entre o Kali e o servidor.  Caso outra máquina conectada em sua rede tente se conectar no servidor FTP, você não conseguirá capturar nada, pois em nosso ambiente com switch simulado, qualquer tráfego não designado para o nosso Kali não será visto pela interface de rede e, então, não será capturada pelo Wireshark. Para conseguir isto, você precisaria fazer um ataque chamado “ARP Cache Poisoning”.

Wireshark - Tráfego FTP capturado

Wireshark – Tráfego FTP capturado

Filtrando o tráfego

O grande volume de tráfego de rede capturado pelo Wireshark pode ser um pouco esmagador, porque, além de nosso tráfego FTP, todos os outros pacotes indo e vindo a partir do Kali é capturado. Para encontrar pacotes interessantes de forma específica, podemos usar filtros no Wireshark. O campo Filter está localizado no canto superior esquerdo da
da tela principal do Wireshark. Como um primeiro exemplo de filtragem Wireshark muito simples, vamos olhar para todo o tráfego que utiliza o protocolo FTP. Digite ftp no campo Filter e dê ENTER, como mostrado abaixo.

Wireshark - Filtrando tráfego FTP

Wireshark – Filtrando tráfego FTP

Como esperado, Wireshark filtra os pacotes capturados para mostrar apenas aqueles que usam o protocolo FTP. Podemos ver toda a nossa conversa FTP, incluindo suas informações de login, em texto simples.

Podemos usar filtros mais avançados para ser mais específico com os pacotes desejados. Por exemplo, podemos usar o filtro ip.dst == 193.104.215.67 para retornar somente pacotes com o endereço IP de destino 193.104.215.67. Podemos até encadear filtros, como o uso do filtro ip.dst == 193.104.215.67 e ftp para encontrar apenas o tráfego FTP destinado para 193.104.215.67.

Wireshark - Filtrando tráfego FTP e IP de destino

Wireshark – Filtrando tráfego FTP e IP de destino

Seguindo um fluxo de conexão TCP

Mesmo após filtrar o tráfego, podem haver várias conexões FTP capturados durante o mesmo período de tempo, por isso ainda pode ser difícil dizer o que está acontecendo. Mas uma vez que encontramos um pacote interessante, tais como o início de uma conexão FTP, podemos aprofundar a conversa clicando no pacote com o botão direito do mouse e selecionando Follow > TCP Stream.

Wireshark - Follow TCP Stream

Wireshark – Follow > TCP Stream

A tela de resultado mostrará o conteúdo completo da conexão FTP, incluindo as credenciais em texto claro.

Wireshark - Follow TCP Stream - Resultado

Wireshark – Follow TCP Stream – Resultado

Dissecando pacotes

Ao selecionar um pacote específico capturado, podemos obter mais informações sobre os dados captados, tal como mostrado abaixo. Na parte inferior da tela do Wireshark, você pode ver os detalhes do pacote selecionado. Com um pouco de orientação, Wireshark vai quebrar os dados para você. Por exemplo, podemos facilmente encontrar a porta de destino TCP selecionando a entrada TCP e procurando a porta de destino, conforme destacado na figura. Quando selecionar este campo, a entrada nos bytes brutos do pacote é destaque também.

Wireshark - Dissecando pacotes

Wireshark – Dissecando pacotes

ARP Cache Poisoning

Embora seja bom ver os detalhes do nosso próprio tráfego, para fins de pentesting, é preferível ver o tráfego que não foi destinado para o nosso sistema Kali. Talvez sejamos capazes de capturar sessão de login de outro usuário que
usa uma conta diferente de anônimo para logar; que nos daria credenciais que funcionem em um servidor de FTP, bem como um conjunto de credenciais que possa ser reutilizado em outras partes do ambiente.

Para capturar o tráfego não destinado ao sistema de Kali, precisamos encontrar alguma maneira de ter os dados relevantes enviados para o nosso sistema de Kali. Como o switch de rede irá enviar apenas os pacotes que pertencem a nós, precisamos enganar nossa máquina de destino ou o switch (ou ambos) em crer que o tráfego pertence a nós. Iremos realizar um ataque conhecido como man-in-the-middle, o que nos permitirá redirecionar o tráfego e intercepção entre dois sistemas (outros que não sejam do nosso próprio sistema) antes de encaminhar os pacotes para o destino correto. Um técnica que aparece como outro dispositivo na a rede é chamado Address Resolution Protocol (ARP) cache poisoning (tambémconhecido como ARP spoofing).

Básico sobre ARP

Quando conectamos em outra máquina em nossa rede, nós geralmente usamos o hostname, FQDN (fully qualified domain name) ou endereço IP. Antes do pacote poder ser enviado de nosso Kali para uma máquina alvo, o Kali deve mapear o endereço IP da máquina alvo com o seu endereço MAC (endereço física da interface de rede), assim o Kali saberá para onde enviar o pacote. Para isto, ele usa o ARP para broadcast com a pergunta “Quem tem IP 192.168.0.10?” na rede local. A máquina com o endereço IP correspondente responde, “Eu tenho 192.168.0.10 e meu endereço MAC é 00:0c:29:e5:f1:35.”. Nosso Kali vai guardar esta informação no seu mapa de endereços, o ARP cache.

Quando ele enviar o próximo pacote, nossa máquina vai verificar primeiro em seu ARP cache por um registro para o IP 192.168.0.10. Se achar algum, ele usará este registro como o endereço da máquina alvoao invés de enviar outro ARP broadcast. Os registros no ARP cache são constantemente atualizados porque a topologia da rede pode mudar de tempos em tempos. Então, os sistemas regularmente irão enviar ARP broadcasts enquanto seus caches são atualizados. Esse processo virá a calhar quando formos executar um ARP cache poisoning.

ARP resolution process

ARP resolution process

Para ver a execução do ARP cache do Kali, entre com o comando arp no filtro do Wireshark. Na figura a seguir, você verá que o único mapeamento do endereço IP para o MAC é o do IP 10.0.2.2, o gateway padrão (máquina host).

Wireshark - ARP

Wireshark – ARP

Caso queira ver o mapeamento através do próprio Kali, abra o terminal e execute o comando arp.

root@kali:~# arp
Endereço       TipoHW   EndereçoHW           Flags Mascara   Iface
gateway        ether    00:23:69:f5:b4:29    C               eth0

Caso novas máquinas entrem na rede e a sua máquina comece a interagir, realizando alguma conexão, ele irá acrescentar em seu ARP cache o registro da nova máquina.

O problema com o processo de resolução ARP é que qualquer dispositivo pode responder a uma requisição de informações sobre o MAC de um IP, até mesmo uma máquina que tenha outro endereço IP. A máquina alvo vai aceitar a resposta, de qualquer forma.

Em poucas palavras, isto é o ARP cache poisoning. Enviamos uma série de ARP reply para dizer ao nosso alvo que somos outra máquina na rede. Assim, quando o alvo envia o tráfego destinado a essa máquina, em vez disso,
enviará os pacotes diretamente para nós para ser pego pelo nosso sniffer de tráfego, como mostrado
na figura abaixo.

Quando iniciamos a captura do tráfego da conexão FTP, a nossa máquina Kali se conectou com o servidor direto, mas poderia ser uma outra máquina na rede se conectando com o servidor. O Kali poderia atuar como uma máquina atacando ao estilo man-in-the-middle após fazer o ARP cache poisoning, assim poderíamos enganar os dois
sistemas para enviar seu tráfego para a nossa máquina de Kali, para ser capturado no Wireshark.

Wireshark - ARP cache poisoning redirecionando o tráfego através do Kali

Wireshark – ARP cache poisoning redirecionando o tráfego através do Kali


IP Forwarding

Mas antes que possamos enganar uma máquina alvo e capturar o seu tráfego, e com sorte suas credenciais de acesso, é preciso ativar o IP Forwarding para dizer ao nosso Kali para encaminhar todos os pacotes estranhos que recebe ao destino apropriado. Sem o IP Forwarding, vamos criar uma condição de negação de serviço (DoS) em nossa rede, onde os clientes legítimos são incapazes de acessar os serviços. Por exemplo, se tivéssemos que usar o ARP cache poisoning sem IP Forwarding para redirecionar o tráfego da máquina alvo, com destino ao servidor FTP,
a nossa máquina Kali, faria que as máquinas nunca recebem os pacotes entre elas.

A configuração de IP Forwarding no Kali está em /proc/sys/net/ipv4/ip_forward. Precisamos definir este valor para 1.

root@kali:~# echo 1 > /proc/sys/net/ipv4/ip_forward

Antes de começar o ARP cache poisoning, observe o registro da máquina alvo Windows XP (192.168.20.10) no cache ARP da máquina Linux. Este valor mudará para o endereço MAC da máquina Kali depois que começar o ARP
cache poisoning.

diego@ubuntu:~$ arp -a
? (192.168.20.1) at 00:23:69:f5:b4:29 [ether] on eth2
? (192.168.20.10) at 00:0c:29:05:26:4c [ether] on eth0
? (192.168.20.9) at 70:56.81:b2:f0:53 [ether] on eth2

ARP Cache Poisoning with Arpspoof

Uma ferramenta fácil de usar para realizar este ataque é o Arpspoof. Para usar Arpspoof, devemos dizer a interface de rede que será utilizada, o alvo do nosso ataque de ARP cache poisoning, e o endereço IP que gostaria de se mascarar. Se vocês deixar de fora o alvo, você vai envenenar toda a rede. Para o nosso exemplo, para enganar o alvo Linux em pensar que o Kali é a máquina Windows XP, precisamos definir a opção -i como eth0 para especificar a interface, a opção -t como 192.168.20.11 para especificar o alvo como o Linux, e 192.168.20.10 como o Windows XP, a máquina que eu quero fingir ser.

root@kali:~# arpspoof -i eth0 -t 192.168.20.11 192.168.20.10

Arpspoof imediatamente começa a enviar respostas ARP ao alvo Linux, informando-o de que a máquina Windows XP está localizado no endereço MAC da máquina Kali.  Registros de cache ARP são atualizados em diferentes momentos em diferentes implementações, mas um minuto é bom tempo de espera.

Para capturar o outro lado da conversa, precisamos enganar a máquina Windows XP para o tráfego de envio destinada ao alvo Linux através da máquina Kali. Inicie outra instância do Arpspoof, e desta vez defina o destino como a máquina de Windows XP e o destinatário como o Linux.

root@kali:~# arpspoof -i eth0 -t 192.168.20.10 192.168.20.11

Depois de começar ARP cache poisoning, verifique cache ARP do seu alvo Linux novamente. Observe que o endereço MAC associado com o Windows XP-alvo foi alterado para 70: 56: 81: b2: f0: 53. O alvo Linux deve enviar todo o
tráfego destinado para o Windows XP para a máquina Kali, onde nós podemos capturá-lo no Wireshark.

diego@ubuntu:~$ arp -a
? (192.168.20.1) at 00:23:69:f5:b4:29 [ether] on eth0
? (192.168.20.10) at 70:56:81:b2:f0:53 [ether] on eth0

Agora faça login no servidor FTP da máquina alvo Windows XP usando a máquina Linux usando outra conta.

diego@ubuntu:~$ ftp 192.168.20.10
Connected to 192.168.20.10.
220-FileZilla Server version 0.9.32 beta
220-written by Tim Kosse (Tim.Kosse@gmx.de)
220 Please visit http://sourceforge.net/projects/filezilla/
Name (192.168.20.10:diego): diego
331 Password required for diego
Password:
230 Logged on
Remote system type is UNIX.

Como temos o IP Forwarding ativado, aparentemente tudo funciona normalmente. Voltando ao Wireshark, vemos desta vez que é possível capturar o tráfego FTP e ler em texto claro as credenciais de login. A saída do Wireshark confirma que a máquina Kali está redirecionando o tráfego FTP entre os dois alvos. Após cada pacote FTP, existe um pacote de retransmissão.

Wireshark - Capturando informações do login

Wireshark – Capturando informações do login

Usando o ARP Cache Poisoning para impersonificar o Gateway Padrão

Podemos também usar o ARP cache poisoning para se passar como o gateway padrão em um tráfego de rede que entra e sai da rede, incluindo o tráfego destinado à Internet. Pare o processo do Arpspoof que você está executando e tente enganar a máquina Linux para rotear todo o tráfego para o gateway através da máquina de Kali, passando-se pelo gateway padrão, como mostrado abaixo.

root@kali:~# arpspoof -i eth0 -t 192.168.20.11 192.168.20.1
root@kali:~# arpspoof -i eth0 -t 192.168.20.1 192.168.20.11

Se começarmos a navegar na Internet a partir do alvo Linux, devemos ver pacotes HTTP sendo capturado pelo Wireshark. Mesmo se as informações sensíveis são criptografadas com HTTPS, ainda vai ser capaz de ver onde os usuários estão indo e qualquer outra informação enviada através de HTTP. Por exemplo, se fizer uma consulta no Google, o texto da consulta será capturado no Wireshark.

DNS Cache Poisoning

Além de ARP cache poisoning, também pode envenenar a entrada do cache do Domain Name Service (DNS) (mapeamentos de nomes de domínio para endereços IP) para encaminhar tráfego destinado a outro site para um que controlamos. Assim como ARP resolve IP para endereços MAC para a rota de tráfego adequadamente, o mapeamento de DNS (ou resolução) traduz nomes de domínio, tais como www.gmail.com para endereços IP.

Para chegar a outro sistema na Internet ou rede local, a nossa máquina precisa saber o endereço IP para se conectar. É fácil de lembrar a URL www.gmail.com se queremos visitar nossa conta de correio web, mas é difícil lembrar um grupo de endereços IP, o que pode até mesmo mudar regularmente. Resolução DNS traduz o nome de domínio legível em um endereço IP. Por exemplo, podemos usar a ferramenta Nslookup para traduzir www.gmail.com em um
endereço IP, como mostrado abaixo.

nslookup - www.gmail.com

nslookup – www.gmail.com

Como você pode ver, Nslookup traduz www.gmail.com a um número de IP, incluindo 172.217.29.37, tudo o que precisamos usar para acessar o Gmail. Para executar a resolução de DNS (figura abaixo), o nosso sistema
consulta seu servidor DNS local para obter informações sobre um nome de domínio específico, tais como www.gmail.com. Se o servidor DNS tem uma entrada de cache para o endereço, ele dá ao nosso sistema o endereço IP correto. Se não, consulta outros servidores DNS na internet procurando as informações corretas.

Quando o endereço IP correto é retornado, o servidor de DNS escreve de volta para a nossa máquina com a resolução endereço IP correta para www.gmail.com, e nosso sistema, em seguida, traduz www.gmail.com em 173.194.37.85, como mostrado na consulta feito acima. Os usuários podem então acessar www.gmail.com pelo nome sem ter de usar o endereço IP.

Resolução DNS

Resolução DNS

Iniciando

DNS cache poisoning funciona semelhante ao ARP cache poisoning: Nós enviamos uma séria de resoluções apontando para o IP errado para um determinar domínio.

Agora tenha certeza que o servidor Apache esteja rodando com o seguinte comando:

root@kali:~# service apache2 start
* Starting web server apache2 [ OK ]

Antes de usarmos a ferramenta de DNS cache poisoning, precisamos criar um arquivo que especifique os nomes DNS que gostaríamos de realizar spoof e para onde enviaremos o tráfego. Por exemplo, vamos supor que qualquer sistema que faça a resolução DNS para www.gmail.com que o endereço IP deste domínio  é o de nossa máquina Kali, adicionando um registro 10.0.2.15 www.gmail.com em um novo arquivo chamado hosts.txt.

root@kali:~# cat hosts.txt
10.0.2.15 www.gmail.com

Usando Dnsspoof

Reinicie Arpspoof entre o alvo Linux e o gateway padrão e vice-versa, conforme discutido anteriormente. Agora podemos começar a enviar tentativas de DNS cache poisoning usando a ferramenta de DNS spoofing dnsspoof, como mostrado abaixo.

root@kali:~# dnsspoof -i eth0 -f hosts.txt
dnsspoof: listening on eth0 [udp dst port 53 and not src 192.168.20.9]
192.168.20.11 > 75.75.75.75.53: 46559+ A? www.gmail.com

Especificamos a interface de rede que iremos usar e apontamos para o dnsspoof o arquivo hosts.txt que criamos antes, dizendo os valores para fazer spoof. Uma vez executando o dnsspoof, quando nós usamos o nslookup na máquina alvo Linux, o endereço IP retornado deve ser da nossa máquina Kali, como mostrado abaixo. O IP exibido não é o do Gmail.

diego@ubuntu:~$ nslookup www.gmail.com
Server: 75.75.75.75
Address: 75.75.75.75#53
Non-authoritative answer:
Name: www.gmail.com
Address: 192.168.20.9

Para demonstrar este ataque, configure um website para onde será direcionado o tráfego. O servidor Apache no Kali exibirá por padrão uma mensagem “It Works” para qualquer um que visite. Nós podemos mudar o conteúdo do arquivo index.html na pasta /var/www, mas a mensagem padrão “It Works” é o suficiente para o nosso propósito. Agora se navegarmos no endereço http://www.gmail.com/ do nosso alvo Linux, a url deverá exibir o endereço www.gmail.com, mas na realidade estaremos exibindo a página do nosso Kali. Nós podemos fazer este ataque ainda mais interessante clonando o site atual do Gmail (ou qualquer outro site que deseja) assim o usuário não notará a diferença.

DNS cache poisoning - Fake Gmail

DNS cache poisoning – Fake Gmail

Ataques SSL

Até agora, temos sido capazes de interceptar o tráfego criptografado, mas não tem sido capaz de obter qualquer informação sensível da conexão criptografada. Para este ataque seguinte, vamos contar com a vontade de um usuário clicar em um aviso de certificado SSL para executar um ataque man-in-the-middle e obter o texto de uma conexão Secure Sockets Layer (SSL), que criptografa o tráfego para protegê-lo de ser lido por um intruso.

Básico de SSL

O objetivo do SSL é fornecer segurança razoável de que qualquer informação sensível (tais como credenciais ou números de cartão de crédito) transmitidos entre o navegador do usuário e um servidor é seguro – incapaz de ser lido por um atacante malicioso ao longo do tráfego. Para provar que a conexão é segura, usam certificados SSL. Quando você navega para um site com SSL, o navegador solicita ao site para identificar-se com o seu certificado SSL. O site apresenta seu certificado, que o navegador verifica. Se o seu navegador aceitar o certificado, ele informa ao servidor, o servidor retorna um reconhecimento assinado digitalmente e a comunicação segura SSL inicia.

Um certificado SSL inclui um par de chaves de criptografia, bem como informações de identificação, como o nome do domínio e o nome da empresa que é dona do site. Um certificado SSL do servidor é geralmente o aval de um Autoridade Certificadora (CA), como a VeriSign ou Thawte. Navegadores vêm pré-instalados com uma lista de CAs confiáveis, e se o certificado SSL de um servidor é garantida por uma CA confiável, o navegador pode criar uma conexão segura. Se o certificado não é confiável, o usuário será alertado com um aviso que diz, basicamente, “A conexão pode ser segura, mas pode não ser. Proceda ao seu próprio risco.”

Usando Ettercap para ataques SSL Man-in-the-Middle

Em nosso ataque ARP cache poisoning, que faz o man-in-the-middled no tráfego entre o nosso Windows XP e Linux (assim como o alvo Linux e a Internet). Estes sistemas eram ainda capazes de se comunicar uns aos outros, mas o nosso sistema Kali foi capaz de capturar o tráfego. Nós podemos fazer a mesma coisa para atacar o tráfego SSL. Podemos quebrar a conexão segura SSL redirecionando o tráfego vindo e indo para www.facebook.com ao nosso sistema de Kali para que possamos interceptar informações sensíveis.

Para este exemplo, vamos usar Ettercap, um conjunto multifuncional para ataques man-in-the-middle, além de ataques SSL, também pode completar todos dos ataques que realizamos até agora com Arpspoof e dnsspoof. Desligue quaisquer outras ferramentas de falsificação antes de iniciar Ettercap.

Configurações iniciais do Ettercap

Antes de executar ele pela primeira vez, nós precisamos fazer algumas mudanças em seu arquivo de configuração em /etc/ettercap/etter.conf. Abra este arquivo através do terminal do Kali.

root@kali:~# nano /etc/ettercap/etter.conf

Primeiro mude os valores userid e groupid para 0 (zero), então o Ettercap pode rodar com privilégios root. Desça no arquivo até as linhas semelhantes a estas abaixo. Troque qualquer valor após o sinal de igual (=) para 0 (zero).

[privs]
ec_uid = 0 # nobody is the default
ec_gid = 0 # nobody is the default

Agora role o scroll para a seção do arquivo e descomente (remova a tralha #) antes das duas linhas mostradas abaixo para configurar o as regras do firewall iptables para redirecionar o tráfego.

#---------------
# Linux
#---------------
# if you use ipchains:
#redir_command_on = "ipchains -A input -i %iface -p tcp -s 0/0 -d 0/0 %port -j REDIRECT
%rport"
#redir_command_off = "ipchains -D input -i %iface -p tcp -s 0/0 -d 0/0 %port -j REDIRECT
%rport"
# if you use iptables:
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j
REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j
REDIRECT --to-port %rport"

Salve e saia do arquivo pressionando ctrl-X e então Y para salvar as mudanças.

Ettercap tem várias interfaces, mas vamos usar a opção -T para o interface baseada em texto neste exemplo. Use a opção -M com arp: remote /gateway/ /target/ para configurar um ataque de ARP cache poisoning entre o gateway padrão e o alvo Linux, como mostrado a seguir. O ataque real irá funcionar da mesma forma que o nosso exercício anterior, com Arpspoof.

root@kali:~# ettercap -Ti eth0 -M arp:remote /192.168.20.1/ /192.168.20.11/

Com o Ettercap rodando, nós esperamos pelos usuários começar a interagir com o servidor web com SSL. Mude para a máquina alvo Linux e tente logar em um site que use SSL. Você será alertado sobre o certificado.

Erro de certificado digital no Facebook

Erro de certificado digital no Facebook

Por causa deste ataque man-in-the-middle, a segurança da sessão SSL não pode ser verificada. O certificado apresentado pelo Ettercap não é válido para www.facebook.com, então a confiança é quebrada.

Ataque SSL man-in-the-middle

Ataque SSL man-in-the-middle

Mas o alerta não para todos os usuários. Se clicarmos para prosseguir e colocarmos nossas credenciais, Ettercap irá capturar em texto claro antes de encaminhá-los para o servidor:

HTTP : 31.13.73.36:443 -> USER: meu_usuario PASS: minha_senha INFO: https://www.facebook.com/

SSL Stripping

Naturalmente, o problema com SSL man-in-the-middle é que os usuários têm de clicar e prosseguir com o aviso do certificado SSL. Dependendo do navegador, isto pode ser um processo que é difícil, se não impossível, para um utilizador ignorar.  A maioria dos leitores provavelmente pode pensar em um momento em que clicou em um aviso de segurança e continuou na página apesar de seu melhor julgamento.

É difícil dizer o quão eficaz avisos de certificado estão em parar usuários de visitar sites HTTPS sem certificados válidos. Testes de engenharia social que empregam os certificados SSL auto-assinados e a taxa do sucesso foi significativamente menor do que aqueles com certificados válidos ou aqueles que não usam HTTPS. Embora alguns usuários clicaram e visitaram os locais, um ataque mais sofisticado nos permitiria capturar informações em texto simples, sem despertar a atenção do usuário com essas advertências óbvias que a conexão SSL está comprometida.

Com SSL stripping, nós fazemos um ataque man-in-the-middle na conexão HTTP antes de redirecionar para o SSL e então adiciona-se a funcionalidade SSL nos pacotes do servidor web. Quando um servidor web responde, o SSL stripping novamente intercepta o tráfego e remove as tags HTTPS antes de enviar os pacotes para o cliente. Esta técnica é ilustrada abaixo.

Ataque SSL Stripping

Ataque SSL Stripping

Moxie Marlinspike, o autor do sslstrip, chamou os avisos de certificado de feedback negativo, ao contrário de feedback positivo que uma sessão é válido, tal como ver HTTPS na barra de URL do navegador. Evitar esse feedback negativo é muito mais importante para o sucesso de um ataque de incluir feedback positivo porque os usuários são naturalmente menos propensos a perceber que uma URL HTTP diz em vez de HTTPS do que eles são um aviso gigante certificado eles têm que clique ativamente para seguir. SSL stripping evita o aviso de certificado em uma nova conexão por man-in-the-middle.

Usuários tipicamente encontram HTTPS tanto clicando em links ou através de redirecionamentos HTTP 302. Muitos usuários não colocam o endereço https://www… ou mesmo http://www…. em seus navegadores; Eles digitam www.site.com.br ou até mesmo site.com.br. E é por isto que um ataque é possível. SSLstrip adiciona o HTTPS nele mesmo e então a conexão SSL entre o Facebook e o Kali é válida. SSLstrip torna a conexão de volta para HTTP e envia ao requisitante original. Sem alerta de certificado.

Usando SSL Stripping

A ferramenta SSLstrip implementa o ataque SSL stripping. Antes de começarmos, precisamos configurar o Iptables para passar o tráfego que esteja direcionado a porta 80 através do SSLstrip. Nós iremos rodar o SSLstrip na porta 8080, como mostrado a seguir e então restartar o Arpspoof e fazer o spoof no gateway padrão.

root@kali:# iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

Agora inicie o SSLstrip e diga para ele iniciar a escuta na porta 8080 com a flag -l.

root@kali:# sslstrip -l 8080

A seguir, navegue em um site que use SSL (tente qualquer site que peça credenciais de login) de sua máquina Linux, como por exemplo o Twitter. Como você pode ver, o HTTP foi substituído pelo HTTPS na barra de endereço. Quando você logar, suas credenciais serão enviadas em texto claro para o SSLstrip.

Tela de login do twitter com SSL Stripping

Tela de login do twitter com SSL Stripping

Este ataque é mais sofisticado que um simples SSL man-in-the-middle. Nós podemos evitar alertas de certificados porque o servidor está completando a conexão SSL com o SSLstrip ao invés do navegador.

2015-12-28 19:16:35,323 SECURE POST Data (twitter.com):
session%5Busername_or_email%5D=seuusuario&session%5Bpassword%5D=suasenha&s
cribe_log=&redirect_after_login=%2F&authenticity_token=a26a0faf67c2e11e6738053
c81beb4b8ffa45c6a

Como pode-se ver, SSLstrip reporta as credenciais enviadas (seuusuario:suasenha) em texto claro.

Fonte: Penetration Testing – A hands-on introduction to Hacking

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.

4 Responses to “Introdução ao Wireshark: Detecção e captura de tráfego em redes”

  1. […] e abra o arquivo .cap no Wireshark com File > Open > seuarquivo.cap. Uma vez no Wireshark, filtre pelo protocolo EAPOL para ver os quatro pacotes que compõem o protocolo de reconhecimento, […]

  2. Anônimo disse:

    Parabéns!

  3. Diego, parabéns. Post muito interessante e didático. Abraços!

  4. Renê Gomes de Santana disse:

    Olá Diego,

    Como posso localizar um ip na minha rede que está realizando ataque de flood, com o Wireshark?

Deixe um comentário para Anônimo Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *