S3 Ep105 : PAS RÉPARÉ ! Le cryptofail de MS Office qui "n'est pas une faille de sécurité" [Audio + Texte]

Horodatage: 20 octobre 2022 12h54
Nœud source: 1726750

by
Paul Canard

QU'ENTENDEZ-VOUS PAR « N'ATTEINT PAS LA BARRE POUR LE SERVICE DE SÉCURITÉ » ?

Cliquez et faites glisser sur les ondes sonores ci-dessous pour passer à n'importe quel point. Vous pouvez également écouter directement sur Soundcloud.

Avec Doug Aamoth et Paul Ducklin. Musique d'intro et d'outro par Edith Mud.

Vous pouvez nous écouter sur Soundcloud, Podcasts Apple, Podcasts Google, Spotify, piqueur et partout où l'on trouve de bons podcasts. Ou déposez simplement le URL de notre flux RSS dans votre podcatcher préféré.

LIRE LA TRANSCRIPTION

DOUG.  Des failles à couper le souffle, un cryptage déchiffrable et des correctifs à gogo.

Tout cela plus sur le podcast Naked Security.

[MODÈME MUSICAL]

Bienvenue sur le podcast, tout le monde.

Je suis Doug Aamoth ; c'est Paul Ducklin.

Paul, comment allez-vous aujourd'hui, Monsieur ?

CANARD.  Doug... Je sais, parce que tu m'as dit à l'avance, ce qui va arriver Cette semaine dans l'histoire de la technologie, et c'est SUPER !

DOUG.  OK!

Cette semaine, le 18 octobre 1958, un oscilloscope et un ordinateur conçus pour simuler la résistance au vent ont été associés à des contrôleurs en aluminium personnalisés, et le jeu Tennis pour deux est né.

Présenté lors d'une exposition de trois jours au Laboratoire national de Brookhaven, Tennis for Two s'est avéré extrêmement populaire, en particulier auprès des élèves du secondaire.

Si vous écoutez ceci, vous devez aller sur Wikipédia et chercher « Tennis for Two ».

Il y a une vidéo là-bas pour quelque chose qui a été construit en 1958…

… Je pense que vous serez d'accord avec moi, Paul, c'était assez incroyable.

CANARD.  J'aimerais *adorer* y jouer aujourd'hui !

Et, comme Asteroids et Battle Zone, et ces jeux dont on se souvient spécialement des années 1980…

…parce que c'est un oscilloscope : des graphiques vectoriels !

Pas de pixellisation, pas de différences selon qu'une ligne est à 90 degrés, ou 30 degrés, ou 45 degrés.

Et le retour sonore des relais dans les manettes… c'est génial !

C'est incroyable que ce soit en 1958.

Revenant à un passé Cette semaine dans l'histoire de la technologie, c'était à l'aube de la révolution des transistors.

Apparemment, la moitié informatique était un mélange de vannes thermioniques (tubes à vide) et de relais.

Et le circuit d'affichage était entièrement basé sur des transistors, Doug

C'était donc au croisement de toutes les technologies : relais, vannes et transistors, le tout dans un jeu vidéo révolutionnaire.

DOUG.  Très sympa.

Découvrez-le sur Wikipédia : Tennis pour deux.

Passons maintenant à notre première histoire.

Paul, je sais que tu es très doué pour écrire un grand poème…

…J'ai écrit un très court poème pour introduire cette première histoire, si vous me permettez.

CANARD.  Ce sera donc deux lignes, n'est-ce pas ? [DES RIRES]

DOUG.  C'est un peu comme ça.

Zoom pour Mac/Ne comprends pas détourné.

[TRÈS LONG SILENCE]

Poème de fin.

CANARD.  Oh désolé!

Je pensais que c'était le titre, et que tu allais faire le poème maintenant.

DOUG.  Donc, c'est le poème.

CANARD.  D'ACCORD.

[SANS ÉMOTION] Charmant, Doug.

DOUG.  [IRONIQUE] Merci.

CANARD.  La rime était spectaculaire !

Mais tous les poèmes ne doivent pas rimer….

DOUG.  C'est vrai.

CANARD.  Nous l'appellerons simplement des vers libres, d'accord ?

