Des véreux de Comodo

C

omme les rédacteurs en chef de MISC n'ont pas le monopole du calembour pourri, c'est ainsi que j'ai décidé d'attaquer cette bafouille sur la énième frappe attribuée à l'APT. Celle qui a compromis l'autorité de certification de Comodo avec, comme conséquence directe, l'émission de neuf certificats véreux.

La réaction fut rapide : révocation des certificats, mise à jour des listes pour les navigateurs, communication à l'envie, etc. Bref, le grand jeu, et vous en avez entendu parler toute la semaine dernière. C'était sans compter sur deux documents apparus ce week-end qui viennent pour le moins jeter le trouble dans les analyses les plus inspirées...

À en croire le communiqué de celui qui se présente sous le surnom explicite de ComodoHacker, l'attaque serait en fait l'affaire d'un seul homme, un informaticien iranien de vingt-et-un ans, patriote, passablement irrité par la couverture médiatique accordée à Stuxnet et à l'égo surdimensionné. La piste iranienne évoquée serait donc exacte, l'attaquant n'ayant pas jugé bon de passer par des proxies anonymisant ailleurs dans le monde, mais on serait donc pour le moins assez loin de la guerre numérique que certains n'hésitent pas à annoncer. Les éléments avancées ne sont certes pas vérifiables par le commun des mortels^[1], vu que ces détails n'ont pas été publiés par Comodo. Mais force est de constater que le scénario présenté est très loin de manquer de crédibilité, d'autant qu'il s'accorde tout à fait avec les éléments disponibles.

L'attaquant aurait dans un premier temps pénétré le serveur Web d'InstantSSL qui vend, justement, des certificats Comodo auprès duquel ils jouent le rôle de Registration Authority. Le serveur en question hébergerait du code lui permettant de déclencher la signature de certificats, lequel se présenterait sous la forme d'une DLL. Cette même DLL dont la décompilation a été publiée hier, et dans laquelle on trouverait toutes les informations nécessaires à l'émission d'un certificat signé en bonne et due forme par la CA racine de Comodo : URLs, login, mot de passe, API.

Mais #FAIL! s'exclameront certains^[2]. Je ne sais pas si on peut aller aussi loin^[3], tant il est toujours facile de juger après coup. Toujours est-il qu'il est surprenant que la compromission du site web d'un tiers, même de confiance, puisse entraîner ce type de conséquences. Le chemin semble en effet étonnamment court... Pour autant, toute personne ayant un jour eu l'occasion de s'essayer aux architecture multi-tiers de ce type, genre système de paiement en ligne par exemple, sait combien ce genre de situation est malheureusement un grand classique. Ce qui se traduisait en particulier par une des conclusions notables du rapport annuel produit par Verizon Business en 2008 sur l'analyse de diverses compromissions. À savoir que dans un peu plus d'un incident sur trois^[4], un partenaire avait été mis à contribution par l'attaquant. On est en plein dedans...

Le mojo de Comodo, société qui, en plus de certificats, vend pleins de produits et de services de sécurité, est "Creating Trust Online". Sauf que la confiance, ça ne se crée pas ; ça se construit. Alors évidemment, c'est plus facile à dire qu'à faire, mais globalement, on ne décide pas de faire confiance à un sous-traitant ou un partenaire juste parce qu'il a signé quatre papiers dans lesquels il promet, juré craché, de prendre la responsabilité de sécuriser son infrastructure et, parfois, de payer les pots cassé si jamais... Parce que si ce genre de promesse a le bon goût de satisfaire les juristes, il en va tout autrement quand ça vous pète à la gueule. Là encore, on est en plein dedans. Sans me lancer dans un savant calcul de partage de responsabilité^[5], il est clair que Comodo en a pris plein la figure, alors qu'InstantSSL n'a pas été, jusqu'à ce matin, été trop exposé. Et je conclurai là-dessus en paraphrasant Audiard, "les responsabilités ça se divise, les dégâts ça s'additionne".

Enfin, il faudra noter que ça fait plusieurs fois que les pratiques douteuses de certaines autorités de certification sont pointées du doigt. Et ce d'autant plus qu'elles mettent à mal un bonne partie du système, quand ce n'est pas son ensemble. Là encore, on se rappellera la fameuse attaque publié au 25C3 permettant de forger des certificats de CA intermédiaire en passant par... une autorité des plus laxiste...

Sinon, si vous voulez lire quelques lectures intéressantes sur la question, je vous conseille :

• un excellent billet de Jacob Appelbaum ;
• la foire aux certificats dénoncée par Sébastien Sauvage ;
• l'analyse de Robert Graham sur le communiqué du pirate, à laquelle je n'adhère pas à 100% mais où on trouve pleins de choses très justes.

Et pendant ce temps, à Vera Cruz, MySQL se serait fait pwner par... une injection SQL. Décidément, les temps sont durs... Et personne n'y échappe...

Notes

[1] On pourrait également avancer, pourquoi pas, qu'il s'agit de désinformation.

[2] Souvent assorti d'un LOL...

[3] On peut en tout cas clamer un "APT attribution fail"...

[4] 39% pour être exact.

[5] Signer directement avec sa root CA des CSR émises par des RA tierces n'est pas forcément la meilleure idée du monde...