Segurança do Bitrix sem Ilusões: 10 Problemas que Não Precisam de um Novo CVE

Quando se discute segurança, o foco rapidamente se volta para CVEs/BDUs: Qual versão está vulnerável? Existe um exploit público? O fornecedor já lançou um patch? Embora isso seja importante, na prática, instalações do Bitrix podem ser comprometidas não por uma única 'vulnerabilidade crítica do ano', mas sim por uma combinação de fatores comuns. Problemas como o filtro proativo desativado devido a falsos positivos, a postergação de atualizações de kernel que quebram customizações, a presença de restore.php na raiz do site, logs de erro acessíveis via navegador, administradores usando contas compartilhadas sem MFA, ou backups armazenados no mesmo servidor e acessíveis para escrita, podem parecer insignificantes individualmente. No entanto, juntos, eles criam um caminho conveniente desde a reconhecimento até a captura do servidor. Este artigo detalha dez problemas de segurança característicos de instalações auto-hospedadas do 1C-Bitrix e Bitrix24, com ênfase na configuração, exploração e desenvolvimento, em vez de CVEs isolados.

1. Módulo de Segurança Desativado e Filtro Proativo: O Bitrix possui um módulo de segurança nativo que inclui um Web Application Firewall (WAF) conhecido como Filtro Proativo, além de funcionalidades de logging, proteção contra redirecionamentos e controle de sessão. Frequentemente, este módulo ou seus componentes são desativados devido a conflitos com código customizado, falsos positivos, durante diagnósticos, após migrações ou por desconhecimento de sua função. O código do Bitrix verifica a ativação do filtro proativo através de CSecurityFilter::IsActive(), considerando sua desativação um problema sério. Contudo, a simples ativação não garante segurança total; o WAF pode ser enfraquecido se sua lista de exceções incluir diretórios inteiros, módulos ou grupos de usuários. É crucial verificar a ativação do módulo security, do filtro proativo, as exceções configuradas (limitando-as a caminhos específicos, métodos e parâmetros de requisição), quem tem permissão para contornar o filtro, a ativação do logging de eventos e como esses eventos são tratados. Exceções excessivas indicam um problema no código da aplicação, não no WAF.

2. Confiança Excessiva no WAF para Corrigir Código Vulnerável: Uma mentalidade perigosa é acreditar que um WAF ativo dispensa a correção do código vulnerável. Embora o WAF seja uma camada de defesa valiosa e útil para virtual patching temporário, ele não pode garantir a proteção contra falhas como quebra de controle de acesso, IDORs, abuso de lógica de negócios, ações de usuários comprometidos, race conditions, processamento inseguro de arquivos, cadeias de ataque complexas ou requisições que caem nas exceções. Mesmo para injeções clássicas, a eficácia do WAF pode variar dependendo da codificação, formato da requisição, ordem de decodificação, tipo de conteúdo e diferenças entre o parser do WAF e a aplicação. Portanto, um virtual patch deve ter um responsável, uma tarefa de correção e um prazo. Após a aplicação do virtual patch, a vulnerabilidade original deve ser reavaliada em um ambiente isolado sem a regra de proteção para confirmar a correção da causa raiz, e não apenas a ocultação de um vetor de exploração.

3. Kernel, Módulos e Código Customizado Desatualizados: Uma instalação do Bitrix é composta por mais do que apenas o kernel do CMS. Ela pode incluir módulos do Marketplace, componentes customizados, bibliotecas PHP, dependências JavaScript, integrações com sistemas de CRM, pagamentos e entrega, além do servidor web, PHP, banco de dados e sistema operacional. Um único componente desatualizado ou abandonado pode deixar todo o sistema vulnerável. O código customizado, em particular, requer atenção especial, pois pode não ter CVEs, boletins de segurança ou assinaturas de scanners conhecidas, mas ainda assim conter SQL injections, XSS, SSRF, deserialização insegura, falhas de autorização ou upload de arquivos inseguro. Um processo mínimo de gerenciamento de vulnerabilidades deve incluir um registro de módulos e dependências, responsáveis por componentes customizados, controle de versão e status de suporte, Software Composition Analysis (SCA) para dependências de terceiros, Static Application Security Testing (SAST) e análise manual de código crítico, notificações regulares do Bitrix e fornecedores, e prazos de correção baseados no risco e acessibilidade do componente pela internet. A geração de um Software Bill of Materials (SBOM) para cada release é benéfica, pois o escaneamento durante a compilação reflete apenas o estado naquele momento, e novas vulnerabilidades em dependências podem surgir posteriormente.

