FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"

No hace mucho os hablaba de HQC "Hamming Quasi-Cyclic" el segundo KEM (Key-Encapsulation Mechanism) elegido por el NIST para completar al primero que se anuncio y que fue bautizado como  Module-Latice-Based KEM, o MLB-KEM o ML-KEM. Estos dos primeros KEM han sido elegidos como parte de la estandarización de los algoritmos de Criptografía Post-Cuántica (PQC: Post-Quantum Cryptography). 

Figura 1: FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC)

que recibe su nombre por "El señor de los anillos"

Sin embargo, hubo otros que se quedaron en el camino, y que con la aceleración de los últimos anuncios de Google Willow Quantum Chip, Microsoft Majorana-1 y Amazon Ocelot Quantum Chip,  merece la pena conocerlos porque alguno se está convirtiendo en estándar ISO. Uno de ellos es FrodoKEM, en el que han colaborado el mundo de la universidad, investigadores de Google y de Microsoft, que incluso tienes publicado en su GitHub para que lo puedas probar.

Figura 2: FrodoKEM en GitHub

Si queréis conocer más información de  Module-Latice-Based KEM, o MLB-KEM o ML-KEM, la podéis encontrar en la publicación completa del standard de ML-KEM la tenéis documentada en el siguiente paper del NIST, y yo escribí un artículo de HQC "Hamming Quasi-Cyclic", que también podéis leer.

Figura 3: Module-Lattice-Based Key-Encapsulation Mechanism Standard

Estos dos algoritmos se basan en una estructura de anillo algebraica central para esos algoritmos, y la apuesta de Frodo "es librarse del anillo". Sí, has entendido correctamente, este algoritmo recibe su nombre en homenaje al mítico personaje "Frodo" de "El señor de los anillos", que si no te has leído el libro, estás tardando ya - yo le dediqué un verano y lo disfruté como un "enano".

Figura 4: El Hobbit y El Señor de los anillos.

Tu lectura de este verano, sí o sí.

En este caso, FrodoKEM utiliza, para la generación de las claves de cifrado PQC (Post-Quantum Cryptography) que se usarán en una solución PKI se basan en la dificultad de resolver el problema de Learning With Errors. En este caso, el problema radica en dada una matriz A cuadrada de n x n generada uniformemente aleatoria, y dos matrices lineales siendo una muestra s de la clave, pero teniendo además la matriz e "errores", se realiza el cálculo de A x s + e y se obtiene una matriz b.

Figura 5: Explicación del problema de Learning With Errors

Para un atacante la dificultad del algoritmo es resolver la inversa, es decir, dado A y el resultado b, encontrar s, que sería la derivada sampleada de la clave, que no sería fácil de resolver para un algoritmo cuántico por la explosión de probabilidades en los que se ha podido inyectar el error, lo que le obliga a descubrir la matriz de errores, además de la clave. Como se puede ver en la imagen siguiente, la clave pública está compuesta de sA y b, por lo que se hace complejo resolver el problema.

Figura 6: Funcionamiento de FrodoKEM

Esta es la base fundamental de FrodoKEM, que como bien explican en la web de "FrodoKEM" y en el artículo "FrodoKEM: A conservative quantum-safe cryptographic algorithm" fue descartado del proceso de estandarización de NIST en la Ronda 3, pero va a ser estandarizado por la ISO/IEC 18033-2 para que sea un estándar que pueda ser utilizado por cualquiera que lo desee en la industria. 

Figura 7: Estandarización ISO de FrodoKEM

El problema que tiene FrodoKEM, como bien explican, es que evitar las posibles vulnerabilidades criptográficas que puede tener en el futuro el "anillo algebraico" en el que se centran ML-KEM y HQC-KEM es un coste en tamaño y en ciclos de computación.

Figura 8: Comparativa de ML-KEN y FrodoKEM

en tamaño y ciclos de computo hecha por el NIST.

