CVE-2020-37153: Quando Sua Plataforma de Billing VoIP Vira um Shell Root

ASTPP se apresenta como uma solução completa de billing para VoIP. O que também foi entregue foi uma cadeia de ataque multi-estágio que permite a um atacante adjacente à rede ir de zero a root em alguns requests cuidadosamente construídos — e o XSS é quase a parte menos interessante dessa história.

🎯 Impact: Comprometimento total do sistema via XSS encadeado + command injection → root RCE
🔓 Attack Vector: Network (autenticado ou via session hijack)
💥 Exploitability: Moderada (requer autenticação, mas XSS remove essa barreira)
🛡️ Fix Available: Patches específicos de versão; upgrade recomendado
⏱️ Patch Now: Sim — imediatamente, se ASTPP 4.0.1 estiver acessível pela internet

O Que Realmente Está Acontecendo

O ponto é esse sobre um CVSS 9.8 classificado sob CWE-79 (XSS): a fraqueza em destaque subestima o perigo real. A entrada NVD menciona XSS e command injection no mesmo respiro, e esse é o sinal-chave. Não são dois bugs independentes — é uma cadeia de vulnerabilidade composta onde o XSS é o mecanismo de entrega e o command injection é o payload.

ASTPP 4.0.1 falha em sanitizar input controlado pelo usuário em pelo menos duas superfícies administrativas:

1. Interface de configuração de dispositivos SIP — Campos que configuram dispositivos SIP (pense em nomes de dispositivos, user agents, strings de codec) são escritos diretamente em arquivos de configuração ou comandos shell sem escaping adequado.
2. Interface de gerenciamento de plugins — Nomes ou parâmetros de plugins são processados em um contexto onde metacaracteres shell são interpretados.

A causa raiz é clássica e dolorosamente comum em software de gerenciamento de telecom PHP legado: interpolação direta de input do usuário em strings de comando shell. O padrão vulnerável se parece com algo assim:

// Representação conceitual do padrão vulnerável
// NUNCA faça isso
$device_name = $_POST['device_name'];  // Input do usuário não sanitizado
$output = shell_exec("asterisk -rx 'sip show peer " . $device_name . "'");

// Um atacante submete: '; id; whoami; #
// Comando resultante: asterisk -rx 'sip show peer '; id; whoami; #'

O XSS vive no mesmo painel admin, onde input como rótulos de dispositivos ou nomes de exibição de plugins é refletido de volta no DOM sem HTML encoding. Por conta própria, XSS armazenado em um painel admin soa como um achado de severidade média. O que torna isso crítico é o que esse painel admin pode fazer — tem caminhos diretos para command injection e, conforme a divulgação, manipulação de tarefas cron com execução em nível root.

Esse padrão — insufficient output encoding e insufficient input validation compartilhando a mesma superfície de ataque — sugere que a aplicação foi construída sem um modelo de segurança coerente para dados fornecidos pelo usuário. Não são dois erros separados de desenvolvedor; são sintomas da mesma filosofia de design subjacente: confiar que a interface admin receba apenas input amigável.

Plataformas de billing VoIP são particularmente propensas a essa classe de bug porque evoluíram de raízes telecom onde o modelo de ameaça era "o admin é confiável". Toda a arquitetura da aplicação foi construída em torno da conveniência para operadores, não defesa contra uma sessão admin comprometida ou maliciosa.

Caminho de Exploração

O ataque tem duas formas distintas dependendo de que acesso um atacante já possui.

Caminho 1: Command Injection Autenticado (Direto)

Pré-requisitos: Credenciais admin válidas (brute force, credential stuffing, creds vazadas de outro breach, ou credenciais padrão não alteradas).

1. Atacante faz login no painel admin ASTPP.
2. Navega para configuração de dispositivos SIP ou gerenciamento de plugins.
3. Injeta metacaracteres shell em um campo de parâmetro de dispositivo (ex: nome do dispositivo contendo ;malicious_command;).
4. ASTPP processa a ação de save, passando input não sanitizado para uma chamada shell_exec() ou equivalente.
5. Atacante alcança execução de comando sob o processo do servidor web (tipicamente www-data ou asterisk).
6. Se manipulação de cron está disponível (e conforme divulgação, está), atacante planta uma tarefa cron executando como root.
7. Game over. Shell root.

Caminho 2: XSS → Session Hijack → Command Injection (Escalação Não-Autenticada)

