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.

Figura 12: Cómo romper la arquitectura de cifrado de

mensajes extremo a extremo de Rocket.Chat [2 de 2]

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. 

Figura 13: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

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ó.

Figura 14: Llamada a la API Rest que se utilizará para la explotación

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.

Figura 15: Manipular las claves de E2EKey

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

Figura 16: Esquema del proceso de reseteo de claves.

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.

Figura 17: Esquema del ataque para conseguir la duplicación

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

Figura 18: PoC  del ataque a Rocket.Chat

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.

Figura 19: Canal seguro con mensaje a obtener como objetivo de la PoC.

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.

Figura 21: Extracción de los datos del usuario objetivo

y actualización de claves E2EKey.

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

Figura 22: Reseteo de credenciales, para el atacante.

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.

Figura 23: Validación final de los datos descifrados.

Conclusión final

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.

Saludo,

Autor: Ildefonso González Sánchez, pentester.

Contactar con Ildefonso González Sánchez

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

A día de hoy, una de las aplicaciones de Software Libre de mensajería instantánea (IM) disponibles en el mercado para su uso a nivel empresa o particular, por robustez, por funcionalidades y por ser una solución multi-dispositivo, podría ser el popular Rocket.chat. En este artículo vamos a ver cómo se rompe la arquitectura de seguridad y se puede acceder a los datos enviamos en los mensajes por culpa de un fallo de seguridad que hay que corregir. 

Figura 1: Cómo romper la arquitectura de cifrado de

mensajes extremo a extremo de Rocket.Chat [1 de 2]

Rocket.chat permite varias modalidades de uso de cara a una compañía, pudiendo montar un servidor centralizado OnPremise, tu propio servidor OnCloud, o simplemente mediante,  el uso del servidor público que proporciona la propia compañía Open.rocket.chat. La conexión al servidor puede realizarse desde múltiples dispositivos como se puede ver en la imagen anterior, tiene cliente Web, aplicación de escritorio para Windows/Linux/MacOS y app móvil para Android e iOS.

Figura 2: Arquitectura de conexiones multi-cliente para Rocket.chat

La funcionalidad a revisar en el artículo, será la del cifrado Extremo a Extremo o "End-2-End" (E2E). Dicha funcionalidad, implementa una capa de seguridad adicional al cifrado TLS a nivel de red utilizado de forma común mediante el protocolo HTTPS, en la mayoría de las comunicaciones actualmente. Como veremos al final, se podrá hacer un descifrado de los mensajes, y veremos cómo se puede mejorar la arquitectura de cifrado. Para entender mejor toda la arquitectura de cifrado, tienes el libro de Cifrado de las comunicaciones digitales: de la cifra clásica a RSA 2ª Edición de 0xWord

Figura 3: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

El cifrado E2E, por defecto, tiene la capacidad de hacer llegar un dato de forma segura desde un origen a un destino, de un modo descentralizado. En este caso, y dado que se encuentra en una arquitectura centralizada debido al diseño del producto, todos los mensajes enviados desde un origen pasarán y se almacenarán en el servidor central antes de llegar al destinatario, siendo la funcionalidad E2EE (End 2 End Encryption) la encargada de realizar este proceso de forma segura.

Arquitectura de Rocket.Chat

Para implementar esta función, Rocket.Chat cuenta con un diseño de arquitectura E2E del cual se ha realizado un pequeño estudio, para preparar este artículo. Esta arquitectura utiliza operaciones criptográficas de varios tipos, diferenciadas por su naturaleza matemática en simétrica, asimétrica y operaciones de hashing:

• Criptografía Simétrica: algoritmo utilizado AES, origen y destino comparten una clave de cifrado.

• Criptografía Asimétrica: algoritmo utilizado RSA, mediante el uso de un par de claves Publica y Privada, los datos serán cifrados con la clave pública y descifrados con la la clave privada.

• Hashing: algoritmo utilizado PBKDf2, la función derivación matemática que generará un resultado irreversible del cual no se puede obtener los datos originales de entrada.

La dirección de la implementación actual del producto a nivel arquitectura de software, por diferentes motivos, como el diseño de las funcionalidades de negocio y mantenimiento de una sola linea de código  para los diferentes dispositivos, se implementa con el framework react-native.

Figura 4: GitHub de Rocket.Chat

Dicho framework trabaja con JavascriptCore que ademas de ejecutarse en los navegadores web, permite la posibilidad de integración de librerías implementadas en otros lenguajes de programación, como puedan ser Java para sistemas operativos Android u Objetive-C para sistemas operativos iOS:

