Tecnologia e inovação

PaperCut Release 2: como corrigir sem perder SAML ou leitura de cartões

|Autor: Equipe editorial da QUASA|6 min de leitura| 3
PaperCut Release 2: como corrigir sem perder SAML ou leitura de cartões

Para corrigir o ambiente sem devolver um serviço quebrado aos usuários, instale o Emergency Patch Release 2 adequado ao PaperCut NG ou MF 24, 25 ou 26 em toda a topologia exigida e só reabra o acesso depois de testar SAML, Card/ID e liberação de impressão. Instalações anteriores à versão 24 precisam ser atualizadas para uma versão atual.

Antes da mudança, retire as interfaces web do Application Server da internet ou restrinja-as a IPs confiáveis. O alerta do NHS England registra exploração ativa, recomenda o Release 2 e orienta eliminar a exposição pública quando a correção imediata não for possível.

1. Conter e inventariar antes da instalação

A contenção vem antes do instalador. Aplique regras de firewall, controles de acesso à rede ou medidas equivalentes para impedir que endereços não confiáveis alcancem as interfaces web do Application Server; mantenha essa restrição durante a atualização e os testes.

Registre produto, versão principal, sistema operacional e função de cada host. O inventário deve incluir o Application Server primário, todos os Site Servers e servidores secundários ou de impressão, além do banco externo, do provedor de identidade SAML e dos dispositivos usados para autenticação e liberação de trabalhos.

  • Anote a versão instalada e o estado dos serviços antes da parada.
  • Faça um backup testável do Application Server, incluindo diretório da aplicação e banco de dados, e guarde-o fora do servidor.
  • Preserve certificados, parâmetros SAML, drivers JDBC e arquivos de configuração alterados.
  • Defina antecipadamente quais falhas exigirão interromper a reabertura, como perda de autenticação ou impossibilidade de liberar uma impressão.

Se já houver indício de comprometimento, preserve o estado atual para investigação. Não considere esse backup automaticamente confiável para uma restauração posterior.

2. Escolher o pacote e conferir o SHA-256

Validação do SHA-256 do instalador correto do Emergency Patch Release 2 antes da execução.

Baixe o pacote correspondente ao produto, ao ramo 24, 25 ou 26 e ao sistema operacional. O boletim de segurança da PaperCut publica os instaladores e hashes SHA-256, determina que o Release 2 substitua o patch inicial e exige versões corrigidas nos Site Servers e servidores secundários ou de impressão. O mesmo boletim registra relatos de falhas pós-patch em SAML e consultas Card/ID, informa que ainda não se trata de uma versão oficial e recomenda reconstruir o Application Server quando houver suspeita de invasão.

Calcule o SHA-256 localmente e compare todos os caracteres com o valor referente ao produto, ramo e plataforma escolhidos. Se houver divergência, não execute o arquivo: refaça o download por um canal autorizado e investigue a origem da cópia anterior. Guarde o nome do instalador e o hash calculado na evidência da mudança.

Não existe pacote emergencial publicado para a versão 23 ou anteriores. Nesses ambientes, o caminho recomendado é migrar para a versão mais recente, o que exige verificar licença, requisitos do sistema, compatibilidade dos dispositivos e mudanças entre versões antes da janela.

3. Atualizar todos os servidores necessários

Use uma janela com interrupção prevista. O procedimento oficial de atualização orienta parar os serviços, renovar os backups, instalar no mesmo diretório e aguardar a conclusão de uma eventual atualização do banco; também exige que os Site Servers recebam a mesma versão do Application Server.

  1. Atualize o Application Server primário com o pacote correto do Release 2.
  2. Aguarde o término de qualquer atualização do banco e confirme a inicialização dos serviços.
  3. Atualize todos os Site Servers para a mesma versão do Application Server. Enquanto houver diferença, eles podem permanecer em modo offline e com funcionalidade reduzida.
  4. Atualize os servidores secundários ou de impressão para uma versão corrigida, conforme a orientação específica do boletim.
  5. Registre o resultado de cada nó antes de considerar a implantação concluída.

Print Deploy e Mobility Print não são afetados por essas vulnerabilidades e não recebem o patch emergencial. Ainda assim, os fluxos que dependem do Application Server devem entrar no teste funcional da mudança.

4. Validar SAML e Card/ID sem presumir que o patch funcionou

Teste pós-patch confirma autenticação SAML, identificação por cartão e liberação do trabalho correto no PaperCut NG/MF.

Um login administrativo não comprova que a autenticação dos usuários continua operacional. Abra uma sessão nova com uma conta comum, confirme o redirecionamento ao provedor SAML, conclua a autenticação e verifique se a identidade correta retorna ao PaperCut. Repita nos pontos de acesso relevantes sem reaproveitar uma sessão autenticada.

Depois, use um cartão de teste conhecido em um dispositivo representativo. Confirme a identificação do usuário, a exibição dos trabalhos esperados e a liberação efetiva de uma impressão; uma tela administrativa acessível, sozinha, não valida esse fluxo.

Quando o ambiente consulta números Card/ID em banco externo, adicione security.card-number-lookup.enabled=Y a server/security.properties e reinicie o Application Server. Sem essa chave, a consulta externa fica desativada e pode ser ignorada mesmo que a interface administrativa ainda mostre a função configurada.

Se a consulta usa SQL Server com o driver legado jTDS, migre primeiro para o driver Microsoft SQL JDBC suportado. Essa troca pode não resolver todos os casos; se SAML ou Card/ID continuar falhando, mantenha as interfaces restritas e acione o revendedor ou o suporte da PaperCut, em vez de reabrir o serviço ou retornar ao primeiro patch.

  • Teste login SAML, logout e nova autenticação.
  • Teste cartão válido, cartão inválido e uma liberação real.
  • Confirme filas, contabilização e histórico dos trabalhos.
  • Verifique a comunicação dos Site Servers e servidores secundários.
  • Correlacione horário, usuário e dispositivo com os registros gerados durante os testes.

5. Distinguir falha funcional de comprometimento

Revise alertas de EDR, IDS e monitoramento de rede relacionados ao Application Server, especialmente atividade suspeita originada por pc-app.exe. Procure também arquivos server.log ausentes, apagados ou truncados e as mensagens “No suitable driver found for jdbc:no:x” e “Database error looking up cardID: VALUES CAST”. A ausência desses sinais não prova que o servidor esteja limpo.

Havendo suspeita razoável de invasão, não trate uma instalação sobre o sistema existente como remediação suficiente. Preserve backups e evidências, ative o processo de resposta a incidentes, apague e reconstrua completamente o Application Server e restaure somente uma cópia limpa criada antes do primeiro comportamento suspeito.

Se o problema for exclusivamente funcional e não houver indícios de intrusão, mantenha a contenção enquanto compara configurações, drivers e registros anteriores. O retorno ao patch inicial não é uma saída segura, porque o Release 2 acrescenta proteções que o substituem.

6. Reabrir apenas após fechar o checklist

Libere somente os acessos necessários depois que todos os servidores previstos estiverem corrigidos e os testes de SAML, Card/ID, impressão e contabilização tiverem sido aprovados. Documente os IPs autorizados; a conclusão do patch não exige restaurar a exposição pública anterior.

Feche a mudança com a lista de hosts, versões finais, hashes verificados, horários dos testes, resultados por integração e exceções abertas. Como o Release 2 é emergencial e uma versão oficial ainda estava em desenvolvimento na última atualização do boletim, acompanhe a página da PaperCut para planejar a substituição posterior sem adiar a correção atual.

Leia também:

Compartilhar:

Assine nossa newsletter

Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.

0