Pré-requisitos: Habilidade de colocar um payload XSS armazenado no sistema (ex: via um input voltado ao cliente que aparece na visão admin — comum em plataformas de billing onde dados de cliente são exibidos para admins).

1. Atacante submete um input construído através de uma superfície voltada ao usuário (ticket de suporte, campo de conta, comentário CDR) que é armazenado no banco de dados.
2. Quando um administrador visualiza a página relevante, o XSS armazenado é disparado.
3. O payload XSS exfiltra o cookie de sessão do admin para um servidor controlado pelo atacante.
4. Atacante reproduce o cookie de sessão, ganhando acesso admin autenticado.
5. Procede através do Caminho 1 a partir do passo 2.

Cenário do mundo real: Uma instância ASTPP de um revendedor VoIP está acessível pela internet (comum — admins precisam de acesso remoto). Um atacante se registra como cliente, submete um ticket de suporte com um payload XSS armazenado. Na próxima vez que um admin abre esse ticket, o atacante possui a sessão. Três passos depois, eles têm um backdoor cron root em uma caixa que provavelmente processa dados de pagamento e armazena registros de chamadas para potencialmente milhares de subscribers.

Quem Realmente Está em Risco

ASTPP é popular no espaço de carriers VoIP wholesale e revendedores VoIP — empresas que o executam são frequentemente pequenos a médios operadores de telecom, provedores de PBX hospedado, e operadores de serviços de callback internacional. Esses ambientes tendem a ter:

• Painéis admin acessíveis pela internet (operadores gerenciam remotamente)
• Credenciais padrão ou fracas (pequenas equipes, muitos pratos girando)
• Monitoramento de segurança mínimo (não é sua competência principal)
• Dados de alto valor (CDRs, informações de pagamento, PII de cliente, credenciais de trunk carrier)

Os setores mais expostos: provedores de infraestrutura de telecom, empresas de comunicações hospedadas, e qualquer empresa executando ASTPP para billing interno de sua implantação Asterisk/FreeSWITCH.

No momento desta redação, não estou ciente de exploração em massa confirmada na natureza selvagem, mas isso não é o conforto que poderia parecer. Essa classe de alvo (billing de telecom) é ativamente caçada por grupos criminosos interessados em toll fraud — e um shell root em um servidor de billing é o sonho de um atacante de toll fraud. A ausência de chatter público de PoC não significa que não esteja sendo usado silenciosamente.

Detecção e Hunting

Se você está executando ASTPP e se perguntando se alguém já passou pela sua porta da frente, aqui está o que procurar:

Padrões de Log para Hunt

Verifique seus logs de acesso do servidor web por requests para os endpoints de configuração de dispositivos SIP e gerenciamento de plugins contendo caracteres suspeitos:

# Padrões em access logs que justificam investigação
/admin/devices/save.*[;|`$(){}]
/admin/plugins/.*[;|`$(){}]
POST.*device_name.*%3B    # Ponto-e-vírgula URL-encoded
POST.*plugin.*%7C         # Pipes URL-encoded

Verificação de Backdoor Cron

Se você suspeita de comprometimento, verifique esses locais imediatamente:

# Verificar todas as entradas crontab por adições inesperadas
crontab -l -u root
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.hourly/ /etc/cron.daily/

# Procurar por artefatos de web shell
find /var/www -name "*.php" -newer /var/www/astpp -ls
find /tmp /var/tmp -name "*.php" -o -name "*.sh" 2>/dev/null

Lógica Conceitual de Detecção SIEM

# Regra estilo Sigma conceitual — adapte para seu SIEM
title: ASTPP Admin Panel Command Injection Attempt
description: Detects shell metacharacters in ASTPP admin POST parameters
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|contains:
      - '/admin/devices'
      - '/admin/plugins'
    cs-method: 'POST'
    cs-uri-query|contains:
      - ';'
      - '|'
      - '`'
      - '$('
      - '&&'
  condition: selection
falsepositives:
  - Legitimate admin activity with unusual device names (low probability)
level: high

Linhagem de Processo: Se você tem EDR, procure por asterisk, apache2, ou php-fpm gerando processos filhos como sh, bash, curl, wget, ou nc. Essa árvore de processo é anormal e vale investigação imediata.

Playbook de Mitigação

1. Imediato (Faça Agora)

