Cómo romper la arquitectura de cifrado de mensajes extremo a extremo de Rocket.Chat [2 de 2]

Tras la primera parte de este artículo de «Cómo romper la arquitectura de cifrado de mensajes extremo a extremo de Rocket.Chat«, hoy toca centrarnos en el ataque sobre la arquitectura del ataque al cifrado E2E. El objetivo del ataque sobre la arquitectura E2E de Rocket.Chat, será la de obtener y descifrar los mensajes almacenados en persistencia del lado del servidor.

Para lograrlo, si habéis podido revisar la arquitectura que os presenté en la primera parte de este artículo, una captura de red que contenga las cabeceras X-user-id y X-auth-token, propias de un usuario autenticado para cualquier llamada a la API Rest del servidor, serán requisito necesario y suficiente para replicar el ataque. 

No obstante, cualquier administrador de la aplicación con acceso a la base de datos no relacional tiene la capacidad de replicarlo obteniendo los mismos resultados, lo que demuestra que la arquitectura de cifrado no garantiza para nada el cifrado E2E. Espero que os guste y os animéis a probarlo, porque es un buen ejemplo para los amantes de los CTFs, de los Bug Bounties o de los ejercicios de Red Team.

El Bug en la arquitectura E2E de Rocket.Chat

La vulnerabilidad reside en la unión de una llamada al servicio de la API e2e.updateGroupKey con bajo nivel de privilegios en autorización de uso, junto con una funcionalidad desarrollada para continuidad de negocio en la que cualquier usuario, puede solicitar el reseteo de credenciales E2E. Siendo el primer usuario con status “online” que pertenezca al grupo, al que el servidor notificó con una llamada en broadcast el encargado de generar la nueva clave E2EKey para el usuario que la solicitó.

Dentro de un grupo seguro el objetivo mediante el uso indebido de la llamada a la API, será el de manipular las claves E2EKey de la colección suscripciones del servidor, como se explica en el gráfico siguiente.

La funcionalidad de negocio que se utilizará para la explotación, será la de reseteo de credenciales que se representa en el siguiente diagrama.

El vector de ataque será el de replicar las claves E2EKey del grupo seguro objetivo, en un nuevo grupo espejo, mediante el uso de de la función e2e.updateGroupKey por el atacante, el diagrama del ataque será el siguiente.

El proceso de la explotación completa, se puede ver en el siguiente vídeo, donde se utiliza un conjunto de código para hacer el exploit. La explicación de los códigos es la siguiente:

• dump_data.py: Desarrollado en Python3. Objetivo: extracción de los datos del servidor para el usuario del que se obtuvo la captura de red.

• attack_mode.py: Desarrollado en Python3. Objetivo: actualización de las claves E2EKey por el usuario atacante al usuario objetivo.

• msg_parser.ts: Desarrollado en javascript, ejecutado en node. Objetivo: convertir el formato de los mensajes y obtener tanto el vector de linealización IV como el cipherText de cada mensaje.

• Microservicio criptográfico: Desarrollado en java. Objetivo: Realizar las operaciones criptográficas de cifrado y hashing.
• automation_process.py: Desarrollado en python3. Objetivo: automatización del proceso de descifrado de mensajes, utilizará llamadas a:
• Servidor central de rocketchat
• msg_parser.ts
• Microservicio criptográfico

Si sigues el vídeo, verás que primero se crea un grupo de chat seguro, donde se manda un mensaje. Esta será la «bandera» a conseguir con la PoC. Será la evidencia para demostrar que se ha conseguido ver un mensaje que supuestamente debería estar protegido E2E.

Para ello, como se ha explicado anteriormente, se crea primero un grupo espejo que se utilizará como parte el esquema de ataque.

Figura 20: Generación del grupo espejo en el que replicar las claves.

Ahora, se extraen los datos del usuario objetivo con los scripts en Python explicados anteriormente, para lograr hacer la actualización de las claves E2EDKey.

Una vez extraídos los datos, ya se puede hacer el reseteo de las credenciales del usuario, para dar acceso al atacante al sistema.

Y con las nuevas credenciales, se pueden ver los datos descifrados que teníamos como objetivo original en el proceso, tal y como se puede ver en el script y en la herramienta de Rocket.Chat.

Este artículo recoge la PoC de una demostración que haré en la próxima LIBRECON en Bilbao, los días 15 y 16 de Noviembre, donde estaré dando una charla. Puedes conseguir tu entrada en MyPublicInbox con Tempos en la sección de Convierte tus Tempos. Además, se ha solicitado un CVE para este bug con el CVE ID Request 1348331 y la investigación se ha reportado vía Hacker1 y tienes en la siguiente URL la información:

• https://hackerone.com/bugs?report_id=1757663

Esperemos que pronto se añadan medidas de seguridad para evitar estos esquemas de ataque y dar más protección a la plataforma Rocket.Chat. Espero que os haya gustado la explicación y que os anime a hacer más investigaciones propias.