4. Customizações que Impedem Atualizações do Bitrix: Uma das falhas arquiteturais mais perigosas ocorre quando desenvolvedores modificam diretamente os arquivos do kernel. Inicialmente visto como débito técnico, isso se torna um problema bloqueador quando uma atualização de segurança é lançada: a atualização sobrescreverá as modificações, a reversão das mudanças customizadas pode ser complexa, a verificação de compatibilidade é difícil, o rollback não foi testado e a aplicação do patch é adiada indefinidamente. Atualizações regulares também podem falhar devido a permissões incorretas de arquivo, atributos imutáveis, falta de espaço, bloqueios de conexão de saída, peculiaridades de proxy ou processos de deploy que restauram arquivos antigos do repositório. Uma prática segura envolve não modificar o kernel diretamente, mas sim implementar customizações em diretórios locais suportados, utilizando eventos, módulos locais, templates e sobrescritas de componentes. As atualizações devem ser testadas em um ambiente similar ao de produção, com backups prévios e procedimentos de rollback testados regularmente. Um prazo máximo para a aplicação de atualizações de segurança deve ser definido. A capacidade de atualizar o sistema deve ser parte da aceitação do projeto; um sistema que funciona, mas não pode ser atualizado com segurança, não é considerado mantido adequadamente.

5. Ferramentas Esquecidas como bitrixsetup.php e restore.php: Após a instalação ou restauração, ferramentas como bitrixsetup.php, restore.php, scripts de migração, importadores de banco de dados, gerenciadores de arquivos, páginas de diagnóstico, ferramentas temporárias de suporte técnico ou cópias antigas com extensões .bak, .old, .save ou .zip podem permanecer na raiz do site (webroot). A proteção dessas ferramentas com nomes de arquivo complexos ou segredos na query string não constitui controle de acesso, mas sim uma aposta na não descoberta do URL. As consequências variam desde a exposição de configurações, upload de arquivos, importação de backups, sobrescrita de dados até execução de código. O ciclo de vida adequado para uma ferramenta temporária inclui: upload antes de trabalhos planejados, restrição de acesso via VPN, ACL de rede e autenticação, execução dos trabalhos, verificação dos resultados, remoção da ferramenta e revisão dos logs de acesso. A busca por esses arquivos deve ser incluída tanto em auditorias internas do sistema de arquivos quanto em escaneamentos externos do site.

6. Dumps, Logs, .git e Configurações no Webroot: A raiz do site frequentemente se torna um repositório de artefatos de exploração, como /backup_2026.sql.gz, /site-old.zip, /.git/HEAD, /.env, /phpinfo.php, /debug.log, /local/php_interface/dbconn.php.bak. Cada um desses arquivos pode expor credenciais, estrutura do banco de dados, código-fonte, histórico de alterações, caminhos internos, versões de componentes, dados pessoais ou chaves de integração. Uma regra de negação no Nginx ou Apache é útil, mas não deve ser a única defesa, pois configurações mudam e novos arquivos podem surgir. A regra mais segura é simples: arquivos sensíveis não devem residir no diretório webroot. Adicionalmente, é necessário desativar a listagem de diretórios, bloquear o acesso a dot-files, impedir a entrega de dumps, arquivos, logs e extensões de configuração, usar uma lista de tipos permitidos para uploads públicos e verificar o site a partir de um nó externo, não apenas revisando a configuração do servidor. A verificação externa é crucial para entender o resultado real do CDN, reverse proxy, virtual host e regras de roteamento.