Por supuesto, si te interesa el mundo de la criptografía, y no estás al día, te recomiendo que te pongas las pilas con el libro de  Cifrado de las comunicaciones digitales: de la cifra clásica a RSA 2ª Edición de 0xWord que te va a aclarar muchos de los conceptos que que son importantes en los algoritmos PQC (Post Quantum Cryptography).

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

Así que, si no tenías lectura para estos días, ya sabes qué te puedes comenzar a leer, que esto es fundamental para entender el mundo de la seguridad informática en cualquiera de las áreas profesionales en la que te quieras especializar.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Hamming Quasi-Cyclic (HQC-KEM): Nuevo Key-Encapsulation Mechanism en Post-Quantum Cryptography

Llevamos años en la estandarización de los algoritmos de Criptografía Post-Cuántica (PQC: Post-Quantum Cryptography), pero con la aceleración de los últimos anuncios de Google Willow Quantum Chip, Microsoft Majorana-1 y Amazon Ocelot Quantum Chip, parece que todo este mundo de la PQC tiene que acelerarse, y lo estamos viendo en las estandarizaciones del NIST, donde el mes pasado tuvimos el anuncio de la selección de un nuevo algoritmo KEM (Key-Encapsulation Mechanism), llamado HQC "Hamming Quasi-Cyclic".

Figura 1: Hamming Quasi-Cyclic (HQC-KEM).

Nuevo Key-Encapsulation Mechanism

en Post-Quantum Cryptography

Este no es el primero que se elige, ya que el año pasado, como algoritmo KEM se anunció Module-Latice-Based KEM, o MLB-KEM o ML-KEM, que lo podéis encontrar de esa forma nombrado según lo leáis. La publicación completa del standard de ML-KEM la tenéis documentada en el siguiente paper del NIST.

Figura 2: Module-Lattice-Based Key-Encapsulation Mechanism Standard

Ahora el NIST ha anunciado que ha elegido un KEM de respaldo, es decir, por si se descubre algún bug estructural de ML-KEM o por si se quieren mantener los dos funcionando como medida de seguridad, llamado HQC "Hamming Quasi-Cyclic" KEM.

Figura 3: NIST PQC Standarization Process Internal Report 8545

Aún no tenemos el standard completo definido, pero sí el documento donde se pueden ver los candidatos que se presentaron para ser elegidos, que llevan los nombres de HQC, BIKE - que estuvo cerca de ser el elegido -, Classic McEliece y SIKE, que han sido descritos en el Internal Report 8545 que os dejo aquí enlazado.

Figura 4: Elección de HQC como KEM PQC

El encapsulado de las claves de HQC, y el de BIKE también, utilizan los Hamming Quasi-Ciclic, que se basan en los códigos de Humming. Un sistema de control de errores en la transmisión de datos que usan un enlazado de los códigos de paridad para detectar errores. 

Figura 5: Explicación de por qué han elegido HQC

En el paper, - que no es la definición del standard HQC -, se explica cuáles han sido los motivos para la elección de este HQC-KEM, donde al final el rendimiento y DFR (Decryption Failure Rate) han sido claves para su elección como standard.

Figura 6: Evaluación de HQC

Como se puede ver en la presentación que ha defendido a HQC en su elección, el DFR es cercano al valor teórico del algoritmo, lo que ha convencido - como se puede ver en la evaluación de la Figura 6 al comité del NIST para elegirlo sobre BIKE.

Figura 7: DFR de HQC comparado con el límite teórico

Pero no tan deprisa, el Standard de HQC-KEM aún tendrá que esperar hasta alcanzar su versión final en algo así como 2 AÑOS, como han dejado ya por escrito en el paper, así que habrá que esperar para poder utilizar este KEM PQC en sistemas en producción. 

Figura 8: Standard HQC-KEM en dos años

Mientras tanto, vamos a tener que seguir los mecanismos estandarizados que nosotros utilizamos en Tu Quantum Encryption & Tu Quantum Drop, para tener redes con VPNs que utilizan un capa extra de seguridad PQC.

Figura 8: Arquitectura de VPN-PQC con Tu Quantum Encryption

