Ma petite parcelle d'Internet...

Pourquoi est-ce que je trouve le whitepaper de Damballa décevant ? Les chiffres parlent d'eux mêmes. Treize pages. Onze d'annexes dont une page contenant trois exemples de corps de spam accompagnant le malware, sept pages complètes de noms DNS dynamiques utilisés par les bots et deux pages de hashes MD5 de variantes du binaires. Ce qui nous laisse trois pages, dont une sert à décrire la société, soit au final deux pages de texte utile. Dans ces deux pages, la moitié de la première constitue l'overview qui constituera en fait le seul passage descriptif du botnet, le reste étant consacré à la détection et la désinfection. Non que je considère que cette dernière partie ne soit pas intéressante, mais considérant qu'un autre whitepaper, disponible sans avoir à s'enregistrer^[1], est consacré à ce sujet précis et fournit nettement plus d'informations...

On y apprend tout de même que Kraken se réplique par email, la bonne vieille technique qui, depuis le ver "I Love You", n'en finit pas de démontrer son efficacité, en se connectant directement sur le port TCP/25 d'adresses codées en dur dans le binaire, qu'il génère des noms aléatoires chez des fournisseurs de services DNS dynamiques^[2], que le botnet utilise UDP/447 et TCP/447 pour ses communications, lesquelles, enfin, sont chiffrées. Tout ça pour ça...

Bref, n'allez pas vous ennuyer à télécharger ce papier, je viens de vous en donner l'essence, qui est de plus disponible partout à l'heure où j'écris ces lignes, et en particulier chez DVLabs. C'est certainement très bien pour briller en société autour d'un ver de champagne et trois petits fours, ou encore justifier des interviews sur 01Net, mais pour ce qui est de faire avancer la science, bof.

Bref, laissons tomber Damballa, et concentrons-nous donc sur les deux billets de TippingPoint. Le premier, celui de Cody Pierce, se concentre sur l'analyse du binaire. La première chose que ce dernier fait lorsqu'il est exécuté consiste à contacter un server CC^[3] sur UDP/447 à l'aide d'un protocole spécifique. Les cibles de ces tentatives sont les fameux noms DNS dynamiques générés aléatoirement. Le germe utilisé pour cette génération est apparemment fixe, ce qui fait que nos bots contactent les mêmes noms en séquence lorsqu'ils sont activés. En testant quelques uns des enregistrements ainsi générés, ils ont certes pu découvrir un véritable serveur CC, mais également pu enregistrer l'un d'entre eux pour infiltrer le botnet en ce faisant passer pour un serveur. C'est de là que part le billet de Pedram Amini.

Pour ce qui est des communications, elles sont effectivement chiffrées. Il s'agit d'un algorithme propriétaire dont la clé, d'une longueur de 64 bits, est spécifique à chaque nœud. Elle est envoyée dans les huits premiers octets en tête de chaque paquet, en clair, pour que le master puisse déchiffrer le payload. Autant dire que c'est trivial à casser. Cela fait penser à la technique d'obfuscation de flux utilisée par Skype, basée sur RC4 et des clés placées en tête de connexion pour TCP ou de paquet pour UDP. Mais sans véritable chiffrement derrière par contre...

Vient ensuite la description du protocole de communication avec le master qui contient un certain nombre de fonction dont, en particulier, un lui permettant de télécharger des modules sur TCP/447 et de les exécuter localement. Ce qui est intéressant, c'est qu'il n'y a aucune forme d'authentification dans ces communications. À partir de là, il est relativement simple de se faire passer pour un master et de prendre le contrôle d'un zombie en lui faire exécuter du code arbitraire. Ce qui peut faire sourire au premier abord constitue malheureusement une porte béante offerte à n'importe qui pour prendre tout ou partie du botnent à son compte. Parce que les guerres de botnet, tout le monde le sait, ça n'existe pas. On s'attend donc à voir un Über-Kraken pointer le bout de son nez...

Le deuxième billet, celui de Pedram Amini, s'intéresse à l'analyse du botnet dans son ensemble, avec une surveillance de l'activité d'une machine se faisant passer pour un server CC pendant une semaine. Durant cette période, ils ont pu voir 65000 différentes adresses IP leur envoyer du trafic, lesquelles correspondraient à 25000 machines uniques. Ils ont pu constater de nouvelles infections chaque jours, venant principalement des USA, d'Espagne et d'Angleterre. On remarque que ce sont les pays hispanophones les plus touchés. Pourquoi ? Mystère et boule de gomme.

Au final, je suis un peu déçu. Pas par le travail fourni dans cette analyse, mais par Kraken lui-même. Je m'attendais en effet à quelque prouesse technologique permettant d'expliquer un tel niveau d'infection, variant entre 185000 et 600000 selon les sources. Mais non. C'est du grand classique. Réplication par email directement sur le port TCP/25 et protocole trivial sur un port spécifique, 447, en UDP et TCP. Et certaines des machines infectées seraient dans les réseaux du fameux "Fortune 500". Ce qui amène immédiatement la question de taille qui revient à chaque infection massive. Comment ce genre d'entreprises arrivent encore à se faire gauler par des mièvreries de ce genre ?

Sans blague. Qu'ils se fassent infecter, passe encore. Mais que leurs machines parviennent à sortir sur UDP/447 pour participer joyeusement au crime organisé me navre au plus haut point. D'ailleurs, pourquoi se limiter au "Fortune 500" ? Ce n'est pas comme si ça faisait une demie-douzaine d'année qu'on rabâchait la même rengaine aux entreprises sur le filtrage des flux sortants. Genre bloquer tout trafic vers TCP/25 à l'exception de son serveur SMTP, ou encore bloquer les ports non utilisés... Parce que si vous faites ça, non seulement vous allez non seulement empêcher vos machines de répandre l'infection et de participer au botnet, mais également détecter les hôtes infectés^[4]. À moins que...

À moins que ces arguments de "Fortune 500" ne soient que du vent. L'argument éculé à caser en tête de rapport pour faire parler de son travail. Non pas que je pense que la sécurité de ces entreprises soit à ce point élaborée, mais ce que constate TippingPoint, c'est que l'essentiel des adresses enregistrées sont des accès résidentiels. Pas des accès entreprise. Et là, tout de suite, ça cadre un peu mieux. Des machines ouvertes à tout vent, sans aucun filtrage, ni dans un sens, ni dans l'autre, voilà qui explique mieux un tel taux d'infection.

Et tout ceci a le bon ton, encore une fois, de soulever quelques polémiques à la peau dure. D'abord celle concernant la diffusion de gentils vers qui nettoient tout le monde. Étant en position de prendre la main sur les 25000 zombies qu'ils ont vu passer, la tentation était grande pour DVLabs de leur envoyer un payload bien senti pour nettoyer ces machines. Ensuite, la polémique sur le filtrage des ports en sortie chez les fournisseurs d'accès résidentiels, TCP/25 en tête. Deux questions épineuses s'il en est, mais qui ont le bon goût de détourner l'attention du problème de fond, à savoir qu'on ne sait pas comment gérer l'utilisateur final...