Grave seguridad: Microsoft Office 365 atacado por encriptación débil

No estamos muy seguros de cómo llamarlo en este momento, por lo que nos referimos a él en el título con el nombre híbrido Microsoft Office 365.

(El nombre "Office" como sustantivo colectivo para las aplicaciones de colaboración, presentaciones, hojas de cálculo y procesamiento de textos de Microsoft está siendo matado durante el próximo mes o dos, para convertirse simplemente en "Microsoft 365").

Estamos seguros de que la gente seguirá usando los nombres de aplicaciones individuales (Palabra, Excel, PowerPoint y amigos) y el apodo de la suite Oficina durante muchos años, aunque los recién llegados al software probablemente terminarán conociéndolo como 365, después de eliminar el omnipresente prefijo de Microsoft.

Como sabrá, las aplicaciones independientes de Office (las que realmente instala localmente para que no tenga que conectarse a Internet para trabajar en sus cosas) incluyen su propia opción para cifrar los documentos guardados.

Se supone que esto agrega una capa adicional de seguridad en caso de que luego comparta cualquiera de esos archivos, por accidente o diseño, con alguien que se suponía que no debía recibirlos, algo que es sorprendentemente fácil de hacer por error al compartir archivos adjuntos por correo electrónico.

A menos y hasta que también le dé al destinatario la contraseña que necesita para desbloquear el archivo, es solo un repollo triturado para ellos.

Por supuesto, si incluye la contraseña en el cuerpo del correo electrónico, no ha ganado nada, pero si es un poco cauteloso acerca de compartir la contraseña a través de un canal diferente, se ha ganado un poco más de seguridad contra los delincuentes. , fisgones y ne'er-do-wells obteniendo fácil acceso a contenido confidencial.

OME bajo los reflectores

¿O tienes?

Según la investigadores en la empresa finlandesa de ciberseguridad WithSecure, sus datos podrían estar disfrutando de mucha menos protección de la que razonablemente podría esperar.

La función que usaron los evaluadores es a lo que se refieren como Cifrado de mensajes de Office 365o OME para abreviar.

No hemos reproducido sus experimentos aquí, por la sencilla razón de que los productos principales de Office, lo siento, 365 no se ejecutan de forma nativa en Linux, que usamos para trabajar. Las versiones basadas en la web de las herramientas de Office no tienen el mismo conjunto de funciones que las aplicaciones completas, por lo que es poco probable que los resultados que obtengamos se alineen con la forma en que la mayoría de los usuarios comerciales de Office, ah, 365 han configurado Word, Excel, Outlook. y amigos en sus portátiles con Windows.

Como lo describen los investigadores:

Esta característica se anuncia para permitir que las organizaciones envíen y reciban mensajes de correo electrónico cifrados entre personas dentro y fuera de su organización de manera segura.

Pero también señalan que:

Desafortunadamente, los mensajes OME están encriptados en el modo de operación inseguro Electronic Codebook (ECB).

BCE explicado

Para explicar.

Muchos algoritmos de cifrado, en particular el Advanced Encryption Standard o AES, que utiliza OME, son lo que se conoce como cifrados de bloque, que codifican grandes fragmentos de datos a la vez, en lugar de procesar bits o bytes individuales en secuencia.

En términos generales, se supone que esto ayuda tanto a la eficiencia como a la seguridad, porque el cifrado tiene más datos de entrada para mezclar, picar, triturar y licuar en cada giro de la manivela criptográfica que impulsa el algoritmo, y cada giro lo lleva más lejos. a través de los datos que desea cifrar.

El algoritmo central AES, por ejemplo, consume 16 bytes de texto sin formato de entrada (128 bits) a la vez y codifica esos datos bajo una clave de cifrado para producir 16 bytes de salida de texto cifrado.

(No confundir tamaño de bloque tamaño clave – Las claves de cifrado AES pueden tener una longitud de 128 bits, 192 bits o 256 bits, según la probabilidad de que no se adivinen, pero los tres tamaños de clave funcionan en bloques de 128 bits cada vez que se “arranca” el algoritmo).

Lo que esto significa es que si elige una clave AES (independientemente de la longitud) y luego usa el cifrado AES directamente en una porción de datos...

…entonces cada vez que obtenga el mismo fragmento de entrada, obtendrá el mismo fragmento de salida.

Como un libro de códigos verdaderamente masivo

Es por eso que este modo directo de operación se llama BCE, corto para libro de códigos electrónico, porque es como tener un enorme libro de códigos que podría usarse como una tabla de búsqueda para cifrar y descifrar.

(Un "libro de códigos" completo nunca podría construirse en la vida real, porque necesitaría almacenar una base de datos que consta de 2¹²⁸ Entradas de 16 bytes para cada clave posible.)

Desafortunadamente, especialmente en datos con formato de computadora, la repetición de ciertos fragmentos de datos suele ser inevitable, gracias al formato de archivo utilizado.