• Atualize ASTPP para a versão mais recente disponível. Se você está na 4.0.1, você está confirmadamente vulnerável.
• Coloque o painel admin offline ou restrinja a VPN/IPs allowlisted via regras firewall. Isso não conserta o bug, mas colapsa dramaticamente a superfície de ataque.
• Force rotação de todas as credenciais admin e invalide sessões ativas.
• Audit de tarefas cron existentes no host ASTPP agora mesmo usando os comandos acima.

2. Curto-prazo (Se Patch Estiver Atrasado)

• Implante uma regra WAF bloqueando requests para endpoints admin contendo metacaracteres shell (;, |, `, $(, &&, ||).
• Habilite a disable_functions do PHP em php.ini para bloquear shell_exec, exec, system, passthru — embora isso possa quebrar funcionalidade da aplicação e requer testes.
• Implemente headers Content-Security-Policy para limitar impacto XSS: Content-Security-Policy: script-src 'self'.
• Habilite flags HTTP-only e Secure em cookies de sessão para reduzir viabilidade de session hijacking.

3. Endurecimento de Longo-prazo

• Execute a aplicação web como um usuário minimamente privilegiado — nunca deve ser capaz de escrever em diretórios cron.
• Implemente um reverse proxy (nginx) na frente de ASTPP com filtragem de request.
• Separe o processo Asterisk/FreeSWITCH do processo da aplicação web; command injection na tier web não deveria alcançar infraestrutura de telefonia diretamente.
• Conduza uma revisão de código de qualquer outra chamada shell_exec/exec no codebase — onde há uma, geralmente há mais.

4. Verifique Que Você Está Protegido

Após patching ou implementação de mitigações, valide por:

• Tentar submeter um nome de dispositivo contendo ; id através da UI admin — deve ser rejeitado ou sanitizado.
• Confirmar que logs WAF estão capturando tentativas de metacaracteres shell.
• Executar uma varredura credenciada com um scanner de vulnerabilidade moderno contra a instância atualizada.

Minha Análise

O CVSS 9.8 é defensável, mas eu diria que o framing em torno de CWE-79 subestima o que está acontecendo aqui. Começar com XSS sugere uma vulnerabilidade web de moderada a alta; o command injection com escalação root via cron é o que merece a classificação crítica. A cadeia de vulnerabilidade é a história, e a divulgação deveria ter começado com ela.

Para ser honesto, essa vulnerabilidade nos diz algo desconfortável sobre o estado da segurança de software de telecom. Plataformas de billing VoIP servem como o sistema nervoso financeiro de carriers pequenos e médios — elas mantêm dados de pagamento, registros de chamadas, credenciais de trunk carrier, e PII de cliente. Ainda assim, são rotineiramente construídas por pequenas equipes de desenvolvimento otimizando entrega de features sobre segurança, e implantadas por operadores que podem não ter pessoal dedicado a segurança. A superfície de ataque que apresentam é desproporcionalmente grande relativamente ao escrutínio que recebem.

O risco do mundo real aqui é mais alto do que análise acadêmica sugere por causa do perfil do alvo. Um ator de toll fraud com um shell root em um servidor de billing VoIP não apenas tem uma caixa comprometida — tem as chaves para potencialmente rotear milhões de dólares em chamadas fraudulentas através de infraestrutura carrier legítima antes de alguém notar. Esse é um resultado concreto e monetizável que torna isso mais atrativo de explorar do que um RCE típico de web app. A comunidade de segurança deveria tratar software de billing de telecom com o mesmo escrutínio que damos a aplicações do setor financeiro, porque nesse ponto, é efetivamente o que são.

Timeline

Nota: Datas precisas de divulgação do pesquisador e notificação do vendor não são documentadas publicamente em fontes disponíveis. Se você tem informações adicionais de timeline, entre em contato.

Referências

• CVE-2020-37153 — NVD Official Entry — O registro de vulnerabilidade canônico; comece aqui para detalhes CVSS
• CWE-79: Improper Neutralization of Input During Web Page Generation — A classificação de fraqueza XSS fundamental
• CWE-78: OS Command Injection — A fraqueza primária mais acurada para o vetor de ataque crítico aqui
• ASTPP Project — Repositório oficial; verifique a versão mais recente contra sua implantação
• OWASP Command Injection — Referência fundamental para entender e prevenir essa classe de vulnerabilidade
• VoIP Security Alliance (VOIPSA) — Recurso da indústria para modelagem de ameaça específica de VoIP