ettercap/ettercapProjeto Ettercap
Copyright 2001-Atual The Ettercap Dev Team
O Ettercap é um conjunto completo de ferramentas para ataques man-in-the-middle. Ele oferece sniffing de conexões ativas, filtragem de conteúdo em tempo real e muitas outras técnicas interessantes. Suporta dissecação ativa e passiva de vários protocolos e inclui muitos recursos para análise de rede e host.
[!NOTE] Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer are in the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it out aynawy.
... então, por favor, desculpe-nos por qualquer erro de digitação na documentação, páginas de manual ou código, a propósito, correções e patches são bem-vindos.
[!TIP] Se você não quiser habilitar o plugin SSLStrip, deve desativá-lo. (mais informações sobre como desativar um plugin no arquivo README.GIT)
libbsdgrofflibltdl (parte do libtool)libpcrencurses >= 5.3Glib >= 2.2.2Gtk+3 >= 3.12.0 (recomendado >= 3.22.0)Atk >= 1.2.4Pango >= 1.2.3[!TIP] Se você estiver usando Debian ou qualquer distribuição baseada em Debian, pode instalar as dependências necessárias executando:
apt-get install build-essential debhelper bison check cmake flex groff libbsd-dev \ libcurl4-openssl-dev libmaxminddb-dev libgtk-3-dev libltdl-dev libluajit-5.1-dev \ libncurses5-dev libnet1-dev libpcap-dev libpcre2-dev libssl-dev
veja o arquivo LICENSE para detalhes...
A maneira mais fácil de compilar o ettercap é da seguinte forma:
mkdir build && cd build
cmake ..
[!TIP] Use
ccmake .para alterar opções como desabilitar suporte a IPv6, adicionar suporte a plugins, etc).
sudo make install
[!NOTE] Leia INSTALL para mais detalhes... e README.PLATFORMS para qualquer problema relacionado ao seu sistema operacional.
Você pode escolher entre 3 Interfaces de Usuário: Modo Texto, Curses, GTK.
Por favor, leia as páginas de manual ettercap(8) e ettercap_curses(8) para aprender como usar o ettercap.
Enviando uma REQUISIÇÃO ARP para cada ip na lan (observando o ip atual e a máscara de rede), é possível obter as RESPOSTAS ARP e então fazer a lista dos hosts que estão respondendo na lan. Com este método, mesmo hosts Windows respondem ao call-for-reply (eles não respondem a broadcast-ping). Tenha muito cuidado se a máscara de rede for classe B (255.255.0.0) porque o ettercap enviará 255*255 = 65025 requisições arp (o atraso padrão entre duas requisições é de 1 milissegundo, pode ser configurado no etter.conf)
O Ettercap NG usa o método de sniffing unificado que é a base para todos os ataques. O encaminhamento de IP do kernel está sempre desabilitado e esta tarefa é realizada pelo próprio ettercap. Pacotes que precisam ser encaminhados são pacotes com endereço MAC de destino igual ao do atacante, mas com endereço IP diferente. Esses pacotes são reenviados de volta ao fio para o destino real. Desta forma, você pode aplicar vários ataques mitm ao mesmo tempo. Você pode até usar atacantes/envenenadores externos, eles só precisam redirecionar pacotes para o host do ettercap e o jogo acabou ;)
Usa duas interfaces de rede e encaminha o tráfego entre elas enquanto realiza sniffing e filtragem de conteúdo. Este método de sniffing é muito furtivo, pois não há como detectar que alguém está no meio. Você pode ver isso como um ataque de camada um. Não use em gateways ou transformará seu gateway em uma ponte.
DICA: Você pode usar o mecanismo de filtragem de conteúdo para descartar pacotes que não deveriam passar. Desta forma, o ettercap funcionará como um IPS inline ;)
Quando você seleciona este método, o ettercap envenenará o cache ARP dos dois hosts, identificando-se como o outro host respectivamente (veja a próxima seção para isso). Uma vez que os caches ARP estão envenenados, os dois hosts iniciam a conexão, mas seus pacotes serão enviados para nós, e nós os gravaremos e, em seguida, encaminharemos para o lado correto da conexão. Portanto, a conexão é transparente para as vítimas, sem que elas saibam que estão sendo espionadas. O único método para descobrir que há um homem-no-meio em sua conexão é olhar para o cache ARP e verificar se há dois hosts com o mesmo endereço MAC! É assim que descobrimos se há outros envenenando o cache ARP em nossa LAN, sendo assim avisados que nosso tráfego está sob controle! =)
HOST 1 - - - - - - - - - - - - - - - - - - - -> HOST 2
(envenenado) (envenenado)
| ^
| |
------------> HOST ATACANTE -------------------
( ettercap )
Legenda:
- - - -> a conexão lógica
-------> a conexão real
O protocolo ARP tem uma insegurança intrínseca. Para reduzir o tráfego no cabo, ele insere uma entrada no cache ARP mesmo que não tenha sido solicitada. Em outras palavras, TODA resposta ARP que passa pelo fio será inserida na tabela ARP. Portanto, aproveitamos essa "característica", enviando respostas ARP falsas para os dois hosts que vamos espionar. Nesta resposta, diremos que o endereço MAC do segundo host é o codificado em nossa placa de rede. Este host agora enviará pacotes que deveriam ir para o primeiro host, para nós, porque ele carrega nosso endereço MAC. O mesmo processo é feito para o primeiro host, de forma inversa, então temos uma conexão perfeita de homem-no-meio entre os dois hosts, recebendo legalmente seus pacotes!!
Exemplo:
HOST 1: mac: 01:01:01:01:01:01 HOST ATACANTE:
ip: 192.168.0.1 mac: 03:03:03:03:03:03
ip: 192.168.0.3
HOST 2: mac: 02:02:02:02:02:02
ip: 192.168.0.2
enviamos respostas arp para:
HOST 1 informando que 192.168.0.2 está em 03:03:03:03:03:03
HOST 2 informando que 192.168.0.1 está em 03:03:03:03:03:03
agora eles estão envenenados!! eles enviarão seus pacotes para nós! então, se recebermos pacotes de:
HOST 1 encaminharemos para 02:02:02:02:02:02
HOST 2 encaminharemos para 01:01:01:01:01:01
simples, não é?
PROBLEMA COM KERNEL LINUX 2.4.x
Na última versão do kernel linux encontramos em :
/usr/src/linux/net/ipv4/arp.c
/* Unsolicited ARP is not accepted by default.
It is possible, that this option should be enabled for some
devices (strip is candidate)
*/
esses kernels usam um sistema de vizinhança especial para prevenir respostas ARP não solicitadas (o que o ettercap envia para a vítima). Graças a Deus, o ettercap é inutilizável com esse kernel? a resposta é NÃO! vamos ver por que... no mesmo código-fonte encontramos:
/*
* Process entry. The idea here is we want to send a reply if it is a
* request for us or if it is a request for someone else that we hold
* a proxy for. We want to add an entry to our cache if it is a reply
* to us or if it is a request for our address.
* (The assumption for this last is that if someone is requesting our
* address, they are probably intending to talk to us, so it saves time
* if we cache their address. Their address is also probably not in
* our cache, since ours is not in their cache.)
*
* Putting this another way, we only care about replies if they are to
* us, in which case we add them to the cache. For requests, we care
* about those for us and those for our proxies. We reply to both,
* and in the case of requests for us we add the requester to the arp
* cache.
*/
então, se o kernel receber uma REQUISIÇÃO, ele armazenará em cache o host... o que isso significa? se o ettercap enviar REQUISIÇÕES falsificadas em vez de RESPOSTAS, o kernel as armazenará em cache? a resposta é SIM!!
o ettercap 0.6.0 e posteriores tem este novo método de ENVENENAMENTO POR REQUISIÇÃO ARP. ele alternará requisições e respostas no envenenamento porque outros SOs não têm essa "característica"...
PROBLEMA COM SOLARIS
O Solaris não armazenará em cache uma resposta se ela já não estiver no cache. O truque é simples: antes de envenenar, o ettercap envia uma requisição ICMP ECHO_REQUEST falsificada para o host; ele terá que responder e criará uma entrada ARP para o host falsificado. Então podemos começar a envenenar como sempre; a entrada agora está no cache...
Este ataque implementa redirecionamento ICMP. Ele envia uma mensagem de redirecionamento icmp falsificada para os hosts na lan fingindo ser a melhor rota para internet. Todas as conexões com a internet serão redirecionadas para o atacante que, por sua vez, as encaminhará para o gateway real. O ataque resultante é um mitm MEIO-DUPLEX. Apenas o cliente é redirecionado, pois o gateway não aceitará mensagens de redirecionamento para uma rede diretamente conectada.
Este ataque implementa DHCP spoofing. Ele finge ser um servidor DHCP e tenta vencer a condição de corrida com o servidor real para forçar o cliente a aceitar respostas dele. Desta forma, o atacante consegue manipular o parâmetro GW e sequestrar todo o tráfego de saída gerado pelos clientes. O ataque resultante é um mitm MEIO-DUPLEX.
Esta técnica é útil para sniffing em um ambiente com switch quando o envenenamento ARP não é eficaz (por exemplo, onde ARPs mapeados estaticamente são usados). Ela inunda a LAN com pacotes ARP. O endereço MAC de destino de cada pacote de "roubo" é o mesmo que o do atacante (outras NICs não verão esses pacotes); o endereço MAC de origem será um dos MACs das vítimas. Este processo "rouba" a porta do switch de cada vítima. Usando baixos atrasos, pacotes destinados a endereços MAC "roubados" serão recebidos pelo atacante, vencendo a condição de corrida com o verdadeiro dono da porta. Quando o atacante recebe pacotes para hosts "roubados", ele interrompe o processo de inundação e realiza uma requisição ARP para o destino real do pacote. Quando recebe a resposta ARP, ele tem certeza de que a vítima "recuperou" sua porta, então o ettercap pode reenviar o pacote ao destino como está. Agora podemos reiniciar o processo de inundação aguardando novos pacotes.
Dissemos que os pacotes são para nós... E os pacotes não serão recebidos pelo destino até que os encaminhemos. Mas o que acontece se os alterarmos? Sim, eles chegam ao destino com nossas modificações. Podemos modificar, adicionar, excluir o conteúdo desses pacotes, simplesmente recalculando o checksum e substituindo-os no tráfego. Mas também podemos fazer mais: podemos inserir pacotes na conexão. Forjamos nossos pacotes com o número de sequência e confirmação corretos e os enviamos para o host desejado. Quando os próximos pacotes passarem por nós, simplesmente subtraímos ou adicionamos o número de sequência com a quantidade de dados que injetamos até que a conexão esteja ativa, impedindo que a conexão seja rejeitada (isso até fecharmos o ettercap, que mantém os números de sequência corretos; após a saída do programa, a conexão deve ser RESETADA ou todo o tráfego futuro será rejeitado, bloqueando a rede da estação de trabalho de origem).
[!NOTE] O injetor suporta sequências de escape. você pode fazer injeção de múltiplas linhas
- ex: "isto na linha um \n isto na linha dois \n e assim por diante..."
- ex: "isto em modo hexadecimal: \x65\x6c\x6c\x65"
- ex: "isto em modo octal: \101\108\108\101"
[!NOTE] lembre-se de terminar sua injeção com \r\n se quiser injetar comandos no servidor.
Quando a conexão começa (lembre-se de que somos os mestres dos pacotes, todos os pacotes passam pelo ettercap), substituímos a chave pública do servidor por uma gerada em tempo real e a salvamos em uma lista para lembrarmos que este servidor foi envenenado antes. Então o cliente envia o pacote contendo a chave de sessão criptografada com nossa chave, então somos capazes de decifrá-la e sniffar a verdadeira chave de sessão 3DES. Agora criptografamos o pacote com a chave pública correta do servidor e o encaminhamos para o daemon SSH. A conexão é estabelecida normalmente, mas temos a chave de sessão!! Agora podemos descriptografar todo o tráfego e sentar assistindo ao fluxo! A conexão permanecerá ativa mesmo se sairmos do ettercap, porque o ettercap não a faz proxy (como o dsniff). Após a troca de chaves, o ettercap é apenas um espectador... ;)
Como a injeção de caracteres, podemos modificar o payload dos pacotes e substituir o número de sequência e confirmação corretos, se necessário. Com o mecanismo de filtragem integrado, você pode programar seus próprios filtros para fazer o melhor filtro para seus objetivos. Uma linguagem de script é usada para criar arquivos de filtro que devem ser compilados com o etterfilter(8) para serem usados pelo ettercap.
Este recurso é muito útil se você quiser conhecer a topologia da lan, mas não quiser enviar nenhum pacote nela. Desta forma, a varredura é feita inteiramente sniffando pacotes e extraindo informações úteis deles. Esta varredura permitirá conhecer os hosts na lan (ela observa requisições ARP), o sistema operacional dos hosts (usa fingerprinting passivo de SO... veja a próxima seção), as portas abertas de um host (olhando para pacotes SYN+ACK), o gateway, os roteadores ou hosts atuando como roteadores (ela observa mensagens ICMP). Como método passivo, é inútil em uma rede com switch (porque pode fazer uma topologia apenas dos hosts que estão se conectando a você), mas se você colocá-la em um gateway e deixá-la rodar por horas ou dias, ela fará um relatório completo dos hosts na lan.
A ideia principal é analisar as informações passivas que vêm de um host quando ele faz ou recebe conexões com outros hosts. Essas informações são suficientes para detectar o SO e os serviços em execução do host. Neste cenário, observamos pacotes SYN e SYN+ACK e coletamos algumas informações interessantes deles: Window Size: o campo TCP header MSS: a opção TCP Maximum Segment Size (pode estar presente ou não) TTL: o campo IP header Time To Live (arredondado para a próxima potência de 2) Window Scale: a opção TCP que indica a escala SACK: a opção TCP para o Selective ACK NOP: se as opções TCP contêm um NOP DF: o campo IP header Don't Fragment TIMESTAMP: se a opção TCP timestamp está habilitada e obviamente o tipo de pacote (SYN ou SYN+ACK)
O banco de dados contém diferentes impressões digitais para cada tipo de pacote porque alguns SOs têm impressões digitais diferentes de SYN para SYN+ACK. Obviamente, a impressão digital SYN é mais confiável, pois o SYN+ACK é influenciado pelo SYN (se um SYN não contém um SACK, o SYN+ACK não terá a opção SACK, mesmo que o host a suporte). Então, enquanto coletamos informações da lan, se recebemos um SYN+ACK, marcamos o SO desse host como temporário e, quando recebemos um SYN, confirmamos isso. Impressões digitais terminando com ":A" são menos confiáveis... isso é porque algumas identificações de SO podem mudar durante o processo de coleta.
Os pacotes SYN+ACK também são usados para descobrir as portas abertas de um host. (veja a próxima seção)
O interessante é que firewalls, gateways e NAT são transparentes para a detecção passiva de SO. Portanto, coletar informações da LAN permitirá conhecer informações até mesmo de hosts remotos. Apenas proxies não são transparentes porque eles fazem uma nova conexão com o destino.
Nosso banco de dados de impressões digitais precisa ser ampliado; portanto, se você encontrar um host com uma impressão digital desconhecida e souber com certeza o SO desse host, por favor, envie-nos um e-mail [email protected] com a impressão digital e o SO, e nós a inseriremos no banco de dados.
As portas abertas são identificadas procurando por pacotes SYN+ACK. Se um SYN+ACK vem de uma porta, ela certamente está aberta, exceto para o comando channel do protocolo FTP; por esse motivo, SYN+ACK indo para a porta 20 não são usados para indicar uma porta aberta. Para as portas udp, a questão é um pouco mais difícil porque nenhum pacote SYN ou ACK está presente no protocolo udp, portanto o ettercap assume que uma porta udp < 1024 que envia pacotes está aberta. Sabemos que desta forma não podemos descobrir portas abertas > 1024, mas elas podem passar despercebidas como abertas quando um cliente envia um pacote para um servidor.
O gateway é simplesmente reconhecido observando pacotes IP com um ip não local (verificando a máscara de rede). Se um IP não local for encontrado, o ettercap observa o endereço ethernet (MAC) e o armazena como o endereço MAC do gateway; em seguida, procura na lista e marca o ip correspondente como o gateway.
Observando as mensagens ICMP, podemos confiar que, se um host envia uma mensagem TTL-exceeded ou redirect, ele é um roteador ou um host atuando como tal.
==============================================================================
vim:ts=3:expandtab