Déchiffrement d’un ZIP vieux de 30 ans pour révéler le code secret de chiffrement de l’ANC « Operation Vula »

 (blog.jgc.org)
2 points par GN⁺ 2024-09-08 | 1 commentaires | Partager sur WhatsApp
  • Le ZIP du code source de l’ANC Operation Vula, conservé chiffré depuis 1991, a été déchiffré, rendant possible la publication d’un code de communication secret utilisé contre le régime d’apartheid en Afrique du Sud
  • Ce code avait servi à la fin des années 1980 à bâtir le réseau clandestin intérieur de l’ANC en Afrique du Sud, en utilisant des ordinateurs 8 bits, des tonalités DTMF, des coupleurs acoustiques et PowerBASIC pour échanger des messages chiffrés par masque jetable
  • Le ZipCrypto des premières versions de PKZIP était vulnérable aux attaques par texte en clair connu, et bkcrack a permis de retrouver la clé à partir de 12 octets de texte prévisible dans le ZIP
  • L’attaque s’est appuyée sur une entrée Store non compressée dans ALLBAS.ZIP, l’en-tête PK d’un ZIP interne et le premier nom de fichier COMKEY.BAS, ce qui a permis d’obtenir après 23 minutes les clés 98e0f009 48a0b11a c70f8499
  • Les fichiers déchiffrés RANDOM.BAS et TECOD.BAS ont ensuite été compilés et exécutés dans DOSBox, confirmant la génération de données aléatoires, le chiffrement et déchiffrement de fichiers, l’usage d’un disque RAM et la destruction des éléments de clé après utilisation

Pourquoi le code d’Operation Vula était resté verrouillé

  • Operation Vula était une opération menée à la fin des années 1980 pour faire entrer en Afrique du Sud des dirigeants et du matériel de l’ANC, et pour construire un réseau clandestin reliant les structures actives à l’intérieur du pays
  • Pour sécuriser les communications, le système utilisait des ordinateurs 8 bits, des tonalités DTMF, des coupleurs acoustiques, divers équipements et des programmes PowerBASIC afin d’échanger des messages chiffrés par masque jetable
  • Tim Jenkin, principal concepteur du système de chiffrement, a publié le code source d’origine sur Vulacode GitHub, avec des explications détaillées dans Talking To Vula.pdf
  • La raison directe du retard de publication du code était un fichier ZIP chiffré créé en 1991
    • En quittant le Royaume-Uni pour rentrer en Afrique du Sud, Tim Jenkin avait regroupé l’ensemble du code source dans un ZIP protégé par mot de passe
    • Une fois de retour en Afrique du Sud, il n’a plus eu besoin d’ouvrir ce code, puis quelques années plus tard, lorsqu’il a voulu y accéder de nouveau, il ne se souvenait plus du mot de passe
    • Un seul fichier accessible correspondait à une version très ancienne, tandis que le reste ne pouvait pas être extrait à cause du chiffrement

Vieux fichiers PKZIP et attaque par texte en clair connu

  • Les fichiers transmis étaient ALLBAS.ZIP et CODMAY93.ZIP, tous deux créés avec une version ancienne de PKZIP et protégés par mot de passe
  • À l’époque, le format ZIP et son ZipCrypto étaient vulnérables à une attaque par texte en clair connu, avec une implémentation open source disponible sous la forme de bkcrack
  • Cette attaque nécessite la prédiction de 12 octets de texte en clair à une position connue à l’intérieur du fichier ZIP
  • ALLBAS.ZIP contenait plusieurs fichiers .BAS, .INC, .ZIP et .EXE, certaines entrées utilisant la méthode de compression Store
    • Une entrée Store correspond à un fichier déjà binaire et non compressé, ce qui permet de prédire le texte en clair sans avoir à deviner le résultat d’une compression
    • Un fichier ZIP lui-même figurait aussi comme entrée Store, et comme un ZIP commence par un en-tête PK, cela en faisait un bon candidat pour le texte en clair

Trouver un candidat de texte en clair : le premier nom de fichier du ZIP interne

  • La cible de l’attaque était le fichier ZIP interne OLDCOD.ZIP, contenu dans ALLBAS.ZIP
  • Comme l’en-tête PK du début d’un ZIP inclut notamment la longueur du nom de fichier et celle du champ additionnel, connaître le premier nom de fichier permettait de construire le texte en clair nécessaire à l’attaque
  • Si le nom du fichier faisait au moins 8 caractères, l’extension comme .BAS ou .INC, combinée aux octets représentant la longueur du nom et celle du champ supplémentaire, suffisait à fournir les 12 octets requis
  • Dans le pire des cas, il aurait été possible de lancer une attaque par force brute sur un nom de fichier en majuscules et chiffres, jusqu’à 8 caractères plus extension, mais cela n’a finalement pas été nécessaire
  • Tim Jenkin possédait une autre version de OLDCOD.ZIP et a pu indiquer que son premier fichier était COMKEY.BAS

