Capturando o tráfego
Propaganda
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 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 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 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 [email protected]. 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 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 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 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 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 A tela de resultado mostrará o conteúdo completo da conexão FTP, incluindo as credenciais em texto claro. 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 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 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 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, série de ARP reply máquina na rede. destinado a essa enviará os pacotes isto é o ARP cache poisoning. Enviamos uma para dizer ao nosso alvo que somos outra Assim, quando o alvo envia o tráfego máquina, em vez disso, 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-inthe-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 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 ([email protected]) 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 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 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 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 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-inthe-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 (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 (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 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 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 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 destination-port 80 -j REDIRECT --to-port 8080 tcp -- 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 Este ataque é mais sofisticado que um simples SSL man-in-themiddle. 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%5 D=suasenha&s cribe_log=&redirect_after_login=%2F&authenticity_token=a26a0fa f67c2e11e6738053 c81beb4b8ffa45c6a Como pode-se ver, SSLstrip reporta as credenciais enviadas (seuusuario:suasenha) em texto claro. Fonte: Penetration Testing – A hands-on introduction to Hacking Conceito de Filtragem Pacotes e Firewall de Os primeiros firewalls usavam a filtragem de pacote somente para proteger a rede interna de usuários externos. O firewall verificava o cabeçalho de cada pacote que entra na rede interna e tomava a decisão de permitir ou bloquear o pacote baseado no IP usado e o numero da porta especificado no cabeçalho, na parte de TCP ou UDP. Filtragem de pacotes é o bloqueio ou liberação da passagem de pacotes de dados de maneira seletiva, conforme eles atravessam a interface de rede. Em sistemas Linux, por exemplo, a filtragem de pacotes é implementada diretamente no kernel. Esses filtros inspecionam os pacotes com base nos cabeçalhos de transporte, rede ou até mesmo enlace. Os critérios mais utilizados são os endereços IP e portas TCP/UDP de origem e destino. Alguns filtros de pacotes também são capazes de transformar o conteúdo dos pacotes, como é o caso do netfilter do Linux. Normalmente as pessoas se referem ao filtro de pacotes do Linux pelo nome de iptables. Na verdade, o iptables é uma utilitário de linha de comando a partir do qual podem ser configuradas as regras de filtragem do netfilter. O netfilter é formado por um conjunto de cadeias. Cada cadeia é um ponto no caminho que um pacote IP percorre ao entrar ou sair de uma máquina. A figura mostra as cadeias do netfilter. Estrutura do Netfilter Existem dois tipos de políticas aplicáveis aos pacotes filtrados: Permissivo – Aceita tudo que não é expressamente proibido. Restritivo – Nega tudo e só encaminha o que for expressamente permitido. A filtragem de pacotes IP é normalmente feita usando um roteador de filtragem de pacotes, quando tais pacotes passam pelo roteador. Normalmete, um roteador de filtragem de pacotes pode filtrar pacotes baseados em alguns ou todos os campos abaixo: Endereço IP de Endereço IP de Portas TCP/UDP Portas TCP/UDP origem; destino; de origem; de destino. Estes sistemas analisam individualmente os pacotes à medida em que estes são transmitidos da Camada de Enlace (camada 2 do modelo ISO/OSI) para a Camada de Rede (camada 3 do modelo ISO/OSI). A principal desvantagem desse tipo de tecnologia é a falta de controle de estado do pacote, o que permite que agentes maliciosos possam produzir pacotes simulados (IP Spoofing) para serem injetados na sessão. Filtragem por política é uma forma diferente de se escrever um conjunto de regras de filtragem. Uma política é definida, a qual configura as regras para quais tipos de tráfego são permitidos e quais tipos são bloqueados. Os pacotes são então classificados, baseando-se no critério tradicional de endereço IP/porta de origem/destino, protocolo, etc. Firewall Firewall é um sistema de proteção de redes internas contra acessos não autorizados originados de uma rede não confiável (Internet), ao mesmo tempo que permite o acesso controlado da rede interna à Internet. Eles podem ser um hardware e/ou software, tendo diferentes tipos de proteção como: pacotes, email, web, etc. Apesar de se tratar de um conceito geralmente relacionado a proteção contra invasões, o firewall não possui capacidade de analisar toda a extensão do protocolo, ficando geralmente restrito ao nível 4, de Transporte, da Camada OSI. A complexidade de instalação depende do tamanho da rede, da política de segurança, da quantidade de regras que controlam o fluxo de entrada e saída de informações e do grau de segurança desejado. A análise da arquitetura de implementação de firewalls traz os conceito de Bastion Host e DMZ. Bastion Hosts são servidores cuidadosamente implementados e de alta segurança que mantém contato com a rede externa, consequentemente estando expostos aos riscos de ataques. Algumas de suas características são: Todo tráfego entre a rede interna e a externa (entrada e saída) deve passar pelo Firewall; Somente o tráfego autorizado passará pelo Firewall, todo o resto será bloqueado; O Firewall em si deve ser seguro e impenetrável; Tipos de controles realizados: Controle de Serviço: determina quais serviços Internet (tipos) estarão disponíveis para acesso; Controle de Sentido: determina o sentido de fluxo no qual serviços podem ser iniciados; Controle de Usuário: controla o acesso baseado em qual usuário está requerendo (tipicamente os internos, ou externo via VPN); Controle de Comportamento: controla como cada serviço pode ser usado (ex: anti-spam); Proxy Firewall Aplicação / Gateways de Os conceitos de gateways de aplicação (application-level gateways) e “bastion hosts” foram introduzidos por Marcus Ranum em 1995. Trabalhando como uma espécie de eclusa, o firewall de proxy trabalha recebendo o fluxo de conexão, tratando as requisições como se fossem uma aplicação e originando um novo pedido sob a responsabilidade do mesmo firewall (non-transparent proxy) para o servidor de destino. A resposta para o pedido é recebida pelo firewall e analisada antes de ser entregue para o solicitante original. Embora os firewalls de filtro de pacotes e statefull apresentem uma diferenças em como pacotes de uma determinada conexão são tratados, ambos se baseiam fundamentalmente nas informações transporte. do cabeçalho dos protocolos da camada de Um application gateway é um firewall stateful capaz de inspecionar os dados da camada de aplicação para tomar decisões mais inteligentes sobre a conexão. Exemplos de controles realizados por um application gateway são autenticação, filtros de URL e filtros de conteúdo. Um application gateway pode ser utilizado para bloquear, por exemplo, aplicações peer to peer (eMule, Kaaza etc.), ou mensageiros instantâneos (IRC, MSN etc.) que tentam se esconder debaixo do protocolo HTTP. No entanto, os application gateway não são capazes de inspecionar dados criptografados via SSL, por exemplo. Os gateways de aplicações conectam as redes corporativas à Internet através de estações seguras (chamadas de bastion hosts) rodando aplicativos especializados para tratar e filtrar os dados (os proxy firewalls). Estes gateways, ao receberem as requisições de acesso dos usuários e realizarem uma segunda conexão externa para receber estes dados, acabam por esconder a identidade dos usuários nestas requisições externas, oferecendo uma proteção adicional contra a ação dos crackers. Firewall Statefull Um firewall de filtro de pacotes é dito um firewall sem estado. Isso porque ele trata cada um dos pacotes que atravessam a interface de forma independente. As conexões TCP são caracterizadas por uma série de atributos como IP’s de origem e destino, portas de origem de destino, números de sequência etc. Em conjunto, esses atributos determinam o estado de uma conexão TCP. Ao contrário dos firewalls de filtro de pacotes, um firewal stateful não filtra pacotes de forma isolada, mas sim com base em informações sobre o estado de conexões pré-estabelecidas. Para um firewall stateful, a comunicação bi-direcional é implícita, de forma que não há necessidade de se escrever regras de filtragem para cada um dos sentidos. A seguir são mostrados alguns exemplos de ragras para um firewall stateful utilizando a sintaxe do iptables. Com a explosão do comércio eletrônico, percebeu-se que mesmo a última tecnologia em filtragem de pacotes para TCP/IP poderia não ser tão efetiva quanto se esperava. Com todos os investimentos dispendidos em tecnologia de stateful firewalls, os ataques continuavam a prosperar de forma avassaladora. Somente a filtragem dos pacotes de rede não era mais suficiente. Os ataques passaram a se concentrar nas características (e vulnerabilidades) específicas de cada aplicação. Percebeu-se que havia a necessidade de desenvolver um novo método que pudesse analisar as particularidades de cada protocolo e tomar decisões que pudessem evitar ataques maliciosos contra uma rede. Se comparado com o modelo tradicional de Firewall, orientado a redes de dados, o Firewall de Aplicação é frequentemente instalado junto à plataforma da aplicação, atuando como uma espécie de procurador para o acesso ao servidor (Proxy). Este tipo de Firewall conta com o Stateful Inspection para inspecionar pacotes e tráfego de dados baseado nas características de cada aplicação, nas informações associadas a todas as 7 camadas do modelo OSI (e não apenas na camada de rede ou de aplicação) e no estado das conexões e sessões ativas Questões de Concursos (CESPE – 2011 – TJ-ES – Analista Judiciário – Análise de Suporte – Específicos) O denominado firewall de estado é um tipo de firewall mais simples que atua na camada de rede (camada 3), para filtrar tráfego a partir de endereços IP de origem e destino e a partir da porta TCP ou UDP. ( ) Certo ( ) Errado (CESPE – 2011 – Correios – Analista de Correios – Analista de Sistemas – Suporte de Sistemas) As ferramentas de firewall conhecidas como filtro de pacotes trabalham na camada de transporte e de rede do protocolo TCP/IP e tratam os protocolos TCP e UDP e as portas de acesso aos serviços. ( ) Certo ( ) Errado (CESPE – 2010 – MPU – Técnico de Informática) Configurar o firewall da rede para bloquear os pacotes destinados a qualquer servidor de HTTP externo é medida que impede que os funcionários dessa empresa utilizem os computadores para acessar a Internet. ( ) Certo ( ) Errado (CESPE – 2010 – MPU – Analista de Informática – Perito) No caso de um usuário remoto acessar rede com firewall de aplicativo proxy ou gateway de aplicativo, os pacotes IP serão encaminhados à rede interna, na qual, então, o proxy gerencia a conexão. ( ) Certo (CESPE – ( 2010 ) Errado – MPU – Analista de Informática – Perito) Firewall pode autorizar, negar ou descartar um pacote de dados como resultado da comparação entre uma tabela de regras e o resultado da análise de cabeçalhos de pacotes que contém os protocolos utilizados, assim como as portas e os endereços IP de origem e destino do pacote. ( ) Certo ( ) Errado (CESPE – 2010 – ABIN – OFICIAL TÉCNICO DE INTELIGÊNCIA – ÁREA DE DESENVOLVIMENTO E MANUTENÇÃO DE SISTEMAS) Um firewall Linux pode ser implementado por meio de um servidor proxy. Nesse caso, as devidas autorizações do usuário e as demais opções de configuração são conferidas em uma tabela. ( ) Certo ( ) Errado (CESPE – 2010 – BASA – Técnico Científico – Tecnologia da Informação – Suporte Técnico) É importante que o sistema operacional da máquina na qual o firewall está sendo executado seja confiável e seguro para que ela não seja facilmente invadida e o firewall, comprometido. ( ) Certo ( ) Errado (ESAF – 2004 – CGU – Analista de Finanças e Controle – Área – Tecnologia da Informação – Prova 3) Analise as seguintes afirmações relativas a tipos e configuração de Firewall: I. A conversão de endereços de rede NAT permite que uma rede utilize um conjunto de endereços de rede internamente e use um conjunto diferente ao lidar com redes externas. II. O sistema de conversão de endereços de rede pode modificar os números de portas de origem e destino (podendo ser chamado de conversão de portas e endereços – PAT). III. Um firewall com arquitetura de host dual-homed é construído com um computador que tem apenas uma interface operando nos dois sentidos, isto é, recebe um pacote, analisa e devolve ao meio físico pela mesma interface de rede. Esta arquitetura, muito útil para pequenas empresas, permite configurar um computador como firewall e roteador ao mesmo tempo. IV. Uma regra de filtragem tem sua segurança próxima do ideal quando utiliza como parâmetro principal o endereço de origem. Estão corretos os itens: a) I e II b) II e III c) III e IV d) I e III e) II e IV (CESGRANRIO – 2005 – MPE-RO – Analista de Redes e Comunicação de Dados) Qual das funções abaixo um firewall NÃO realiza em uma rede? a) Bloquear acesso não autorizado aos aplicativos remotos que podem ser perigosos para a rede. b) Criar redes privadas virtuais (VPN). c) Filtrar URL, negando acesso para sites não autorizados. d) Suportar varreduras de vírus no correio eletrônico. e) Tratar códigos maliciosos de ataques do tipo Cavalode- Tróia. Gabarito e Comentários das Questões (CESPE – 2011 – TJ-ES – Analista Judiciário – Análise de Suporte – Específicos) O denominado firewall de estado é um tipo de firewall mais simples que atua na camada de rede (camada 3), para filtrar tráfego a partir de endereços IP de origem e destino e a partir da porta TCP ou UDP. Errado. O Firewall de Estado (Stateful) é um firewall mais robusto que a filtragem de pacotes e atua em todas as 7 camadas do modelo OSI. A descrição dada na questão é de um “filtro de pacotes”. (CESPE – 2011 – Correios – Analista de Correios – Analista de Sistemas – Suporte de Sistemas) As ferramentas de firewall conhecidas como filtro de pacotes trabalham na camada de transporte e de rede do protocolo TCP/IP e tratam os protocolos TCP e UDP e as portas de acesso aos serviços. Correto. (CESPE – 2010 – MPU – Técnico de Informática) Configurar o firewall da rede para bloquear os pacotes destinados a qualquer servidor de HTTP externo é medida que impede que os funcionários dessa empresa utilizem os computadores para acessar a Internet. Errado. A Internet não é composta somente por um serviço que roda através de um servidor HTTP. Ainda temos os servidores de e-mails (IMAP/POP3/SMTP), mensageiros instantâneos, servidores de arquivos com FTP, e outros serviços. Baseado na questão, o filtro de pacotes apenas restringiu o acesso ao serviço HTTP, mas não impediu. (CESPE – 2010 – MPU – Analista de Informática – Perito) No caso de um usuário remoto acessar rede com firewall de aplicativo proxy ou gateway de aplicativo, os pacotes IP serão encaminhados à rede interna, na qual, então, o proxy gerencia a conexão. Errado. O Proxy não tem a função de encaminhar os pacotes, mas sim de ser um “interprete” entre a conexão externa e a interna. Ao receber uma requisição, ele irá gerar uma outra para o destino final, não encaminhando o IP original, mas sim o seu próprio IP. (CESPE – 2010 – MPU – Analista de Informática – Perito) Firewall pode autorizar, negar ou descartar um pacote de dados como resultado da comparação entre uma tabela de regras e o resultado da análise de cabeçalhos de pacotes que contém os protocolos utilizados, assim como as portas e os endereços IP de origem e destino do pacote. Correto. (CESPE – 2010 – ABIN – OFICIAL TÉCNICO DE INTELIGÊNCIA – ÁREA DE DESENVOLVIMENTO E MANUTENÇÃO DE SISTEMAS) Um firewall Linux pode ser implementado por meio de um servidor proxy. Nesse caso, as devidas autorizações do usuário e as demais opções de configuração são conferidas em uma tabela. Correto. (CESPE – 2010 – ABIN – OFICIAL TÉCNICO DE INTELIGÊNCIA – ÁREA DE DESENVOLVIMENTO E MANUTENÇÃO DE SISTEMAS) Um firewall Linux pode ser implementado por meio de um servidor proxy. Nesse caso, as devidas autorizações do usuário e as demais opções de configuração são conferidas em uma tabela. Correto. (ESAF – 2004 – CGU – Analista de Finanças e Controle – Área – Tecnologia da Informação – Prova 3) Analise as seguintes afirmações relativas a tipos e configuração de Firewall: Letra “A”. O item III está errado pelo fato de um firewall host dual-homed ser composto por duas ou mais interfaces de rede. Um computador que fica entre duas redes pode ser um dual-homed gateway, já que este pode atuar como um roteador entre as redes. Mas no caso de um firewall deste caso, esta função de roteamento é desabilitada. Desta forma, os pacotes IP vindos da Internet não são repassados diretamente para a rede interna. Sistemas dentro dofirewall podem se comunicar com o dual-homed host, e sistemas fora do firewall podem somente se comunicar com o dual-homed host. Já no item IV, não podemos afirmar que a segurança está perto do ideal somente com o endereço de origem, pois ele pode ser burlado com IP Spoofing, por exemplo. (CESGRANRIO – 2005 – MPE-RO – Analista de Redes e Comunicação de Dados) Qual das funções abaixo um firewall NÃO realiza em uma rede? Letra “E”. Tratar códigos maliciosos é função do anti-vírus.
