Há algum tempo, tive a oportunidade de experimentar as configurações de um roteador comum. O fato é que o primeiro de abril me obrigou a interpretar meus companheiros da universidade. A universidade tinha uma rede Wi-Fi. Decidi criar uma rede falsa no meu roteador (definir um nome, senha e definir o endereço MAC de um dos pontos de acesso legítimos), iniciar meu próprio servidor DNS no servidor. Todos que acidentalmente se conectaram à minha rede e tentaram acessar qualquer site devem ser redirecionados para minha página com uma foto de April Fools. Mas a história não é sobre isso. Quando eu estava mexendo nas configurações do roteador, encontrei um bug interessante, vou falar sobre isso hoje.
No estágio de configuração, o roteador estava conectado à Internet. Mas, por alguma razão, os dispositivos conectados ao Wi-Fi não receberam a Internet. Eu tenho que entender. Como havia uma guia no painel do roteador com a capacidade de usar o utilitário ping, o telnet não pode ser ativado (espero que todos os leitores entendam o perigo do telnet aberto para o exterior?). O formulário ficou assim:
Esse recurso é implementado da seguinte maneira. O programa roteador recebe do usuário uma sequência contendo o endereço e substitui o comando ping na sequência de chamadas:
ping -c < > <>
Quão bem o roteador verifica a string que contém o endereço? Foi essa questão que surgiu na minha cabeça. Depois substituí o e comercial e o
comando ls . Eu entendi isso:
Para aqueles no tanque
Nos sistemas UNIX, podemos forçar o bash a executar um comando em segundo plano, substituindo um e comercial depois dele. Ao mesmo tempo, podemos substituir um comando após oe comercial, e ele será executado simultaneamente com o primeiro. O que eu usei neste caso. Substituindo "8.8.8.8 & ls", obtive "ping -c 3 8.8.8.8 & ls". O roteador executou os comandos ping e ls simultaneamente. Então trouxe o resultado.
Se esse bug fosse permitido em outro lugar, ele se tornaria uma ameaça muito séria. Afinal, essa vulnerabilidade ajudaria um invasor a forçar o roteador a executar qualquer comando ou a obter controle completo sobre o dispositivo. Essas vulnerabilidades são classificadas como
CWE-78 (Injeção de comando do SO) .
Não fiquei quieto e me apressei a escrever ao fabricante sobre o bug encontrado. Descrevi em detalhes o modelo do roteador, a versão do firmware e o script para executar o bug. Para o qual recebi uma resposta interessante:
Tradução (verbatim)
Você pode verificar a versão do hardware na etiqueta inferior do produto?
Nós não temos Rev. Px. Você conhece a fonte ou o local de compra deste dispositivo?
Como se viu, eles não levaram em conta o que eu estava escrevendo da Rússia. Este modelo do roteador foi distribuído apenas em nosso país. A correspondência terminou com um novo firmware que me foi enviado, o que eliminou todas as deficiências do anterior e adicionou muitos recursos, mas, por algum motivo, não era de domínio público.
