NSA - À propos de BULLRUN

Voici la suite des « études » des leaks (fuites) de Snowden menées pour NSA-Observer. Dans cet article, nous allons revenir sur les révélations du Spiegel datant de fin décembre lors du 31c3 (Chaos Computer Congress) et du 17 janvier 2015 portant sur les moyens offensifs de la NSA ainsi que d'autres agences concernant la cryptographie.

La conférence « Reconstructing narratives » de Laura Poitras et Jacob Appelbaum présentant ces documents est visible ci-dessous (mais aussi sur le site du CCC) :

• mp4
• webm

BULLRUN, qu'est ce que c'est ?

BULLRUN est un « programme » de la NSA exploitant différents moyens pour accéder à du contenu chiffré. Le New York Times avait abordé le sujet fin 2013 dans son article « Secret Documents Reveal N.S.A. Campaign Against Encryption » mais sans aucun détail (comme The Guardian ou encore propublica).

Sommaire

• Historique
• À propos de configurations
  • SSL/TLS
    • Bonnes pratiques :
  • SSH
  • IPSec
• Je peux utiliser quoi alors ?

Historique

On savait, à l'époque, que l'on pouvait distinguer en simplifiant trois méthodes utilisées par la NSA utilise pour pouvoir accéder à du contenu chiffré. La première méthode utilise les mathématiques, c'est-à-dire trouver de nouvelles méthodes pour réussir à casser un algorithme (par exemple pour « casser » RC4).