Figura 5: Arquitectura de JavascriptCore con Java  y Objetive-C

Las conexiones que se implementan entre los diferentes clientes y el servidor central de Rocket.Chat podrán ser de dos tipos diferenciados por la dirección en la que se comunican:

Figura 6: Conexiones API REST y WebSocket

La  conexión vía API Rest es Cliente → Servidor y unidireccional, mientras que la conexión vía Websocket permite en modo full-duplex transferencias bi-direccionales Servidor → Cliente y Cliente → Servidor.

Descripción de la arquitectura E2E

La funcionalidad E2E, se arranca tras la autenticación inicial de un usuario (U) sobre sobre un dispositivo (D).

• El dispositivo (D), solicitará al usuario (U) o generará unas credenciales específicas E2E (En función de si es la primera vez o no, que el usuario se autentica en el dispositivo con el servidor de Rocket.Chat).

• Tras introducir las credenciales mediante la derivación de la contraseña junto al identificador unívoco del usuario (U) UID y el uso del algoritmo criptográfico de hashing PBKDF2, se generará la primera clave criptográfica de la aplicación master-key.

Figura 7: Generación de Master Key en dispositivo

A continuación, el dispositivo (D) como cliente del servidor de Rocket.Chat procederá con la generación o solicitud (en función de si es la primera vez en la que el usuario se autentica en el dispositivo) de un par de claves RSA de longitud 2048 que serán las claves criptográficas E2E del usuario:

• Generación public_key, private_key: RSA-OAEP 2048

• Utilizando la master-key, mediante criptografía simétrica utilizando el algoritmo AES-CBC el dispositivo (D), cifrará la private_key.

Figura 8: Generación de claves pública y privada para cifrado asimétrico

El dispositivo (D), mediante una llamada a la API Rest de tipo POST, sobre la API de Rocket.Chat realiza el envío del par de claves, public_key y private_key (ésta última cifrada, para garantizar la confidencialidad del usuario).

• La función de la API Rest que proporciona este servicio, es e2e.setUserPublicAndPrivateKeys.

• El servidor de Rocket.Chat en su BD no relacional (mongodb) almacenará estas claves asociadas al usuario (U), en la colección users.

Figura 9: Envío de claves pública y privada a servidor de Rocket.Chat

La aplicación para cifrar los datos punto a punto, requiere de una habitación o chat seguro por tanto ya sea dirigido desde el usuario (U), al usuario unívoco (U₁) o a los múltiples usuarios (U₁),(U₂)...(U_n), por lo tanto será necesario crear un grupo cifrado.

• La operación de la API Rest del servidor de Rocket.Chat que proporciona este servicio será create.group, especificando los parámetros adecuados de grupo privado y encriptado.

• El servidor de Rocket.Chat generará en la BD no relacional una entrada en la tabla rocketchat_subscriptions por cada usuario (U1..n), que pertenezca a la habitación segura alojada en la colección rocketchat_room.

Figura 10: Creación de un grupo de cifrado con clave simétrica

El creador del grupo seguro, será el encargado de generar la clave criptográfica de cifrado de mensajes Room-Key (el cual será cifrado simétrico), y almacenarlo únicamente de forma cifrada en la BD del servidor, en la colección rocketchat_subscriptions, mediante la operación de la API Rest e2e.UpdateGroupKey. Éste proceso se realizará N veces para cada uno de los usuarios que pertenecen al grupo:

• Se cifrará la Room-Key: de forma asimétrica mediante el algoritmo RSA para cada usuario del chat seguro.

• Se utilizará para el cifrado la public_key, disponible en la colección users del servidor, reportada mediante la invocación al servicio API Rest de Rocket.Chat e2e.requestSubscriptionsKeys.

Figura 11: Envío de claves Room-Key a los usuarios del grupo

Para la obtención de la clave de cifrado de mensajes E2E, en determinado grupo cualquier usuario que sea miembro de este, deberá realizar los siguientes pasos:

• El usuario (U), ya autenticado en la aplicación y en la arquitectura E2E estando en posesión de su master-key.

• Solicitará la clave de sesión E2EKey, almacenada para su usuario (U), en la colección rocketchat_subscription (cifrada asimétricamente con RSA).

• Solicitara sus claves de cifrado al servidor, public_key y private_key (esta última, cifrada simétricamente con AES).

• Descifrará con AES, la clave privada mediante el uso de la master-key.