Y, por supuesto, no te puedes olvidar de la criptografía clásica, que va a seguir con nosotros durante un largo tiempo aún, así que si no estás al día, te recomiendo que te pongas las pilas con el libro de  Cifrado de las comunicaciones digitales: de la cifra clásica a RSA 2ª Edición de 0xWord que te va a aclarar muchos de los conceptos que que son importantes en los algoritmos PQC.

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

Así que, si no tenías lectura para estos días, ya sabes qué te puedes comenzar a leer, que esto es fundamental para entender el mundo de la seguridad informática en cualquiera de las áreas profesionales en la que te quieras especializar.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

WhatsApp: Passkeys para hacer más cómodo el proceso de Login y reducir los SMS-OTP

Una de las características que ha introducido WhatsApp para mejorar su proceso de autenticación es la del uso de las Passkeys. No es que WhatsApp haya cambiado su forma de iniciar sesión ten tu cuenta, con el famoso SMS que se usa como canal OTP de desafío a tu número móvil, sino que se ha añadido, una vez instalado en un dispositivo, poder autenticarse mediante un sistema de clave privada / clave pública como alternativa al SMS.

Figura 1: WhatsApp: Passkeys para hacer más cómodo

el proceso de Login y reducir los SMS-OTP

Es decir, la idea es reducir el número de SMS-OTP que se envían - y que han sido tradicionalmente el punto de ataque para robar cuentas de WhatsApp -, permitiendo que el usuario pueda utilizar las Passkeys - si las tiene -, como forma cómoda y segura de autenticarse.

Figura 2: Passkeys en WhatsApp

Como podéis ver en la imagen superior del Help Center de WhatsApp, las claves se pueden utilizar opcionalmente, si se tienen, lo que hará mucho más cómodo el proceso de autenticación, ya que será como autenticarse como con cualquier otra credencial de los gestores de contraseñas que tienen Android e iPhone, por lo que se puede utilizar FaceID o la Biometría de la huella dactilar.

Figura 3: WhatsApp INT: OSINT en WhatsApp.

Nuevo libro de Luis Márquez en 0xWord.

Es decir, para el usuario será más cómodo porque no hay que esperar que llegue el SMS OTP, no tendrá que leerlo y escribirlo, y no se producirá una transmisión del código para que pueda ser capturado por un posible atacante.  Pero si no lo tiene, no pasa nada, el usuario puede autenticarse como siempre.

Figura 4: Creación de Passkeys

Crear la Passkey es tan sencillo como podéis ver en estas capturas. Se entra en Account -> Passkeys, le damos al botón de Continuar y la Passkey es creada. Y tendremos una solución temporal de autenticación utilizando claves criptografías.

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

Una vez que pasa esto, sólo hay que almacenarla en el gestor de credenciales de tu dispositivo, lo que hace WhatsApp de manera automática. En mi caso, que tengo un iPhone, me autentico con FaceID y se queda guardada en el Password Manager de Apple.

Figura 6: Creación, almacenamiento y borrado de las Passkeys

Como se ve en la imagen anterior, se puede eliminar la Passkey, y si existe esa Passkey, se puede utilizar para iniciar sesión en cualquier dispositivo sin utilizar el SMS-OTP tradicional. 

Conclusión

Este proceso implica dos cosas a tener en cuenta que quiero recalcar para que sea fácil entender este sistema de autenticación:

1.- No sustituye el SMS-OTP como forma permanente de autenticación: Es una alternativa que puede ser utilizada, pero si has perdido las Passkeys porque has perdido el dispositivo, con recuperar la SIM puedes volver a iniciar sesión. 

2.- Si alguien tiene las Passkeys podría iniciar sesión: Así que debes, como ves en la figura 5, eliminar las Passkeys antes de cambiarte de Android a iPhone, o de cambiar de Password Manager, porque si alguien pudiera acceder a ellas, tendría acceso a tu sesión.

3.- Más info para verificar un robo de cuenta: He querido añadir este punto porque al final, si alguien te clona la SIM o consigue tu OTP, y tú tienes también el SMS-OTP haciendo un login en paralelo, pero además tienes las Passkey, puede ser que Meta use las Passkeys como elemento para determinar que estás sufriendo un ataque, así que no viene mal tenerlas. 

