Wi Phi
1.0.0
─ Um sistema de PHIshing sem fio totalmente automático e integrado à IoT da Şefik Efe Altınoluk ─
Não experimente este software em usuários/sistemas para os quais você não tem permissão legal. O uso de Wi-Phi para atacar alvos sem consentimento mútuo prévio é ilegal. É responsabilidade do usuário final obedecer a todas as leis locais, estaduais e federais aplicáveis. Não assumo nenhuma responsabilidade e não sou responsável por qualquer uso indevido ou dano causado por este software, documentação ou qualquer coisa neste repositório.
(VER #4) Como Wi-Phi pode ser usado de forma maliciosa, não compartilho a maior parte do código-fonte. Contate-me no LinkedIn para qualquer caso empresarial/acadêmico/educacional em que você precise de todo o código funcional.
Este projeto está licenciado sob a Licença Pública Geral Gnu Versão 3.0
Consulte LICENÇA para obter mais detalhes.
Wi-Phi é um system automático phishing totalmente integrado a placas IoT (Internet das Coisas) sem fio.
Pode ser pensado como um Wifi Pineapple avançado e rico em recursos.
Wi-Phi é capaz de fazer phishing em usuários que executam pelo menos um dos seguintes softwares:
Os principais componentes do Wi-Phi são:
MicroPython . Eu uso Deneyap Kart baseado em ESP32 .esp32-20220117-v1.18.binObtenha um dispositivo ESP32 IoT.
Conecte o ESP32 ao seu computador e obtenha a porta serial à qual o ESP32 está conectado.
COMx/dev/ttyUSBx ou /dev/tty/USBxEm seguida, execute os seguintes comandos para GNU/Linux.
[efe@lhost ~] $ git clone https://github.com/f4T1H21/Wi-Phi.git && cd Wi-Phi
[efe@lhost Wi-Phi] $ pip3 install -r requirements.txt
[efe@lhost Wi-Phi] $ sudo ./setup.sh < serial_port > Agora que o software deve estar funcionando, verifique se você vê uma rede Wi-Fi chamada Google Free Wi-Fi .
Sempre que você conecta o ESP32 a uma fonte de alimentação, o projeto é executado automaticamente após o estágio de inicialização.
Nada mais importa.
Todo o software é implementado em MicroPython e roda em ESP32.
ESP32 passa a ser um AP (Ponto de Acesso) Wireless; e executa três (3) soquetes independentes (na camada 4 do OSI):
53/UDP para servidor DNS80/TCP para servidor HTTP2121/TCP para servidor Credential Store Toda a ligação é feita no endereço IP do gateway (AP), que é 210.210.210.1
A razão pela qual escolhi essa classe de IP é porque, por algum motivo, os dispositivos Samsung não consideram endereços IP curtos como portais cativos. O que foi um problema para mim.
A ideia principal é servir um site de phishing estático em um servidor HTTP e torná-lo um captive portal para dispositivos (estações) de qualquer fornecedor que estejam conectados por Wi-Fi.
Static site servido por servidor HTTPDNS , HTTP e CSTCP e UDP para protocolos de alto nívelGatewayLANWireless AP , Wi-Fi Abaixo mostra o cenário bem projetado em que Wi-Phi funciona.
Este também é um estudo de caso que atribuí a mim mesmo. Então vamos mergulhar no caso...
A maioria dos fornecedores de dispositivos envia solicitações HTTP para determinados terminais de servidores de detecção de portal cativo específicos do fornecedor e espera respostas HTTP específicas para entender se a rede Wi-Fi tem um portal cativo ou não.
A tabela abaixo mostra o que responder para vários fornecedores de dispositivos, a fim de fazer com que o dispositivo suponha que existe um portal cativo na rede Wi-Fi.
Nota : Mozilla é uma exceção aos 'fornecedores de dispositivos'. O Firefox (como navegador) é capaz de tomar essa decisão sozinho, de acordo com seu próprio servidor de detecção de portal cativo.
As respostas com o código de status 302 Found também precisam ter um cabeçalho Location: para redirecionar o navegador (cliente) corretamente.
| Fornecedor de dispositivos | Pontos finais | Código de status | Corpo de Resposta |
|---|---|---|---|
| Microsoft (Windows) | www.msftconnecttest.com/ncsi.txt | 200 OK | Microsoft NCSI |
| Microsoft (Windows) | www.msftconnecttest.com/connecttest.txt | 200 OK | Microsoft Connect Test |
| Microsoft (Windows) | www.msftconnecttest.com/redirect | 302 Found | |
| Google (Android) | connectivitycheck.gstatic.com/gen_204 | 302 Found | |
| Google (Android) | connectivitycheck.gstatic.com/generate_204 | 302 Found | |
| Google (Android) | clients3.google.com/generate_204 | 302 Found | |
| Xiaomi | connect.rom.miui.com/gen_204 | 302 Found | |
| Xiaomi | connect.rom.miui.com/generate_204 | 302 Found | |
| Apple (IOS/Mac OS) | captive.apple.com/hotspot-detect.html | 302 Found | |
| Mozilla (Firefox) | detectportal.firefox.com/canonical.html | 302 Found | |
| Mozilla (Firefox) | detectportal.firefox.com/success.txt | 302 Found |
Para poder responder às solicitações http feitas aos endpoints acima, essas solicitações devem ser enviadas ao servidor HTTP do ESP32. Para conseguir isso, o ESP32 deve responder a pesquisas de domínio específicas para seu próprio endereço IP.
google.com deve ser 210.210.210.1Portanto, é necessário que haja um servidor de sistema de nomes de domínio em execução no ESP32. Deste ponto de vista, o cenário é semelhante aos ataques de sequestro de DNS.
Acho que o Google é a empresa de tecnologia mais popular e confiável do mundo. Então preparei uma página estática de phishing, que se parece quase com a antiga página de login do Gmail. E também nomeou a rede Wi-Fi como Google Free Wi-Fi .
À medida que o cenário continua, após redirecionar o navegador (cliente) para a página de login estática, o usuário deve inserir suas credenciais e pressionar o botão próximo. E as credenciais são armazenadas em um arquivo local. Então o usuário será banido do IP até a próxima reinicialização do ESP32. Caso contrário, o banco de dados local pode ser confuso por credenciais falsas/erradas. Depois de tudo isso, o cliente é redirecionado para o diretório / do site estático.
Sempre que um cliente IP banido tenta acessar qualquer recurso no servidor HTTP, o mesmo arquivo html hacklendin.html está sendo servido independentemente do método, cabeçalho, corpo da solicitação HTTP, etc.
Por outro lado, o armazenamento de credenciais locais pode ser visualizado remotamente conectando-se ao 2121/tcp e autenticando com a senha codificada enquanto estiver conectado ao Wi-Fi.
Wi-Phi é um sistema rico em recursos. Logs detalhados criados por serviços Wi-Fi , HTTP e DNS podem ser visualizados em tempo real. Esses logs não são armazenados localmente para economizar armazenamento.
Para poder ver registros detalhados,
boot.py para um arquivo local chamado main.py .boot.py do dispositivo ESP32.main.py no ESP32. Você pode usar a ferramenta ampy para operações de arquivos e execução de software no ESP32.
Vejamos um caso em que temos vários dispositivos independentes de vários fornecedores conectados ao nosso Google Free Wi-Fi ao mesmo tempo.
Quando os dispositivos IOS encontram um portal cativo, eles acionam automaticamente a página do portal cativo, sem avisar o usuário, Legal!
Os dispositivos Samsung mostram apenas uma notificação. Portanto, aqui o usuário precisa clicar em Sign in to the network ou na notificação na parte superior da tela.
Os dispositivos Xiaomi também mostram uma notificação. Às vezes, eles também abrem a página do portal cativo automaticamente, sem avisar o usuário novamente!
No Firefox, um prompt aparece na parte superior da janela do aplicativo. Depois de clicar em Open network login page , a página do portal cativo será aberta em uma nova guia.
E o outro cara que nem deixa o usuário decidir (como o IOS). Sempre abre a página do portal cativo automaticamente.
Como expliquei antes,
Todo o período de aprendizado, implementando o que aprendi na vida real, corrigindo bugs e escrevendo esta documentação foi muito divertido para mim! Espero que você use esse conhecimento para a ética! Contate-me para perguntas adicionais e casos empresariais/acadêmicos/educacionais.
Twitter
LinkedIn
HackerOne
Hackear a caixa
─ Escrito por Şefik Efe Altınoluk ─
