ServiceNow corrige falha que permitia acesso não autenticado a tabelas de instâncias

A ServiceNow aplicou em 5 de junho um patch silencioso em todas as instâncias hospedadas após identificar uma vulnerabilidade que permitia a usuários não autenticados, em determinadas circunstâncias, obter acesso maior do que o pretendido às instâncias da plataforma. A empresa detectou tentativas de exploração e, em comunicado posterior, atribuiu a atividade observada a pesquisadores participantes de programa de bug bounty. Há, contudo, indícios de que a falha foi reportada à companhia já em 7 de abril e demorou cerca de dois meses para ser tratada.

O que aconteceu

A plataforma da ServiceNow é amplamente usada por organizações para automatizar e gerenciar fluxos de IT Service Management (ITSM), RH, atendimento ao cliente e outras operações corporativas críticas. Falhas em sistemas como esse têm potencial de pivot lateral significativo, já que costumam armazenar tickets, dados de funcionários, integrações com Active Directory e workflows com privilégios elevados.

A empresa não tornou pública nenhuma informação sobre o incidente, mas um aviso disponível apenas a clientes autenticados — uma cópia do qual circulou no Reddit — indica que as instâncias hospedadas receberam o patch em 5 de junho. Inicialmente, a ServiceNow não havia revelado se atribuiria um CVE ao caso. Após contato da imprensa especializada, publicou um aviso público clarificando que considera a atividade observada como pertencente a pesquisadores de segurança e que nenhum dado teria sido retido.

Detalhes da vulnerabilidade

Segundo o aviso interno citado pela SecurityWeek, a falha “poderia permitir que um usuário não autenticado, em certas circunstâncias, obtivesse acesso maior às instâncias do ServiceNow do que o pretendido”. A correção mudou a configuração de um endpoint para limitar o acesso apenas a usuários autenticados — sinalizando que a raiz do problema estava em controle de autenticação ausente ou mal configurado em uma rota específica.

“Detectamos atividade anômala relacionada à questão de segurança. Para um subconjunto de clientes, observamos evidências de consultas bem-sucedidas em tabelas de instâncias. Notificamos os clientes quando consultas bem-sucedidas foram observadas, via caso.” — ServiceNow, aviso a clientes autenticados

A empresa esclareceu que os usuários afetados estão concentrados na release “Australia platform” ou em clientes que fizeram mudanças específicas de configuração que estendem endpoints públicos. Um relato no Reddit afirma que a equipe de segurança da empresa do autor reportou a vulnerabilidade na semana anterior à divulgação, e que a ServiceNow teria conhecimento do problema desde 7 de abril, mas não a considerou um risco — afirmação que, se verdadeira, levanta questões importantes sobre triagem de vulnerabilidades.

Quem é afetado

• Clientes do ServiceNow na release “Australia platform” — escopo geográfico/regional específico
• Clientes que aplicaram mudanças específicas de configuração que estendem endpoints públicos
• Empresas notificadas individualmente pela ServiceNow via “case” — sinal de que houve consultas bem-sucedidas nas suas tabelas
• Em tese, qualquer organização que tivesse dados sensíveis em tabelas acessíveis pelo endpoint afetado durante a janela de exploração (abril a junho)

Não há, até o momento, indicação de que dados tenham vazado para terceiros maliciosos. A ServiceNow afirma que a atividade observada foi atribuída a pesquisadores de bug bounty que confirmaram não ter retido qualquer informação.

Análise

O caso ServiceNow ilustra uma dinâmica recorrente em vulnerabilidades de plataformas SaaS multi-tenant: a divulgação fica restrita a clientes autenticados, sem CVE imediato, e o público externo só sabe do problema porque alguém vaza o aviso no Reddit. Isso cria um problema de visibilidade para times de segurança que dependem de feeds CVE para priorização, e levanta a questão se a comunidade deveria pressionar provedores SaaS por divulgação pública mesmo quando o patch é aplicado server-side sem ação do cliente.

Outro ponto sensível é o intervalo entre o reporte inicial (suposta data de 7 de abril) e a remediação efetiva (5 de junho) — quase dois meses. Mesmo que a atividade detectada tenha sido apenas de pesquisadores de bug bounty, a janela em que a falha esteve explorável foi longa o suficiente para que um atacante real, com motivação e oportunidade, pudesse tê-la encontrado independentemente. A defesa “atividade vista era de pesquisadores” funciona apenas se você puder provar que não houve outros acessos não registrados — o que exige logging exaustivo. A história também acende um alerta para empresas brasileiras que dependem do ServiceNow para ITSM e gestão de incidentes: vulnerabilidades em ferramentas de gerenciamento de segurança são particularmente perigosas, porque comprometem o próprio sistema usado para detectar e responder a outros incidentes.

Recomendações práticas

• Verifique no portal Now Support se sua organização recebeu notificação de “case” relacionada a consultas bem-sucedidas no período — investigação interna obrigatória se sim
• Audite logs da instância ServiceNow entre 7 de abril e 5 de junho buscando padrões anômalos de acesso a endpoints REST e tabelas (sys_user, incident, kb_knowledge)
• Revise endpoints customizados expostos publicamente — qualquer ACL recente ou mudança de configuração que estenda acesso não autenticado deve passar por revisão extra
• Para clientes na release Australia platform, confirme que a versão atual da instância recebeu o patch e documente a janela de exposição
• Considere implementar WAF entre o tráfego corporativo e a ServiceNow para registro independente de chamadas REST
• Como prática contínua: pressione fornecedores SaaS por divulgação CVE mesmo em patches server-side — isso melhora postura defensiva de toda a indústria
• Revise contratos de SLA para garantir notificação proativa de incidentes que afetem subsets de clientes, não só clientes diretamente impactados

Fonte: SecurityWeek