mercredi 7 septembre 2011

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?

jeudi 1 septembre 2011

kernel.org est compromis.

Le site kernel.org est le site officiel du développement du noyau linux. Il s'agit d'un site massivement mirroré au travers du monde. Un des serveurs, hera.kernel.org (indisponible à cette heure) a été compromis. Le message du site central est éloquent: "Security Breach".  Le message qui suit est une traduction commentée du message initial diffusé sur kernel.org.

La compromission fût détectée fortuitement le 28 Août par un administrateur qui a lu des messages d'erreurs étranges dans le /dev/mem lié à Xnest alors qu'Xnest n'était pas installé... Ceci me fait penser à la vidéo de Nicolas Ruff sur les APT que j'ai visionnée sur le blog de Cédric Blancher. Une des diapositives de sa présentation indique: "Les compromissions sont souvent découvertes par hasard"...

Une seconde analyse attentive du serveur par les administrateurs à montré qu'un troyen était lancé automatiquement au reboot de la machine, signe évident de compromission. De plus les fichiers liés à ssh (openssh, openssh-server et openssh-clients) ont été modifiés et étaient en cours d'utilisation. Apparement le programme malveillant loggait les actions des utilisateurs du système. Une analyse élargie a montré que plusieurs autres serveurs présentaient des erreurs curieuses une fois de plus liées à Xnest, sans qu'il ne soit possible à l'heure actuelle de faire le lien formel entre compromission et messages d'erreurs Xnest. Quoi qu'il en soit, il est conseillé à tous les développeurs noyaux impliqués de vérifier la présence de ce genre de messages sans qu'il ne soit plus donné de précisions (Que faut il chercher? un crash? oops? autre type d'erreur?).

La compromission initiale s'est faite en deux temps selon les administrateurs. L'attaquant aurait utilisé un login/mot de passe (soit faible, soit obtenu par un moyen tiers ce n'est pas précisé) pour obtenir un shell local puis aurait utilisé une faille inconnue pour devenir root. Des recherches sont en cours, une note indique que le noyau 3.1rc2 pourrait bloquer cette attaque sans plus de certitudes.

Une grosse opération de nettoyage est en cours puisque les machines ont toutes été mises off-line pour analyse. Les autorités (haha) américaines et européennes ont été prévenues. Toutes les machines de kernel.org vont être réinstallées. Les 448 utilisateurs de ces machines vont devoir changer de mots de passes et/où de clé SSH.  Et enfin tous les fichiers composant le noyau linux sont analysés, ainsi que les tarballs pour s'assurer qu'aucune modification n'y a été effectuée.

Le message d'alerte termine sur une note positive en indiquant que l'attaque est inutile car le mode de développement de liux est basé sur git. Git calcule un hash SHA-1 de chacun des fichiers composant l'arbre des sources. Il n'est donc pas possible de modifier un de ces fichiers, et donc l'attaquant n'a pas de possibilités de "trojaniser" un noyau linux qui sera diffusé par la suite. Un deuxième avantage lié au mode de développement décentralisé de linux fait qu'il existe une quantité innombrable de duplicata de ces sources, permettant ainsi de détecter le changement entre deux versions. Le message termine par ces mots "(we) are confident that our systems, specifically git, have excellent desgin to prevent real damage from these types of attacks".

Dans un sens, oui, ils ont raison, mais je ne suis pas rassuré pour autant. Je ne suis pas développeur, je n'utilise donc pas git, je ne peux donc pas compter sur son mécanisme de checksums élaboré. Je télécharge mes noyaux en tar.bz2 sur un des mirroirs cités plus haut en vérifiant sa signature. Et la vérification de signature, http://www.kernel.org/signature.html, le dit bien: "This signature does not guarantee that the Linux Kernel Archives master site itself has not been compromised.". Donc à l'heure actuelle, je ne vais sûrement pas télécharger de noyaux :-) Le second point qui m'inquiète toujours un peu dans ce genre de compromissions c'est le flou artistique (apache, redhat) qui entoure la compromission. La communication est toute à leur honneur et est je pense essentielle. Néanmoins, j'aimerai également (vœu pieux) un gros travail de communication rétroactif une fois la crise passé pour pouvoir prendre le temps d'analyser cette compromission à froid.

EDIT: les serveurs ne sont toujours pas remontés. Linux Torvalds a choisi de migrer l'arbre des sources sur github.