Récupération de la clé avec bkcrack

  • Un petit programme Perl a été écrit pour injecter COMKEY.BAS comme candidat de texte en clair, puis l’attaque a été lancée sous la forme bkcrack -C ALLBAS.ZIP -c OLDCOD.ZIP -p ... -o 26 -j 8
  • Au bout de 23 minutes, bkcrack a trouvé les clés suivantes
    • 98e0f009 48a0b11a c70f8499
  • Avec cette même clé, ALLBAS.ZIP a été déchiffré pour produire ALLBAS-DECRYPTED.ZIP, et la même clé a aussi fonctionné sur CODMAY93.ZIP pour générer CODMAY93-DECRYPTED.ZIP
  • Une autre option consistait à attaquer d’autres ZIP internes de la même manière, puis, en cas d’échec, à tenter la force brute sur les noms de fichiers
  • Un candidat ultérieurement vérifié, TECOD5.BAS, a permis de retrouver la même clé en seulement 38 secondes, montrant à quel point le choix d’un texte en clair approprié influe sur la vitesse de l’attaque

Exécution du code déchiffré

  • Les deux programmes ont été compilés et exécutés avec PowerBASIC dans DOSBox
    • RANDOM.BAS : utilisé pour créer des disques de nombres aléatoires servant de masque jetable
    • TECOD.BAS : utilisé pour chiffrer et déchiffrer des messages à envoyer par e-mail
    • Le code compilé et les exécutables générés sont disponibles dans jgc-vula-september-2024
  • La compilation a été effectuée avec PowerBASIC Compiler Version 3.00b ; TECOD.BAS est signalé avec 2 575 instructions et 2 329 lignes, et RANDOM.BAS avec 2 194 instructions et 1 940 lignes
  • RANDOM.EXE utilisait trois méthodes différentes de génération aléatoire pour produire les données, dont l’une reposait sur une clé aléatoire saisie manuellement par l’utilisateur
  • TECOD.EXE était protégé par mot de passe, et le mot de passe intégré dans cette version, stocké dans le code sous une forme où l’ordre des caractères était dispersé, était TIMBOBIMBO
    • Tim Jenkin a intégré ce mot de passe dans le programme de façon simple mais obscurcie
    • Le mot de passe variait selon les versions du programme distribuées aux différents membres de l’ANC
  • Un manuel pour ceux qui veulent exécuter le programme eux-mêmes est disponible ici : TECOD_HLP.pdf

Détails révélés sur le mode opératoire de l’époque

  • L’exécution d’exemple suivait le flux consistant à créer, avec RANDOM.EXE, des données aléatoires pour la clé dans RANDATA.1, puis à chiffrer PLAIN.TXT en PLAIN.BIN, avant de l’inverser
  • Toutes les opérations cryptographiques étaient conçues pour être réalisées sur un disque RAM
  • Dans l’exemple de chiffrement, les fichiers TECOD.EXE et TECOD.CNF se trouvent sur la disquette A:, le disque de données contenant le fichier de clé sur B:, et le disque RAM sur R:
  • Lors de l’étape de chiffrement, le nom du fichier RANDATA.1 devait être remplacé par SNUM ; lors du déchiffrement, RANDATA.1 sur B: devait porter le nom RNUM
  • Le programme incluait des mécanismes de destruction des éléments de clé après usage, de vérification de la distribution des octets aléatoires générés et insistait sur l’utilisation du disque RAM

À lire aussi