Por último, recalcar que, a día de hoy, el proceso de login sólo se hace cuando hay cambio de dispositivo, o un cambio drástico en el sistema operativo, por lo que ya a día de hoy hay un proceso de autenticación para mantener la seguridad de la cuenta mediante claves de dispositivo que también se guardan en el Password Manager, así que digamos que esto es una evolución que permite utilizar estas Passkeys más allá del uso actual.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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

Mis problemas con el DNIe en la renovación de certificados

Hacía tiempo que - por desgracia - no me tocaba firmar un documento digitalmente con mi DNIe, del que soy poseedor desde que mi amigo Rames Sarwat me evangelizara con su libro, así que cuando me ha tocado volver a usarlo... mis certificados digitales estaban caducados y tenía que renovarlos.

"¡No!", pensé en un grito cerval interior recordando los peores momentos iniciales de renovar mi DNI cuando tenía 18 años y no había ni servicios de cita previa... Pero había que hacerlo. Con este ánimo me puse en actitud de niño que no quiere ir al cole, fruncí el ceño, busqué donde tenía apuntada la pedazo de password que le puse al DNIe en su momento, y me embarqué en el maligno-móvil dispuesto a estar enfadado con el mundo, que ya me tocaba.

Tras un breve trayecto me planté en la comisaría del barrio con el coche y de repente... ahí estaba. En la puerta de la comisaría, un sitio para aparcar el coche de 5 metros de largo y que no era zona azul, verde, roja, amarilla o cualquier otro color del arco-iris. Escarmentado como estoy, pues me han puesto una multa por no ver una señal de prohibido aparcar oculta por los árboles, revisé la acera un par de decenas de metros a cada lado buscando restos de señales arrancadas. Pero no. No había ninguna. Era un sitio enorme esperándome a mí. Aparqué y entré extrañado en la comisaría.

Al llegar esperaba encontrarme las colas, pero sólo me encontré a un agente que me dijo: "Buenas tardes, ¿Qué necesita?". Dispuesto a contar mi vida digital a un agente que supuse que no sabría nada de informática le dije: "Es que me han caducado los cert..." y antes de que terminara de contarle mi vida me respondió: "Para renovar los certificados del DNIe usa este kiosko que tienes aquí. Solo mete el DNIe y listo".

No sé si me sorprendió más que me ayudara tan rápido y bien o que supiera qué son los certificados digitales, así que me fui tras decir un sencillo "gracias" de mínimo a la máquina con el DNIe en la mano a ver dónde me esperaba la sorpresa negativa del día. Algo tenía que pasar, no iba a ser todo miel sobre hojuelas.

Metí el DNIe y rápidamente el sistema me solicitó mi password. La iba a sacar, pero una idea malévola se me pasó... ¿y si no me acuerdo de ella? Con maligna idea le di a la opción de no recuerdo mi clave, y el sistema me respondió ipso-facto con una solicitud biométrica de la huella digital de mi dedo índice. "Je", pensé, "ahora es cuando viene la fiesta". Puse el dedo, esperando que entre los millones de dedos de españoles esto funcionara regular. Sin embargo, en unos segundos, me respondió con mis datos personales del DNIe y una pregunta: "Establezca una nueva clave".

Tenía que haber cámara oculta, no podía ser todo tan sencillo. Miré a la máquina con cara de... "¿donde está la sorpresa?", pero puse la password. Al introducirla recordé lo horrorosa que era mi primera password del DNIe, esperando que me solicitara una igual de compleja, pero no. El sistema me permitió poner una contraseña compleja del tipo passphrase que uso yo...a la primera.

Después, el sistema me reconoció que tenía los certificados caducados y me ofreció renovarlos, a lo que dije que sí. A esto había venido al fin y al cabo. Tas decir que sí, el sistema me advirtió: "No retire su DNIe, este proceso puede llevar unos minutos". Con ese tiempo de espera me farfullé en la mente eso de "Esta es la mía, a probar el truco de las sticky keys mientras tanto".

