Petite FAQ sur la faille Windows CVE-2020–0601 et la NSA à l’usage des paranoïaques

CVE-2020–0601 a surpris tout le monde. Enfin, pas la faille elle-même, mais plus par qui elle a été révélée : la NSA. Seraient-ils devenus sympas ? Quelques réponses à des questions que vous vous posez (ou pas).

Que penser de la nouvelle position de la NSA de transmettre publiquement ce type d’informations ?

La NSA a commencé cet été à changer sa posture en publiant Ghidra en logiciel open source, qu’ils ont d’abord développé en interne pendant de longues années, pour analyser des programmes.

Maintenant, ils préviennent Microsoft d’une faille. Pourquoi un tel changement ?

Cela remonte à la fuite de données de la NSA par le groupe Shadow brokers à l’été 2016. Parmi les révélations, la vulnérabilité ETERNALBLUE a été utilisée dans plusieurs “gros” ransomware, comme WannaCry ou NotPetya. À ce moment, la NSA s’est fait taper sur les doigts pour ne pas avoir partagé cette vulnérabilité critique avec Microsoft, qui n’avait donc pu la corriger à temps.

Lors de la fuite par les Shadow brokers, la communauté cyber s’est rendue compte que certaines failles / outils avaient été utilisées jusque 14 mois avant la révélation. Dès lors, il a été très compliqué pour la NSA de se disculper, pendant que d’autres utilisaient leurs outils en se faisant passer pour des Américains. Là, en dévoilant la faille à Microsoft, ils évitent ce risque.

Il ne faut pas oublier que la NSA, contrairement à chez nous où les rôles sont clairement séparés, travaille à la fois sur le défensif (notre ANSSI) et l’offensif (notre DGSE). Ils ont sans aucun doute pesé le pour et le contre. Mais suite à ETERNALBLUE, il semble que le défensif soit un peu plus écouté.

Pour autant, il ne faut pas être naïf : s’ils ont prévenu Microsoft de cette vulnérabilité, c’est qu’ils en ont d’autres en réserve. Ils ne peuvent pas se permettre de prendre le risque de ne plus avoir de munitions.

Alors pourquoi la NSA révèle-t-elle cette faille précise ?

Comme évoqué précédemment, la NSA travaille à la fois sur du défensif et de l’offensif. Si cette fois le défensif l’a emporté, c’est qu’il y a de bonnes raisons. Lesquelles ? Probablement parce qu’ils considèrent que cette faille représente risque plus élevé de pertes que de gains.

Ces pertes se traduiraient par des attaquants étrangers s’en prenant à des intérêts américains. Ils sont quelques-uns dans le contexte géopolitique actuel, à commencer par le gouvernement iranien.

Pourquoi s’en prendre à la cryptographie ?

La NSA aime bien jouer avec la cryptogrpahie et les clés :

• de la _NSAKEY dissimulée dans les systèmes (1999)
• RSA BSAFE, où la NSA a carrément pousser, via des standards, un générateur aléatoire faible, Dual_EC_DRBG et quelques autres annecdotes autour de la société RSA (2004 à 2013).
• à l’ajout de certificats comme dans le cas du malware FLAME en 2012 lors d’une opération contre le nucléaire Iranien menée entre autres par la NSA … déjà. La coïncidence temporelle est pour le moins “amusante” étant donné la situation géopolitique actuelle.

De telles failles sont très intéressantes. D’une part, elles sont très difficiles à voir car elles reposent sur des petits détails mais aux conséquences significatives. D’autre part, une fois une faiblesse cryptographique installé sur le système cible, les interceptions sont alors complètement invisibles pour tout le monde, sauf ceux qui connaissent l’existence de la faiblesse … jusqu’à ce que d’autres la découvre également (je recommande la lecture d’articles sur les backdoors dans les équipements Juniper, l’une introduite fin 2013, l’autre en 2012, et où on reparle de Dual_EC_DRBG).

Quel impact sur Microsoft et ses utilisateurs ?

La faille CVE-2020–0601 frappe au cœur de la confiance numérique. Elle touche ce qui permet de vérifier qu’un programme est authentique, et que les communications sont proprement protégées.

La vulnérabilité permet, quand elle est exploitée, à un attaquant d’affaiblir les communications chiffrées de la cible ou d’exécuter un programme en le faisant passer pour légitime. En gros, l’attaque leur donne un double des clés de chiffrement. C’est une attaque en 2 bandes :

1. on affaiblit les paramètres cryptographiques de la cible ;

2. on intercepte ses communications (les grandes oreilles … domaine où la NSA se débrouille ;-)

Ensuite, la NSA collecte le trafic de la cible via ses moyens d’interception, et peut tout déchiffrer, car ils ont un double de la clé.

Ce problème est particulièrement “marrant” quand il touche des mises à jour. Là, Microsoft a mis en place du certificate pinning, et n’est donc pas vulnérable à une attaque. Ce n’est pas nécessairement le cas d’applications tierces. Ce problème de confiance en des mises à jour est bien connu des informaticiens : faut-il d’abord faire confiance au patch mais sans possibilité de vérifier qu’il est légitime, ou faut-il faire confiance au système de mise à jour en priant pour qu’il ne soit pas attaqué pendant la mise à jour (oeuf, poule, tout ça…)

Cela avait déjà été évoqué dans un article de 1984 (oui, oui, 1984), Reflections on Trusting Trust, par Ken Thompson, un des pères fondateurs de l’informatique moderne

Qu’est-ce que cette nouvelle faille signifie sur les moyens mis en œuvre par les entreprises pour se protéger ?

Cette faille montre surtout la dépendance envers les éditeurs de logiciels. De tous, dans tous les secteurs. On ne conçoit pas notre vie sans Internet et sans ordinateur aujourd’hui. Nous sommes en état de dépendance.

Les entreprises n’ont rien fait de mal en l’occurrence, et l’éditeur non plus. Au contraire, il a fourni un patch très rapidement, et des moyens de détection au cas où l’attaque serait exploitée.

Plutôt que de moquer pour “encore une nouvelle faille” ou “encore un échec”, il vaut mieux se faire à l’idée que ces bugs sont inévitables, et apprendre à vivre avec pour être efficaces quand ils surviennent. Et là, franchement, c’est le cas. Toute la communauté a réagi très très rapidement.

Et les grands éditeurs ne voient pas cela comme une fatalité : ils font leur possible pour éliminer un maximum de bugs, et les rendre compliqué à exploiter. C’est une nouvelle posture, depuis quelques années.

Pour les éditeurs moyens ou petits, ce n’est pas la même chose, car ils ne disposent pas des mêmes capacités que les GAFAM.