Falha no Salesforce pode expor dados sensíveis

Sumário executivo

Uma comunidade do Salesforce configurada incorretamente pode fazer com que dados confidenciais na plataforma sejam expostos a qualquer pessoa na Internet. Os usuários anônimos podem consultar objetos que contêm informações confidenciais, como listas de clientes, casos de suporte e endereços de e-mail de funcionários.
Nossa equipe de pesquisa descobriu várias comunidades do Salesforce acessíveis ao público que estão configuradas incorretamente e expõem informações confidenciais.

Esta não é a primeira nem a última vez que uma configuração SaaS criará um incidente de segurança potencial, enfatizando a necessidade das equipes de segurança avaliarem continuamente sua exposição ao SaaS.
Este guia explica como um invasor pode explorar a configuração incorreta e fornece aos administradores do Salesforce etapas detalhadas para:

1. Ajudar você a se certificar de que as permissões do seu perfil de convidado não exponham coisas que você não deseja que sejam expostas (registros de contas, calendários de funcionários, etc.)
2. Desativar o acesso à API para perfis de convidado
3. Definir o proprietário padrão para registros criados por usuários convidados
4. Habilitar o acesso seguro de usuário convidado

Impacto

No mínimo, um agente mal-intencionado pode explorar essa configuração incorreta para realizar o reconhecimento de uma campanha de phishing. Na pior das hipóteses, hackers podem roubar informações confidenciais sobre o negócio, suas operações, clientes e parceiros.

Em alguns casos, um invasor sofisticado pode ser capaz de se mover lateralmente e recuperar informações de outros serviços integrados à conta do Salesforce.

O que são as comunidades do Salesforce?

Um site da Comunidade Salesforce permite que seus clientes e parceiros interajam com sua instância do Salesforce de fora de sua organização – eles podem abrir tíquetes de suporte, fazer perguntas, gerenciar suas assinaturas, entre outras funcionalidades.

As comunidades são voltadas ao público e, por padrão, indexadas pelo Google. Embora seja útil para clientes e parceiros, torna mais fácil para invasores que descobrem uma vulnerabilidade ou configuração incorreta procurar e abusar de comunidades em grande escala.

Como você verá, o Salesforce é altamente personalizável e pode ser difícil de administrar. Não há duas instâncias do Salesforce iguais, considerando-se as centenas de aplicativos de terceiros que podem ser integrados, objetos personalizados e configurações.

Informações técnicas

As comunidades do Salesforce são executadas na estrutura Lightning do Salesforce. Lightning é uma estrutura de desenvolvimento rápido para sites móveis e de desktop.

Salesforce Lightning é uma estrutura orientada a componentes. Esses componentes, chamados de componentes do Aura, são objetos autocontidos que um desenvolvedor pode montar para criar páginas da web personalizadas.

Os componentes do aura podem ser usados para realizar ações em objetos do Salesforce – como visualizar ou atualizar registros. Esses componentes possuem controladores que exportam diferentes métodos para realizar certas tarefas.

Navegar em um site da comunidade com um serviço de proxy, como o pacote Burp, nos mostra o Lightning em ação. A interface de usuário da web front-end de uma comunidade usa endpoint HTTP /s/sfsites/aura.

O navegador usa o endpoint aura para recuperar informações sobre o site e executar ações do lado do servidor à medida que o usuário interage com o site da comunidade. Naturalmente, as permissões do usuário se aplicam a essas ações.

O chamado do aura no endpoint acontece por meio de uma requisição HTTP simples, que pode ser GET ou POST, e que consiste nos seguintes parâmetros:

• pageURI – o caminho para o site, sem o host. Por exemplo: “/s”.
• token – o token atual do usuário. O valor “undefined” indica um usuário convidado.
• context – o contexto da sessão atual, fornecido pelo site.
• message – descreve a ação desejada. É possível executar vários métodos na chamada de sarne aura. Esta estrutura contém uma lista de ações, que contém o descritor do método (um identificador único do método) e os parâmetros de chamada.

A estrutura da mensagem é uma URL codificada com JSON. Aqui está um exemplo:

• id– uma string randômica que pode ser usada quando mais de uma ação é enviada dentro da mesma requisição. Dessa maneira, o browser vai caputar ações e respostas/
• descriptor – o método específico para realizar a requisição.
• callingDescriptor – geralmente “UNKNOWN” – já que esse parâmetro é frequentemente ignorado
• params – usado para fornecer parâmetros ao método.

Existem muitos métodos diferentes que um usuário não autenticado pode executar para realizar ações, como:

• Obter informações sobre o site
• Obter informações sobre a assinatura do Salesforce
• Ver objetos padrão e personalizados e seus campos
• Recuperar dados e registros

Alguns dos objetos que você pode consultar são Conta, Usuário, Caso, Funcionário, Anexo, Contato e Cliente potencial.

Como os invasores podem explorar uma configuração incorreta nas comunidades?

Em sites mal configurados, o invasor pode realizar o reconhecimento procurando informações sobre a organização, como usuários, objetos e campos que expõem nomes e endereços de e-mail e, em muitos casos, podem se infiltrar no sistema ou roubar informações.

Primeiro, o invasor deve encontrar um site da comunidade para explorar. Alguma mágica do Google resolverá o problema. Existem “impressões digitais” de URL comuns que indicam que um site é desenvolvido por Comunidades do Salesforce:

• /s/topic
• /s/article
• /s/contactsupport

Usar operadores como “inurl:” junto ao nome do destino, por exemplo, leva frequentemente ao site da comunidade desejado:

A próxima etapa é recuperar informações sobre o site. O invasor pode fazer isso chamando o seguinte método:

Este método retorna o domínio da organização, algumas configurações de segurança (por exemplo, domínios permitidos de política de segurança de conteúdo -CSP) e objetos disponíveis.

O invasor pode chamar diferentes métodos para realizar diferentes ações, como:

• Listagem de objetos Salesforce
• Registros de listagem
• Busca de registros
• Recuperando um objeto
• Buscando informações sobre a instância do Salesforce

Buscando dados confidenciais

Os invasores podem tentar acessar dados confidenciais diretamente. Nossa equipe de segurança encontrou muitos registros sensíveis expostos em nossa pesquisa. O invasor pode atingir objetos específicos e examiná-los chamando o método:

Isso vai retornar as informações sobre um objeto. Este método oferece suporte a todos os tipos de objetos, incluindo os personalizados. As informações incluem os diferentes campos, como eles são configurados e os relacionamentos filhos do objeto. A próxima etapa seria listar os registros usando o método:

Aqui está um exemplo de listagem de contas usando esse método:

O criminoso pode obter ainda mais dados, usando outros métodos, tais como:

Para buscar registros interessantes com mais campos e objetos relacionados.

Procurando por componentes vulneráveis de terceiros

Um adversário avançado pode tentar atacar componentes de terceiros e custam vulneráveis. Em alguns casos, é possível assumir o controle de toda a instância do Salesforce apenas explorando uma classe de Apex customizada vulnerável que é exposta a usuários convidados.

Ao navegar no site, podemos ver que o navegador carrega vários arquivos JavaScript diferentes com URLs estranhos, que começam com / 1 / e, em seguida, um objeto JSON codificado.

Nesses arquivos JavaScript, podemos encontrar as definições para os terminais mais acessíveis, incluindo aqueles custam e / ou aplicativos de terceiros. As definições são codificadas em JSON:

Ao escanear a resposta para sequências JSON formadas de forma semelhante, pode-se aprender sobre os métodos personalizados e como chamá-los.

O que você pode fazer a respeito?

Gerenciar um site de comunidade é uma tarefa difícil. É importante certificar-se de que os usuários convidados anônimos e os usuários da comunidade só possam acessar os registros pretendidos e necessários. Há informações que você pode querer compartilhar com o mundo e outras que não deseja.

Para proteger seu ambiente do Salesforce, é muito importante seguir o princípio do menor privilégio e garantir que os perfis de convidado permitam apenas as permissões mínimas necessárias.

Etapa 1 – Audite as permissões do seu perfil de convidado

Navegue até o seu Site Builder (pesquise “AII Sites” na configuração) e clique em Configurações ou no ícone de engrenagem à esquerda.

Você encontrará seu perfil de usuário convidado em Geral. Clique nele para modificar as permissões do usuário convidado.

Aqui você pode controlar a segurança e o acesso em um nível muito granular. É aqui que você precisará tomar decisões sobre o acesso que são específicas às suas necessidades de negócios.

Etapa 2- Desabilite o acesso de APIs

Certifique-se que o acesso a APIs esteja desativado, bem como o acesso às atividades:

Etapa 3 – Configure o proprietário dos registros criados por usuários convidados

Vá diretamente para os espaços de trabalho do seu site ou use o construtor de sites para navegar até o espaço de trabalho de Administração:

Em preferências, certifique-se de configurar um proprietário padrão para registros criados por usuários convidados e, na maioria dos casos, você deseja desativar Permitir que usuários convidados vejam os membros deste site.

Etapa 4 – Habilite o acesso seguro ao registro do usuário convidado

Verifique se a configuração de acesso padrão para usuários convidados é segura: vá para a configuração e pesquise por Configurações de compartilhamento. Procure a opção Proteger o acesso ao registro do usuário convidado e verifique se ela está marcada.

O Salesforce está tentando ajudá-lo a tomar decisões inteligentes sobre o acesso de convidados. A partir do lançamento do Summer ’20, o Salesforce tornou impossível desativar essa configuração. Eles também o impediram de conceder aos usuários convidados as permissões Exibir todos os usuários e você não pode conceder a eles acesso para exibir todos os dados.

Ainda é de extrema importância, no entanto, revisar as definições de configuração. O Salesforce não pode desabilitá-los todos porque usuários diferentes têm requisitos diferentes.

Conclusões

Como você pode ver, com aplicativos SaaS tão complexos e personalizáveis quanto o Salesforce, há incontáveis definições de configuração e permissões com que se preocupar. A maioria das organizações implementa dezenas de aplicativos SaaS sancionados, cada um com seus próprios objetos, modelos de permissões, APls e recursos de compartilhamento.

É por isso que criamos o DatAdvantage Cloud – para fornecer uma maneira unificada de encontrar exposições, privilégios do tamanho certo e realizar investigações em todos os seus aplicativos SaaS sancionados.

Para saber mais detalhes sobre a falha, clique aqui. Para conhecer o DatAdvantage Cloud, consulte as informações sobre a solução aqui.