Pulse las teclas a ver si se levantaba el Windows por algún sitio, como ya me lo había enviado alguien antes... pero estaba resuelto. No salió nada. Y en menos de 2 minutos y medio, el sistema me avisó que mi DNIe tenía renovados los certificados para los próximos años.

"¿Desea algo más?"

Con cara de "¿ya?" le dije que no, saqué mi DNIe y me fui hacia la puerta, donde el agente me dijo al salir: "Que tenga buen día". Le contesté que igualmente y sin mucho más que hacer, me subí en el maligno-móvil - que no tenía ninguna multa - y me fui con mi vida reflexionando sobre lo bien que iba este sistema - a pesar de lo que me esperaba a priori - y lo contento que me quedé al usarlo yo en mi vida útil.

Por cierto, mis problemas con el DNIe en la renovación de certificados ese día fueron cero, y pasar por la Comisaría de Policía me alegró la tarde.

Saludos Malignos!

Hacking Remote Apps: Jailbreaking con Excel (II de IV)

**************************************************************************************************
- Hacking Remote Apps: Jailbreaking con Excel (I de IV)
- Hacking Remote Apps: Jailbreaking con Excel (II de IV)
- Hacking Remote Apps: Jailbreaking con Excel (III de IV)
- Hacking Remote Apps: Jailbreaking con Excel (IV de IV)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

Tal y como se vio en la primera parte, los documentos Excel se pueden convertir en grandes aliados en máquinas cuando hay acceso local, y eso es lo que se tiene cuando se ejecuta en un entorno con Terminal Services o Citrix. Es por eso que revisar las políticas de seguridad de Excel con respecto a la ejecución de macros se convierte en algo obligatorio.

Políticas de Excel respecto a macros VBA

Un usuario puede configurar la seguridad de su aplicación Excel mediante las opciones del Trust Center (Centro de Confianza) del producto. No obstante, en un entorno administrado, estas opciones se pueden establecer mediante el uso de políticas GPO distribuidas desde el Active Directory, o bien en un entorno Stand Alone del servidor, con el Editor de Políticas.

Para configurar correctamente las políticas referidas a todo el paquete Microsoft Office, se proveen unas plantillas donde aparecen todas las opciones configurables del producto y, por supuesto, las opciones de seguridad de las macros están allí, en la clave de la ruta: Microsoft Office Excel 2007 / Excel Options / Security Trust Center / VBA Macro Warning Settings

Figura 5: Ruta de Política de seguridad con macros VBA

Esa ruta es análoga en Microsoft Office 2010 y, como se puede ver en la imagen, solo está disponible para versiones de Windows Vista o Windows 7.

Una cosa que ya se puede ver es que no es una opción de seguridad como tal, sino que el propio nombre de la clave habla de "Warnings", lo que deja entrever que nunca se pensó en el propio usuario de Excel como un enemigo, sino que el documento que pudiera abrir el usuario fuera el enemigo. Es decir, que las políticas de seguridad de Excel están considerando al usuario del programa como un aliado, y en este entorno no va a ser así, lo que hará que las políticas no sean suficientes para proteger al servidor Terminal Services o Citrix de un uso inapropiado.

Política 1: Ejecutar todas las macros en todos los documentos

Esta opción se considera insegura en las opciones de las macros, y desde el punto de vista nuestro, es decir, en un entorno donde un usuario armado con un Excel lleno de comandos quiere ejecutar instrucciones en el servidor Citrix o Terminal Services, así lo será. Es decir, si está configurada esta opción, entonces se conseguirá la ejecución en el sistema.

Política 2: Case by case

Esta es la configuración por defecto de la seguridad de macros VBA en Excel, con esta opción, el usuario recibirá un warning avisándole de la existencia de macros dentro del documento y de que la ejecución de las mismas podría ser nociva para el sistema. Obviamente, en este entorno, el atacante solo necesita "confiar" en las macros de su documento Excel para poder ejecutar los comandos en el sistema.

Figura 6: El usuario puede activar el contenido

