.
A ServiceNow está lançando uma correção para uma falha que expõe dados depois que um pesquisador publicou um método para invasores não autenticados roubarem arquivos confidenciais de uma organização.
O pesquisador de segurança Aaron Costello destacou problemas aparentes com as configurações padrão dos widgets do ServiceNow, permitindo a exposição de dados pessoais.
Os widgets do ServiceNow atuam como APIs poderosas para o Portal de Serviços da plataforma. Apesar de uma mudança de código no início deste ano para melhorar a segurança, a configuração padrão desses widgets era tornar seus registros públicos, o que significa que, se permanecerem inalterados, eles retornarão o tipo de dados especificado por um invasor.
Antes de emitir discretamente uma correção em 20 de outubro, a ServiceNow disse Strong The One que estava ciente da pesquisa que descrevia “um possível problema de configuração incorreta”. No entanto, não disse que faria quaisquer alterações, acrescentando que trabalha regularmente com os clientes para garantir que as configurações de segurança sejam implementadas adequadamente para cada organização específica.
“Trabalhamos proativamente com os clientes na segurança contínua de suas configurações de segurança, incluindo Listas de Controle de Acesso (ACLs), para garantir que estejam adequadamente estruturadas e alinhadas à finalidade pretendida”, disse um porta-voz.
“Tornamos esses protocolos extensíveis para que nossos clientes possam configurá-los com base em suas necessidades exclusivas de segurança – desde empresas com portais públicos que fornecem amplo acesso a informações até casos de uso específicos de empresas onde o acesso é restrito a usuários selecionados”.
Como os dados são expostos
O problema gira em torno dos widgets do ServiceNow que são amplamente usados em toda a plataforma.
Tantos Registro os leitores sabem, os widgets são como APIs que podem receber parâmetros de entrada de um usuário – um nome de tabela e um nome de campo. Uma tabela é como um tipo de dado armazenado, como dados do usuário, e o nome do campo refere-se a um campo dessa tabela, como nomes. Ao passar nomes específicos de tabelas e campos em uma chamada para um widget, um usuário não autenticado pode recuperar os dados que deseja.
As listas de controle de acesso (ACLs) regem o acesso a recursos no ServiceNow, como tabelas, mas não os próprios widgets. Eles têm uma verificação de três partes para funções, condições e scripts. Se não existir uma ACL para um determinado recurso, a implementação padrão será negar acesso, mas se um recurso tiver uma ACL com cada uma das três verificações deixadas “vazias”, as tentativas de acesso serão resolvidas como verdadeiras.
Em sua pesquisa, Costello sugeriu que muitas das ACLs em uso no ServiceNow estão em branco – as três verificações são deixadas em branco e, portanto, o acesso é concedido a possíveis invasores.
O widget que Costello usou em seu pesquisar como exemplo está a Lista Simples, cuja função é retornar dados de registros quando nomes de tabelas e campos são fornecidos.
Suas descobertas revelaram que um invasor que quisesse lucrar com essas configurações incorretas poderia fazê-lo criando um script direcionado a uma instância do ServiceNow e iterando uma série de nomes de tabelas e campos conhecidos, chamando continuamente um widget para ver se algum dado foi retornado.
Informações de identificação pessoal (PII), como nomes completos e endereços de e-mail, estão entre os dados recuperados pelos pesquisadores por meio desse método. Documentos internos e detalhes do incidente também foram recuperados por outros.
Costello não detectou nenhuma tentativa de explorar essas configurações incorretas em tentativas de roubo de dados. No entanto, ele enfatizou que só começou a rastreá-los em 2021, e os erros de configuração estão em jogo desde 2015, quando o widget Lista Simples foi adicionado à plataforma, o que significa que seria muito difícil verificar o histórico de tentativas.
“É do meu conhecimento, e não um palpite, que existem vetores quase idênticos em outros aplicativos SaaS populares, não apenas no ServiceNow e Força de vendas”, disse Costello em seu artigo.
Em 3 de março de 2023, a ServiceNow fez o primeiro ajuste em seus recursos que verificou se a função pública foi aplicada explicitamente na ACL. Caso contrário, o acesso seria negado. Costello sugeriu que isso não foi suficientemente longe, pois havia outras maneiras de tornar um recurso público.
“Sabemos que é preciso satisfazer a função, a condição e as partes do script de uma ACL”, disse Costello. “Se ‘público’ não for definido como uma função na ACL, um usuário não autenticado ainda poderá passar a condição ou partes do script e, assim, receber acesso.
“Ainda mais provável é que a ACL esteja totalmente vazia de uma função, condição ou script definido; permitindo que um usuário não autenticado acesse o recurso.”
O pesquisador fez questão de destacar que a ServiceNow não possuía nenhuma documentação pública sobre o componente afetado.
Ele também sugeriu que, ao emitir uma correção inicial em março, a ServiceNow demonstrou que sabia do problema, mas fez pouco para entrar em contato com os clientes, alertando-os sobre uma possível exposição de dados.
“O fato de esse desastre de widget ser conhecido pelo fornecedor, como comprovado este ano por suas modificações, mas existir desde 2015 sem qualquer documentação pública, é terrível”, disse ele.
Existe um suporte ServiceNow público publicado recentemente página anunciando que a empresa estava investigando o problema, mas a comunicação com o cliente que se seguiu foi limitada a artigos da Base de Conhecimento (KB) exclusivos para clientes.
Depois que a pesquisa começou a atrair atenção na semana passada, a ServiceNow lançou discretamente uma segunda correção para o problema que definia todas as ACLs em branco para proibir o acesso público por padrão.
Foi anunciado em um artigo não público da base de conhecimento, visto por Strong The Oneque uma atualização foi aplicada a todas as ACLs em branco para adicionar um script garantindo que o acesso só fosse concedido se um usuário estivesse conectado.
Embora a empresa acredite que isso deve ajudar muito a mitigar qualquer tentativa de acesso não autorizado, ela recomendou definir a função, a condição e as verificações de script em todas as ACLs usadas no ServiceNow.
Ele também alertou que a atualização pode ter afetado instâncias de clientes que permitiram intencionalmente que usuários não autorizados acessassem determinados recursos. Nesses casos, os clientes devem remover o script que foi adicionado a cada ACL pela atualização e habilitar manualmente a função pública ou criar uma nova ACL para a tabela e o campo e definir sua função como “pública”.
Para qualquer tabela que exija acesso público, os clientes foram instados a considerar a redução do número de linhas às quais a ACL concede acesso público, o que pode ser feito adicionando um script, bem como aplicando a função pública apenas aos campos específicos que a exigem. .
Os widgets também devem ser revisados para sinalizadores “públicos” que não são necessários e, se o acesso externo não for necessário, o controle de acesso IP deve ser aplicado à instância do ServiceNow para permitir apenas endereços IP confiáveis. ®
.