Por ejemplo, los archivos que rutinariamente rellenan secciones de datos para que se alineen en límites de 512 bytes (un tamaño de sector común cuando se escribe en el disco) o en límites de 4096 bytes (un tamaño de unidad de asignación común cuando se reserva memoria) a menudo producirán archivos con tiradas largas de cero bytes.

Del mismo modo, los documentos de texto que contienen muchos repetitivos, como encabezados y pies de página en cada página, o menciones repetidas del nombre completo de la empresa, contendrán muchas repeticiones.

Cada vez que un fragmento de texto sin formato repetido se alinea en un límite de 16 bytes en el proceso de cifrado AES-ECB, aparecerá en la salida cifrada. como exactamente el mismo texto cifrado.

Por lo tanto, incluso si no puede descifrar formalmente el archivo de texto cifrado, es posible que pueda hacer inferencias inmediatas que rompan la seguridad a partir de él, gracias al hecho de que los patrones en la entrada (que puede conocer, o ser capaz de inferir, o adivinar) se conservan en la salida.

Aquí hay un ejemplo basado en un artículo que publicamos hace casi nueve años cuando explicamos por qué el ahora notorio uso del cifrado en modo ECB por parte de Adobe para "descifrar" las contraseñas de sus usuarios era No es Buena idea:

Observe cómo los píxeles que son de color blanco sólido en la entrada producen un patrón repetitivo en la salida, y las partes azules permanecen algo regulares, de modo que la estructura de los datos originales es obvia.

En este ejemplo, cada píxel del archivo original ocupa exactamente 4 bytes, por lo que cada ejecución de 4 píxeles de izquierda a derecha en los datos de entrada tiene una longitud de 16 bytes, lo que se alinea exactamente con cada bloque de cifrado AES de 16 bytes, lo que acentúa el “efecto BCE”.

---

Coincidencia de patrones de texto cifrado

Peor aún, si tiene dos documentos que sabe que están encriptados con la misma clave, y resulta que tiene el texto sin formato de uno de ellos, entonces puede revisar el texto cifrado que no se puede descifrar e intentar hacer coincidir secciones con patrones en el texto cifrado que podemos descifrar.

Recuerde que no necesita la clave para "descifrar" el primer documento si ya lo tiene descifrado; esto se conoce, como era de esperar, como un ataque de texto sin formato conocido.

Incluso si solo hay unas pocas coincidencias de texto aparentemente inocente que no son datos secretos en sí mismos, el conocimiento que un adversario puede extraer de esta manera puede ser una mina de oro para espías de propiedad intelectual, ingenieros sociales, investigadores forenses y más.

Por ejemplo, incluso si no tiene idea de a qué se refieren los detalles de un documento, al hacer coincidir fragmentos de texto sin formato conocidos en varios archivos, puede determinar que una colección aparentemente aleatoria de documentos:

• Todos fueron enviados al mismo destinatario, si hay un saludo común en la parte superior de cada uno.
• Consulte el mismo proyecto, si hay una cadena de texto de identificación única que sigue apareciendo.
• Tener la misma clasificación de seguridad, si está interesado en centrarse en las cosas que claramente deben ser "más secretas" que el resto.

¿Qué hacer?

¡No utilice el modo ECB!

Si está utilizando un cifrado de bloques, elija un modo de operación de cifrado en bloque que:

• Incluye lo que se conoce como IV, o vector de inicialización, elegido al azar y de forma única para cada mensaje.
• Organiza deliberadamente el proceso de encriptación para que las entradas repetidas salgan diferentes cada vez.

Si está utilizando AES, el modo que probablemente desee elegir en estos días es AES-GCM (Modo de contador de Galois), que no solo usa un IV para crear un flujo de datos de cifrado diferente cada vez, incluso si la clave sigue siendo la misma, sino que también calcula lo que se conoce como Código de autenticación de mensajes (MAC), o suma de control criptográfica, al mismo tiempo que codifica o descifra los datos.

AES-GCM significa no solo que evita patrones repetidos de texto cifrado, sino que también siempre termina con una "suma de verificación" que le indicará si los datos que acaba de descifrar fueron manipulados en el camino.

Recuerde que un ladrón que no sabe lo que realmente significa el texto cifrado podría engañarlo para que confíe en un descifrado inexacto sin saber (o preocuparse) con qué tipo de resultado incorrecto termina.

Un MAC que se calcula durante el proceso de descifrado, basado en la misma clave e IV, le ayudará a asegurarse de que sabe que el texto cifrado que recibió es válido y, por lo tanto, es casi seguro que ha descifrado lo que se colocó originalmente en el otro extremo.

Alternativamente, utilice un dedicado cifrado de flujo que produce un flujo de claves pseudoaleatorio byte por byte que le permite cifrar datos sin tener que procesar 16 bytes (o cualquiera que sea el tamaño del bloque) a la vez.