• Descifrará con RSA, utilizando la clave privada (private_key) descifrada y la clave E2E (E2EKey) obteniendo la room-key o session-key.

Visto todo esto, si eres amante de la seguridad informática, el hacking y te gusta la criptografía, supongo que ya has visto algunos puntos débiles de esta arquitectura que, si se pueden atacar, pueden romper la seguridad de la plataforma. En la segunda parte de este artículo lo vemos.

Saludo,

Autor: Ildefonso González Sánchez, pentester.

Contactar con Ildefonso González Sánchez

Xencrypt: Evasión en Windows 10 con Powershell usando cifrado AES

Los investigadores Xentrooy y SecForce han publicado un crypter en Powershell. Es un proyecto bastante nuevo, ya que si se ve el Github consta de pocos días. Llamó mi atención, ya que todo lo que es Powershell me llama la atención, debido a que los amigos de HackPlayers publicaron un interesante artículo.

Figura 1: Xencrypt: Evasión en Windows 10 con Powershell usando cifrado AES

Sin duda Xencrypt propone una solución interesante al juego de siempre, el juego de la evasión. El gato y el ratón. El que detecta con el que intenta no ser detectado. Como digo siempre en las clases, las protecciones mejoran y otros intentan evadirlas, con el objetivo de mejorar la protección. Este es el juego de la ciberseguridad, en cualquier protección que se precie.

PowerShell para Atacantes

Además, quería probar esta funcionalidad y herramienta, ya que creo que es un factor interesante, todo lo que es la evasión de protecciones. Viendo que me queda poco tiempo para el taller de Rooted Lab el día 3 de marzo sobre Offensive Powershell. Un taller donde le daremos ‘cera’ a Windows 10 y la Powershell. Había que probarlo e incluirlo.

Figura 4: Libro de Pentesting con PowerShell 2ª Edición de Pablo González

En otras palabras, Xencrypt proporciona un crypter que permite llevar a cabo la ofuscación de scripts y código para evitar su detección. La idea de Xencrypt es poder generar infinitas formas diferentes, es decir, tener diferentes scripts para ejecutar lo mismo que permiten la no detección por parte de un antivirus. Xencrypt es un crypter de Powershell, el cual utilizar cifrado AES y compresión GZip. Cada vez que se invoca se genera un script nuevo, con una salida o ejecución igual a lo que se quiere. En definitiva, como bien dicen los autores de la herramienta, es esencia es para Powershell un PE Crypter.

Figura 3: Xencrypt en GitHub

En otras palabras, con cada ejecución de Xencrypt, lo importante, es el gran número de variantes de script que se genera. Es decir, si tenemos un Mimikatz en Powershell, el cual es ‘cazado’ por el antivirus, se puede pasar por Xencrypt y la salida de la ejecución será un nuevo código de Mimikatz ofuscado y cifrado. Cuando lo llevemos al equipo dónde antes se detectaba, la probabilidad de que lo detecte el antivirus habrá disminuido.

Probando Xencrypt

Lo primero era hacer una prueba con el propio script de Powershell. Si lo cargamos directamente en una Powershell con Windows 10 puede que nos salte el antivirus, ya que este código ya es detectado, por lo que se puede probar, pero hay que tenerlo en cuenta. Si vamos a una Powershell en un Windows 7, AMSI no estará para poder detectarlo.

La ejecución de la función Invoke-Xencrypt es muy sencilla. Tiene tres parámetros. El parámetro infile indica que el fichero de entrada. El parámetro outfile refleja el fichero de salida, el cual estará ya cifrado y ofuscado. El parámetro iterations indicará el número de iteraciones que se realizará. Este es uno de los factores que hacen que las variantes de la salida sean casi infinitas.

Figura 4: Función Invoke-Xencrypt

A continuación, se puede ver la salida del script prueba.ps1. El código hace lo mismo que el de entrada, solo que tiene un aspecto bastante diferente. En tiempo de ejecución se llevará a cabo un descifrado de la acción y realizará una ejecución del código. Se intenta evitar que palabras clave, rutas claves y etiquetas claves sean detectadas por AMSI.

Figura 5: Salida del script prueba.ps1

Las características que indican los autores y que son muy interesantes sobre esta herramienta son las siguientes:

• Evasión de AMSI y AV modernos. 

• Comprime y cifra scripts. 

• El overhead es mínimo, incluso negativo. 

• Variables aleatorias. 

• Cifrado aleatorio con máxima entropía. 

• Capas recursivas (o iteraciones) hasta 500.

