Sécurité sérieuse : Microsoft Office 365 attaqué pour un cryptage faible

Nous ne savons pas trop comment l'appeler pour le moment, nous y avons donc fait référence dans le titre par le nom hybride Microsoft Office 365.

(Le nom "Office" en tant que nom collectif pour les applications de traitement de texte, de feuille de calcul, de présentation et de collaboration de Microsoft est en train d'être tué au cours des deux prochains mois, pour devenir simplement "Microsoft 365".)

Nous sommes sûrs que les gens continueront à utiliser les noms d'applications individuels (Word, Excel, PowerPoint et amis) et le surnom de la suite Bureaux pendant de nombreuses années, même si les nouveaux venus dans le logiciel finiront probablement par le connaître comme 365, après avoir supprimé le préfixe Microsoft omniprésent.

Comme vous le savez peut-être, les applications autonomes Office (celles que vous installez localement pour que vous n'ayez pas à vous connecter en ligne pour travailler sur vos affaires) incluent leur propre option pour chiffrer les documents enregistrés.

Ceci est censé ajouter une couche de sécurité supplémentaire au cas où vous partageriez ultérieurement l'un de ces fichiers, par accident ou par conception, avec quelqu'un qui n'était pas censé les recevoir - ce qui est étonnamment facile à faire par erreur lors du partage de pièces jointes par e-mail.

À moins que et jusqu'à ce que vous donniez également au destinataire le mot de passe dont il a besoin pour déverrouiller le fichier, c'est tellement de chou déchiqueté pour lui.

Bien sûr, si vous incluez le mot de passe dans le corps de l'e-mail, vous n'avez rien gagné, mais si vous êtes même un peu prudent quant au partage du mot de passe via un autre canal, vous vous êtes procuré une sécurité supplémentaire contre les voleurs. , les fouineurs et les vauriens obtiennent un accès facile à du contenu confidentiel.

L'OME sous les projecteurs

Ou avez-vous?

Selon chercheurs chez la société finlandaise de cybersécurité WithSecure, vos données pourraient bénéficier d'une protection bien moindre que ce à quoi vous pourriez raisonnablement vous attendre.

La fonctionnalité utilisée par les testeurs est ce qu'ils appellent Chiffrement des messages Office 365ou OME pour faire court.

Nous n'avons pas reproduit leurs expériences ici, pour la simple raison que les produits Office de base, désolé, 365 ne fonctionnent pas nativement sur Linux, que nous utilisons pour le travail. Les versions Web des outils Office n'ont pas le même ensemble de fonctionnalités que les applications complètes, de sorte que les résultats que nous pourrions obtenir ne correspondront probablement pas à la façon dont la plupart des utilisateurs professionnels d'Office, ah, 365 ont configuré Word, Excel, Outlook et amis sur leurs ordinateurs portables Windows.

Comme le décrivent les chercheurs :

Cette fonctionnalité est annoncée pour permettre aux organisations d'envoyer et de recevoir des messages électroniques chiffrés entre des personnes à l'intérieur et à l'extérieur de votre organisation de manière sécurisée.

Mais ils précisent aussi que :

Malheureusement, les messages OME sont cryptés en mode de fonctionnement ECB (Electronic Codebook) non sécurisé.

La BCE expliquée

Expliquer.

De nombreux algorithmes de chiffrement, notamment le Advanced Encryption Standard ou AES, que OME utilise, sont ce qu'on appelle chiffrements par bloc, qui brouillent de gros morceaux de données à la fois, plutôt que de traiter des bits ou des octets individuels en séquence.

D'une manière générale, cela est censé contribuer à la fois à l'efficacité et à la sécurité, car le chiffrement a plus de données d'entrée à mélanger, hacher, déchiqueter et liquéfier à chaque tour de la manivelle cryptographique qui pilote l'algorithme, et chaque tour vous amène plus loin à travers les données que vous souhaitez chiffrer.

L'algorithme principal AES, par exemple, consomme 16 octets de texte en clair d'entrée (128 bits) à la fois et brouille ces données sous une clé de cryptage pour produire 16 octets de sortie de texte chiffré cryptés.

(Ne pas confondre taille de bloc comprenant taille de clé – Les clés de cryptage AES peuvent avoir une longueur de 128 bits, 192 bits ou 256 bits, selon la probabilité que vous souhaitiez qu'elles soient devinées, mais les trois tailles de clé fonctionnent sur des blocs de 128 bits chaque fois que l'algorithme est « lancé ».)

Cela signifie que si vous choisissez une clé AES (quelle que soit sa longueur), puis utilisez le chiffrement AES directement sur un bloc de données…

…puis chaque fois que vous obtenez le même bloc d'entrée, vous obtenez le même bloc de sortie.

Comme un livre de codes vraiment massif

C'est pourquoi ce mode de fonctionnement direct est appelé BCE, court pour livre de code électronique, parce que c'est un peu comme avoir un énorme livre de codes qui pourrait être utilisé comme table de consultation pour chiffrer et déchiffrer.

(Un "livre de codes" complet ne pourrait jamais être construit dans la vraie vie, car vous auriez besoin de stocker une base de données composée de 2¹²⁸ Entrées de 16 octets pour chaque clé possible.)

Malheureusement, en particulier dans les données au format informatique, la répétition de certains morceaux de données est souvent inévitable, grâce au format de fichier utilisé.

Par exemple, les fichiers qui remplissent régulièrement des sections de données afin qu'ils s'alignent sur des limites de 512 octets (une taille de secteur commune lors de l'écriture sur le disque) ou sur des limites de 4096 octets (une taille d'unité d'allocation commune lors de la réservation de mémoire) produiront souvent des fichiers avec longues séries de zéro octet.

De même, les documents texte qui contiennent beaucoup de passe-partout, tels que les en-têtes et les pieds de page sur chaque page, ou la mention répétée du nom complet de l'entreprise, contiendront de nombreuses répétitions.

Chaque fois qu'un morceau de texte en clair répété s'aligne sur une limite de 16 octets dans le processus de cryptage AES-ECB, il apparaîtra donc dans la sortie cryptée comme exactement le même texte chiffré.

Ainsi, même si vous ne pouvez pas déchiffrer formellement le fichier de texte chiffré, vous pourrez peut-être en tirer des conclusions immédiates et destructrices de sécurité, grâce au fait que les modèles dans l'entrée (que vous connaissez peut-être ou que vous pouvez déduire, ou à deviner) sont conservés dans la sortie.

Voici un exemple basé sur un article que nous avons publié il y a près de neuf ans lorsque nous expliquions pourquoi l'utilisation désormais notoire par Adobe du chiffrement en mode ECB pour "hacher" les mots de passe de ses utilisateurs était Pas une bonne idée:

Notez comment les pixels qui sont d'un blanc uni dans l'entrée produisent de manière fiable un motif répétitif dans la sortie, et les parties bleues restent quelque peu régulières, de sorte que la structure des données d'origine est évidente.

Dans cet exemple, chaque pixel du fichier d'origine occupe exactement 4 octets, de sorte que chaque exécution de 4 pixels de gauche à droite dans les données d'entrée a une longueur de 16 octets, ce qui s'aligne exactement sur chaque bloc de cryptage AES de 16 octets, accentuant ainsi l'« effet BCE ».

---

Modèles de texte chiffré correspondants

Pire encore, si vous avez deux documents dont vous savez qu'ils sont cryptés avec la même clé et que vous avez le texte en clair de l'un d'eux, vous pouvez parcourir le texte chiffré que vous ne peut pas déchiffrer et essayez d'en faire correspondre des sections avec des modèles dans le texte chiffré que vous vous décrypter.

N'oubliez pas que vous n'avez pas besoin de la clé pour "déchiffrer" le premier document si vous l'avez déjà sous forme déchiffrée - ceci est connu, sans surprise, comme un attaque en clair connu.

Même s'il n'y a que quelques correspondances de textes apparemment innocents qui ne sont pas eux-mêmes des données secrètes, les connaissances qu'un adversaire peut extraire de cette manière peuvent être une mine d'or pour les espions de la propriété intellectuelle, les ingénieurs sociaux, les enquêteurs médico-légaux, etc.

Par exemple, même si vous n'avez aucune idée de ce à quoi les détails d'un document font référence, en faisant correspondre des morceaux de texte en clair connus dans plusieurs fichiers, vous pourrez peut-être déterminer qu'une collection apparemment aléatoire de documents :

• ont tous été envoyés au même destinataire, s'il y a une salutation commune en haut de chacun.
• Reportez-vous au même projet, s'il y a une chaîne de texte d'identification unique qui continue d'apparaître.
• Avoir la même classification de sécurité, si vous tenez à vous concentrer sur les choses qui sont clairement censées être "plus secrètes" que les autres.

Que faire?

N'utilisez pas le mode ECB !

Si vous utilisez un chiffrement par blocs, choisissez un mode de fonctionnement du chiffrement par blocs que:

• Comprend ce qu'on appelle un IV, ou vecteur d'initialisation, choisi de manière aléatoire et unique pour chaque message.
• Organise délibérément le processus de cryptage de sorte que les entrées répétées sortent différemment à chaque fois.

Si vous utilisez AES, le mode que vous souhaitez probablement choisir ces jours-ci est AES-GCM (Galois Counter Mode), qui non seulement utilise un IV pour créer un flux de données de cryptage différent à chaque fois, même si la clé reste la même, mais calcule également ce qu'on appelle un Code d'authentification des messages (MAC), ou somme de contrôle cryptographique, en même temps que le brouillage ou le décryptage des données.

AES-GCM signifie non seulement que vous évitez les modèles de texte chiffré répétés, mais aussi que vous vous retrouvez toujours avec une "somme de contrôle" qui vous dira si les données que vous venez de déchiffrer ont été falsifiées en cours de route.

N'oubliez pas qu'un escroc qui ne sait pas ce que signifie réellement le texte chiffré pourrait néanmoins être en mesure de vous inciter à faire confiance à un déchiffrement inexact sans jamais savoir (ou se soucier) du type de sortie incorrecte que vous obtenez.

Un MAC qui est calculé pendant le processus de déchiffrement, basé sur la même clé et IV, vous aidera à vous assurer que vous savez que le texte chiffré que vous avez reçu est valide, et donc que vous avez presque certainement déchiffré ce qui a été initialement mis à l'autre extrémité.

Sinon, utilisez un chiffrement de flux qui produit un flux de clés pseudo-aléatoire octet par octet qui vous permet de chiffrer des données sans avoir à traiter 16 octets (ou quelle que soit la taille de bloc) à la fois.

AES-GCM convertit essentiellement AES en un chiffrement de flux et ajoute une authentification sous la forme d'un MAC, mais si vous recherchez un chiffrement de flux dédié conçu spécifiquement pour fonctionner de cette façon, nous suggérons celui de Daniel Bernstein. ChaCha20-Poly1305 (la partie Poly1305 est le MAC), comme détaillé dans RFC 8439.

Ci-dessous, nous avons montré ce que nous avons obtenu en utilisant AES-128-GCM et ChaCha20-Poly1305 (nous avons ignoré les codes MAC ici), ainsi qu'une "image" composée de 95,040 330 octets RGBA (72 × 4 à XNUMX octets par pixel) du Générateur pseudo-aléatoire du noyau Linux.

N'oubliez pas que ce n'est pas parce que les données semblent non structurées qu'elles sont vraiment aléatoires, mais si elles ne semblent pas aléatoires, mais qu'elles prétendent être cryptées, vous pouvez aussi bien supposer qu'il reste une structure et que le cryptage est suspect:

Qu'est-ce qui se passe ensuite?

Selon WithSecure, Microsoft ne prévoit pas de corriger cette « vulnérabilité », apparemment pour des raisons de rétrocompatibilité avec Office 2010…

Les anciennes versions d'Office (2010) nécessitent AES 128 ECB, et les documents Office sont toujours protégés de cette manière par les applications Office.

…et…

Le rapport [des chercheurs de WithSecure] n'a pas été considéré comme répondant à la barre des services de sécurité, ni comme une violation. Aucun changement de code n'a été effectué et donc aucun CVE n'a été émis pour ce rapport.

En bref, si vous comptez actuellement sur OME, vous pouvez envisager de le remplacer par un outil de chiffrement tiers pour les messages sensibles qui chiffre vos données indépendamment des applications qui ont créé ces messages, et fonctionne donc indépendamment du chiffrement interne. code dans la gamme Office.

De cette façon, vous pouvez choisir un chiffrement moderne et un mode de fonctionnement de chiffrement moderne, sans avoir à revenir au code de déchiffrement à l'ancienne intégré à Office 2010.

---

COMMENT NOUS AVONS CRÉÉ LES IMAGES DANS L'ARTICLE Commencez par sop330.png, que vous pouvez créer vous-même en recadrant le logo SOPHOS nettoyé de l'image la plus haute, en supprimant la bordure bleue de 2 pixels et en l'enregistrant au format PNG.  L'image devrait finir à 330x72 pixels.
 Convertir en RGBA en utilisant ImageMagick : $ convert sop330.png sop.rgba La sortie est de 330x72 pixels x 4 octets/pixel = 95,040 XNUMX octets.
 === Crypter en utilisant Lua et la bibliothèque LuaOSSL (Python a une liaison OpenSSL très similaire) : -- charger les données > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- créer des objets de chiffrement > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- initialiser les mots de passe et les IV -- AES-128-ECB a besoin d'un mot de passe de 128 bits, mais pas d'IV -- AES-128-GCM a besoin d'un mot de passe de 128 bits et d'un IV de 12 octets -- ChaCha20 a besoin d'un mot de passe de 256 bits et un IV de 12 octets > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- chiffre les données du fichier avec les trois chiffres > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- un chiffrement de flux produit une sortie octet par octet, -- donc le texte chiffré doit avoir la même longueur que le texte en clair > gcmout:len() 95040 > chaout:len() 95040 -- nous n'utiliserons pas les codes MAC de GCM et Poly1305 ici, -- mais chaque chiffre produit une "somme de contrôle" de 128 bits (16 octets) -- utilisée pour authentifier le déchiffrement une fois qu'il est terminé, -- pour détecter si le texte chiffré d'entrée est corrompu ou piraté -- (le MAC dépend de la clé, donc un l'attaquant ne peut pas le falsifier) ​​> base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -- créer une "image" 95040 directement depuis /dev/random > rndout = misc.filetostr('/dev/random',#fdat) -- enregistrez-les tous - notez que nous tronquons explicitement la sortie de chiffrement par bloc AES-ECB à la longueur d'image exacte requise, car -- ECB a besoin d'un rembourrage pour correspondre à la taille d'entrée avec la taille du bloc > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === Pour charger les fichiers dans une visionneuse d'images standard, vous devrez peut-être les reconvertir sans perte au format PNG : $ convert -depth 8 -size 330x72 aes .rgba aes.png $ convertir -profondeur 8 -taille 330x72 gcm.rgba gcm.png $ convert -depth 8 -size 330x72 cha.rgba cha.png $ convert -depth 8 -size 330x72 rnd.rgba rnd.png === Étant donné que le processus de cryptage brouille les quatre octets dans chaque pixel RGBA , l'image résultante a une transparence variable (A = alpha, abréviation de transparence).
 Votre visionneuse d'images peut décider d'afficher ce type d'image avec un arrière-plan en damier, qui ressemble de manière confuse à une partie de l'image, mais qui n'en est pas.  Nous avons donc utilisé le bleu Sophos de l'image d'origine comme arrière-plan pour les fichiers chiffrés afin de faciliter leur visualisation.  La teinte bleue globale ne fait donc pas partie des données d'image.