DOUG.  Ok s'il vous plaît.

CANARD.  Malheureusement, il s'agissait d'une porte dérobée gratuite dans Zoom pour Mac.

[SE SENTIMENT COUPABLE] Désolé, ce n'était pas une très bonne suite, Doug.

[RIRES] Vous marchez sur le terrain de quelqu'un d'autre, vous échouez souvent…

DOUG.  Non c'est bon!

J'essayais des poèmes cette semaine; vous essayez des enchaînements.

Nous devons sortir de nos zones de confort de temps en temps.

CANARD.  Je suppose que c'était du code qui devait être compilé lors de la construction finale, mais qui a été accidentellement laissé dedans.

C'est uniquement pour la version Zoom pour Mac, et elle a été corrigée, alors assurez-vous d'être à jour.

Fondamentalement, dans certaines circonstances, lorsqu'un flux vidéo démarre ou que la caméra est activée par l'application elle-même, elle pense par inadvertance que vous pourriez vouloir déboguer le programme.

Parce que, hé, peut-être que vous étiez développeur ! [DES RIRES]

Ce n'est pas censé se produire dans les versions de version, évidemment.

Et cela signifiait qu'il restait un port de débogage TCP ouvert sur l'interface réseau locale.

Cela signifiait que quiconque pouvait transmettre des paquets dans ce port, qui pourrait être n'importe quel autre utilisateur connecté localement, donc il n'aurait pas besoin d'être un administrateur ou même vous… même un utilisateur invité, cela suffirait.

Ainsi, un attaquant qui avait une sorte de malware proxy sur votre ordinateur qui pourrait recevoir des paquets de l'extérieur et les injecter dans l'interface locale pourrait essentiellement envoyer des commandes aux entrailles du programme.

Et les choses typiques que les interfaces de débogage permettent incluent : vider de la mémoire ; extraire des secrets ; modifier le comportement du programme ; ajuster les paramètres de configuration sans passer par l'interface habituelle afin que l'utilisateur ne puisse pas le voir ; capturez tout l'audio sans le dire à personne, sans afficher l'avertissement d'enregistrement ; tout ce genre de choses.

La bonne nouvelle est que Zoom l'a trouvé par lui-même, et ils l'ont corrigé assez rapidement.

Mais c'est un excellent rappel que, comme nous le disons si souvent, [RIRES] "Il y a beaucoup de dérapages entre la tasse et la lèvre."

DOUG.  D'accord, très bien.

Restons à bord du patch train et arrêtons-nous à la prochaine gare.

Et cette histoire… peut-être que la partie la plus intéressante de cette histoire du dernier Patch Tuesday était ce que Microsoft *n'a pas* inclus?

CANARD.  Malheureusement, les correctifs auxquels tout le monde s'attendait probablement - et nous avons spéculé dans un podcast récent, "Eh bien, il semble que Microsoft va nous faire attendre encore une semaine jusqu'au Patch Tuesday, et ne pas faire une sortie anticipée hors bande". » sont ces deux Exchange zero-days de mémoire récente.

Ce qui est devenu connu sous le nom de E00F, ou Exchange Double faille Zero-Day dans ma terminologie, ou ProxyNotShell car il est peut-être connu de manière quelque peu confuse dans la Twittersphere.

C'était donc la grande histoire du Patch Tuesday de ce mois-ci : ces deux bogues n'ont pas été corrigés de manière spectaculaire.

Et donc nous ne savons pas quand cela va arriver.

Vous devez vous assurer que vous avez appliqué toutes les mesures d'atténuation.

Comme je pense que nous l'avons déjà dit, Microsoft a continué à trouver que les atténuations précédentes qu'ils suggéraient… eh bien, peut-être qu'elles n'étaient pas assez bonnes, et ils ont continué à changer de ton et à adapter l'histoire.

Donc, si vous avez un doute, vous pouvez retourner sur nakedsecurity.sophos.com, rechercher la phrase ProxyNotShell (un seul mot), puis allez lire ce que nous avons à dire.

Et vous pouvez également créer un lien vers la dernière version de la correction de Microsoft…

… parce que, de toutes les choses dans Patch Tuesday, c'était la plus intéressante, comme vous dites : parce qu'elle n'était pas là.