Es fácil de modificar, quizá sea el punto más interesante, para poder crear una variante propia y que mejore la evasión en un momento determinado. Probando el prueba.ps1 con diferentes motores de antivirus, la salida es más que interesante.

Figura 6: Script ofuscado bypasseando frimas de AV

Por supuesto, hay que probarlo en Windows 10 con el AMSI y las posibilidades que este ofrece. Ya hemos hablado en este blog sobre AMSI y diferentes técnicas de bypass y que nuestra iBombshell ya implementa. Al final, esto es probar, probar y probar en busca de la evasión. El Ethical Hacking es así.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 11: Contactar con Pablo González

Clonado de SIMs utilizando técnicas de Differential Power Analysis en algoritmos MILENAGE de 3G & 4G

Ayer viernes noche, revisando las charlas de BlackHat USA 2015 topé con una que me llamó la atención más que las demás. Tal vez no ha tenido tanta repercursión en los medios de comunicación como el caso del bug de Stagefright en Android, el control remoto del Jeep Cherokee o la modificación del disparo de un rifle mediante una conexión remota, pero que quizá vaya a tener mucho impacto en el futuro de nuestras vidas. Se trata del trabajo de extracción de datos de la zona segura de las USIM (Universal SIMs) utilizadas hoy en día aprovechándose de la implementación de algoritmos para 3G y 4G, utilizando para ello un side-channel, lo que abre nuevos ataques a sistemas de comunicaciones móviles.

Figura 1: Clonado de SIMs utilizando técnicas de Differential Power Analysis
en algoritmos MILENAGE de 3G & 4G

El trabajo, que ha sido titulado "Small Tweaks do Not Help: Differential Power Analysis of MILENAGE Implementations in 3G/4G USIM Cards" lo que hace es extraer de la zona seguridad de la SIM, los datos necesarios para poder clonarla, haciendo un análisis de las diferencias de energía que existen para los diferentes datos de entrada. Esta aproximación es totalmente distinta a los ataques por medio del ataque COMP128: A Birthday Suprise que se han hecho en las antiguas SIM basadas en COMP128(v1).

Figura 2: clonadores de SIM COMP128(v1)

Tras aumentar el nivel de seguridad de las tarjetas, las nuevas COMP128(v2), COMP128(v3) y COMP128(v4) no habían sido vulnerables a estos ataques que pudieran extraer la Master Key K, y los nuevos valores OPc (Clave de Operador) y los secretos de operación que se agregaron a las USIM.  Con este nuevo enfoque, lo que se hace es aprovechar que en 3G y 4G se implementan los algoritmos MILENAGE con AES 128, para lograr sacar la Clave Maestra K, la Clave de Operador OPC, y las secretos de operación definidos por el operador r1,c1.. r5, c5. El proceso es introducir valores conocidos y medir el side-chanell de energía para reconocer las variaciones.

Figura 3: Paper que explica cómo extraer la información privada de la SIM con un DPA

En el trabajo se explica en detalle cómo basta con un osciloscopio para poder realizar las mediciones de energía y aplicar el estudio DPA haciendo ejecutar sucesivas veces el algoritmo MILENAGE con el objeto de conseguir ir sacando los bits de las claves K, OPc inicialmente.

Figura 4: Equipo de laboratorio. Un lector de SIM creado por ellos y un osciloscopio.

Una vez conseguido sacar la Master Key K y el Secreto de Operador OPc, sacar el resto de los secretos de realiza de forma análoga, tal y como se puede ver en las diapositivas de la presentación que han dado.

Figura 5: Explicación de la fase 2 del algoritmo para recuperar K y OPc

En sus pruebas de laboratorio, con SIMs de 8 diferentes operadores y de distintos fabricantes, fueron capaces de extraer los datos en tiempos inferiores a menos de hora y media, debido a la ausencia de protecciones contra la medición externa de la energía.

Figura 6: Resultados de experimentación con USIMs de varios fabricantes y operadores

Con este trabajo se abre una puerta a que aparezcan los famosos clonadores de tarjetas SIM que tan populares se hicieron con las SIM antiguas que utilizaban Comp128v1, pero ahora para cualquier tarjeta que no tenga una protección extra contra la medición de este side-channel. Según los investigadores, esto está comunicado a los fabricantes de tarjetas SIM y puede que alguna haya empezado a aplicar medidas de protección y mitigación, pero por supuesto, todas las SIMs desplegadas seguirán siendo vulnerables a estos ataques durante años, así que habrá que vigilar el acceso físico a tu SIM en todo momento.

Saludos Malignos!