AES-GCM esencialmente convierte AES en un cifrado de flujo y agrega autenticación en forma de MAC, pero si está buscando un cifrado de flujo dedicado diseñado específicamente para funcionar de esa manera, le sugerimos el de Daniel Bernstein. ChaCha20-Poly1305 (la parte Poly1305 es el MAC), como se detalla en RFC 8439.

A continuación, mostramos lo que obtuvimos usando AES-128-GCM y ChaCha20-Poly1305 (descartamos los códigos MAC aquí), junto con una "imagen" que consta de 95,040 bytes RGBA (330 × 72 a 4 bytes por píxel) del Generador pseudoaleatorio del kernel de Linux.

Recuerde que el hecho de que los datos parezcan no estructurados no significa que sean realmente aleatorios, pero si no parecen aleatorios, pero afirman estar cifrados, también podría suponer que queda algo de estructura y que el cifrado es sospechar:

¿Qué ocurre después?

Según WithSecure, Microsoft no planea arreglar esta “vulnerabilidad”, aparentemente por razones de retrocompatibilidad con Office 2010…

Las versiones heredadas de Office (2010) requieren AES 128 ECB, y los documentos de Office aún están protegidos de esta manera por las aplicaciones de Office.

…y…

Se consideró que el informe [de los investigadores de WithSecure] no cumplía con los requisitos para el servicio de seguridad, ni se considera una infracción. No se realizó ningún cambio de código, por lo que no se emitió CVE para este informe.

En resumen, si actualmente confía en OME, puede considerar reemplazarlo con una herramienta de cifrado de terceros para mensajes confidenciales que cifra sus datos independientemente de las aplicaciones que crearon esos mensajes y, por lo tanto, funciona independientemente del cifrado interno. código en el rango Office.

De esa forma, puede elegir un cifrado moderno y un modo moderno de operación de cifrado, sin tener que volver al código de descifrado de la vieja escuela integrado en Office 2010.

---

CÓMO CREAMOS LAS IMÁGENES DEL ARTÍCULO Comience con sop330.png, que puede crear usted mismo recortando el logotipo de SOPHOS limpio de la imagen superior, eliminando el límite azul de 2 píxeles y guardando en formato PNG.  La imagen debería terminar en un tamaño de 330x72 píxeles.
 Convierta a RGBA usando ImageMagick: $ convert sop330.png sop.rgba La salida es 330x72 píxeles x 4 bytes/píxel = 95,040 bytes.
 === Cifre usando Lua y la biblioteca LuaOSSL (Python tiene un enlace OpenSSL muy similar): -- cargar datos > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- crear objetos cifrados > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- inicializar contraseñas y IVs -- AES-128-ECB necesita una contraseña de 128 bits, pero no IV -- AES-128-GCM necesita una contraseña de 128 bits y un IV de 12 bytes -- ChaCha20 necesita una contraseña de 256 bits y un IV de 12 bytes > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- cifrar los datos del archivo con los tres cifrados > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- un cifrado de flujo produce una salida byte a byte -- por lo que el texto cifrado debe tener la misma longitud que el texto sin formato > gcmout:len() 95040 > chaout:len() 95040 -- aquí no usaremos los códigos MAC de GCM y Poly1305, -- pero cada cifrado produce una "suma de verificación" de 128 bits (16 bytes), que se usa para autenticar el descifrado una vez que finaliza, para detectar si el texto cifrado de entrada se corrompe o se piratea (el MAC depende de la clave, por lo que un el atacante no puede falsificarlo) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -- crea una "imagen" 95040 directamente desde /dev/random > rndout = misc.filetostr('/dev/random',#fdat) -- guárdelos todos - tenga en cuenta que truncamos explícitamente el AES-ECB -- bloquee la salida de cifrado a la longitud de imagen exacta requerida, porque -- ECB necesita relleno para que coincida con el tamaño de entrada con el tamaño de bloque > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === Para cargar los archivos en un visor de imágenes normal, es posible que deba convertirlos de nuevo al formato PNG sin pérdidas: $ convert - depth 8 -size 330x72 aes .rgba aes.png $ convertir -profundidad 8 -tamaño 330x72 gcm.rgba gcm.png $ convertir -profundidad 8 -tamaño 330x72 cha.rgba cha.png $ convertir -profundidad 8 -tamaño 330x72 rnd.rgba rnd.png === Dado que el proceso de cifrado codifica los cuatro bytes en cada píxel RGBA , la imagen resultante tiene una transparencia variable (A = alfa, abreviatura de transparencia).
 Su visor de imágenes puede decidir mostrar este tipo de imagen con un fondo de tablero de ajedrez, que de manera confusa parece parte de la imagen, pero no lo es.  Por lo tanto, usamos el azul de Sophos de la imagen original como fondo para los archivos cifrados para que fueran más fáciles de ver.  Por lo tanto, el tono azul general no forma parte de los datos de la imagen.