DOUG.  OK, passons maintenant à la vitesse supérieure histoire très frustrante.

C'est une tape sur les doigts pour une grande entreprise dont la cybersécurité est si mauvaise qu'elle n'a même pas remarqué qu'elle avait été piratée !

CANARD.  Oui, c'est une marque que la plupart des gens connaîtront probablement sous le nom de SHEIN ("she-in"), écrit en un seul mot, tout en majuscules. (Au moment de la violation, la société était connue sous le nom de Zoetop.)

Et c'est ce qu'on appelle la « fast fashion ».

Vous savez, ils l'empilent et le vendent à bas prix, et non sans controverse sur l'origine de leurs créations.

Et, en tant que détaillant en ligne, vous vous attendriez peut-être à ce qu'ils aient les détails de la cybersécurité de la vente au détail en ligne.

Mais, comme vous le dites, ils ne l'ont pas fait !

Et le bureau du procureur général de l'État de New York aux États-Unis a décidé qu'il n'était pas satisfait de la manière dont les résidents de New York avaient été traités qui figuraient parmi les victimes de cette violation.

Ils ont donc intenté une action en justice contre cette société… et ce fut une litanie absolue de gaffes, d'erreurs et finalement de dissimulations - en un mot, Douglas, de la malhonnêteté.

Ils ont eu cette brèche qu'ils n'ont pas remarquée.

Cela, du moins dans le passé, était malheureusement courant : les entreprises ne réalisaient pas qu'elles avaient été piratées jusqu'à ce qu'un gestionnaire de carte de crédit ou une banque les contacte et leur dise : « Vous savez quoi, nous avons eu énormément de de plaintes pour fraude de clients ce mois-ci.

"Et quand nous avons regardé en arrière ce qu'ils appellent le RPC, le point d'achat commun, le seul et unique marchand auprès duquel chaque victime semble avoir acheté quelque chose, c'est vous. Nous estimons que la fuite vient de vous.

Et dans ce cas, c'était encore pire.

Apparemment, un autre processeur de paiement est arrivé et a dit: "Oh, au fait, nous avons trouvé toute une tranche de numéros de carte de crédit à vendre, proposés comme volés à vous les gars."

Ils avaient donc des preuves claires qu'il y avait eu soit une brèche massive, soit une brèche petit à petit.

DOUG.  Alors sûrement, lorsque cette entreprise a été mise au courant de cela, elle a agi rapidement pour rectifier la situation, n'est-ce pas ?

CANARD.  Eh bien, cela dépend de la façon dont vous… [RIRE] Je ne devrais pas rire, Doug, comme toujours.

Cela dépend de ce que vous entendez par « rectifier ».

DOUG.  [RIANT] Oh, mon Dieu !

CANARD.  Il semble donc qu'ils * aient * traité le problème… en effet, il y avait des parties qu'ils ont très bien dissimulées.

Apparemment.

Il semble qu'ils aient soudainement décidé : « Oups, nous ferions mieux de nous conformer à la norme PCI DSS ».

De toute évidence, ils ne l'étaient pas, car ils avaient apparemment conservé des journaux de débogage contenant les détails des cartes de crédit des transactions échouées… tout ce que vous n'êtes pas censé écrire sur le disque, ils l'écrivaient.

Et puis ils ont réalisé que c'était arrivé, mais ils ne pouvaient pas trouver où ils avaient laissé ces données dans leur propre réseau !

Donc, évidemment, ils savaient qu'ils n'étaient pas conformes à la norme PCI DSS.