1 commentaires

 
GN⁺ 2024-09-08
Commentaires sur Hacker News

  • Ce qui était intéressant dans Vula, c’est que le manque d’utilisabilité du système a fini par causer sa perte
    Même des militants extrêmement dévoués, opposés à un régime meurtrier au nom de la liberté, n’arrivaient pas à l’utiliser correctement
    Ils laissaient des documents non chiffrés, les clés étaient faciles à obtenir, et le logiciel était si contraignant qu’une partie des communications importantes était envoyée en clair
    On sait tous à quel point configurer et utiliser correctement PGP peut être pénible ; au final, la sécurité, c’est l’utilisabilité
    Un texte qui en parle un peu plus en détail : https://shkspr.mobi/blog/2014/01/the-hardest-problem-in-encr...

    • Il suffit d’imaginer que si vous perdez la clé de votre maison, vous ne pourrez plus jamais y entrer
      Dans la plupart des cas, l’utilisabilité va dans le sens d’une réduction de la sécurité

  • J’ai regardé le générateur aléatoire du one-time pad utilisé pour la sécurité, et Melissa O'Neil l’aurait probablement apprécié. C’est presque du PCG
    Il utilise le générateur congruentiel linéaire Rand du système PowerBASIC pour choisir l’un des trois nouveaux ensembles de fonctions rand1-3, dont deux utilisent des LCG différents
    https://github.com/Vulacode/RANDOM/blob/d6a1a1d694b22e6a115b...

    • Cette méthode de génération de one-time pad a l’air franchement mauvaise. Il semble tout à fait possible de reconstituer l’état initial des différents générateurs, et les LCG sont très faciles à rétroconcevoir
      Comme les générateurs pseudo-aléatoires semblent être initialisés à partir du générateur aléatoire du système, il devrait suffire de retrouver la graine initiale du LCG système pour rétroconcevoir le one-time pad
      Je ne connais pas la taille de graine du LCG système, mais si c’est du 32 bits, on pourrait probablement simplement bruteforcer l’état de la graine et appliquer une analyse d’entropie sur le résultat pour le casser en moins d’une heure
    • Il faut aussi rappeler que le programmeur d’origine a appris la cryptographie et le BASIC sur le tas en écrivant ça
      « Ne concevez jamais votre propre chiffrement » est la première règle, mais à la fin des années 80, en manipulant une technologie nouvelle et séduisante, ça a peut-être pu sembler être une exception
    • C’est évidemment très loin du compte pour un vrai one-time pad

  • L’effondrement de l’apartheid en Afrique du Sud dans son ensemble est assez fascinant. Je connaissais très peu cet aspect
    Fait intéressant : le mouvement BDS (boycott, désinvestissement, sanctions) a commencé là, et à l’époque beaucoup pensaient que l’apartheid ne prendrait jamais fin
    Mais, sur une longue période, une pression continue sur de multiples points a fini par créer une contrainte énorme, qui a mené à son effondrement
    Le fait que ce travail ait été réalisé sur un Toshiba T-100 est aussi assez fascinant ; c’est une superbe machine

  • Intéressant. L’Afrique du Sud en a vraiment vu de toutes les couleurs. J’espère que le GNU actuel fera reculer l’horloge de l’apocalypse
    Je recommande Action Kommandant. Cela donne un aperçu de la vie d’Ashley Kriel, martyr et fierté de Bonteheuwel

    • Ravi de voir le nom d’Ashley Kriel mentionné. La vie et les talents variés des camarades talentueux qui ont travaillé avec l’ANC sont souvent éclipsés, donc j’ai toujours voulu mieux connaître ce genre de figures
      C’est en cours d’anglais au secondaire, grâce à un professeur radical qui avait quitté l’Afrique du Sud pour le Canada dans les années 80 afin d’échapper à la surveillance, que j’ai découvert Athol Fugard, et cela m’a ouvert les yeux
      Je souhaite aussi bonne chance aux Sud-Africains. Un pays avec autant de personnes talentueuses et de richesses naturelles mérite bien mieux. Au moins, l’ère de la politique rigide au sein de l’ANC semble terminée

  • Le code Rust pour le bruteforce : https://github.com/rhulha/ZipMcKracken

  • Operation Vula, des ordinateurs 8 bits, des tonalités DTMF, un coupleur acoustique : fascinant
    La CIA/NSA a flairé le fait qu’Operation Vula fonctionnait avec un Philips PX-1000 commercial doté d’un DES intégré, et a soudoyé Philips pour y insérer une porte dérobée : https://www.cryptomuseum.com/crypto/philips/px1000/

    • Tim Jenkins a contourné ce problème en utilisant son propre système et son propre chiffrement
      Au lieu d’un DES backdooré, il utilisait des one-time pads transportés sur disquette à chaque correspondant par des coursiers
      Même si une de ces disquettes était saisie en Afrique du Sud, seuls les messages du destinataire concerné seraient compromis, et cela finirait de toute façon par être détecté assez vite
    • Si vous utilisez n’importe quelle technologie de chiffrement commerciale, en général, c’est fichu
      Mais générer les clés d’un one-time pad avec un générateur pseudo-aléatoire est une approche naïve
      Tout l’intérêt du one-time pad est d’utiliser des clés réellement aléatoires pour obtenir une vraie sécurité. Avec le type de clés utilisé ici, il aurait suffi d’échanger une graine pour les générer localement, ce qui aurait évité d’exposer les coursiers
      Je comprends que le développeur était autodidacte et apprenait au fur et à mesure, mais quand on manipule des secrets vraiment critiques, il ne faut pas commettre ce genre d’erreur
      Cela dit, produire de grandes quantités de véritable hasard n’est pas simple non plus. Il faudrait sans doute fabriquer son propre dispositif matériel, car la plupart des équipements commerciaux ont de fortes chances d’être compromis

  • Si vous devez casser un « vieux » chiffrement ZIP et que vous connaissez quelques caractères du contenu de l’archive, difficile de faire mieux que ceci : https://github.com/kimci86/bkcrack

    • Tout l’article ne parle-t-il pas précisément de ce programme ?