7. Depuração e Logs que se Tornam Vazamentos: Em ambientes de produção, recursos como o modo de depuração de exceções do Bitrix, $DBDebug, $DBDebugToFile, display_errors do PHP, Xdebug, trace detalhado de SMTP ou cURL, e constantes de depuração temporárias não devem permanecer ativados. Erros detalhados podem revelar consultas SQL, caminhos de arquivo, classes, versões de módulos, nomes de host e detalhes da lógica interna. Logs podem conter cookies, tokens, corpos de requisição, dados pessoais e strings de conexão. A análise do código do Bitrix revela caminhos de logging dentro do diretório raiz, como bitrix/modules/error.log, mysql_debug.sql, bitrix/modules/updater.log, modules/updater_partner.log, bitrix/modules/serverfilelog-*.dat. A localização de logs no diretório do site representa um risco de publicação acidental. Para logs de usuário e de exceção, um diretório separado, como /var/log/bitrix/, é preferível. Além da mudança de caminho, são necessárias permissões mínimas de leitura/escrita, rotação e limitação de tamanho, período de retenção, sincronização de tempo, mascaramento de segredos, proteção contra falsificação e envio de cópias para um SIEM. Um log não analisado só ajuda após um incidente; um log com regras de detecção configuradas pode ajudar antes que o dano se torne evidente.

8. Proteção Fraca do Acesso Administrativo: O painel de administração é um alvo valioso, e ainda é comum encontrar contas de administrador compartilhadas, senhas fracas ou reutilizadas, ausência de MFA, acesso contínuo de ex-funcionários e contratados, privilégios excessivos para editores, acesso irrestrito de qualquer rede e falta de notificações sobre novos administradores ou alterações no MFA. O comprometimento de uma conta administrativa pode tornar a exploração de vulnerabilidades técnicas desnecessária, pois o atacante já obtém uma interface de gerenciamento legítima. Medidas básicas incluem contas individuais, MFA obrigatório para usuários privilegiados, princípio do menor privilégio, revisão regular de acessos, desativação rápida de ex-funcionários e contratados, restrição do painel via VPN, identity-aware proxy ou ACL de rede, logging de logins, redefinições de senha, alterações de grupo, permissões e MFA, e alertas sobre atividades anômalas. É importante verificar quem tem permissão para contornar o Filtro Proativo, pois um privilégio conveniente para um editor confiável aumenta as consequências do roubo de sua conta.

9. Configuração Insegura do Servidor Web, PHP e Sistema de Arquivos: Mesmo um código bem escrito opera dentro de um ambiente operacional. Falhas nesse nível podem anular as defesas da aplicação. Problemas típicos incluem versões TLS e cifras fracas desatualizadas, ausência de HTTPS obrigatório, exposição de versões de PHP e servidor web, páginas de status públicas, métodos HTTP desnecessários, permissões globais 0777, a capacidade do processo web de modificar todo o código do site, execução de PHP em diretórios de upload, acesso à base de dados ou cache pela internet, e o uso de credenciais compartilhadas entre a aplicação, backups e administração. A combinação de upload de arquivos com a capacidade de executá-los como PHP é particularmente perigosa. Diretórios de upload, cache, arquivos temporários, dumps e logs não devem executar scripts. As permissões do sistema de arquivos devem ser projetadas para que o código da aplicação seja, na medida do possível, somente leitura para o processo web, com escrita permitida apenas em um número restrito de diretórios explicitamente definidos. O controle do cabeçalho Host, acesso direto ao servidor de origem contornando CDN/WAF e o conjunto de nomes de host virtuais permitidos também devem ser monitorados.

