À 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és 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 motto 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...

Update (29/03/2011) : Robert Graham poste une interview quelque peu décevante de ComodoHacker, lequel a encore étayé ses affirmations en publiant le vrai-faux certificat pour addons.mozilla.org, clé privée comprise, ainsi qu'une archive de quelques 800 mots de passe...

Update (30/03/2011) : Deux autres RA ont apparemment été compromises en plus de d'InstantSSL.


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


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