Parce qu'il faut parler de DigiNotar...

S

ur Exploitability, Kevin se demande s'il faut parler de DigiNotar. S'il est vrai que depuis deux semaines, tout le monde en parle, et si certains vont même jusqu'à avancer que les conséquences de cet incident seront plus grave que celles de Stuxnet, ce qu'on n'a aucune peine à croire, je pense qu'on peut encore en parler...

Depuis qu'on a appris qu'un vrai-faux certificat pour *.google.com était activement utilisé du côté de l'Iran, c'est une véritable avalanche de révélations qui tombe sur la tête de l'autorité responsable de tout ce chahut : DigiNotar. Et sur le modèle de sécurité de SSL, évidemment...

On a tant écrit sur la débacle DigiNotar, filiale de Vasco, à côté de laquelle les mésaventures de Comodo ressemblent à une mauvaise blague, que je ne serai probablement pas original dans mes conclusions. Mais tout de même, il y a quand même nombre de choses qu'on sait à présent, et plus encore d'enseignements à tirer de cette histoire.

Sur l'origine de l'attaque. On apprenait en début de semaine que la compromission ne serait pas le fait d'un inconnu. C'est une nouvelle fois le fameux ComodoHacker qui revendique l'attaque. Si c'est effectivement le cas, et rien n'indique que ça ne l'est pas, bien au contraire, nous avons affaire à un individu sans autres moyens qu'une machine, une connexion Internet et un cerveau qui tourne à plein régime. Les motivations qu'il avait exposées à l'époque du ComodoGate étaient essentiellement politiques et tout indique qu'il a agit seul, de manière totalement indépendante.

Sur l'attaque en elle-même. Le gouvernement hollandais s'est immédiatement emparé de l'affaire, action qui a débouché sur la publication d'un rapport intermédiaire par la société Fox-IT. Rapport dont on aimerait que son contenu soit particulièrement croustillant. En fait non, il est navrant de banalité : architecture à plat, serveurs non patchés, scripts vulnérables, mots de passe faibles, IDS inopérant, etc. On notera que l'attaquant a utilisé aussi bien des outils publics archi-connus, qui sont allègrement passés à travers les protections anti-virales^[1], que des scripts développés spécifiquement pour l'environnement rencontré^[2]. On est donc très loin du mythe de l'attaque super sophistiquée qui se glisse subrepticement à travers la messagerie jusqu'à l'utilisateur naïf. C'est de la bonne attaque frontale en règle, patiemment menée sur une période de temps relativement importante.

Sur la gestion de la sécurité par DigiNotar. On a vu que l'infrastructure de l'autorité souffrait, et c'est le moins qu'on puisse dire, de sérieuses carences en sécurité. Mais ce qui est tout aussi intéressant, c'est qu'en lisant le déroulement des évènements décrit dans le rapport, on s'aperçoit qu'un problème a été détecté dès le 19 juin, alors qu'aucun certificat n'avait encore été généré. La première tentative de génération ne sera en effet faite que deux semaines plus tard, le 2 juillet. Les faux certificats seront quant à eux générés sur une période qui s'étale du 10 au 20 juillet. Le certificat pour *.google.com commencera à être utilisé le 27 juillet, date de la première requête OCSP, lequel ne sera révoqué que le 29 août, date à laquelle des mises à jour pour Internet Explorer et Firefox seront mises à disposition. Les opérations de forensics, qu'on imagine consécutives à la détection de l'incident ne commenceront que le 22 juillet. Il se sera donc passé plus d'un mois entre la détection d'incident et la première prise d'action, ce qui a amplement laissé le temps à l'attaquant de faire ce qu'il avait en tête...

Sur les conséquences de l'incident. Un peu plus de cinq cents certificats ont été émis sur une période de dix jours et activement utilisés dans le cadre d'attaques de type Man in the Middle. Pas moins de 300000 adresses IP distinctes, dont 99% originaires d'Iran, auraient utilisé le certificat *.google.com, probablement pour accéder à Gmail, et se seraient donc exposées à un espionnage en règle de leur messagerie. Avec à la clé pour les attaquants, informations personnelles, voire bancaires, et autres données confidentielles.

