BK-210 - Hardening do disparo de listas + filtro de eventos externos

Objetivo

Fechar a execução pública indevida de z_dispara.php e z_dispara_diario.php e corrigir o disparo de lista digital para considerar apenas peças com venda online do próprio site.

Contexto confirmado

• z_dispara.php e z_dispara_diario.php ficam na raiz pública do site
• ambos podiam ser chamados por URL e não tinham trava explícita de execução via CLI apenas
• z_dispara_diario.php estava consultando toda a tabela pecas ativa do dia, sem separar:
• peças com venda online
• eventos externos de produtor/bot exibidos em eventos.php
• caso concreto confirmado:
• Equipe Sonic /TIJUCA
• origem = bot
• id_produtor = 50929
• parceria_online = 0
• link_externo apontando para Sympla

Regra de filtro adotada

Usar a mesma distinção já aplicada na vitrine de eventos.php:

• venda online:
• id_produtor IS NULL
• ou parceria_online = 1
• evento externo:
• id_produtor preenchido
• e parceria_online = 0

Próximos passos

• bloquear execução web pública dos dois scripts
• restringir o SQL para peças com venda online
• validar sintaxe PHP

Atualização de 2026-04-03 20:24 -03

• z_dispara.php passou a aceitar apenas execução via CLI
• z_dispara_diario.php passou a aceitar apenas execução via CLI
• ambos agora retornam 403 quando acessados por URL pública
• o filtro de peças para lista digital ficou restrito a:
• id_produtor IS NULL
• ou parceria_online = 1
• isso elimina da rotina diária os eventos externos mostrados em eventos.php
• caso concreto validado fora do filtro:
• Equipe Sonic /TIJUCA
• origem=bot
• id_produtor=50929
• parceria_online=0
• link_externo Sympla

Validação

• php -l z_dispara.php
• php -l z_dispara_diario.php
• curl -I https://rionoteatro.com.br/z_dispara.php -> 403
• curl -I https://rionoteatro.com.br/z_dispara_diario.php -> 403

Atualização de 2026-04-11 14:55 -03

Achado crítico novo

• re_env.php estava público na web e respondia 200
• esse arquivo monta exatamente assuntos Lista Vendas PRÉ: / Lista Vendas FINAL:
• ele também contém um bug grave de reenvio:
• $enviada_anteriormente = false;
• if (!$enviada_anteriormente) { ... envia ... }
• na prática, se executado, ele reprocessa histórico de tab_emailenviado sem idempotência real

Evidência desta rodada

• curl -I https://rionoteatro.com.br/re_env.php retornava 200 antes do hotfix
• curl -I https://rionoteatro.com.br/z_dispara.php e z_dispara_diario.php já retornavam 403
• mailq/postqueue mostrou 426 mensagens enfileiradas do remetente www@rionoteatro.com.br
• a fila foi purgada de forma emergencial para interromper o envio contínuo
• z_dispara.php atual não era a origem imediata do disparo, porque está falhando cedo com Unauthorized ao tentar parsear XML do PagSeguro

Mitigação emergencial aplicada

• re_env.php agora exige CLI
• o vhost Nginx passou a bloquear via web:
• /re_env.php
• /z_dispara.php
• /z_dispara_diario.php
• /z_dispara_pagamento.php
• Canadá (CA) entrou na lista Geo bloqueada do site

Leitura técnica atual

• há ataque real de varredura contra /produtor/modulos/eventos/incluir.php
• mas a evidência atual favorece problema operacional interno + helper legado exposto, não execução confirmada do hacker dentro do cron

Atualização complementar de 2026-04-11 15:15 -03

• z_dispara.php ficou com automação de e-mail desativada por padrão
• reativação futura só via RNT_LISTA_EMAILS_ENABLED=1
• z_dispara_diario.php ficou com e-mail diário desativado por padrão
• o fluxo diário passa a operar em modo WhatsApp-only enquanto a investigação continua
• quando houver sucesso de WhatsApp, a sessão agora pode ser marcada como enviada mesmo sem e-mail
• z_dispara.php também recebeu lock MySQL próprio para evitar sobreposição futura caso o canal seja reativado

Leitura operacional

• isso não prova comprometimento do hacker no cron
• isso reduz drasticamente o risco residual imediato do nosso lado
• a trilha de e-mail da lista fica suspensa até revisão completa de credenciais, fallback SMTP e reentrada

Atualização complementar de 2026-04-11 15:32 -03

• z_dispara.php ficou com automação de e-mail desativada por padrão
• reativação futura só via RNT_LISTA_EMAILS_ENABLED=1
• a entrada de cron do wrapper 80db3a025a56a14fa7d6abb30c7e0444 foi removida do crontab do root
• z_dispara_diario.php ficou com e-mail diário desativado por padrão
• o fluxo diário passa a operar em modo WhatsApp-only enquanto a investigação continua
• quando houver sucesso de WhatsApp, a sessão pode ser marcada como enviada mesmo sem e-mail
• re_env.php agora exige CLI e --confirmed
• a fila do MTA do remetente www@rionoteatro.com.br foi zerada

Leitura operacional refinada

• o vetor mais perigoso encontrado foi helper legado exposto + fila local de e-mail, não prova de execução remota bem-sucedida do cron
• o ataque ao produtor/eventos continua relevante, mas até aqui sem evidência de persistência do payload no nome das peças ativas
• risco residual mais importante: credenciais SMTP hardcoded ainda expostas no código legado