Execução remota de código no Infomir Ministra expôs plataforma IPTV a controle de servidor

Falhas encadeadas em autenticação, consulta SQL e desserialização em PHP permitiam assumir servidores Ministra usados para gerenciar set-top boxes e clientes de provedores IPTV.

Componente	Plataforma web Infomir Ministra, anteriormente Stalker, usada por provedores IPTV, OTT e VoD para gerenciar set-top boxes e clientes.
Vetor	Bypass de autenticação em funções AJAX do painel administrativo, seguido de injeção SQL em parâmetros de tabela e desserialização PHP de dados controláveis.
Impacto	Execução remota de código no servidor Ministra, com risco de controle da plataforma, acesso a dados de clientes mantidos pelo provedor e alteração de conteúdo distribuído aos dispositivos.
Prioridade	Confirmar atualização para a versão 5.4.1 ou posterior, revisar exposição do painel administrativo e procurar abuso em logs de controladores AJAX, consultas SQL anômalas e escrita inesperada de arquivos PHP.
Versões	As vulnerabilidades foram corrigidas na versão 5.4.1 de Stalker/Ministra.
Artefatos	Controladores em admin/src/Controller, funções como video_schedule_list_json, video_logs_json, prepareDataTableParams, setLinksForVideoLog, uso de unserialize e classes SwiftMailer.
Mitigação	Aplicar a correção do fornecedor, restringir acesso administrativo, validar entrada usada em chaves de consulta, remover desserialização insegura de dados não confiáveis e monitorar escrita de arquivos no servidor web.

Resumo técnico

A falha analisada atingia o Infomir Ministra, uma plataforma web em PHP usada por provedores de IPTV, OTT e VoD para administrar clientes, set-top boxes e entrega de conteúdo. O Ministra atua como ponto intermediário entre o provedor e os dispositivos instalados nas residências: o set-top box consulta a plataforma para obter parâmetros, programação e conteúdo, enquanto a operação do provedor usa a interface administrativa para gerenciar assinantes e serviços. Quando esse plano de controle fica comprometido, o impacto não se limita ao servidor isolado, porque a plataforma concentra funções de administração do serviço e dados associados aos clientes do provedor.

O problema principal não era uma única falha isolada, mas uma cadeia explorável. A primeira etapa permitia contornar verificações de autenticação em algumas funções AJAX do painel administrativo. A partir desse acesso indevido a rotas internas, entradas controladas pelo usuário eram passadas para uma rotina de preparação de parâmetros de tabela, influenciando chaves posteriormente usadas em consultas SQL. Essa condição viabilizava injeção SQL. Em outro ponto do fluxo, dados obtidos por consulta podiam chegar a uma chamada de unserialize, criando uma ponte entre injeção SQL refletida e injeção de objeto PHP. Com classes presentes no ambiente, especialmente do SwiftMailer, a cadeia podia resultar em escrita arbitrária de arquivo e, por consequência, execução remota de código no servidor.

Fluxo técnico

A superfície inicial estava em controladores administrativos localizados em admin/src/Controller. Algumas funções foram projetadas para uso AJAX e diferenciavam o comportamento conforme a presença do cabeçalho X-Requested-With com valor associado a XMLHttpRequest. O erro lógico estava em condicionar a validação de autenticação ao caminho considerado AJAX. Quando a requisição não seguia esse formato esperado, certas funções podiam ser alcançadas de maneira não autenticada, ampliando a superfície exposta do painel. Esse tipo de falha é crítico porque desloca código originalmente pensado para operadores autenticados para um cenário em que entradas externas passam a atingir rotinas administrativas.

Depois do bypass, a função video_schedule_list_json, dentro de VideoClubController, encaminhava dados de GET ou POST para prepareDataTableParams. A rotina processava estruturas como colunas, ordenação, filtros e busca, e permitia que nomes de colunas definidos pelo usuário influenciassem chaves em arrays como order, select e like. Em muitos sistemas, valores recebem validação mais rígida do que nomes de campos ou chaves internas, porque o desenvolvedor presume que esses identificadores vêm de código confiável. Aqui, essa suposição quebrava: a entrada externa afetava elementos usados mais adiante na construção da consulta, permitindo injeção SQL cega ou refletida conforme o ponto atingido.

