Les erreurs de configuration inconnues de SendBird

Lors d'une collaboration aléatoire de chasse aux bugs avec mon équipe ( thaivu , lamscun , thefool45 , fergustr4n ), nous étions tombés sur une cible privée aléatoire comme d'habitude. En exploitant la cible, j'ai découvert que notre cible avait implémenté une fonctionnalité de discussion en utilisant un service d'une plate-forme tierce. Après avoir fait quelques google dork, j'ai découvert que la fonctionnalité de chat de notre cible est un produit de SendBird— "la principale plate-forme d'API d'interaction à laquelle font confiance les applications numériques modernes telles que Paypal, Yahoo, Reddit, Delivery Hero et Hinge pour intégrer facilement le chat, la voix et la vidéo en temps réel dans leurs applications". Cela a attiré mon intérêt et j'ai décidé de faire des recherches supplémentaires sur son fonctionnement pour voir s'il y aurait des actions cachées que je pourrais faire ou des configurations cachées que les développeurs pourraient manquer…

1er - Découvrez les produits et documents du tiers

Je suis allé directement sur le site principal de SendBird pour savoir à quoi je serais confronté. Le Portail Développeur SendBird fournit aux développeurs des documents très clairs et utiles pour chaque type de produits (guides d'utilisation, exemples d'API, Notes, Recommandations,…).

Il y a quelques notes intéressantes au moment où j'ai commencé mes recherches ( Certaines pourraient être obsolètes lorsque vous lirez ce blog ):

• L'hébergeur de l'Application SendBird du Client se présente sous la forme "https://api-{application_id}.sendbird.com"
• Sendbird fournit diverses options de contrôle d'accès et certaines sont activées par défaut pour éviter les erreurs inattendues lors de la création d'exemples d'applications.
• Les clients ne peuvent pas modifier eux-mêmes les paramètres de la liste de contrôle d'accès. La modification du paramètre ACL n'est possible que par un membre de l'équipe d'ingénierie des solutions de Sendbird .
• Par défaut, les paramètres de sécurité de l'application SendBird pour les « utilisateurs sans jeton d'accès » sont « Lecture et écriture » ​​- chat et « Appel et réponse » - appel.

Après avoir eu un aperçu du fonctionnement de SendBird, je suis revenu sur mes objectifs à utiliser, j'ai joué avec les fonctions pour vérifier avec ce que j'avais lu ci-dessus. J'ai confirmé qu'il y avait des API avec l'hôte avec le même modèle que "api-{application_id}.sendbird.com" et avec des chemins identiques à ceux que j'avais vus dans les documents. Ensuite, j'ai rapidement utilisé la session API en cours pour essayer différentes API dans les documents API. Au hasard, j'ai choisi une API qui répertorie les utilisateurs dans l'application SendBird "GET /v3/users/" et étonnamment, le serveur a répondu avec tous les utilisateurs répertoriés !!! En sautant de joie, j'ai dit à tous mes coéquipiers de vérifier.

Nous avons essayé et savions que la session de nos utilisateurs pouvait appeler diverses API et effectué de nombreuses actions sur les utilisateurs, les canaux, les messages, … au sein de l'application SendBird de nos cibles. C'était définitivement un gros contrôle d'accès cassé à cause d'une mauvaise configuration des ACL !!!

Cependant, il y avait une chose que nous ne pouvions pas comprendre : d'où venait la "Session-Key" et comment était-elle générée puisque nous ne pouvions pas voir la valeur "Session-Key" dans les réponses ?

De retour à SendBird Documents pour en savoir plus et en faire plus, nous savions encore plus de choses :

• "Par défaut, le serveur Sendbird peut authentifier un utilisateur uniquement par un identifiant utilisateur unique"
• "Si aucun ID utilisateur correspondant n'est trouvé, le serveur crée un nouveau compte utilisateur avec l'ID utilisateur"
• "Une authentification d'utilisateur peut être effectuée uniquement avec son propre ID utilisateur, mais également avec un jeton d'accès ou un jeton de session"
• Notre cible en tant que ClientApp aurait pu s'authentifier auprès de SendBird Server via WebSocket avec le format d'URL de mise à niveau WebSocket comme : " wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token } »

• Le client SendBird de notre cible s'est authentifié auprès du serveur SendBird via WebSocket.
• La "Clé de session" sera envoyée au client via un message WebSocket après l'appel du client Mettre à niveau l'URL WebSocket comme ci-dessus
• Le client SendBird de notre cible pourrait s'authentifier uniquement par ID utilisateur avec le " access_token=null"
• Nous avons également trouvé une API cachée pour s'authentifier via USER ID uniquement en tant que méthode WebSocket dans le fichier JS : " POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — body : {" app_id”:”<application_id>”} ”

3e - Comment effectuer une vérification massive des vulnérabilités sur d'autres instances SendBird dans différentes cibles

1. Nous devons confirmer que nos cibles implémentent SendBird dans leurs applications en explorant, en effectuant une découverte de contenu sur les cibles et en grep pour le mot "sendbird" et la regex de l'ID d'application de SendBird " [0–9A-F]{8}-[0– 9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12} »
2. Après avoir confirmé les cibles implémentant SendBird et obtenu l'ID de l'application SendBird, nous vérifions si les paramètres de sécurité de l'application SendBird pour les « utilisateurs sans jeton d'accès » sont mal configurés ou non en effectuant une connexion/création d'utilisateur anonyme de la manière suivante :
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 — corps : {"app_id":"<application_id>"}

4. Si l'étape numéro 2 n'a pas réussi, nous allons parcourir manuellement les fonctions sur la cible, obtenir la session utilisateur SDK de la manière normale que la cible fait et vérifier la mauvaise configuration des ACL à l'étape 3.

5. Automatisez-les tous !

Références pour les API SendBird à vérifier :

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


Après avoir vérifié les vulnérabilités sur différentes applications SendBird, la plupart d'entre elles sont vulnérables à la mauvaise configuration des ACL. Cependant, sur la base de différentes applications avec des exigences et des impacts commerciaux différents, la gravité doit également être considérée comme différente (de moyenne à critique).

Les impacts sont variés :

• Fuir les informations sensibles des utilisateurs
• Créer un canal de discussion (sans créer de nouvelle ligue)
• Gérer le canal de chat
• Mettre à jour le profil de chat de l'utilisateur
• Mettre à jour la configuration du canal de groupe
• Discuter avec n'importe quel utilisateur
• Un attaquant pourrait modifier/supprimer les messages de n'importe quel utilisateur tout en jouant le rôle d'opérateur du canal qu'il a lui-même créé.
• Un attaquant pourrait mettre à jour les détails, les configurations du canal tout en étant membre de n'importe quel canal.
• Comme documenté, un seul utilisateur SendBird ne pouvait rejoindre qu'une limite de 2000 canaux de groupe, l'attaquant pouvait créer 2000 canaux de groupe et ajouter tous les utilisateurs de l'application SendBird à ces canaux. En conséquence, tous les utilisateurs ne pouvaient plus rejoindre aucun canal SendBird après cela, ce qui pouvait entraîner un déni de service.
• …






Excellentes collaborations avec thaivu , lamscun , thefool45, fergustr4n $$$$



### Mises à jour de SendBird

• SendBird a plus de documents sur les recommandations de sécurité, en particulier sur les ACL.
• SendBird permet désormais à ses clients de modifier eux-mêmes les ACL.

MERCI D'AVOIR LU! BONNE HACKING, APPRENTISSAGE, CHASSE ET GARDE DES OISEAUX EN SÉCURITÉ !