mardi 16 mars 2010

Analyse DNS comportementale anti-botnets

L'administrateur réseau et sécurité doit surveiller son réseau pour détecter des activités malveillantes afin d'y parer. Le problème est classique et revient à s'interroger sur ce qui différencie une action normale d'une action malveillante. L'evil Bit étant resté au rang de draft, le meilleur moyen consiste d'avoir des logs et de les consulter.
Le log management est une activité à part entière et généralement on est coincé entre des logs gigantesques contenant forcément l'information pertinente, mais noyée, et des logs réduits qui ne sont finalement que quelques statistiques facilement exploitables, mais loin d'être suffisantes.

Aujourd'hui, le risque, c'est le botnet. Les filtres IP en bordure deviennent puissants, de niveau applicatif, et il devient difficile de les attaquer de front. Toutefois, cela n'empêche pas les botnets de communiquer. Certains utilisent des protocoles de type P2P, ce qui peut se bloquer simplement, d'autres des requêtes web légitimes protocolairement parlant ce qui est bien plus compliqué à bloquer.

Toutefois, je pense qu'il est possible de tracer l'activité de machines zombifiées. Tout d'abord, il faut se poser la question: "que font ces machines?". Elles se connectent au canal de commande et contrôle, puis obéissent aux ordres reçus. Ces ordres sont (je schématise), soit envoyer du SPAM en quantités, soit servir de relais web (ou P2P) pour héberger du malware servant à infecter les futures victimes. La partie qui transforme la machine en site web ne m'intéresse pas. Regardons de plus près les autres activités.

Effectuons une analyse rétroactive. Ces machines vont donc tôt ou tard envoyer du SPAM. Cette activité revient à envoyer du mail. Comment envoie-t'on un mail? En débutant par une requête mail MX pour trouver l'adresse IP du serveur mail de destination. Ceci est donc une trace permettant de lever une suspicion légitime: toute machine de son réseau effectuant une requête DNS MX doit immédiatement être investiguée plus en avant.

Mais à l'origine, le zombie doit se connecter à son canal de commande. Encore une fois, il doit réaliser une requête DNS pour trouver l'adresse IP de destination. Il s'agit d'une requête de type A, banale, commune à toutes les autres requêtes. Toutefois, je pense qu'on peut creuser par là. Les domaines changent en permanence, inutile de vouloir corréler la dessus. Par contre, un point m'a toujours étonné: comment font ces botmaster pour déposer 5000 noms de domaines par jour, alors qu'en déposer un me coute 5 euros? La réponse est simple, il suffit de trouver un registrar complaisant. Et ce point me semble suffisement important pour être noté.
Donc il suffit de surveiller son DNS, et chercher les authoritative DNS pour chaque domaine interrogé. Ensuite, une liste est faite entre les DNS "finaux" si je peux dire, et les requêtes faites par les machines locales. Cette liste permettra d'indiquer une part de "crédibilité" du serveur DNS répondant du domaine. Si un léger pourcentage des machines de mon réseau interroge régulièrement des serveurs DNS hébergés chez un fournisseur n'ayant pas toute les garanties, cela doit être un signal d'alarme.
Comment connaître ces DNS douteux? Je pense que la géolocalisation IP est une piste qui doit être corrélée avec les AS contenant les serveurs.
Petit à petit, il doit être possible de donner un indice d'innocuité ou non à des serveurs DNS, à la manière de DNSBL ou autre mécanisme de ranking.
Idéalement, il serait sans doute possible d'identifier un botnet via ses serveurs DNS de références (quel AS, quel registrar, etc...)

Le volume de ces données doit rester gérable même pour des gros réseaux en fonction des doublons. Chaque nom de domaine doit être unique dans la base. Ensuite, chaque enregistrement des serveur DNS doit remonter la liste des domaines dont il s'occupe.

Quoi qu'il en soit, cela ne réglera pas le problème des botnets. Cette méthode permet à mon avis d'être plus proactif dans la détection des machines zombifiées sur un gros réseau uniquement avec une analyse des logs DNS:
-si une machine émet une requête DNS MX, alors une analyse est nécessaire
-un log continu des requêtes DNS A des machines doit permettre de trouver assez rapidement quelles machines vont se connecter sur le botmaster, et devra mener à une analyse approfondie.
Pour valider cette analyse j'aurais besoin de grandes quantités de trafic DNS sur un réseau vaste. Je ne pense pas que cela se trouve facilement sur internet. Toutefois, cela mériterait qu'on s'y arrête, ne serait-ce que pour essayer.

jeudi 11 mars 2010

Feynman, les coffres forts et les mots de passe.

Je viens de finir de lire "Vous voulez rire, Mr Feynman" par lui-même. Il retrace entre autre la manière dont il est devenu un expert en ouverture de coffres-forts.
Mr Feynman, physicien de profession (Nobelisé) a travaillé pour le projet Manhattan. Les documents relatifs aux recherches devaient bien entendu être stockés de manière sécurisée. A cette époque, il n'y avait pas d'informatique, mais la problématique de la sécurisation de l'information était la même qu'aujourd'hui.