O encadeamento tornava-se mais grave em video_logs_json, também associado ao mesmo controlador. Essa função combinava o bypass de autenticação, a rotina vulnerável de preparação de parâmetros e uma consulta cujo resultado seguia para setLinksForVideoLog. Dentro desse caminho, dados retornados podiam ser entregues a unserialize. Em PHP, desserializar conteúdo sob controle indireto do atacante permite instanciar objetos e acionar métodos mágicos existentes no código carregado, como __destruct. A cadeia descrita aproveitava classes do SwiftMailer disponíveis no ambiente para chegar a uma primitiva de escrita de arquivo. Como o servidor processava PHP, escrever conteúdo em um caminho executável pelo servidor web podia transformar a falha em execução remota de código.

O ponto defensivo mais importante é que nenhuma dessas etapas deve ser tratada de forma isolada. Um bypass de autenticação em função administrativa já é severo; uma injeção SQL em chaves de consulta agrava a exposição; e uma desserialização insegura de dados influenciáveis cria a transição para execução de código. A exploração completa dependia da combinação dessas condições, mas todas pertenciam à mesma aplicação e ao mesmo fluxo lógico de controladores, consultas e pós-processamento de resultados.

Superfície afetada

A plataforma afetada era o Ministra, antes chamado Stalker, usado por provedores que compravam a solução para oferecer serviços de streaming e televisão via IP a seus clientes. O levantamento descrito no contexto identificou cerca de mil provedores ou revendedores associados à plataforma em diferentes países, embora o número de assinantes finais por provedor não tenha sido determinado. Isso significa que a superfície real dependia da quantidade de instâncias expostas, do estado de atualização de cada instalação e da forma como cada provedor publicava o painel e os endpoints administrativos.

O servidor Ministra é sensível porque concentra funções de gerenciamento de clientes e de entrega de conteúdo aos set-top boxes. Um comprometimento do servidor poderia permitir controle operacional da plataforma do provedor. O contexto aponta riscos sobre dados pessoais e detalhes financeiros da base de clientes, além da possibilidade de alterar o conteúdo transmitido aos usuários conectados à rede do serviço. Esses impactos devem ser entendidos como consequência do controle da aplicação de gestão, não como confirmação de que dados foram efetivamente extraídos em algum incidente específico.

Ambientes com maior exposição eram aqueles que mantinham versões anteriores à correção, publicavam a interface administrativa ou endpoints relacionados sem segmentação adequada e não aplicavam validação forte sobre rotas administrativas. Como o problema estava em funções internas chamadas a partir de controladores PHP, controles de borda capazes de bloquear padrões específicos ajudam, mas não substituem a atualização da aplicação e a revisão do desenho de autenticação.

• Instâncias Infomir Ministra/Stalker anteriores à versão 5.4.1.
• Servidores usados por provedores IPTV, OTT e VoD para administrar set-top boxes e assinantes.
• Rotas administrativas PHP com funções AJAX expostas além do escopo autenticado esperado.
• Fluxos que passam dados de requisição para prepareDataTableParams e depois para consultas SQL.
• Código que chama unserialize sobre dados derivados de consultas ou de entradas não confiáveis.

Hunting e telemetria

A investigação defensiva deve começar pelos logs HTTP do servidor Ministra, especialmente requisições para controladores administrativos que não apresentem o padrão esperado de sessão autenticada. Como o bypass envolvia o tratamento de requisições AJAX, vale comparar chamadas legítimas feitas pela interface administrativa com chamadas sem o cabeçalho esperado ou com variações incomuns de parâmetros de tabela. A presença de parâmetros associados a colunas, ordenação, visibilidade, pesquisa e nomes de campo em endpoints administrativos acessados por clientes não autenticados é um sinal relevante.

No banco de dados e na camada da aplicação, os defensores devem procurar consultas com nomes de coluna anômalos, uso inesperado de operadores em campos de ordenação e filtros, erros SQL gerados por parâmetros de tabela e respostas administrativas fora do padrão. Como a cadeia podia refletir dados arbitrários para posterior desserialização, eventos que combinem erros SQL, respostas volumosas incomuns e chamadas subsequentes a rotinas de logs de vídeo merecem prioridade. Em ambientes PHP, falhas de desserialização podem deixar rastros como erros de classe, warnings de objeto inválido, mensagens relacionadas a métodos mágicos ou exceções vindas de bibliotecas carregadas.