La deuxième méthode permet « simplement » d'accéder aux clés privées de la cible (pouvant être aussi bien une personne qu'une multinationale) ou aux informations demandées. On arrive là dans un ensemble d'autres programmes, un des plus secrets de la NSA (classification est « CORE SECRETS »). On trouve dans les documents, que les agents peuvent être sous couverture dans une entreprise (qu'elle soit américaine ou étrangère), ou encore que le programme TAREX (pour TARget EXploitation) conduit des opérations clandestines aussi bien SIGINT (renseignement d'origine électromagnétique) qu'HUMINT (renseignement humain) partout dans le monde pour exploiter des systèmes via différents moyens : « off net-enabling » (activité clandestine ou sous couverture sur le terrain), « supply chain-enabling » (modifier des équipements directement dans la chaîne logistique ou via le détournement de livraisons) et « hardware implant-enabling » qui semble regrouper un peu des deux précédents.

Les États-unis ne sont évidemment pas obligés de passer par ce genre d'opérations pour obtenir ce qu'ils veulent de leurs entreprises, il existe le « Foreign Intelligence Surveillance Act » (FISA) et les « lettres de sécurité nationale » qui sont des requêtes contraignantes et qui peuvent obliger une entreprise à permettre un accès à quelque chose en ayant l'obligation de ne pas en parler.

Ainsi, en 2013, l'entreprise Lavabit décida de fermer plutôt que de donner sa clé privée SSL/TLS au FBI, le tribunal la menaçait d'une amende de 5000 € par jour de retard. Lavabit hébergeait les mails d'Edward Snowden parmi ses 400 000 utilisateurs.

En 2008, Yahoo a été menacé d'une amende de 250 000 $ par jour de retard s'il ne donnait pas des données d'utilisateurs à la NSA.

La troisième méthode consiste à mettre en place ou profiter d'une mauvaise implémentation, comme le générateur de nombre aléatoire Dual_EC_DRBG, qui pourrait permettre, par exemple, de lire des flux SSL/TLS. Une méthode complémentaire consiste à payer une entreprise pour qu'elle utilise quelque chose en particulier, la NSA a payé 10 millions de dollars à l'entreprise RSA, pour utiliser Dual_EC_DRBG dans certains de ses produits (comme BSAFE).

Ainsi, la NSA (et sans doute les autres agences) a activement travaillé à insérer des vulnérabilitées dans des produits commerciaux, des réseaux (par exemple en se connectant à un routeur pour diminuer la crypto d'un VPN), des protocoles (vous pouvez lire les spéculations de John Gilmore sur la NSA et IPsec) ou directement sur des périphériques de cibles.

Le New York Times rapporte qu'en 2006, la NSA avait réussi à pénétrer les communications de trois compagnies aériennes, un système de réservation de voyages, un programme nucléaire d'un gouvernement étranger en craquant les VPNs les protégeant, et en 2010, EDGEHILL (l'équivalent Britannique de BULLRUN) avait réussi à "déchiffrer" le traffic de 30 cibles.

À propos de configurations

Pour ce que l'on en sait, il suffit d'une bonne configuration pour résoudre la majorité des problèmes (à noter tout de même : les documents datent de 2012, et énormement de choses ont pu changer depuis (Heartbleed, Poodle, nouvelles failles, etc).

SSL/TLS

Le cryptographe Matthew Green a fait un article sur les différents moyens que la NSA a pour "casser" SSL/TLS. Selon lui, la NSA peut utiliser plusieurs méthodes :

• Voler les clés RSA (voir l'introduction de cet article) : en volant ces clés, la NSA peut lire le contenu des flux SSL/TLS, mais aussi déchiffrer les flux qu'elle a capté avant ;
  • contre-mesure : utiliser les courbes elliptiques et surtout le Forward Secrecy (FS, ou confidentialité persistante) ;
• avoir "accès" aux puces matérielles de chiffrement ;
  • contre-mesure : changer de matériel ? (et avoir de l'open-hardware, utiliser un générateur externe quand c'est possible) ;
• avoir "accès" aux puces logicielles de chiffrement (comme Dual_EC_DRBG) ;
  • contre-mesure : utiliser un générateur externe ;
• Side channel attacks : un système peut faire fuiter des informations (operation time, resource consumption, cache timing, RF emissions) qui peuvent parfois être exploitables en étant sur le même espace physique (i.e le même serveur physique, voir Attack of the week: Cross-VM side-channel attacks) ; Matthew parle aussi d'une autre attaque, « remote timing information », en notant que certains chipsets matériels désactivent la contre-mesure par défaut ;
  • contre-mesure : faire attention à ses voisins, RSA blinding.

Bonnes pratiques :

• dans la mesure du possible, centraliser la configuration SSL/TLS pour un logiciel sur le serveur : pour Apache 2, par exemple, vous pouvez mettre votre configuration (SSLCipherSuite…) dans /etc/apache2/mods-available/ssl.conf (pour Debian et ses dérivées), cette conf sera alors active pour l'ensemble de vos vhosts, et il faudra donc la changer uniquement en cas de besoin (et non vhost par vhost, au risque d'en oublier) ;
• disposer d'une clé RSA égale ou supérieure à 2048 bits ;
• utiliser des courbes elliptiques ;
• activer Forward Secrecy ;
• utiliser SSLHonorCipherOrder on ;
• enlever les algorithmes de chiffrement faibles, obsolètes, voire dangereux (par exemple DES et RC4) ;
• ne plus utiliser SSLv3, et s'assurer par la même occasion que SSLv2 est bien mort et enterré (SSLProtocol all -SSLv2 -SSLv3 pour Apache2 par exemple), TLSv1 est aujourd'hui le minimum acceptable ;
• désactiver la compression, pour éviter l'attaque CRIME.

Pour vous aider dans la configuration de votre serveur web, vous pouvez utiliser le site JeVeuxHTTPS, et bien entendu le désormais célèbre SSL Labs qui permet de tester sa configuration.

Des outils comme sslscan, xmpp.net (XMPP/Jabber), StartTLS.info (mails) peuvent aussi être utiles.

SSH

La seule trace du terme backdoor dans les documents à propos d'openSSH est en fait un rootkit, ce qui signifie qu'il FAUT avoir réussi à rentrer dans le serveur et à être root pour pouvoir modifier le binaire et permettre l'accès à une clé ou à un mot de passe. À noter que cette modification empêche de voir les connexions « pirates » de ces comptes dans les logs.

Un problème concernant SSH pourrait être l'utilisation d'algorithmes de chiffrement obsolètes. Vous pouvez vérifier ceux proposés par votre serveur avec la commande ssh -vvv pour vous connecter. Une connexion sur un serveur donne quelque chose ressemblant à ceci comme résultat :

ssh -vvv skhaen@exemple.com

[...]
kex_parse_kexinit: ssh-rsa,ssh-dss
kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[...]

Arcfour est en fait un autre nom de RC4, qui pour le coup est cassé depuis un moment. La version 6.7 d'OpenSSH le supprime, et Microsoft recommande de le désactiver depuis 2013.

Pour améliorer la configuration de votre serveur SSH (il n'y a pas que le choix des algorithmes de chiffrement), vous pouvez vous référer aux trois articles ci-dessous. Faites très attention avant toutes modifications, elles peuvent vous empêcher de vous (re)connecter à votre serveur !

• Secure Secure Shell par stribika (hard way, nécessite d'avoir un système récent) ;
• NSA-proof SSH par whykacper/ (soft way) ;
• Bettercrypto.org.

IPSec

Concernant IPSec et comment mieux le configurer, vous pouvez vous référer à l'article de Paul Wouters « Don’t stop using IPsec just yet » (en espérant que le problème se trouve bien là).

On peut résumer cet article en deux principales recommandations :

• utiliser Perfect Forward Secrecy : pfs=yes ;
• éviter les PreSharedKeys : authby=secret.

Je peux utiliser quoi alors ?

Il ne faut surtout pas tomber dans le piège « on est tous foutus, rien ne marche, on ne peut rien faire » : ce n'est absolument pas le cas. Dans les bonnes nouvelles, nous avons aussi la preuve que Tor, OTR, GPG, TAILS et Redphone sont sûr (du moins en 2012 ;-)).

• Trivial : suivre le parcours d'un document sur Internet ;
• mineur : enregistrer un chat privé sur Facebook ;
• modéré : décrypter un email envoyé via le service de messagerie russe mail.ru ;
• majeur : utiliser des services comme Zoho (?), Tor, TrueCrypt ou OTR ;
• catastrophique : utiliser plusieurs protocoles en même temps, par exemple faire passer de la VoIP utilisant ZRTP par le réseau TOR, le tout à partir d'un ordinateur sous Linux.

On notera avec beaucoup d'intérêts qu'il n'y a aucune trace de logiciels commerciaux (bitlocker…) dans les documents.

• Tor est un logiciel libre qui, grâce à une technique de routage en oignon, permet d’anonymiser les connexions sur Internet ;
• OTR permet de chiffrer des communications, en particulier sur XMPP/Jabber, ne pas hésiter à l'utiliser avec du SSL/TLS par dessus.

• GPG permet de chiffrer un mail, un fichier ou un dossier entier ; il permet aussi de signer un fichier (ou un mail) pour s'assurer de son authenticité.

• TAILS est un système d'exploitation live, que vous pouvez démarrer, sur quasiment n'importe quel ordinateur, depuis un DVD, une clé USB, ou une carte SD. Son but est de préserver votre vie privée et votre anonymat, et de vous aider à utiliser Internet de manière anonyme et contourner la censure (toutes les connexions sortantes vers Internet sont obligées de passer par le réseau Tor).
• Redphone est une application pour Android qui permet d'avoir des conversations chiffrées (on peut aussi s'intéresser à Textsecure, application Android de la même entreprise pour chiffrer les SMS).

Dans un autre document, le logiciel Truecrypt est aussi considéré comme « solide », il ne reste plus qu'à attendre que son fork soit prêt pour enfin pouvoir le réutiliser.

Le point commun de tous ces logiciels ? Ce sont des logiciels libres.

Les documents sont disponibles sur le site du Spiegel :

• NSA Documents: Attacks on VPN, SSL, TLS, SSH, Tor ;
• The Digital Arms Race: NSA Preps America for Future Battle.

Aller plus loin

• Lien vers l'article original (216 clics)
• nsa-observer (106 clics)
• Article précédent sur LinuxFr.org (74 clics)