10. Ausência de Controle Independente no Servidor: O módulo de segurança do CMS tem uma visão limitada do que está acontecendo. Ele pode registrar uma requisição HTTP suspeita, mas pode não detectar um novo web shell, modificação de cron jobs do sistema, adição de chaves SSH, execução de um processo PHP filho suspeito, conexão de saída para um servidor de comando e controle, roubo de dados diretamente do SGBD, ou desativação/limpeza de logs locais. Portanto, as instalações requerem um nível independente de monitoramento: antivírus, EDR, HIDS ou controle de integridade de arquivos, coleta centralizada de logs, correlação SIEM, monitoramento de processos e conexões de saída, e alertas sobre alterações de código, configuração e privilégios. É útil enriquecer eventos com dados do ambiente, proprietário do ativo, nome do host, site, usuário, módulo e ID da requisição para que analistas de SOC possam priorizar rapidamente. Backups também devem ser independentes da aplicação; se um processo PHP pode excluir o banco de dados de produção e todos os seus backups, a estratégia de recuperação não é completa.

Quando Executar SAST, DAST e Scanners Externos: Uma verificação única antes do lançamento não garante segurança contínua, pois código, infraestrutura, dependências e o perímetro externo mudam. Um cronograma básico prático pode incluir: SAST no CI/CD para PHP e JavaScript customizados (para cada pull request e scan completo semanalmente); SCA e busca por segredos no CI/CD, repositórios, imagens e dependências (para cada pull request e diariamente); DAST básico em ambiente de teste ou efêmero (para cada candidato a release); DAST autenticado em staging (noturno ou semanal); escaneamento externo contra o perímetro real (após deploy e mensalmente); escaneamento de infraestrutura a partir da rede de gerenciamento com autenticação (mensalmente e após mudanças significativas); Pentest em perímetro de produção acordado (antes do lançamento, após grandes mudanças e anualmente); e re-verificação no local onde o problema foi encontrado (após correção de riscos críticos e altos). Testes de carga, recuperação, upload em massa, pagamentos, email/SMS e negação de serviço devem ser realizados em ambiente isolado, a menos que explicitamente acordado para produção. No entanto, o ambiente de produção não deve ser totalmente excluído, pois apenas nele se observam diferenças reais em TLS, cabeçalhos, roteamento, WAF, CDN, DNS e acessibilidade de arquivos de serviço.

Por Onde Começar a Auditoria de uma Instalação Existente: Se um programa AppSec completo ainda não foi construído, comece com uma lista curta: verifique versões do kernel, módulos, PHP, servidor web e SO; assegure que o mecanismo de atualização nativo funciona e foi testado; verifique o módulo security, Filtro Proativo, exceções e MFA; procure instaladores, dumps, arquivos, logs, .git e arquivos de diagnóstico no webroot; desative a saída de depuração e mova logs para fora do webroot; proíba a execução de scripts em diretórios de upload e dados temporários; revise contas administrativas e privilégios; verifique backups com restaurações reais; execute escaneamento externo, SAST, SCA e auditoria autenticada do servidor; e atribua um responsável e prazo para cada problema encontrado. É importante avaliar não apenas a presença de uma configuração específica, mas todo o ciclo de vida; um WAF ativado é inútil sem análise de eventos, e um backup é inútil sem uma restauração de teste bem-sucedida.

Conclusão: A segurança do Bitrix raramente é definida por um único botão ou atualização. É uma solução complexa que envolve desenvolvedores, administradores, DevOps, especialistas em segurança e proprietários do sistema. Uma instalação bem protegida é atualizada sem edição manual do kernel, não armazena segredos ou artefatos de exploração no webroot, não exibe erros internos aos usuários, restringe o acesso administrativo, utiliza o WAF como camada adicional e não substituta para correções, verifica código customizado e dependências, envia eventos para um sistema de monitoramento independente e é capaz de se recuperar de falhas e comprometimentos. Um cheat sheet expandido com o modelo 'Problema - Risco - Solução' está disponível no repositório.