As incontáveis ​​configurações incorretas do SendBird

Nov 29 2022
Em uma colaboração aleatória de caça a bugs com minha equipe (thaivu, lamscun, thefool45, fergustr4n), encontramos um alvo privado aleatório, como sempre. Durante a exploração do alvo, descobri que nosso alvo implementou um recurso de bate-papo usando um serviço de uma plataforma de terceiros.

Em uma colaboração aleatória de caça a bugs com minha equipe ( thaivu , lamscun , thefool45 , fergustr4n ), encontramos um alvo privado aleatório como de costume. Durante a exploração do alvo, descobri que nosso alvo implementou um recurso de bate-papo usando um serviço de uma plataforma de terceiros. Depois de pesquisar no Google, descobri que o recurso de bate-papo do nosso alvo é um produto do SendBird— “a principal plataforma de API de interação confiável por aplicativos digitais modernos como Paypal, Yahoo, Reddit, Delivery Hero e Hinge para incorporar facilmente bate-papo, voz e vídeo em tempo real em seus aplicativos”. Isso despertou meu interesse e decidi pesquisar mais sobre como funciona para ver se haveria alguma ação oculta que eu pudesse fazer ou configurações ocultas que os desenvolvedores pudessem perder…

1º — Conheça os produtos e documentos de terceiros

Fui direto ao site principal do SendBird para saber o que enfrentaria. O SendBird Developer Portal fornece aos desenvolvedores documentos muito claros e úteis para cada tipo de produto (guias de uso, amostras de APIs, notas, recomendações,…).

Existem algumas notas interessantes na época em que comecei minha pesquisa ( algumas podem estar desatualizadas quando você lê este blog ):

  • O host do aplicativo SendBird do cliente estaria na forma de “https://api-{application_id}.sendbird.com”
  • O Sendbird fornece várias opções de controle de acesso e algumas são ativadas por padrão para evitar erros inesperados ao criar aplicativos de amostra.
  • Os clientes não podem alterar a configuração da Lista de controle de acesso sozinhos. A alteração da configuração de ACL só é possível por um membro da equipe de engenharia de soluções do Sendbird .
  • Por padrão, as configurações de segurança do aplicativo SendBird para “ usuários sem tokens de acesso ” são “Read & Write” — chat e “Call & Answer” — chamada.

Depois de ter uma visão geral sobre como o SendBird funciona, voltei aos meus alvos para usar, brincar com as funções para verificar com o que li acima. Confirmei que havia APIs com o host com o mesmo padrão de “api-{application_id}.sendbird.com” e com caminhos iguais aos que vi nos documentos. Em seguida, usei rapidamente a sessão de API atual para experimentar diferentes APIs nos documentos da API. Aleatoriamente, escolhi uma API que lista os usuários no aplicativo SendBird “GET /v3/users/” e, surpreendentemente, o servidor respondeu com todos os usuários listados !!! Pulando de alegria, disse a todos os meus companheiros para verificarem.

Tentamos e sabíamos que a sessão de nossos usuários poderia chamar várias APIs e realizar muitas ações em usuários, canais, mensagens, … dentro do aplicativo SendBird de nossos destinos. Foi definitivamente um grande controle de acesso quebrado por causa da configuração incorreta das ACLs !!!

No entanto, havia uma coisa que não conseguíamos entender: de onde veio a “Session-Key” e como ela foi gerada, já que não conseguimos ver o valor da “Session-Key” em nenhuma resposta?

De volta aos Documentos SendBird para ler mais e fazer mais, sabíamos mais algumas coisas:

  • “Por padrão, o servidor Sendbird pode autenticar um usuário apenas por um ID de usuário exclusivo”
  • “Se nenhum ID de usuário correspondente for encontrado, o servidor cria uma nova conta de usuário com o ID de usuário”
  • “Uma autenticação de usuário pode ser feita apenas com seu próprio ID de usuário, mas também com um token de acesso ou um token de sessão”
  • Nosso alvo como ClientApp poderia ter autenticado no SendBird Server via WebSocket com o formato Upgrade WebSocket URL como: “ wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token }”
  • O cliente SendBird do nosso alvo autenticado no servidor SendBird via WebSocket.
  • A “Session-Key” seria enviada ao cliente via WebSocket Message após a chamada do cliente Atualizar WebSocket URL como acima
  • O cliente SendBird do nosso alvo pode autenticar apenas pelo ID do usuário com o “ access_token=null”
  • Também encontramos uma API oculta para autenticar via USER ID apenas como WebSocket no arquivo JS: “ POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — body: {“ app_id”:”<application_id>”}

3º — Como realizar verificação massiva de vulnerabilidades em outras Instâncias SendBird em alvos diferentes

  1. Temos que confirmar que nossos destinos implementando SendBird em seus aplicativos rastreando, realizando descoberta de conteúdo nos destinos e grep para a palavra “sendbird” e o regex do ID do aplicativo SendBird “ [0–9A-F]{8}-[0– 9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12}
  2. Depois de confirmar os destinos implementando o SendBird e obter o ID do aplicativo SendBird, verificamos se as configurações de segurança do aplicativo SendBird para “usuários sem tokens de acesso” estão configuradas incorretamente ou não , realizando login/criação de usuário anônimo usando as seguintes maneiras:
  3. wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token}
  4. POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — corpo: {“app_id”:”<application_id>”}
  5. 4. Se a etapa número 2 não for bem-sucedida, passaremos manualmente pelas funções no destino, obteremos a sessão do usuário do SDK da maneira normal que o destino faz e verificaremos a configuração incorreta das ACLs como na etapa 3.

    5. Automação de todos eles!

    Referências para APIs SendBird para verificar:

    • https://www.postman.com/sendbird/workspace/sendbird-platform-api/overview
    • https://sendbird.com/docs

    Depois de verificar as vulnerabilidades em diferentes aplicativos SendBird, a maioria deles está vulnerável à configuração incorreta das ACLs. No entanto, com base em diferentes aplicativos com diferentes requisitos e impactos de negócios, a gravidade também deve ser considerada diferente (de Médio a Crítico).

    Os impactos são variados:

    • Vazamento de informações confidenciais dos usuários
    • Crie um canal de chat (sem criar uma nova liga)
    • Gerenciar o canal de bate-papo
    • Atualize o perfil de bate-papo do usuário
    • Atualize a configuração do canal do grupo
    • Bate-papo com qualquer usuário
    • Um invasor pode editar/excluir mensagens de qualquer usuário enquanto estiver na função de operador do canal criado por ele mesmo.
    • Um invasor pode atualizar os detalhes e as configurações do canal enquanto é membro de qualquer canal.
    • Conforme documentado, um único usuário SendBird só pode ingressar em um limite de 2.000 canais de grupo, o invasor pode criar 2.000 canais de grupo e adicionar todos os usuários no aplicativo SendBird a esses canais. Como resultado, todos os usuários não puderam ingressar em nenhum canal SendBird depois disso, o que poderia causar negação de serviço.

    Grandes colaborações com thaivu , lamscun , thefool45, fergustr4n $$$$

    ### Atualizações do SendBird

    • SendBird tem mais documentos sobre recomendações de segurança, especialmente sobre as ACLs.
    • O SendBird agora permite que seus clientes alterem os ACLs por conta própria.

    OBRIGADO POR LER! FELIZ HACKING, APRENDIZAGEM, CAÇA E MANTENHA OS PÁSSAROS SEGUROS!