Selon Trail of Bits (blog), dans une analyse publiée en février 2026, deux bibliothèques populaires, aes-js (JavaScript) et pyaes (Python), exposent leurs utilisateurs à des failles cryptographiques en fournissant un IV par défaut en mode AES-CTR, ce qui a entraîné des vulnérabilités dans de nombreux projets en aval, dont strongMan (outil de gestion pour strongSwan), qui a été corrigé.

  • Problème central: IV par défaut (0x00000000_00000000_00000000_00000001) en AES-CTR dans aes-js et pyaes, avec des exemples de documentation omettant l’IV. Cela favorise la réutilisation clé/IV, permettant la récupération de l’XOR des textes en clair et rendant le chiffrement très fragile (récupération de masques et secrets en chaîne).

  • Portée: Adoption large (≈850 dépendants npm pour aes-js ; ≈700 000 dépôts GitHub intégrant aes-js et ≈23 000 pyaes, de façon directe/indirecte), multiplicateur de risques dans l’écosystème. Les bibliothèques ne prennent pas en charge AES-GCM/GCM-SIV (pas d’authentification), rendant les chiffrés malléables; et présentent des problèmes de timing (S-box en table de consultation favorisant les attaques cache-timing, oracle de bourrage PKCS7 en CBC). Manque de maintenance: aes-js (dernier update 2018), pyaes (2017), avec divers tickets ouverts (distutils obsolète, perf streaming, encodage UTF-8, génération IV/clé absente).

  • Réponses des développeurs: un ticket de 2022 sur aes-js signalant l’IV par défaut a reçu une réponse minimisant le problème (“yadda, yadda, yadda”) et aucun suivi aux relances (nov. 2025). À l’inverse, strongSwan (projet distinct) a offert une réponse exemplaire.

  • Cas fort (strongMan): l’outil web strongMan chiffrait des clés PKCS#8 et certificats X.509 dans SQLite via pyaes en CTR avec IV par défaut. Conséquence: avec des modulus RSA 2048 bits, l’XOR des facteurs peut permettre de récupérer les facteurs en secondes; de plus, les certificats X.509 prévisibles permettent de reconstruire le flot de clé et de déchiffrer les clés privées. Un attaquant accédant au fichier SQLite pouvait usurper des identités et mener des attaques de type homme‑du‑milieu.

  • Correctifs (strongMan): passage à une bibliothèque moderne, remplacement de CTR par GCM‑SIV avec vérification de tag, dérivation de clé par entrée pour éviter toute répétition clé/IV, et scripts de migration. Un avis de sécurité strongMan accompagne la mise à jour. L’article met en contraste négligence vs. artisanat dans les réponses apportées et documente les mesures de remédiation.

IOCs: Aucun indicateur technique (IP, domaines, hachages) communiqué.

TTPs observés/évoqués:

  • Réutilisation de paires clé/IV en AES‑CTR (permet récupération de l’XOR des clairs)
  • Exploitation de la malléabilité de CTR (modification bit‑à‑bit non détectable sans authentification)
  • Récupération de flot de clé via données X.509 prévisibles
  • Attaques cache‑timing via S‑box en tables de consultation
  • Oracle de bourrage PKCS7 dû à des timings en CBC

Type d’article: analyse et mise en lumière d’un problème systémique, avec un cas d’impact réel et la description des correctifs appliqués.

🧠 TTPs et IOCs détectés

TTP

Réutilisation de paires clé/IV en AES‑CTR, Exploitation de la malléabilité de CTR, Récupération de flot de clé via données X.509 prévisibles, Attaques cache‑timing via S‑box en tables de consultation, Oracle de bourrage PKCS7 dû à des timings en CBC

IOC

Aucun indicateur technique (IP, domaines, hachages) communiqué.

🔗 Source originale : https://blog.trailofbits.com/2026/02/18/carelessness-versus-craftsmanship-in-cryptography/