Ils ont entrepris de se rendre conformes à la norme PCI DSS, apparemment, ce qu'ils ont réalisé d'ici 2019. (La violation s'est produite en 2018.)

Mais quand on leur a dit qu'ils devaient se soumettre à un audit, une enquête médico-légale…

… selon le procureur général de New York, ils ont délibérément gêné l'enquêteur.

Ils ont essentiellement permis aux enquêteurs de voir le système tel qu'il était * après * l'avoir réparé, soudé et poli, et ils ont dit: "Oh non, vous ne pouvez pas voir les sauvegardes", ce qui me semble plutôt méchant. .

DOUG.  Uh-huh.

CANARD.  De plus, la façon dont ils ont divulgué la violation à leurs clients a suscité une colère importante de la part de l'État de New York.

En particulier, il semble qu'il était assez évident que les détails de 39,000,000 5 XNUMX d'utilisateurs avaient d'une manière ou d'une autre été falsifiés, y compris des mots de passe très faiblement hachés : un sel à deux chiffres et un tour de MDXNUMX.

Pas assez bien en 1998, encore moins 2018 !

Ils savaient donc qu'il y avait un problème pour ce grand nombre d'utilisateurs, mais apparemment ils n'ont commencé à contacter que les 6,000,000 XNUMX XNUMX de ces utilisateurs qui avaient effectivement utilisé leurs comptes et passé des commandes.

Et puis ils ont dit: "Eh bien, nous avons au moins contacté toutes ces personnes."

Et *puis* il s'est avéré qu'ils n'avaient pas vraiment contacté les 6,000,000 XNUMX XNUMX millions d'utilisateurs !

Ils venaient de contacter ceux des six millions qui vivaient au Canada, aux États-Unis ou en Europe.

Donc, si vous venez de n'importe où ailleurs dans le monde, pas de chance !

Comme vous pouvez l'imaginer, cela n'a pas été bien accueilli par les autorités, par le régulateur.

Et, je dois admettre… à ma grande surprise, Doug, ils ont été condamnés à une amende de 1.9 million de dollars.

Ce qui, pour une entreprise aussi grande…

DOUG.  Oui!

CANARD.  … et faire des erreurs aussi flagrantes, puis ne pas être entièrement décent et honnête sur ce qui s'était passé, et se faire reprocher d'avoir menti au sujet de la violation, en ces termes, par le procureur général de New York ?

J'imaginais un peu qu'ils auraient pu subir un sort plus grave.

Peut-être même inclure quelque chose qui ne pouvait pas être simplement payé en apportant de l'argent.

Oh, et l'autre chose qu'ils ont faite, c'est que lorsqu'il était évident qu'il y avait des utilisateurs dont les mots de passe étaient à risque… parce qu'ils étaient profondément cassables en raison du fait qu'il s'agissait d'un sel à deux chiffres, ce qui signifie que vous pourriez créer 100 dictionnaires précalculés …

DOUG.  Est-ce commun?

Juste un sel à deux chiffres semble vraiment bas !

CANARD.  Non, vous voudriez généralement 128 bits (16 octets), voire 32 octets.

En gros, cela ne fait de toute façon pas de différence significative dans la vitesse de craquage, car (selon la taille de bloc du hachage), vous n'ajoutez que deux chiffres supplémentaires dans le mélange.

Ce n'est même pas comme si le calcul réel des hachages prenait plus de temps.

Dès 2016, les personnes utilisant des ordinateurs de huit GPU exécutant le programme "hashcat", je pense, pouvaient faire 200 milliards de MD5 par seconde.

À l'époque! (Ce montant est quelque chose comme cinq ou dix fois plus élevé maintenant.)

Donc très, très éminemment craquable.

Mais plutôt que de contacter les gens et de dire : "Votre mot de passe est en danger parce que nous avons divulgué le hachage, et ce n'était pas un très bon, vous devriez le changer", [RIRES] ils ont juste dit…

…c'étaient des mots très fous, n'est-ce pas ?

DOUG.  "Votre mot de passe a un niveau de sécurité faible et peut-être à risque. Veuillez changer votre mot de passe de connexion.

Et puis ils l'ont changé en "Votre mot de passe n'a pas été mis à jour depuis plus de 365 jours. Pour votre protection, veuillez le mettre à jour maintenant.

CANARD.  Oui, "Votre mot de passe a un niveau de sécurité faible…"

DOUG.  "À CAUSE DE NOUS!"

CANARD.  Ce n'est pas seulement de la condescendance, n'est-ce pas ?

C'est à ou au-delà de la frontière dans le blâme de la victime, à mes yeux.

Quoi qu'il en soit, cela ne m'a pas semblé être une incitation très forte pour les entreprises qui ne veulent pas faire ce qu'il faut.

DOUG.  D'accord, exprimez-vous dans les commentaires, nous aimerions savoir ce que vous en pensez !

Cet article s'intitule : La marque de mode SHEIN condamnée à une amende de 1.9 million de dollars pour avoir menti sur une violation de données.

Et sur une autre histoire frustrante…

..,un autre jour, un autre récit édifiant sur le traitement des entrées non fiables !

CANARD.  Aaargh, je sais ce que ça va être, Doug.

C'est le Texte Apache Commons bogue, n'est-ce pas?

DOUG.  Il est!

CANARD.  Juste pour être clair, ce n'est pas le serveur Web Apache.

Apache est une fondation logicielle qui propose toute une série de produits et d'outils gratuits… et ils sont vraiment très utiles, et ils sont open source, et ils sont géniaux.

Mais nous avons eu, dans la partie Java de leur écosystème (le serveur Web Apache httpd n'est pas écrit en Java, alors ignorons cela pour l'instant - ne confondez pas Apache avec Apache Web Server)…

… l'année dernière, nous avons eu trois problèmes similaires dans les bibliothèques Java d'Apache.

Nous avons eu le infâme Log4Shell bug dans la bibliothèque dite Log4J (Logging for Java).

Ensuite, nous avons eu un bug similaire, qu'est-ce que c'était?… Configuration d'Apache Commons, qui est une boîte à outils pour gérer toutes sortes de fichiers de configuration, par exemple des fichiers INI et des fichiers XML, le tout de manière standardisée.

Et maintenant, dans une bibliothèque de niveau encore inférieur appelée Texte Apache Commons.

Le bogue dans la chose qui en Java est généralement connue sous le nom d'"interpolation de chaîne".

Programmeurs dans d'autres langages… si vous utilisez des choses comme PowerShell ou Bash, vous le saurez comme "substitution de chaîne".

C'est là que vous pouvez transformer comme par magie une phrase pleine de caractères en une sorte de mini-programme.

Si vous avez déjà utilisé le shell Bash, vous saurez que si vous tapez la commande echo USER, il fera écho ou imprimera la chaîne USER et vous verrez, sur l'écran USER.

Mais si vous lancez la commande echo $USER, cela ne signifie pas faire écho à un signe dollar suivi de USER.

Cela signifie "Remplacez cette chaîne magique par le nom de l'utilisateur actuellement connecté et imprimez-le à la place."

Donc sur mon ordinateur, si vous echo USER, vous recevez USER, mais si tu echo $USER, vous obtenez le mot duck à la place.

Et certaines des substitutions de chaînes Java vont beaucoup, beaucoup, beaucoup plus loin que cela… comme quiconque a souffert la joie de réparer Log4Shell plus de Noël 2021 s'en souviendra!

Il existe toutes sortes de petits mini-programmes intelligents que vous pouvez intégrer dans des chaînes que vous traitez ensuite avec cette bibliothèque de traitement de chaînes.

Alors il y a l'évidence : pour lire le nom d'utilisateur, vous mettez ${env: (pour "lire l'environnement") user}… vous utilisez des crochets ondulés.

C'est le signe dollar ; support ondulé; une commande magique; support ondulé qui est la partie magique.

Et malheureusement, dans cette bibliothèque, il y avait une disponibilité par défaut incontrôlée de commandes magiques comme : ${url:...}, qui vous permet d'inciter la bibliothèque de traitement de chaînes à accéder à Internet, à télécharger quelque chose et à imprimer ce qu'elle récupère de ce serveur Web au lieu de la chaîne ${url:...}.

Donc, bien que ce ne soit pas tout à fait de l'injection de code, car il ne s'agit que de HTML brut, cela signifie toujours que vous pouvez mettre toutes sortes de déchets et de choses étranges et merveilleuses non fiables dans les fichiers journaux des utilisateurs ou leurs pages Web.

Il ya ${dns:...}, ce qui signifie que vous pouvez tromper le serveur de quelqu'un, qui pourrait être un serveur de logique métier à l'intérieur du réseau…

… vous pouvez le tromper en faisant une recherche DNS pour un serveur nommé.

Et si vous possédez ce domaine, en tant qu'escroc, vous possédez et exploitez également le serveur DNS qui se rapporte à ce domaine.

Alors, quand la recherche DNS se produit, devinez quoi ?

Cette recherche se termine * sur votre serveur * et peut vous aider à cartographier les entrailles du réseau d'entreprise de quelqu'un… pas seulement son serveur Web, mais des choses plus profondes dans le réseau.

Et enfin, et le plus inquiétant, au moins avec les anciennes versions de Java, il y avait… [RIRES] tu sais ce qui s'en vient ici, Doug !

La commande ${script:...}.

"Hé, laissez-moi vous fournir du JavaScript et veuillez l'exécuter pour moi."

Et vous pensez probablement, "Quoi ?! Attendez, c'est un bug de Java. Qu'est-ce que JavaScript a à voir avec ça ?

Eh bien, jusqu'à relativement récemment… et rappelez-vous, de nombreuses entreprises utilisent encore des versions plus anciennes et toujours prises en charge du kit de développement Java.

Jusqu'à récemment, Java… [RIRES] (encore une fois, je ne devrais pas rire)… le kit de développement Java contenait, à l'intérieur de lui-même, un moteur JavaScript complet et fonctionnel, écrit en Java.

Maintenant, il n'y a aucune relation entre Java et JavaScript à l'exception des quatre lettres "Java", mais vous pouvez mettre ${script:javascript:...}et exécutez le code de votre choix.

Et, agaçant, l'une des choses que vous pouvez faire dans le moteur JavaScript à l'intérieur de l'environnement d'exécution Java est de dire au moteur JavaScript : "Hé, je veux exécuter ce truc via Java".

Ainsi, vous pouvez faire en sorte que Java appelle *into* JavaScript, et JavaScript essentiellement appelle *out* dans Java.

Et puis, à partir de Java, vous pouvez dire "Hey, lancez cette commande système".

Et si vous allez à l'article de Naked Security, vous me verrez utiliser une commande suspecte pour [TOUSSE PAR EXCLUSION] faire éclater un calcul, Doug !

Une calculatrice HP RPN, bien sûr, parce que c'est moi qui fais sauter la calculatrice…

DOUG.  Ça doit être, oui !

CANARD.  … celui-ci est un HP-10.

Ainsi, même si le risque n'est pas aussi génial comme Log4Shell, vous ne pouvez pas vraiment l'exclure si vous utilisez cette bibliothèque.

Nous avons quelques instructions dans l'article Naked Security sur la façon de savoir si vous avez la bibliothèque Commons Text… et vous pourriez l'avoir, comme beaucoup de gens l'ont fait avec Log4J, sans s'en rendre compte, car il peut être accompagné d'une application.

Et nous avons également un exemple de code que vous pouvez utiliser pour tester si les mesures d'atténuation que vous avez mises en place ont fonctionné.

DOUG.  Très bien, rendez-vous à Naked Security.

Cet article s'intitule : Trou dangereux dans Apache Commons Text - comme Log4Shell encore une fois.

Et nous terminons par une question : "Que se passe-t-il lorsque les messages cryptés ne sont qu'un peu cryptés ?"

CANARD.  Ah, vous faites référence à ce qui était, je suppose, un rapport de bogue officiel déposé récemment par des chercheurs en cybersécurité de la société finlandaise WithSecure…

… à propos du cryptage intégré proposé dans Microsoft Office, ou plus précisément, une fonctionnalité appelée Office 365 Message Encryption ou OME.

C'est très pratique d'avoir une petite fonctionnalité comme celle-ci intégrée à l'application.

DOUG.  Oui, cela semble simple et pratique !

CANARD.  Oui, sauf… oh, mon Dieu !

Il semble que la raison de tout cela soit due à la rétrocompatibilité, Doug…

… que Microsoft souhaite que cette fonctionnalité fonctionne jusqu'aux personnes qui utilisent encore Office 2010, qui intègre des capacités de décryptage plutôt à l'ancienne.

Fondamentalement, il semble que ce processus OME de cryptage du fichier utilise AES, qui est le dernier et le plus grand algorithme de cryptage normalisé par le NIST.

Mais il utilise AES dans le mauvais mode dit de cryptage.

Il utilise ce qu'on appelle ECB, ou livre de code électronique mode.

Et c'est simplement la façon dont vous vous référez à l'AES brut.

AES crypte 16 octets à la fois… soit dit en passant, il crypte 16 octets que vous utilisiez AES-128, AES-192 ou AES-256.

Ne confondez pas la taille du bloc et la taille de la clé - la taille du bloc, le nombre d'octets qui sont mélangés et chiffrés chaque fois que vous tournez la manivelle du moteur de chiffrement, est toujours de 128 bis ou 16 octets.

Quoi qu'il en soit, en mode livre de codes électronique, vous prenez simplement 16 octets d'entrée, tournez la manivelle une fois sous une clé de cryptage donnée et prenez la sortie, brute et non retraitée.

Et le problème avec cela est que chaque fois que vous obtenez la même entrée dans un document aligné sur la même limite de 16 octets…

… vous obtenez exactement les mêmes données dans la sortie.

Ainsi, les modèles de l'entrée sont révélés dans la sortie, tout comme ils le sont dans un César chiffre ou un Vigenère chiffrer:

Maintenant, cela ne signifie pas que vous pouvez déchiffrer le chiffrement, car vous avez toujours affaire à des morceaux de 128 bits de large à la fois.

Le problème avec le mode livre de code électronique se pose précisément parce qu'il fait passer des modèles du texte en clair dans le texte chiffré.

Les attaques de texte en clair connues sont possibles lorsque vous savez qu'une chaîne d'entrée particulière est chiffrée d'une certaine manière, et pour le texte répété dans un document (comme un en-tête ou un nom de société), ces modèles sont reflétés.

Et bien que cela ait été signalé comme un bogue à Microsoft, apparemment, la société a décidé de ne pas le corriger car il « ne respecte pas la barre » pour un correctif de sécurité.

Et il semble que la raison en soit : "Eh bien, nous rendrions un mauvais service aux personnes qui utilisent encore Office 2010".

DOUG.  Ouf !

CANARD.  Oui!

DOUG.  Et sur cette note, nous avons un commentaire de lecteur pour cette semaine sur cette histoire.

Naked Security Reader Bill commente, en partie :

Cela me rappelle les «cribs» que les décrypteurs de Bletchley Park utilisaient pendant la Seconde Guerre mondiale. Les nazis terminaient souvent les messages avec la même phrase finale, et ainsi les briseurs de code pouvaient travailler à partir de cet ensemble final de caractères cryptés, sachant ce qu'ils représentaient probablement. Il est décevant que 80 ans plus tard, nous semblions répéter les mêmes erreurs.

CANARD.  80 années!

Oui, c'est vraiment décevant.

Ma compréhension est que d'autres crèches que les briseurs de code alliés pourraient utiliser, en particulier pour les textes chiffrés par les nazis, traitaient également du * début * du document.

Je crois que c'était une chose pour les bulletins météorologiques allemands… il y avait un format religieux qu'ils suivaient pour s'assurer qu'ils donnaient exactement les bulletins météorologiques.

Et les bulletins météorologiques, comme vous pouvez l'imaginer, pendant une guerre qui implique des bombardements aériens la nuit, étaient des choses vraiment importantes !

Il semble que ceux-ci suivaient un modèle très, très strict qui pourrait, à l'occasion, être utilisé comme ce que vous pourriez appeler un peu un "relâcheur" cryptographique, ou un coin que vous pourriez utiliser pour vous introduire en premier lieu.

Et cela, comme le souligne Bill… c'est exactement pourquoi AES, ou n'importe quel chiffrement, en mode livre de codes électronique n'est pas satisfaisant pour chiffrer des documents entiers !

DOUG.  D'accord, merci d'avoir envoyé ça, Bill.

Si vous avez une histoire intéressante, un commentaire ou une question que vous aimeriez soumettre, nous serions ravis de le lire sur le podcast.

Vous pouvez envoyer un e-mail à tips@sophos.com, commenter n'importe lequel de nos articles ou nous contacter sur les réseaux sociaux : @nakedsecurity.

C'est notre émission d'aujourd'hui; merci beaucoup pour votre écoute.

Pour Paul Ducklin, je suis Doug Aamoth, je vous rappelle jusqu'à la prochaine fois pour…

TOUS LES DEUX.  Restez en sécurité!

Horodatage:

Plus de Sécurité nue