Tout d'abord, il s'est rendu compte que les coffres ne fermaient tout simplement pas (!). Il suffisait de passer la main par l'arrière du coffre pour accéder aux documents.
Si on parle d'informatique sécurisée, cela signifie qu'il est donc essentiel de pouvoir valider la solidité de l'algorithme employé.

Suite à cela, de nouveaux coffres sont arrivés, disposant de trois roues crantées, allant de 00 à 99. Feynman s'y est attaqué par jeu. Il n'était pas possible de contourner la porte pour accéder aux documents. Après quelques tests pour mettre les roues en place manuellement, tester l'ouverture, changer de combinaison etc, il s'est rendu compte que le bruteforce n'était pas réalisable.
Après s'être renseigné sur les méthodes des perceurs de coffres, il s'est rendu compte que les méthodes se basaient sur l'intuition mélée à de la chance. En effet, il était conseillé de tester des dates connues, des dates de naissances, des chiffres particuliers (comme 3.14159, ou 2.71828). L'autre solution consistant à chercher des papiers collés sur le bureau ou dans les tiroirs sur lesquels étaient inscrits des chiffres sans signification évidentes. Il est intéressant de retrouver rigoureusement les mêmes conseils à l'heure de l'informatique; seul le post-it a remplacé le papier scotché ;)

Ces méthodes ne lui ont pas permis d'ouvrir beaucoup de coffres; il préférait trouver une méthode fiable pour pouvoir tous les ouvrir.
Après quelques tests, il s'est rendu compte que les roues crantées avaient du jeu. En effet, si 45 était la valeur correspondant à une roue, alors 43, 44, 45, 46 et 47 fonctionnaient aussi. Après quelques entrainements, il a calculé que le bruteforce tombait à 8h pour toutes les combinaisons. C'était malgré tout toujours trop. Après plusieurs tests complémentaires sur son coffre, il a vu que lorsque le coffre était ouvert il pouvait facilement manipuler la première et seconde roue, ce qui lui permettait de connaitre avec une précision acceptable leurs valeurs. Le brute force (qui ne se faisait que sur la troisième roue et quelques valeurs des deux premières tombait à 20mn).

Il est donc allé voir ses collègues, et tout en discutant, il s'approchait de leur coffres ouvert en manipulant les roues. Après quelques temps, il a connu la plupart des codes des deux premières roues de la majorité de ses collègues. Cela lui assurait un grand prestige lors des situations de crises ou un document nécessaire était indispensable et la personne absente. Il ajoutait un peu de cinéma ("laissez moi seul avec mes outils et le coffre") et sa réputation fût faite. S'il s'agisssait d'un bureau dont il ne connaissait pas le code, il prétextait un travail urgent pour ne pas avoir à le faire.
Le bruteforce est resté, il s'est simplement réduit. En crypto, on retrouve un peu les mêmes méthodes. Si le code est solide, alors on fait de la bruteforce. Si la bruteforce est hors de portée, alors on réduit l'espace de solutions pour que la bruteforce redescende en un temps acceptable. A force de travailler avec des gens, il est fréquent de connaître une partie de leurs mots de passes. Untel qui a tapé son mot de passe derrière son login sans taper entrée, tel autre qui n'utilise que le pavé numérique, etc..

Pour finir, deux anecdotes. Le général en chef, sachant que Feynman était fort pour ouvrir des coffres, s'est fait livrer le coffre le plus gros le plus lourd et le plus cher qu'il existait. Il se méfiait énormément de Feynman, l'empêchant d'accéder au coffre. Un jour vint, ou il fallait un document dans ce coffre alors que le général était absent et injoignable. Feynman a décliné l'offre lui demandant de l'ouvrir. Malgré tout le coffre a été ouvert par le serrurier de la base! Ce serrurier avait en effet constaté que les coffres de cette compagnie arrivait avec deux codes, toujours les mêmes. Il a essayé le premier, échec. Le second code l'a ouvert :) Feynman s'est immédiatement renseigné sur les codes par défaut avec lesquels étaient livrés les coffres.
Une autre fois, Feynman attendait un collègue dont il ne connaissait pas les codes des deux premières roues. Il a essayé e au cas ou (e=2.71828, soit 27-18-28). Le coffre s'est ouvert. Avisant un second coffre, il essaye le même code, qui fonctionne aussi. Et cela s'est reproduit avec les 6 coffres de ce bureau. N'utilisez jamais le même code de partout! Pour connaître un très grand nombre de codes, montez dans votre entreprise (ou site web communautaire) un quelconque truc (genre wiki) qui demande une authent. Ré-essayez les codes que les utilisateurs vont vous fournir sur d'autres accès.. Le succès est garanti.

Les technologies changent, mais les faiblesses humaines restent décidément les mêmes :)