NSA - À propos de BULLRUN

45
5
fév.
2015
Sécurité

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) :

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

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 :

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 !

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 ;-)).

levels

  • 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.

otr

  • 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é.

gpg

  • 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 :

  • # Puisqu'on est sur Linuxfr, autant être précis

    Posté par (page perso) . Évalué à 10. Dernière modification le 05/02/15 à 16:39.

    La grosse image dans l’article, c’est rigolo ça me fait penser à

    Elmer l’éléphant bariolé. C’était bien la maternelle.

    Sinon à part ça j’ai pas compris ce qu’elle signifiait.

    Pareil, les quelques images avec marqué [OC: blabla], c’est quoi exactement?

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

    Perdu! TrueCrypt n’est pas considéré comme libre.

    Oh et puis tant qu’à faire, autant pinailler:

    « Foreign Intelligence Surveillance Act »(FISA)

    manque une espace

    Dans le paragraphe «SSL/TLS», des guillemets droits sont utilisés alors que des guillemets typographiques sont utilisés partout ailleurs.

    Le cryptographe Matthew Green a fait un article sur les différents moyens, que la NSA a, pour "casser" SSL/TLS.

    Les virgules me semblent inutiles, cassant le rythme et le sens de la phrase, mais je vous laisse juge.


    Bon sinon pas trop long, intéressant, un mélange équilibré théorique/pratique si je puis dire, j’ai repéré de bons liens: ça fait plaisir du contenu de qualité.

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Puisqu'on est sur Linuxfr, autant être précis

      Posté par (page perso) . Évalué à 2.

      Pour le FISA et les virgules, c'est corrigé. Merci.

    • [^] # Re: Puisqu'on est sur Linuxfr, autant être précis

      Posté par (page perso) . Évalué à 1.

      Pour le schéma, je vais me risquer à une interprétation : c'est le schéma classique de gestion du risque (projet, sécurité…), sauf que là il est présenté du point de vue NSA :

      • seule la ligne du haut est étudiée (les autres "cibles" sont moins intéressantes on va dire)
      • plutôt que d'afficher la mitigation du risque, l'outil utilisé est indiqué dans chaque case : cela permet de classer les outils et les rapprocher de l'impact pour gêner l'interception (du moins fort au plus fort)

      Tu retrouve ce genre de schéma, par exemple, sur :
      http://www.firewall.cx/cisco-technical-knowledgebase/cisco-voice/914-cisco-unified-com-risk-management.html

      Pareil, les quelques images avec marqué [OC: blabla], c’est quoi exactement?

      j'imagine que c'est la sortie obfusquée d'un des logiciels interceptant les communications XMPP.

      • [^] # Re: Puisqu'on est sur Linuxfr, autant être précis

        Posté par (page perso) . Évalué à 3. Dernière modification le 05/02/15 à 21:41.

        Pour le schéma, je vais me risquer à une interprétation : c'est le schéma classique de gestion du risque (projet, sécurité…) […]

        J’ai rien compris ni à l’un ni à l’autre. Je comprends ce que ça représente, mais je n’arrive pas à le lire. Du coup j’imagine que je dois pas être le seul dans le même cas.

        Pareil, les quelques images avec marqué [OC: blabla], c’est quoi exactement?

        j'imagine que c'est la sortie obfusquée d'un des logiciels interceptant les communications XMPP.

        Je me doute, mais ça serait bien qu’on prenne une ligne ou deux pour expliquer d’où ça sort.

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Puisqu'on est sur Linuxfr, autant être précis

          Posté par . Évalué à 4.

          J’ai rien compris ni à l’un ni à l’autre.

          Je pense sincèrement qu'il n'y a rien à comprendre. On a un tableaux avec trois échelles ordinales (classés, mais qualitativement) : une mesure de gravité, une mesure de fréquence, et une mesure d'importance. L'importance augmente avec la gravité? OK. L'importance augmente avec la fréquence? OK. Mais une "unité" de fréquence vaut une unité de gravité, c'est très étrange. Je doute qu'on puisse faire quoi que ce soit de sérieux avec un truc aussi fumeux.

  • # TextSecure... et f-droid

    Posté par (page perso) . Évalué à 5.

    La discussion concernant l'éviction de TextSecure sur f-droid.org est assez intéressante, notamment quel est l'intérêt de recenser pour le distributeur l'ensemble de ses utilisateurs (ayant peut-être des choses à cacher) via un dépôt centralisé et instrumenté (sans doute) pas la NSA.

    Voir https://f-droid.org/posts/security-notice-textsecure/

    Une compréhension du développeur des implications de ne souhaiter distribuer que via google play pourrait être intéressante, notamment en comprenant l'intérêt d'être sur f-droid. J'ai l'impression qu'il faudra un mainteneur intéressé pour rétablir la situation… étonnant qu'il n'en soit visiblement émergé aucun parmi les utilisateurs :/

    Sinon, il y a le développeur d'une alternative qui semble motivé
    https://f-droid.org/forums/topic/tinfoil-sms-perfect-alternative-to-textsecure/

    • [^] # Re: TextSecure... et f-droid

      Posté par . Évalué à 1.

      En fait le problème qu'avait le créateur de TextSecure sur f-droid concernant la mise à jour du soft sur f-droid.

      F-droid avait laissé trainer une version pendant assez longtemps sur le repo alors que l'application officielle avait déjà plusieurs itération d'avance. Créant des rapport de bug venant des utilisateurs de f-droid sur un problème réglé depuis plusieurs semaines.

      Le dev préfèrait avoir le contrôle complet de la distribution et donc également des statistiques d'installation pour pouvoir vraiment suivre de plus près les utilisateurs.
      Mais actuellement l'équipe de TextSecure réfléchit à une autre alternative pour remplacer le google play, mais cela concerne surtout l'utilisation de GCM (lié à google play) qui permet de faire du push vers les terminaux.

      Le problème c'est que les gens de f-droid ont quasiment nié avoir mis trop de temps à mettre à jour le repo et qu'au final ce n'était pas trop grave alors pourquoi pêter un câble ? Sauf que je préfère savoir le développeur principal bosser sur l'appli plutôt que de faire du tri de bug ayant été corrigés depuis longtemps…

  • # Tails

    Posté par . Évalué à 3.

    Je n'arrive pas à trouver le document où il apparait que Tails résistait à la NSA en 2012. Lors de la sortie du Spiegel, lemonde.fr avait repris l'information en indiquant que Tails faisait partie de la liste des logiciels qui chagrinent la NSA mais en regardant le Spiegel, je n'ai pas trouvé mention de la distribution. Du coup si quelqu'un peut me diriger vers un article/document confirmant cela, je lui en serai reconnaissant.

  • # Concernant l'"Open Hardware"

    Posté par . Évalué à 2.

    Bonjour,

    J'ai beaucoup apprécié cet article bien expliqué et instructif.
    D'ailleurs j'ai une suggestion pour la partie "open hardware" : en utilisant une rasbperry pi BeagleBone Black (qui sait faire AES, SHA, and MD5) en lui ajoutant une cryptocape on peut alors faciement arriver à un système intéressant à peu de frais :

    • Secure Boot
    • VPN / SSL endpoint
    • Hardware digital wallet
    • Random number generator
    • Authentication Device

    Le but de ce cape étant essentiellement l’accélération pour soulager la BBB.

    • [^] # Re: Concernant l'"Open Hardware"

      Posté par . Évalué à 1.

      J'ajoute le lien vers le document de présentation (pdf) de l'auteur que je trouve intéressant car il décrit toutes les parties de sa carte et explique la raison de leurs présence :

  • # Freenet ?

    Posté par . Évalué à 4.

    Visiblement, freenet (www.freenetproject.org) n'est pas dans la liste. Pourtant, si ce que ce projet annonce est vrai (anonymat, résistance à la censure, etc.) et vu les protocoles évolués qu'il utilise (chiffrement des communications entre nœuds et entre les destinataires finaux, impossibilité ou au moins grande difficulté de tracer l'insertion des contenus et leur récupération), ça devrait être difficile pour la NSA !

    Serait-ce lié au fait qu'ils utilisent les courbes elliptiques du NIST ? Voyez-vous d'autres explications ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.