No endpoint e no sistema de arquivos do servidor, a hipótese de escrita arbitrária deve ser validada com cuidado. Procure arquivos PHP criados ou modificados fora do ciclo normal de atualização da aplicação, especialmente em diretórios graváveis pelo processo do servidor web. Alterações próximas ao horário de requisições administrativas anômalas, arquivos com nomes incomuns, permissões alteradas e conteúdo PHP não pertencente ao pacote original são evidências fortes. Também é útil comparar a árvore da aplicação com uma instalação limpa da versão correta e revisar integridade de bibliotecas como SwiftMailer, sem presumir que a biblioteca seja maliciosa por si só.

• Requisições a controladores em admin/src/Controller sem sessão administrativa válida.
• Chamadas a funções AJAX com ausência ou manipulação incomum de X-Requested-With.
• Parâmetros de tabela contendo nomes de colunas, ordenação, filtros ou busca fora do padrão da interface.
• Erros SQL, respostas refletidas inesperadas e logs de aplicação envolvendo prepareDataTableParams.
• Mensagens PHP relacionadas a unserialize, métodos mágicos, SwiftMailer ou objetos inválidos.
• Arquivos PHP novos ou modificados em diretórios servidos pela aplicação, sem correspondência com atualização planejada.
• Mudanças de conteúdo transmitido, comportamento anormal de set-top boxes ou ações administrativas não atribuídas a operadores legítimos.

Mitigação

A correção primária é atualizar Stalker/Ministra para a versão 5.4.1 ou posterior, na qual as vulnerabilidades descritas foram corrigidas. Provedores que ainda operam versões antigas devem tratar a atualização como medida prioritária, porque a cadeia permite sair de uma requisição não autenticada para execução de código no servidor. Antes da atualização, é recomendável preservar evidências de logs e fazer cópia forense dos artefatos relevantes quando houver suspeita de exploração, para evitar perda de sinais durante a substituição de arquivos da aplicação.

Além do patch, a arquitetura de exposição deve ser revista. O painel administrativo e seus endpoints não devem ficar acessíveis diretamente a partir da Internet sem controles adicionais. Segmentação de rede, allowlists administrativas, autenticação forte, proteção por VPN corporativa e registros centralizados reduzem a chance de exploração e aumentam a capacidade de investigação. A aplicação também deve tratar rotas AJAX como rotas administrativas comuns: a validação de autenticação precisa ocorrer independentemente de cabeçalhos que apenas indicam o tipo de requisição feita pelo navegador.

No código, a correção conceitual passa por três pontos. Primeiro, dados do usuário não podem controlar identificadores SQL sem lista positiva estrita de colunas permitidas. Segundo, construtores de consulta devem validar separadamente valores e nomes de campos, porque chaves de arrays também podem se tornar parte da instrução SQL. Terceiro, unserialize não deve consumir dados que possam ser influenciados por requisições, banco de dados ou respostas refletidas, salvo em desenho extremamente controlado e com classes permitidas de maneira explícita. Quando a desserialização for indispensável, a revisão deve considerar todos os métodos mágicos e classes carregadas no processo PHP.

Para resposta a incidente, a sequência defensiva deve combinar atualização, isolamento, coleta e validação. Instâncias expostas devem ser retiradas temporariamente do acesso público quando houver indício de exploração, sem interromper evidências necessárias. Em seguida, revisar usuários administrativos, sessões, histórico de alterações de conteúdo, base de clientes, logs de aplicação, logs do servidor web e integridade de arquivos. Caso haja evidência de escrita arbitrária ou execução de código, a recuperação deve partir de mídia confiável e versão corrigida, não apenas da remoção manual de um arquivo suspeito.

• Atualizar Ministra/Stalker para a versão 5.4.1 ou posterior.
• Restringir acesso ao painel administrativo por rede, identidade forte e segmentação.
• Aplicar lista positiva para nomes de colunas e campos usados em consultas SQL.
• Remover ou encapsular com segurança chamadas a unserialize sobre dados não confiáveis.
• Revisar arquivos PHP criados recentemente e comparar a aplicação com uma versão limpa.
• Centralizar logs HTTP, PHP e banco de dados para correlação de requisições, erros e alterações de arquivos.
• Verificar ações administrativas, mudanças em conteúdo entregue aos set-top boxes e acessos a dados de clientes.
• Reinstalar a aplicação a partir de pacote confiável quando houver sinal de execução de código no servidor.