Aller au contenu

LOGJAM Common Prime Vulnerability

Vulnérabilité LOGJAM Common Prime

Description

Cette vulnérabilité indique que le serveur utilise des nombres premiers Diffie-Hellman largement partagés qui permettent des attaques par précalcul efficaces, autorisant des adversaires étatiques à déchiffrer passivement de grandes quantités de trafic internet.

LOGJAM-common_primes se produit lorsque les serveurs utilisent les mêmes paramètres DH standards (nombres premiers) partagés par des millions d'installations. Bien que l'utilisation de nombres premiers partagés ait été considérée comme sûre, l'algorithme du crible du corps de nombres (number field sieve) permet aux attaquants de précalculer des tables cryptographiques coûteuses une seule fois par nombre premier, puis de casser rapidement toute connexion utilisant ce nombre premier.

Fonctionnement :

  1. L'attaquant identifie les nombres premiers DH largement utilisés (par ex. les paramètres par défaut d'Apache/OpenSSL).
  2. Il effectue un précalcul coûteux (des semaines de temps de calcul) pour le nombre premier cible.
  3. Il capture passivement les échanges de clés DH de n'importe quel serveur utilisant ce nombre premier.
  4. Il utilise les tables précalculées pour casser des connexions individuelles en quelques minutes.
  5. Il met l'attaque à l'échelle sur des millions de serveurs partageant le même nombre premier.

Prérequis :

  • Le serveur utilise des nombres premiers DH communs/par défaut (1024 bits ou moins).
  • Des ressources de calcul importantes pour le précalcul initial (~100 M$ pour 1024 bits).
  • La capacité de capturer le trafic réseau des connexions cibles.
  • Aucune capacité de type man-in-the-middle n'est nécessaire - attaque purement passive.

Scénario d'exemple : Un fournisseur cloud majeur utilise des paramètres DH de 1024 bits par défaut sur des milliers de serveurs. Un acteur étatique passe des mois à précalculer des tables cryptographiques pour ce nombre premier spécifique. Une fois terminé, il peut surveiller passivement le trafic internet et déchiffrer toute connexion TLS vers ces serveurs en temps réel, affectant des millions d'utilisateurs sans aucune interférence active ni détection.

Casser le nombre premier de 1024 bits le plus courant permettrait une écoute passive sur 18 % des principaux domaines HTTPS, tandis que casser les deux nombres premiers les plus courants compromettrait 66 % des serveurs VPN et 26 % des serveurs SSH à l'échelle mondiale.

Recommandation

Pour atténuer les attaques LOGJAM par nombre premier commun :

Défense principale - Générer des paramètres DH uniques :

# Générer des paramètres DH 2048 bits uniques
openssl dhparam -out unique-dhparams.pem 2048

# Apache : utiliser des paramètres personnalisés
SSLOpenSSLConfCmd DHParameters /path/to/unique-dhparams.pem

# Nginx : spécifier des paramètres uniques  
ssl_dhparam /path/to/unique-dhparams.pem;

Éviter les nombres premiers par défaut/communs :

N'utilisez jamais ces nombres premiers largement compromis : - Nombre premier Apache de 512 bits par défaut (utilisé par des millions de serveurs). - Nombre premier OpenSSL de 512 bits par défaut (dans SSLeay depuis 1995). - Nombres premiers standards RFC 5114 (potentiellement influencés par la NSA).

Migrer vers ECDHE :

La meilleure solution - éliminer complètement la vulnérabilité DH : 

# Apache : prioriser ECDHE par rapport à DHE
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE

# Nginx : n'utiliser que des chiffrements ECDHE
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE;

Utiliser des paramètres de 2048 bits minimum :

Si DHE est requis : 

# Assurer une taille de clé minimale
ssl_dhparam_size 2048;  # Nginx

Tester la présence de nombres premiers communs :

# Extraire les paramètres DH du serveur
openssl s_client -connect example.com:443 -cipher DHE 2>&1 | \
  openssl dhparam -inform PEM -text -noout

# Comparer aux nombres premiers vulnérables connus
# Vérifier si le nombre premier correspond à la valeur par défaut d'Apache ou à d'autres valeurs courantes

Protections supplémentaires :

  • Utiliser TLS 1.3 qui élimine complètement le DH sur corps fini.
  • Implémenter le certificate pinning pour détecter les tentatives de MITM.
  • Surveiller les schémas de connexion inhabituels indiquant une analyse de trafic en masse.
  • Considérer les implications de la Perfect Forward Secrecy lors du choix des suites de chiffrement.

Information critique : Même des paramètres DH forts de 1024 bits deviennent vulnérables lorsqu'ils sont partagés entre de nombreux serveurs, car le coût de précalcul peut être amorti. L'unicité est tout aussi importante que la taille.

Liens

Normes

  • SOC2_CONTROLS:
    • CC_6_7
    • CC_7_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_32
  • PCI_STANDARDS:
    • REQ_4_1
    • REQ_6_2
    • REQ_11_3