Parler ou pas de Diginotar?

En ce moment, on entend énormément parler de l'EPIC FAIL de Diginotar qui s'est fait pirater. Mais cela vaut il la peine d'en parler? Nous savons que l'architecture SSL d'internet repose sur la confiance que l'on donne à une liste d'autorités installées par défaut dans notre navigateur.
News0ft a écrit un excellent post de blog expliquant pourquoi SSL est cassé. Il faut aujourd'hui compléter son post de blog en ajoutant que l'architecture SSL est encore plus cassée si l'on prend en compte la faible sécurité des infrastructures des entreprises délivrant des certificats.


On refait le match:
A l'origine, nous avons un blogueur iranien qui détecte à l'aide du public key pinning de google chrome que le certificat de gmail n'est pas le bon. Il envoie un message sur twitter, puis le security circus s'emballe et s'enflamme.
Résultat de ce bruissement, pas grand chose. On savait déjà qu'il est possible de faire du MiTM sur SSL tant qu'on a un certificat adéquat, on savait déjà que les CA sont le maillon faible de l'architecture de confiance, et le seul fait finalement intéressant et à discuter concerne l'EPIC FAIL de diginotar.


EPIC FAIL:
La lecture du compte-rendu de l'attaque par l'entreprise Fox-It est édifiante. Dans l'ordre, nous avons:

• des serveurs webs non patchés (Un message intéressant de F-secure indique que les serveurs webs de diginotar ont été hackés une première fois en mai 2009 (!) Ceci dit, nulle part n'est indiqué comment cette date a été trouvée.)
• une infrastructure critique sans antivirus, le pirate a pu utiliser des outils comme Cain&Abel.
• un mot de passe faible
• un unique domaine windows, ce qui permet avec un seul login/mdp de naviguer sur l'ensemble du réseau
• un accès direct à l’infrastructure de signature de certificats, alors que la règle veut que ces machines soient déconnectées de tout réseau (et pour y avoir travaillé, je confirme que j'ai vu dans des grandes entreprises la CA sur un portable déconnecté du réseau dans un coffre).
• Le pirate a pu générer plus de 500 certificats (!!!) et les récupérer. Il devient évident que la CA de diginotar doit être évacuée des magasins de certificats.

La timeline des évènements m'étonne également beaucoup:

• Le 6 juin 2011 le pirate arrive.
• Le 17, il a la main sur la DMZ
• Le 19 juin Diginotar détecte la compromission (et que font ils? Ils prennent le café? Ils font une réunion pour se tenir chaud?)
• Le 2 juillet le pirate essaye de créer des certificats. Le 10 juillet, il y arrive, le premier est celui de *.google.com
• Le 20 juillet, le dernier certificat est créé. 
• Le 27 juillet, une requête OCSP pour *.google.com arrive chez diginotar. 
• A partir du 4 août, un énorme afflux de requêtes OCSP proviennent de l'iran.
• Le 27 août un message est posté sur un forum google (27 selon le rapport, 28 selon le message du forum?)
• Le 29 Août le faux certificat de google est révoqué. 
• Le 1er septembre OCSP fonctionne sur un mécanisme de whitelist, je suppose que c'est face à l'étendue de la débâcle découverte par Fox-it.

Et le pirate:
Le pirate semble être le même que Comodohacker. Son message sur pastebin semble véridique, et le rapport note quelques similitudes entre les deux attaques. Un seul point diffère entre l'analyse de Fox-it et les dires du pirate: il affirme s'être connecté sur un réseau déconnecté d'internet pour faire signer ses certificats, Foxit indique que l'architecture signant les requêtes était joignable depuis un réseau d'administration.
Il a posté deux nouveaux messages confirmant son attaque. [tiens, je vais supprimer Globalsign de mon magasin de certificats juste au cas où :-) ]
Update: Cela se confirme, Globalsign a décidé de ne plus signer de certificats le temps de vérifier ses infrastructures.
Update: le pirate continue d'émettre sur pastebin ses messages. Rien de neuf si ce n'est qu'il indique être très fort et qu'il faut le prendre très au sérieux.


Sooooo, what's the point?
Eh bien on apprend qu'un pirate peut attaquer avec succès des sociétés délivrant des certificats, et que de ce fait les communications SSL peuvent être écoutées. Comme je disais en introduction, rien de bien neuf, cela vaut il la peine d'en parler? Sur internet, "trust, but verify" est de mise. Je rappelle les extensions firefox données sur le blog de News0ft: perspectives et certificate patrol.
Update: On lit encore sur internet des déclarations outrées sur le fait que le pirate ait pu avoir l'accès à la clé privée de la CA de diginotar. Je ne pense pas qu'il y ait eu accès, s'il avait cette clé, il n'aurait jamais fait signer par diginotar ses +500 certificats. Je pense à la lecture du compte-rendu de FoxIt et du message de ComodoHacker que le pirate n'a eu accès qu'au workflow de signature de certificats, a pu ajouter les siens puis récupérer les certificats signés à la sortie. En ce sens, il y a du FAIL chez diginotar qui aurait du détecter que le nombre de certificats variait, de plus des alertes devraient être levées dès que des wildcards ou des certificats au nom de "google" ou autre nom sensible sont demandés.

Par contre, puisqu'on apprend actuellement toutes les semaines que des grandes infras sont piratées, je jetterai bien une idée en l'air. Et si on imaginait que nos infras étaient piratées? Là, maintenant. Qu'on lance le même genre d'investigations poussées suite à un incident avéré. Qui serait capable de lancer un audit complet? Que trouverions nous dans nos infras?