Las configuraciones erróneas no contadas de SendBird

En una colaboración aleatoria de búsqueda de errores con mi equipo ( thaivu , lamscun , thefool45 , fergustr4n ), nos habíamos topado con un objetivo privado aleatorio como de costumbre. Mientras explotaba el objetivo, descubrí que nuestro objetivo ha implementado una función de chat utilizando un servicio de una plataforma de terceros. Después de hacer un poco de Google Dork, descubrí que la función de chat de nuestro objetivo es un producto de SendBird— “la plataforma API de interacción líder en la que confían aplicaciones digitales modernas como Paypal, Yahoo, Reddit, Delivery Hero y Hinge para integrar fácilmente chat, voz y video en tiempo real en sus aplicaciones”. Me interesó y decidí investigar más sobre cómo funciona para ver si habría alguna acción oculta que pudiera hacer o configuraciones ocultas que los desarrolladores pudieran perder...

1º — Conozca los productos y documentos de terceros

Fui directamente al sitio principal de SendBird para saber a qué me enfrentaría. El Portal para desarrolladores de SendBird proporciona a los desarrolladores documentos muy claros y útiles para cada tipo de producto (guías de uso, API de muestra, notas, recomendaciones,…).

Hay algunas notas interesantes en el momento en que comencé mi investigación ( algunas pueden estar desactualizadas cuando lea este blog ):

• El host de la Aplicación SendBird del Cliente tendría la forma de “https://api-{application_id}.sendbird.com”
• Sendbird proporciona varias opciones de control de acceso y algunas están activadas de forma predeterminada para evitar errores inesperados al crear aplicaciones de muestra.
• Los clientes no pueden cambiar la configuración de la lista de control de acceso por sí mismos. Cambiar la configuración de ACL solo es posible por un miembro del equipo de ingeniería de soluciones de Sendbird .
• De manera predeterminada, la configuración de seguridad de la aplicación SendBird para " usuarios sin tokens de acceso " es "Lectura y escritura": chat y "Llamada y respuesta": llamada.

Después de tener una descripción general de cómo funciona SendBird, volví a mis objetivos para usar, jugar con las funciones para verificar lo que había leído anteriormente. Confirmé que había API con el host con el mismo patrón que "api-{application_id}.sendbird.com" y con rutas como las que había visto en los documentos. Luego, usé rápidamente la sesión de API actual para probar diferentes API en los documentos de API. Al azar, elegí una API que enumeraba a los usuarios en la aplicación SendBird "GET /v3/users/" y, sorprendentemente, ¡el servidor respondió con todos los usuarios enumerados! Saltando de alegría, les dije a todos mis compañeros que lo revisaran.

Probamos y sabíamos que la sesión de nuestros usuarios podía llamar a varias API y realizamos muchas acciones en usuarios, canales, mensajes, … dentro de la aplicación SendBird de nuestros objetivos. ¡Definitivamente fue un gran control de acceso roto debido a una mala configuración de ACL!

Sin embargo, hubo una cosa que no pudimos entender: ¿de dónde vino la "clave de sesión" y cómo se generó, ya que no pudimos ver el valor de la "clave de sesión" en ninguna respuesta?

Volvamos a Documentos de SendBird para leer más y hacer más, sabíamos algunas cosas más:

• “De forma predeterminada, el servidor de Sendbird puede autenticar a un usuario solo con una ID de usuario única”
• “Si no se encuentra una ID de usuario coincidente, el servidor crea una nueva cuenta de usuario con la ID de usuario”
• “La autenticación de un usuario se puede realizar solo con su propia ID de usuario, pero también con un token de acceso o un token de sesión”
• Nuestro objetivo como ClientApp podría haberse autenticado en SendBird Server a través de WebSocket con el formato de URL de actualización de WebSocket como: “ wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token }”

• El cliente SendBird de nuestro objetivo autenticado en el servidor SendBird a través de WebSocket.
• La "Clave de sesión" se enviará al cliente a través del mensaje WebSocket después de que el cliente llame Actualice la URL de WebSocket como se indicó anteriormente
• El cliente de SendBird de nuestro objetivo podría autenticarse solo con el ID de usuario con el " token_de_acceso=null"
• También encontramos una API oculta para autenticarse a través de la ID de USUARIO solo como WebSocket en el archivo JS: “ POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — cuerpo: {“ id_aplicación”:”<id_aplicación>”} ”

Tercero: cómo realizar una verificación masiva de vulnerabilidades en otras instancias de SendBird en diferentes objetivos

1. Tenemos que confirmar que nuestros objetivos implementan SendBird en sus aplicaciones rastreando, realizando el descubrimiento de contenido en los objetivos y grep para la palabra "sendbird" y la expresión regular del ID de la aplicación de SendBird " [0–9A-F]{8}-[0– 9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12} ”
2. Después de haber confirmado los objetivos que implementan SendBird y obtener la ID de la aplicación SendBird, verificamos si la configuración de seguridad de la aplicación SendBird para "usuarios sin tokens de acceso" está mal configurada o no mediante el inicio/creación de usuarios anónimos de las siguientes maneras:
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 — cuerpo: {“app_id”:”<application_id>”}

4. Si el paso número 2 no tuvo éxito, revisaremos manualmente las funciones en el objetivo, obtendremos la sesión de usuario del SDK de la manera normal que lo hace el objetivo y verificaremos la configuración incorrecta de las ACL como en el paso 3.

5. ¡Automatícelos a todos!

Referencias para las API de SendBird para verificar:

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


Después de haber verificado las vulnerabilidades en diferentes aplicaciones de SendBird, la mayoría de ellas son vulnerables a la configuración incorrecta de las ACL. Sin embargo, en función de diferentes aplicaciones con diferentes requisitos comerciales e impactos, la gravedad también debe considerarse diferente (de Media a Crítica).

Los impactos son variados:

• Filtrar información confidencial de los usuarios
• Crear un canal de chat (sin crear una nueva liga)
• Administrar el canal de chat
• Actualizar el perfil de chat del usuario
• Actualizar la configuración del canal del grupo
• Chatear con cualquier usuario
• Un atacante podría editar/eliminar mensajes de cualquier usuario mientras cumple la función de operador del canal creado por él mismo.
• Un atacante podría actualizar los detalles, las configuraciones del canal mientras es miembro de cualquier canal.
• Como se documentó, un solo usuario de SendBird solo podía unirse a un límite de 2000 canales de grupo, el atacante podía crear 2000 canales de grupo y agregar a todos los usuarios de la aplicación SendBird a esos canales. Como resultado, todos los usuarios no pudieron unirse a ningún canal de SendBird después de eso, lo que podría causar una denegación de servicio.
• …






Grandes colaboraciones con thaivu , lamscun , thefool45, fergustr4n $$$$



### Actualizaciones de SendBird

• SendBird tiene más documentos sobre recomendaciones de seguridad, especialmente sobre las ACL.
• SendBird ahora permite a sus clientes cambiar las ACL por sí mismos.

¡GRACIAS POR LEER! ¡FELIZ HACKEO, APRENDIZAJE, CAZA Y PROTECCIÓN DE LAS AVES!