Política 3: Sólo macros firmadas digitalmente de confianza

Esta podría ser una buena candidata a ser la opción de seguridad de muchos entornos. Con esta opción, cuando un documento lleve macros sin firmar por una entidad de confianza del sistema, no se podrán ejecutar y aparecerá un mensaje avisando de este problema.

Una de primeras aproximaciones que seguro que todos habéis podido pensar es la de utilizar macros firmadas con un certificado self signed, y no vais desencaminados, solo que cuando se hace esto, como se puede ver en la imagen siguiente, no hay opción de poder habilitar el contenido en el cuadro de diálogo de alerta, luego parece más o menos seguro.

Figura 7: Warning obtenido con un documento Excel con macros VBA auto-firmadas

La pregunta es, ¿se podrá saltar esta restricción? Pues sí, y no es tan complicado como pueda parecer en un principio. Al final, el problema es otra vez, algo de Playing the piano. En la imagen se puede ver que hay un enlace que pone "Show Signature Details", así que hay que hacer clic en él y seguir la ruta hasta poder visualizar el certificado digital de la CA auto-firmada que se ha utilizado para firmar las macros VBA. En nuestro caso Defcon19.

Figura 8: CA usada para firmar las macros VBA

Una vez allí, el truco es instalar la CA nuestra como una Entidad Raíz de Confianza, con lo que una vez que estemos viendo el certificado de la CA haremos clic en Install Certificate.

Figura 9: Instalación del CA en contenedor de usuario

Para ello, deberemos utilizar el asistente de instalación, que es a nivel de usuario, es decir, no se necesita ser administrador y, podremos ponerla en el contenedor de las CA Raíz de confianza.

Figura 10: Instalación como CA Raíz de Confianza

Una vez hecho esto... ¿qué sucederá con el warning de seguridad de macros? Lo vemos en la siguiente parte.

**************************************************************************************************
- Hacking Remote Apps: Jailbreaking con Excel (I de IV)
- Hacking Remote Apps: Jailbreaking con Excel (II de IV)
- Hacking Remote Apps: Jailbreaking con Excel (III de IV)
- Hacking Remote Apps: Jailbreaking con Excel (IV de IV)
**************************************************************************************************

Cotilleando la estructura PKI del DOD usando LDAP

Con el lío que se ha formado estos días con el ataque a las entidades de certificación, como DigiNotar, Comodo, StartSSL o GlobalSign, quería comprobar si es difícil hacer un ataque APT similar contra la infraestructura PKI de una organización interna. Es decir, en lugar de robar el certificado de una CA central, robar, crear o falsificar certificados digitales de una compañía que tenga su propia infraestructura PKI.

No, no he llegado a hacer nada, y hoy solo os dejo una forma de cotillear la infraestructura PKI de una organización, para saber cuáles son las CAs, cuales son las que pueden firmar qué, etcétera. Para ello usé un truco muy sencillo, y os voy a poner un ejemplo con el Departamento de Defensa Americano. Para ello, nos vamos a aprovechar de que, como se puede ver en este certificado digital de uno de los servidores web que usan Http-s, usan una estructura LDAP para gestionar las CAs. 

Figura 1: Certificado Digital usando en un servicio https

Así, lo único que hay que hacer es abrir nuestro cliente LDAP favorito (yo después de probar varios en Mac OS X y llevarme varios chascos abrí Windows y use LDAP Browser como en el caso del Listín de Teléfonos) y crear una conexión anónima a ese servidor LDAP y ... pasear por allí tomando notas.

Figura 2: Cotilleando la estructura PKI del DOD usando LDAP Browser

Como se puede ver, toda la información es pública, y se pueden acceder a las claves públicas de las CAs, ver cuáles usan sistemas de hashing que puedan ser atacados fácilmente por problemas de colisiones, descargar todas las CAs públicas para hacer las pruebas en local y ver si cuelan los certificados falsos, etc... Así que, si tienes una estructura PKI interna tuya, cuida de tus certificados, que no es muy difícil cotillearlos todos rápidamente.

Saludos Malignos!