Sur la faillite du modèle de sécurité de SSL. Je ne vais pas répéter les arguments avancés par Nicolas Ruff au printemps dernier, ils parlent d'eux-même, ou encore disserter sur ce que l'élimination de la folle quantité de faux certificats en circulation aura nécessité des patches^[3] pour retirer purement et simplement l'AC^[4] de la liste de confiance. Les mésaventures de Comodo d'abord et DigiNotar maintenant ne font qu'enfoncer le clou. SSL ne fonctionne en effet que par une délégation de confiance à sens unique, c'est à dire qu'on vous oblige à faire confiance à des gens qui, in fine, n'ont absolument aucune responsabilité à votre égard, et donc rien à vous rendre pour faire en sorte que cette confiance soit placée à bon escient. Et là, le moins qu'on puisse dire, c'est que ce n'était pas le cas...
En outre, ComodoHacker, qui s'est également vanté d'être à l'origine d'une attaque apparemment sans conséquence sur StartSSL, se targue d'avoir compromis d'autres autorités, citant en particulier GlobalSign qui a d'ors et déjà officiellement suspendu ses services et fait appel aux services de Fox-IT. Dernier point qui tendrait à confirmer les dires de l'attaquant...

Sur la réaction du gouvernement hollandais enfin. Parce que DigiNotar, ce n'est pas la petite AC au coin de la rue. C'est une autorité qui délivre des certificats qualifiés dont les signatures sont automatiquement considérés comme pouvant faire preuve lorsque délivrée par des équipements labellisés SSCD, au même titre que les signatures manuscrites. Ce n'est pas rien, et c'est pour cela, en plus du fait qu'elles leur achète des certificats, que les autorités hollandaises s'en mêlent, mais un peu tard. Car si tout cela vient avec quelques contraintes imposées par les lois hollandaises et européennes, comme l'obtention de certifications et la réalisation d'audits récurrents, il aura fallu un incident sans précédent pour s'apercevoir de l'état de l'environnement dans lequel cette autorité opérait.
On aurait donc attendu de la part des autorités hollandais qu'elles se montrent un peu plus pro-actives vis-à-vis d'une AC de ce niveau. Le changement, inévitable, de crèmerie suite à ce clash n'étant finalement pas grand chose de plus qu'un aveu d'impuissance devant l'ampleur des dégâts...

Qu'est-ce qu'on peut en retenir ?

• Qu'une autorité de confiance de haut niveau s'est faite déchirer par un individu avec peu de moyens. Contraste qui servira sans tarder à illustrer le concept d'asymétrie en cyber-défense...
• Que les obligations réglementaires auxquelles elle était soumise n'ont pas empêché cette autorité d'opérer une infrastructure défaillante en terme de sécurité. Ce qui en dit long, encore une fois, sur l'efficacité de la mise en œuvre des certifications et autres audits de conformité...
• Que bien qu'ayant détecté l'attaque, cette autorité ne s'est pas montrée capable de réagir convenablement pour la bloquer. On imagine qu'un maillon clé de la chaîne de décision n'est revenu de vacances que mi-juillet...
• Et pour couronner le tout, que les fruits de la compromission ont été utilisés rapidement dans le cadre d'attaques actives.

On pourra y aller de ses réflexions sur SSL, citer du Moxie^[5] à tour de bras, donner du Convergence et du Perspectives^[6] ou encore lapider DigiNotar sur la place publique. Ce que je retiendrai avant tout de ça, c'est qu'on assiste aujourd'hui à la récolte des fruits d'années d'une gestion de la sécurité de nos systèmes d'information qui n'avait rien de vertueuse. Car le cas DigiNotar, s'il est spectaculaire par ses conséquences, n'en reste pas moins d'une affligeante banalité, pâle copie de tant d'autres compromissions. Et c'est bien là que le bât blesse : que des gens investis de ce genre de responsabilités se fasse compromettre comme des Sony...
Et ça, ça n'a malheureusement plus grand chose à voir avec l'échec de SSL...

En parlant de Sony... Ils se sont enfin trouvé un CISO. Un joli challenge en perspective, comme on dit par ici...

Notes

[1] Y'en avait pas :)

[2] avec un mois devant lui, l'attaquant avait tout le temps pour les écrire, les tester et les peaufiner.

[3] Sauf Chrome quand il s'agit des services Google.

[4] autorité de Certification.

[5] Lequel tape sur SSL depuis presque dix ans.

[6] Que je vous recommande pour Firefox et dérivés...