CVE-2020-12124

Anatomia de uma Exploração de IoT, da Prática ao RCE

originalmente em https://www.klogixsecurity.com/scorpion-labs-blog/anatomy-of-an-iot-exploit-from-hands-on-to-rce

por David E. Baker, publicado em 1 de junho de 2023

Prefácio

Este estudo trata do firmware do roteador Gigabit Wavlink Wireless-AC1200 de junho de 2020. As vulnerabilidades aqui discutidas podem ou não ter sido corrigidas pelo fabricante, mas este é um caso de pesquisa de vulnerabilidade que mostrará a jornada como recompensa, e não sua conclusão. O autor conduziu esta pesquisa antes da divulgação pública das vulnerabilidades, mas depois de elas terem sido descobertas independentemente por outros pesquisadores e reportadas ao fabricante.

O fabricante disponibiliza firmware para seus produtos na seção de suporte de seu site; esta é uma forma comum de obter firmware de IoT e uma alternativa útil para extraí-lo da memória do dispositivo. O firmware não é criptografado, portanto pode ser facilmente extraído com binwalk. A análise dinâmica foi feita com acesso a um exemplar físico do dispositivo, e a análise estática foi feita através do Ghidra.

tl;dr

A interface web do roteador Gigabit Wavlink Wireless-AC1200 possui vários endpoints vulneráveis que permitem a cópia irrestrita de dados fornecidos pelo usuário para a pilha da aplicação ou até mesmo diretamente para a linha de comando, resultando em execução arbitrária de comandos.

Prática e Local

As varreduras iniciais do dispositivo sugerem que o único recurso exposto era o console administrativo web, acessível a usuários autenticados na interface LAN via HTTP na porta TCP 80. O dispositivo pode oferecer mais serviços, mas estes não são ativados de fábrica e por padrão. Dessa forma, esta investigação foca apenas na interface web.

_{Uma varredura nmap do exemplar do dispositivo, mostrando apenas a interface web ouvindo.}

Os testes habituais — como as injeções de comando típicas encontradas em painéis de diagnóstico de dispositivos que permitem uma injeção de comando nos parâmetros de um comando ping ou traceroute — não produziram resultados imediatamente interessantes, o que foi decepcionante.

_{Opções de gerenciamento disponíveis após autenticação no painel administrativo web. "Armazenamento USB" pode ser visto como a segunda opção.}

A primeira interface (explorável em última análise) examinada aqui foi encontrada no painel "Armazenamento USB", que pode ser visto como a segunda opção na captura de tela acima. O dispositivo possui uma porta USB adjacente aos seus conectores Ethernet 802.2, sugerindo que poderia oferecer funcionalidade de armazenamento conectado à rede (NAS).

_{Uma fotografia da parte traseira do exemplar real, mostrando a disponibilidade USB.}

Um princípio simples na pesquisa de vulnerabilidades é que, quanto mais componentes um trecho de código interage e mais partes móveis possui, maior a probabilidade de haver código explorável por perto. A presença de capacidades NAS é promissora porque indica a presença de código que interage simultaneamente com a camada de software do dispositivo, camada de hardware e periferia conectada (o próprio armazenamento USB).

A interface de gerenciamento para o console de Armazenamento USB é mostrada abaixo. A presença apenas do campo "Workgroup" é promissora, pois sugeriria que este roteador WiFi pode até tentar interagir via Server Message Block (SMB) — uma grande capacidade para um roteador IoT. Não consigo contar o número de vezes que vi entrada fornecida pelo usuário ser enviada diretamente para a linha de comando como argumento para a função Unix smbpasswd.

_{Opções de armazenamento USB disponíveis para usuários autenticados.}

Tentativas iniciais de manipular essas configurações falharam porque o dispositivo não detectou um drive USB, como visto abaixo.

_{As alterações de configuração nas opções de Armazenamento USB não serão salvas a menos que um drive formatado adequadamente seja conectado manualmente à porta USB do dispositivo.}

No entanto, assim que um drive formatado corretamente é conectado, o dispositivo permitiu que um nome de usuário e senha FTP fossem definidos. Como suspeitado, ele colocou essa entrada fornecida pelo usuário na linha de comando:

_{Uma injeção de comando no campo 'password' concede o primeiro acesso ao shell diretamente ao sistema operacional do dispositivo.}

Embora interessante, essa vulnerabilidade é difícil de gerar entusiasmo esmagador: ela exige não apenas acesso autenticado à interface administrativa do dispositivo, mas também acesso físico ao dispositivo para manipular seu drive USB. A exploração acima permite que um pesquisador interaja com os componentes individuais do sistema operacional (e os exfiltre para fins de engenharia reversa).

Podemos Fazer Melhor

O dispositivo era um sistema Linux centrado em busybox com uma interface web alimentada por Lighttpd. A funcionalidade Common Gateway Interface (CGI) era fornecida por binários individuais em /etc_ro/lighttpd/www/cgi-bin/, com requisições web para URIs CGI lançando esses binários diretamente. Uma rápida olhada em nas.cgi no Ghidra mostra a injeção de comando na linha 38 abaixo, que envia uma senha fornecida pelo usuário diretamente para a função do_system (ela própria simplesmente um wrapper em torno da chamada de sistema libc padrão).

_{A entrada do usuário é colocada na linha de comando como argumento para o script chpasswd.sh na Linha 38, resultando em uma injeção de comando e acesso ao shell diretamente ao sistema operacional do dispositivo.}

Olhando pelo diretório /cgi-bin/, reduz-se a tarefa de encontrar uma exploração mais interessante a enumerar as interfaces CGI disponíveis para o usuário, mostradas abaixo:

_{Uma lista exaustiva dos binários CGI disponibilizados no dispositivo, obtida ao vivo do shell estabelecido pela exploração descrita nesta seção. A entrada do usuário é colocada na linha de comando como argumento para o script chpasswd.sh na Linha 38, resultando em uma injeção de comando e acesso ao shell diretamente ao sistema operacional do dispositivo.}