Bem-vindo de volta.
Neste capítulo, falaremos sobre ataques do tipo man in the middle, especialmente para dispositivos Android.
E isso é absolutamente essencial porque a maioria das vulnerabilidades que encontramos em aplicativos móveis não
está nos provedores de conteúdo de atividades ou nos receptores de transmissão.
Eles estão dentro dos serviços de rede do próprio aplicativo.
Há muitas configurações diferentes sobre como executar um ataque do tipo man in the middle em um dispositivo
Android, mas muitas delas têm grandes pontos fracos.
Eles funcionam como um proxy para solicitações HTTP e HTTPS.
Por exemplo, se você acessar as configurações de Wi-Fi, poderá definir um proxy aqui.
E se você inserir o IP e a porta de escuta da instância do burp, sim, você terá estabelecido uma conexão
intermediária em relação aos seus serviços da Web, mas perderá muitas coisas.
Por exemplo, se esse aplicativo usar SSH, SQL, MQTT ou SIP, você não verá esse tráfego.
Esse tráfego não será encaminhado para o seu burp e, portanto, você definitivamente o perderá.
E isso é algo que não queremos ter.
Queremos ver tudo, mas, além do fato de perdermos muitas coisas, também não temos controle sobre o
próprio tráfego da rede.
Por exemplo, não temos controle sobre o DHCP e o DNS.
Esse é o motivo pelo qual escolhi uma configuração diferente, e a configuração que estou usando
oferece controle total sobre o DNS, DHCP e também pode interceptar e manipular todas as conexões que os dispositivos
estabelecem, por exemplo, se estiverem usando SIP, MQTT, SSH, SQL ou qualquer outro.
Por isso, escolhi esse tipo de configuração.
Mas antes de mergulharmos na configuração, vamos falar primeiro sobre os ataques do Man in the Middle em si.
Então, o que é um ataque "man in the middle"?
E, para ser sincero, não tenho uma descrição oficial para isso no momento.
Mas esse ataque significa simplesmente que somos o homem no meio de uma conexão.
Portanto, entre dois dispositivos.
Na maioria dos casos, isso significa que estamos no meio da conexão.
Na maioria dos casos, isso significa simplesmente que estamos na conexão de um roteador e um dispositivo de rede, por exemplo,
o smartphone.
Se estivermos no meio dessa conexão, poderemos analisar, farejar e também manipular esses pacotes se eles não estiverem
sendo criptografados.
Falaremos sobre SSL mais adiante, mas, por enquanto, vamos nos concentrar no homem no meio em si.
Portanto, agora sabemos o que é um ataque do tipo "man in the middle", mas como podemos estabelecer essa conexão?
Existem várias configurações diferentes, mas vamos nos concentrar na mais básica: o ataque de envenenamento
de cache ARP.
Mas não se preocupe.
O envenenamento do cache ARP não faz parte de nossa configuração do Man in the Middle mais adiante.
Esse é apenas um bom exemplo para você se familiarizar com o que é um ataque do tipo "man in the middle" e como ele funciona.
É por isso que eu o escolhi como um exemplo aqui.
Tudo bem.
Portanto, antes de entendermos como funciona um ataque de envenenamento de cache ARP, precisamos entender
como o cliente A está se comunicando com o cliente B. Então, o que está acontecendo na linha em que esses dois podem se comunicar?
É preciso haver alguma troca de informações, e isso é algo que estamos analisando no momento.
Mas não se preocupe, fazemos isso em um nível muito alto e não entramos muito em detalhes.
Muito bem.
Está bem.
Então, vamos voltar para os slides.
Tudo bem.
Portanto, aqui temos nossa configuração básica de rede.
Temos o roteador, dois laptops e um dispositivo móvel que está conectado via Wi-Fi.
Todo dispositivo tem uma placa de rede, e essa placa de rede tem um endereço mac.
E esse é um identificador exclusivo que está gravado em seu cartão.
Portanto, esse endereço MAC só existe uma vez.
Não haverá duplicata desse número.
Aqui.
Um endereço MAC consiste em seis bytes, sendo que os três primeiros são referentes ao ID do fornecedor
e os três últimos são referentes a tornar esse endereço MAC exclusivo.
Isso significa que, teoricamente, podemos ficar sem endereços MAC.
Temos um número de dois quadrados seis vezes oito, que é.
Bem, é bastante.
Portanto, mesmo tendo agora todos esses dispositivos Iot, carros conectados e todo esse tipo de coisa,
não ficaremos sem endereços Mac tão cedo.
Isso é algo com que não precisamos nos preocupar no momento.
Além desse endereço Mac, há também um endereço IP, que está sendo atribuído via
DHCP ou estaticamente.
Portanto, no nosso caso, temos um roteador que está executando um serviço DHCP e esse roteador está fornecendo endereços
IP a todos os clientes conectados.
No nosso caso, temos uma rede de classe C, o que significa que temos 192. 168. um e, em seguida, podemos fornecer
endereços IP para conectar hosts de dois a 245.
O restante está sendo reservado para transmissão, gateway e outras coisas.
Muito bem.
Bem, esta é uma recapitulação da rede em um nível elevado.
Agora, digamos, declinou aqui.
Este aqui é o cliente A, e o cliente A quer enviar uma mensagem para o cliente B aqui.
O cliente A sabe o endereço IP do cliente B e este é o ponto 14.
Mas o que o cliente A não sabe é o endereço Mac.
E isso também é absolutamente essencial para preparar esse pacote.
Temos um quadro Ethernet e esse quadro Ethernet precisa ter o endereço Mac do destino.
Host Então, como podemos obter esse endereço MAC?
E é aí que o ARP entra em ação.
ARP é o protocolo de resolução de endereços e tem um tipo diferente de códigos de operação.
Uma delas é, por exemplo, a solicitação ARP, e a solicitação ARP é simplesmente um pacote de rede que pergunta
quem tem esse endereço.
Esse tipo de pacote está sendo criado pelo cliente A e está sendo enviado para toda a rede.
Portanto, para o roteador, e o roteador está transmitindo isso para toda a rede.
Esse pacote está sendo transmitido e recebe o smartphone via Wi-Fi.
O smartphone está dando uma olhada nesse pacote e responde: "Não, esse não sou eu".
O cliente B também recebe esse pacote e também está extraindo essas informações e percebe: "Ah, esse
sou eu".
Portanto, o Cliente B está preparando um pacote de resposta ARP.
Esse pacote de resposta ARP contém o endereço IP e também o endereço Mac desse cliente do Cliente B com essas
informações.
Esse pacote está sendo enviado de volta ao Cliente A.
O cliente A recebe esse pacote, dá uma olhada nele e verifica se está tudo bem, eu tenho o endereço IP,
mas agora também o endereço Mac do cliente B e o cliente A também é muito preguiçoso.
Portanto, o cliente A não quer pedir isso repetidamente.
Portanto, o cliente A está salvando essas informações em algo chamado cache ARP.
Essa é a resolução do endereço IP e do endereço MAC.
Portanto, na próxima vez que o cliente A estiver enviando uma mensagem para o cliente B.
O cliente A não precisa solicitar isso mais uma vez.
Portanto, o cliente A está simplesmente dando uma olhada em seu cache ARP interno e percebe que este é o endereço
Mac do cliente B e que este é o endereço que preciso usar em meu quadro Ethernet para envolvê-lo em
meu pacote.
Está bem.
Portanto, é assim que a troca de informações funciona em um nível muito alto.
Depois de obter essas informações, o cliente A agora pode se comunicar com o cliente B e você pode simplesmente preparar
uma mensagem e enviá-la ao cliente B.
Esse pacote agora está sendo agrupado em um quadro Ethernet, e esse quadro Ethernet contém o IP de
destino e também o endereço Mac de destino, que agora é conhecido pelo Cliente A.
Está bem.
Até agora, tudo bem.
Mas e se o seu PC quebrar?
Por exemplo, se você for pego trapaceando em uma grande LAN party, seu PC será expulso dessa
LAN e se quebrará completamente em pedaços.
Sua placa de rede.
Absolutamente desaparecido.
Isso significa que sua placa de rede não está mais disponível.
O cliente ainda tem essa referência em seu cache ARP.
Portanto, com relação a esse endereço IP e a esse endereço MAC.
E agora vamos imaginar que um novo cliente está entrando na rede e o roteador está reciclando o endereço
IP do outro cliente.
Portanto, é claro que o novo cliente também tem um endereço MAC.
Mas isso agora é diferente do outro porque os endereços Mac são exclusivos e o cliente agora recebe
o endereço IP do cliente anterior.
Portanto, nesse caso, o cache ARP agora é inválido.
Como podemos corrigir esse problema?
Bem, depois que o cliente A tentou várias vezes se conectar ao cliente B e ele não está mais disponível, o cliente
A está executando a mesma abordagem mais uma vez.
Portanto, o Cliente A está preparando uma solicitação ARP e a envia para a rede.
O cliente A está perguntando quem tem esse endereço IP.
Informe seu endereço MAC e esse pacote será transmitido para a rede.
O smartphone ainda responde com No, it's not me, mas na verdade não envia nenhum pacote.
Essa é apenas uma informação para nós de que não é o smartphone no momento.
Não haverá nenhum pacote em relação a uma solicitação ARP, mas o cliente C, que agora tem esse endereço IP,
responde com seu próprio endereço Mac.
Portanto, o cliente está respondendo com um pacote de resposta ARP, que agora contém o endereço IP e também o novo
endereço Mac do cliente.
No momento, esse pacote será enviado ao Cliente A.
O cliente A recebe esse pacote e também atualiza seu cache interno.
Assim, o endereço Mac antigo será excluído e o novo será inserido.
E é assim que um cache ARP é atualizado.
E essa é uma etapa muito, muito importante em relação a um ataque do tipo man in the middle em relação
ao envenenamento de cache ARP, porque o protocolo de resolução de endereços foi desenvolvido em 1980.
Portanto, não tenho certeza de quando exatamente, mas durante esse tempo, ninguém pensou em segurança em um protocolo
como esse.
E é nesse ponto que a vulnerabilidade se baseia no próprio protocolo ARP.
E isso é algo que vamos investigar agora mesmo.
Então, como podemos tirar proveito desse tipo de ataque para atualizar um cache ARP?
Bem, vamos descobrir agora mesmo.
Tudo bem.
Então, agora a pergunta é: como podemos abusar disso como invasores?
Como podemos acessar essa conexão entre o smartphone e o roteador neste momento com base nos
pacotes ARP?
Portanto, aqui temos o smartphone com o endereço dez e também temos o roteador que tem o endereço. um.
Portanto, o roteador também atua como um gateway.
Essa conexão foi estabelecida e ambos os dispositivos criaram seu próprio cache ARP.
Portanto, o smartphone tem o cache ARP para esse roteador com esse endereço MAC.
Além disso, o roteador criou seu próprio cache ARP para o smartphone.
Assim, com o endereço Mac do smartphone, o atacante entra em ação.
O cache do aplicativo foi configurado e aqui está o atacante no momento.
O invasor também entra na rede e recebe um endereço IP.
Mas essa não é a parte mais importante.
A parte mais importante é que o invasor agora está criando um pacote de resposta ARP.
Sim, você ouviu absolutamente certo, um pacote de resposta ARP, não em solicitação e resposta.
E esse pacote contém agora o endereço do roteador.
E agora temos a pista.
O invasor está preenchendo esse pacote com o endereço Mac do próprio invasor, portanto, não com o endereço
Mac do roteador.
E esse pacote será encaminhado para o cliente.
Então, para o smartphone, o smartphone está recebendo esse pacote, mas o smartphone diz: "Bem, eu não
pedi isso, então, por favor, não me incomode com isso".
Mas continuamos a enviá-lo repetidamente.
E, com base no próprio protocolo, não há nenhum tipo de autorização, autenticação ou qualquer outra coisa.
Portanto, ao responder a esse pacote várias vezes, depois de algum tempo o smartphone o aceitará e atualizará
o cache ARP para essa entrada.
O dispositivo agora pensa que o invasor é o gateway real.
Todo o tráfego do smartphone agora está sendo encaminhado para o invasor, e isso é tudo o que o invasor precisa
fazer.
O invasor simplesmente precisa inundar o dispositivo móvel com muitos pacotes de resposta ARP.
E essa é a vulnerabilidade desse protocolo, porque o pacote de resposta não exige uma solicitação
antes, o que significa que podemos simplesmente criar um pacote de resposta sem ter uma solicitação desse
cliente aqui.
E, ao responder a esse pacote repetidamente, a entrada do cache ARP nesse dispositivo é atualizada em relação
ao endereço Mac envenenado.
Tudo bem.
E é só assim que podemos estabelecer uma conexão "man in the middle".
Por exemplo, o smartphone está abrindo uma página da Web.
Por exemplo, aqui, digamos Exemplo. org.
Aprenderemos a lidar com isso mais adiante.
Portanto, como podemos criar nossos próprios certificados, aplicá-los ao dispositivo e também interceptar o tráfego SSL.
Mas, por enquanto, queremos nos concentrar em ataques man in the middle relacionados ao envenenamento de cache ARP e,
portanto, não precisamos torná-lo mais complexo do que realmente é.
Tudo bem.
Portanto, o cliente está abrindo ou tentando abrir o site, por exemplo. org.
E isso agora está sendo elaborado como um pacote.
Portanto, como um pacote HTTP, o cliente, o smartphone nesse caso, está encaminhando isso para o roteador, mas
não para o roteador real do invasor, porque o smartphone acha que esse é o gateway no momento.
O invasor recebe esse pacote e agora pode analisá-lo e também manipulá-lo.
Assim, por exemplo, se houver algumas credenciais de usuário ou se o invasor também puder enviar diferentes tipos
de solicitações para os sistemas originais, coisas desse tipo.
Portanto, agora estamos em uma posição de homem no meio.
Neste momento, tudo o que o invasor precisa fazer é encaminhar isso para o roteador real e atualizar o quadro Ethernet.
Vamos pular essa parte agora, mas sim, isso não é nada demais.
Certo, então o pacote chegou ao roteador e o roteador está agora encaminhando-o para a Internet
para o Example. org.
Exemplo. org está respondendo a esse pacote e está enviando a resposta referente a essa solicitação HTTP.
O roteador agora verifica o pacote e o pacote agora é para a máquina do invasor, porque o invasor substituiu
todos os quadros necessários, por exemplo, o quadro ethernet.
Portanto, o roteador está encaminhando esse pacote agora mesmo para o invasor.
O invasor pode então inspecioná-lo novamente e também manipular a resposta.
Por exemplo, aqui, insira alguns campos de formulário ocultos, injete JavaScript, keyloggers, coisas assim.
Depois de realizar esse tipo de ação, o invasor agora só precisa encaminhar esse pacote para a fonte
original, o próprio smartphone.
Mas o smartphone nem percebe que esse não foi roteado pelo gateway original.
Ele foi roteado para a máquina do invasor.
Assim, o smartphone pega esse pacote e o renderiza em seu navegador porque é a resposta da
solicitação HTTP original.
Portanto, para o smartphone, tudo está bem.
O atacante também está feliz.
E o gateway, quero dizer, o gateway também não percebeu que esse pacote foi enviado originalmente
do próprio smartphone.
Portanto, para cada dispositivo nessa conexão aqui, parece estar tudo bem com o tratamento dessa solicitação.
Tudo bem.
Portanto, é assim que o ataque do homem do meio funciona.
Mas, como já mencionado, esse ataque também tem muitos pontos fracos.
Por exemplo, precisamos inundar permanentemente a entrada do smartphone porque
pode acontecer de o gateway original voltar ao cache ARP fornecendo novos pacotes.
Portanto, temos que enviar permanentemente esses pacotes de resposta ARP, o que causa uma sobrecarga e, com certeza,
perderemos alguns pacotes do próprio smartphone.
Portanto, se não tivermos controle sobre o dispositivo nessa rede aqui, então, sim, essa
pode ser a única solução.
Está bem.
Há outras possibilidades.
Por exemplo, como falsificação de DNS, em que respondemos mais rapidamente do que o servidor de nomes original e coisas
do gênero.
Mas, sim, na maioria das vezes é a mesma abordagem.
Mas, sim, todos eles não são muito confiáveis.
Portanto, pode ser que o dispositivo tenha mudado de volta a conexão e isso pode ser apenas para algumas
solicitações até que a recuperemos novamente, mas essas poucas solicitações serão perdidas em nosso tráfego e isso
é algo que não queremos ter.
Se analisarmos um sistema.
Portanto, temos uma configuração diferente, e isso é algo que veremos no próximo vídeo.
Se você tiver alguma dúvida sobre ARP, envenenamento de cache, falsificação de DNS ou outros tipos de ataques
do tipo man in the middle, escreva-me uma mensagem.
Fico muito feliz quando recebo feedback sobre determinados tópicos.
E sim, se você ficar preso no ponto.
Faço o possível para ajudá-lo nisso.
Tudo bem.
Está bem.
No próximo vídeo, veremos um tipo diferente de configuração, e essa configuração nos dá controle total
sobre toda a rede e também sobre o tráfego nesse dispositivo sem inundá-lo permanentemente
com pacotes maliciosos.
Portanto, estou realmente ansioso para vê-lo no próximo vídeo.