Botnet

Vulnérabilité Java CVE-2012-4681 – Et si on devenait enfin responsables !

In English anglais

Mise à jour : 30/08/2012 20h10

Oracle vient de publier une mise à jour au moteur Java standard (versions 6 et 7). Il vous est recommandé de le mettre à jour si vous avez Java installé sur votre machine.

Une mise à jour de l’information sur cette vulnérabilité est publiée sur le site d’Oracle. Une analyse de la mise à jour est publiée ici.

Le tweet où tout commence

Vous en avez peut-être entendu (ou lu) parler ici (Korben), ici (eh oui ça touche les Mac aussi!), au Monde Informatique ou même ici (l’ANSSI vous en parle)… Assez peu toutefois dans la presse grand public (en tous cas je n’ai rien trouvé ?), même si des blogs destinés à un public assez large l’évoquent en détail (Numérama ou Malekal).

Il s’agit d’une faille (apparemment un cumul de deux failles), dites 0-day, parce que non révélées auparavant et encore exploitables parce que le produit qui est ciblé n’a pas encore été corrigé. Cette vulnérabilité, référencée sous le nom de code “CVE-2012-4681” dans la base de référence américaine du MITRE, touche le moteur Java de la société Oracle dans sa version 1.7, soit la plus récente. Le CERT US détaille la vulnérabilité.

Chronologie

On vit cette fois-ci un enchaînement et une combinaison de phénomènes particulièrement défavorable (Eric Romang analyse aussi une partie de cette chronologie):

  • 04/2012… (j’en parle un peu plus bas)
  • 26/08/2012, FireEye publie sur son blog l’annonce de cette vulnérabilité jusque là inconnue. Elle leur est révélée grâce à l’étude de ce qu’ils décrivent comme une attaque ciblée d’un de leurs clients (d’autres spécialistes comme Eric Romang ou la société Trend Micro ne croient pas à cette analyse, mais plutôt à une vulnérabilité circulant déjà peut-être depuis quelques mois, Symantec de son côté effectue un rapprochementavec les attaques ciblée d’une équipe surnommée Nitro)
    • FireEye a eu quelques jours auparavant des soucis avec une découverte qui n’en était pas une, alors qu’ils annonçaient avoir découvert un serveur de commande du botnet Gauss, commun avec celui d’un autre botnet semblable, Flame. En réalité c’est la société antivirus Kaspersky Lab qui avait mis en place un serveur pour reprendre le contrôle de ces deux botnets. Cela a peut être précipité leur publication expresse de l’information sur cette vulnérabilité.
  • L’annonce est reprise de nombreuses fois dans beaucoup de blogs sur la sécurité informatique, y compris avec des codes de démonstration (PoC). S’agissant d’une vulnérabilité indépendante des systèmes d’exploitation, elle est potentiellement exploitable sur tous, de Linux à Microsoft Windows en passant par MacOSX.
  • 27/08/2012, il semblerait que les développeurs de différentes plateformes d’exploit annoncent à leurs ‘clients’ qu’ils vont pouvoir profiter eux aussi de cette vulnérabilité très rapidement (Brian Krebs en parlait lundi au sujet de BlackHole et très vite des chercheurs en sécurité repèrent des serveurs malveillants qui l’exploitent) et selon Kafeine (et ici), l’exploit kit Sakura et Sweet orange semblent être sur les rangs. Je vous ai parlé des plateformes d’exploit dans mon article de décembre 2011 sur le rançongiciel gendarmerie ou dans l’article de février dernier sur le botnet Citadel.
  • 27/08/2012, toujours, Rapid7 annonce que sa plateforme de tests d’intrusion et d’évaluation sécuritaire Metasploit intègre cette nouvelle vulnérabilité dans sa batterie de tests;
  • 28/08/2012, en fin de journée, l’équipe du Kaspersky Lab pousse un petit coup de gueule. On ne sait trop si c’est contre FireEye (encore, la guerre de communication entre les sociétés de sécurité ?) ou bien contre ceux qui ont publié très rapidement des “PoC” (proof of concept, démonstrateurs de l’exploitation de la vulnérabilité).

  • 29/08/2012, on apprend qu’Oracle aurait été avisé de ces vulnérabilités dès le mois d’avril (ComputerWorld) par la société polonaise Security Explorations. Notons qu’il est normal que des vulnérabilités ne soient pas corrigées immédiatement par les développeurs d’un logiciel, le développement d’une correction demandant parfois de nombreux tests pour éviter que de nouvelles failles ou dysfonctionnements soient créés par ces changements.
  • 30/08/2012, à ce jour, Oracle ne reprend toujours pas l’alerte sur cette vulnérabilité et ne semble pas vouloir publier de mise à jour avant celle qui est programmée pour le mois d’Octobre 2012:

Quelque chose ne va pas dans le monde de la sécurité

Je suis assez d’accord avec certains qui ne sont pas satisfaits de cette chronologie, même si elle permet de démontrer un enchaînement particulièrement prévisible, mais qui est ici exacerbé, en moins de trois jours on aura eu:

  • Une société de sécurité qui publie brutalement des informations sibyllines, mais assez faciles à déchiffrer, relatives à une vulnérabilité;
  • Quelques heures après, des chercheurs s’empressent de publier presque en se faisant la course au premier qui le fera, grâce aux éléments diffusés par la dite société, des détails sur la vulnérabilité et la façon de l’exploiter;
  • Un éditeur qui ne communique pas vers son public sur les mesures qu’il envisage de prendre tout de suite ou prochainement;
  • Quelques heures après, les démonstrateurs publiés sont directement intégrés dans les plateformes d’exploits utilisées par les groupes criminels;
  • Très rapidement, des victimes se font exploiter de façon massive, notamment pour diffuser les virus bancaires et autres rançongiciels particulièrement actifs actuellement.

Il est grand temps que les professionnels de la sécurité informatique se mettent enfin d’accord sur des procédures responsables de divulgation des vulnérabilités et ce de façon coordonnée (développeurs, comme chercheurs en sécurité de tous bords). Au vu des conséquences des exploitations aujourd’hui possibles grâce au type de botnets qui sont en activité, il est fort probable que plus de 100.000 euros aient été déjà détournées de victimes à travers le monde (les montants sont difficiles à évaluer, mais c’est l’ordre de grandeur de ce qu’on constate comme gains sur certains botnets en un ou deux jours et comme beaucoup agissent en même temps et que cette vulnérabilité n’est pas forcément celle qui est utilisée pour toutes les attaques il est encore trop tôt pour être plus précis), et vraisemblablement le compteur va finir de tourner tant qu’une mise à jour de Java n’est pas massivement diffusée. Par ailleurs, depuis lundi, des milliers de responsables informatiques se grattent la tête à travers la planète pour savoir comment sécuriser leurs réseaux et s’échangent des scripts pour rapidement désactiver Java 1.7 chez leurs utilisateurs.

Que puis-je faire chez moi ?

Sur un ordinateur personnel, il est vraisemblable que vous n’ayez pas besoin très souvent de Java, même s’il est parfois nécessaire pour certaines applications disponibles en ligne. Il est donc raisonnable d’envisager de désactiver Java dans son ordinateur, au moins pour la version 1.7.

Plusieurs sites expliquent les procédures: le blog Malekal, ou encore ici en anglais. Vous pouvez vous prémunir de ce type d’attaques et bien d’autre en installant des extensions de sécurité telles que NoScript (http://noscript.net/ pour Firefox ou Notscripts ou Scriptno sous Chrome) qui vous permettent d’avoir un contrôle site par site du lancement grâce à des programmes intégrés (scripts) de ce type de modules depuis une page Web.

Dans une entreprise, beaucoup seront peut-être encore à la version précédente qui certes a d’autres vulnérabilités mais permet de faire tourner certaines applications. Si Java n’est pas nécessaire dans votre entreprise, il semble aujourd’hui urgent de le désactiver pour éviter tout incident. Si Java 1.7 est indispensable dans votre contexte, il existe des correctifs non officiels qui pourraient vous aider.

Faites circuler l’information et continuez de vous tenir informés des bonnes pratiques.

Mise à jour : 30/08/2012 20h10

Oracle vient de publier une mise à jour au moteur Java standard (versions 6 et 7). Il vous est recommandé de le mettre à jour si vous avez Java installé sur votre machine.

Une mise à jour de l’information sur cette vulnérabilité est publiée sur le site d’Oracle.

Le DNS cible de toutes les attaques?

Le DNS (domain name system – voir l’article de Wikipédia) est ce service qui permet à votre ordinateur de faire le lien entre un nom de serveur et une adresse IP. Il permet aussi aujourd’hui de diffuser de plus en plus d’informations contribuant à la sécurité des domaines sur Internet. L’actualité de ce début d’année 2012 offre de nouvelles occasions d’en parler, abordons deux d’entre elles:

  • DNS Changer, un logiciel malveillant que l’on croyait maîtrisé, fait encore et toujours parler de lui et pourrait très bien empêcher certains d’entre nous de naviguer d’ici quelques jours ;
  • Une nouvelle vulnérabilité dite des “domaines fantômes” (Ghost domains) a été révélée récemment par des chercheurs, qui pourrait permettre à des domaines abandonnés ou fermés de continuer à survivre dans certaines portions de l’Internet et permettre des abus.

DNS Changer

Le 9 novembre 2011, le ministère de la justice américain annonce (voir l’histoire telle que la raconte le FBI) la réussite de son opération Ghost Click. Ainsi six résidents Estoniens ont été interpellés pour avoir géré une opération criminelle qui leur permettait d’escroquer des millions d’internautes et un certain nombre de sociétés gérant des campagnes publicitaires.

Une variante du cheval de Troie Zlob avait été créée, apparemment en 2006 ou un peu avant, pour modifier de façon massive la configuration DNS des victimes. La première version de ce cheval de Troie, appelé DNS Changer par la plupart des sociétés antivirus, modifiait la configuration des systèmes d’exploitation pour que la résolution des noms de domaine ne soit plus réalisée par les serveurs de noms de domaine du fournisseur d’accès de la victime, mais par une batterie de serveurs gérée par le groupe criminel. Une version ultérieure permettait même la modification de la configuration de certains routeurs locaux (les boîtiers que l’on installe chez soi pour permettre l’accès à plusieurs ordinateurs au travers de la même connexion Internet).

Les serveurs de noms de domaine contrôlés par le groupe criminel étaient sur les adresses IP suivantes:

  • 85.255.112.0 à 85.255.127.255
  • 67.210.0.0 à 67.210.15.255
  • 93.188.160.0 à 93.188.167.255
  • 77.67.83.0 à 77.67.83.255
  • 213.109.64.0 à 213.109.79.255
  • 64.28.176.0 à 64.28.191.255

Ainsi, le trafic légitime des utilisateurs était détourné vers des sites commerciaux associés à ces criminels, conduisant par exemple les victimes à effectuer des achats sur des sites illégitimes, ou bien l’ordinateur affichait des campagnes publicitaires non prévues. Cela leur permettait aussi d’empêcher les mises à jour de logiciels antivirus.

Le groupe criminel était à la tête d’une société qui avait pignon sur rue, Rove Digital (voir la synthèse réalisée par Trend Micro), elle-même ayant plusieurs filiales (Esthost, Estdomains, Cernel, UkrTelegroup,…) – j’ai déjà évoqué Estdomains dans un article précédent sur les hébergeurs malhonnêtes. Comme on peut le lire dans l’article de Trend Micro, leurs activités ne se limitaient pas aux DNS malveillants (commercialisation de faux antivirus notamment).

Des serveurs DNS remplacés par des serveurs sûrs, mais plus pour longtemps

Grâce à une décision judiciaire et l’assistance de sociétés spécialisées dans la sécurité informatique (regroupées dans le groupe de travail DCWG), l’ensemble de ces serveurs de noms de domaine ont été remplacés par des serveurs légitimes (gérés par ISC). L’avantage d’une telle solution est qu’elle n’a pas soudainement coupé des millions de personnes d’un accès normal à Internet. L’inconvénient est qu’elles ne se sont pas forcément rendues compte qu’elles étaient concernées.

Cette solution est à comparer à celle qu’ont employée les autorités néerlandaises lors du démantèlement du botnet Bredolab. Dans ce dernier cas, les victimes étaient redirigées, grâce à l’utilisation de fonctions intégrées dans le logiciel malveillant, vers une page Web les avertissant de la contamination:

Message de la police néerlandaise pour avertir les victimes du botnet Bredolab

Mais, dans les prochaines semaines, vraisemblablement le 8 mars, les serveurs gérés par le DCWG ne fonctionneront plus et les ordinateurs qui sont encore contaminés par ce logiciel malveillant ou qui ne sont pas complètement reconfigurés ne pourront plus accéder normalement à Internet, les serveurs DNS qu’ils utilisent n’étant plus accessibles. Il est donc important de vérifier qu’on n’est pas concerné.

Pour vous aider à faire cela, des serveurs Web ont été mis en place dans différentes parties du monde qui vous permettent de vérifier si vous pouvez être concerné. Ainsi le CERT-LEXSI a mis en place la semaine dernière un serveur http://www.dns-ok.fr/ qui doit vous afficher l’une des pages ci-dessous:

Tout va bien

Rien ne va plus

Si vous voulez aller plus loin et vérifier plus avant votre configuration, vous pouvez consulter ce document en anglais diffusé par le FBI (voir le PDF joint) et qui donne un peu plus de précisions sur les vérifications à effectuer. En pratique, il s’agit de vérifier que la configuration DNS de vos ordinateurs ou routeurs locaux ne pointe pas vers l’une des adresses IP listées plus haut dans l’article.

Vous trouverez d’autres ressources ici: http://www.dcwg.org/checkup.html et notamment une liste de serveurs de diagnostic par le Web ici: http://dns-ok.de/, http://dns-ok.be/, http://dns-ok.fi/, http://dns-ok.ax/, …

Que faire si vous pensez être concernés?

Les conseils sont ceux que l’on donne habituellement lors de la découverte d’une contamination virale informatique: sauvegardez vos données les plus sensibles, mettez à jour votre logiciel antivirus (après avoir réglé correctement votre configuration DNS) et lancez une procédure décontamination au démarrage si elle est disponible dans votre logiciel et n’oubliez pas de faire le ménage sur tous vos supports amovibles (clés USB) qui sont connus pour avoir été utilisés pour la diffusion de cette catégorie de logiciels malveillants. Vous trouverez d’autres conseils sur le blog Malekal.

Est-ce qu’il s’agissait d’un botnet ?

Oui. Il ne s’agit pas de la structure classique d’un botnet tel qu’on l’imagine habituellement (logiciel malveillant qui reçoit des commandes sur un serveur IRC ou en se connectant sur un serveur Web), mais il y a un bien une infrastructure de commande (les centaines de serveurs DNS de Rove Digital/Esthost), un langage de communication particulier au travers de ces serveurs DNS, et une prise de contrôle assez avancée du comportement de la machine des victimes. Cette organisation malveillante rentre donc bien dans la définition que nous donnons d’un botnet sur le wiki Botnets.fr.

C’est exactement ce que dit Trend Micro dans son article sur ce dossier. J’avais évoqué d’autres modes de commande originaux pour des botnets sur ce blog: des images ou des Google groups.

Les domaines fantômes

La vulnérabilité dite des ghost domains n’a aucun rapport avec l’opération Ghost Click que nous venons d’évoquer, mais elle concerne bien une faille dans les serveurs DNS, même si elle n’a pas d’impact immédiat pour la plupart des lecteurs de ce blog.

Des chercheurs chinois et américains (Jian Jiang, Jinjin Liang, Kang Li, Jun Li, Haixin Duan et Jianping Wu) ont ainsi mis en évidence, dans un article intitulé Ghost Domain Names: Revoked Yet Still Resolvable (voir le PDF), qu’il était possible de maintenir, dans la mémoire cache d’une grosse partie des serveurs DNS répartis sur la planète, la résolution d’un nom de domaine qui n’est normalement plus actif, longtemps après qu’il ait été révoqué.

En théorie, cela permet par exemple de maintenir en activité un système de commande et de contrôle d’un botnet longtemps après qu’il ait été mis hors service.

Principe de la vulnérabilité

Le principe décrit par les auteurs suppose d’interroger l’ensemble des serveurs DNS dans lesquels on cherche à maintenir l’information vivante, avec des requêtes qui provoquent une mise à jour. Pour ce faire:

  • si le nom de domaine que l’on cherche à protéger est fantome.com
  • que le serveur de nom de domaine principal de ce domaine est dns.fantome.com (pointant vers l’adresse IP x.y.z.t
  • on modifie le nom du serveur pour un autre, soit par exemple test.fantome.com (pointant toujours vers x.y.z.t)
  • et on interroge ensuite chacun des serveurs DNS attaqués pour qu’ils identifient test.fantome.com
  • comme ils ne connaissent pas test.fantome.com mais savent déjà résoudre les adresses du domaine fantome.com, ils se connectent sur x.y.z.t et se rendent alors compte qu’il a changé de nom et mettent à jour le serveur de nom de domaine pour fantome.com avec la valeur test.fantome.com et réinitialisent la valeur du TTL (time to live, voir Wikipédia), qui constitue en quelque sorte la date d’expiration de l’information dans le cache local du serveur DNS.

Ainsi, pour tous les serveurs qui sont vulnérables à cette attaque, si on les contacte au moins une fois par jour (ou juste un peu moins qu’un jour, si le TTL est configuré à 86400 secondes) pour provoquer une mise à jour, ils continueront de conserver l’information erronée, sans jamais vérifier auprès des registres de noms de domaine de plus haut niveau (voir Wikipédia).

Quel est le risque réel

Les chercheurs soulignent dans leur article qu’ils ont pu mesurer qu’une grande majorité des serveurs DNS sont concernés aujourd’hui par cette vulnérabilité. Et s’ils n’ont pas identifié une utilisation passée, ils ont pu montrer qu’elle fonctionnerait. L’un des scénarios qu’ils décrivent consisterait à cibler l’attaque contre des serveurs de noms de domaine d’un réseau donné. Des mises à jour sont en cours de déploiement dans différentes versions des serveurs DNS. Selon les spécialistes interrogés (voir l’article du Register), le risque n’est pas très grand étant donné que la vulnérabilité permet uniquement de maintenir en fonctionnement des domaines malicieux après leur disparition et non pas d’injecter des informations erronées sur des domaines légitimes existants (voilà quelques années, Dan Kaminsky mettait en lumière une faille beaucoup plus importante, en voir la synthèse chez Stéphane Bortzmeyer).

Conclusion

Internet fonctionne sur un ensemble de fonctions essentielles dont les serveurs DNS ou le protocole de routage BGP. Bien qu’ils soient relativement simples au départ, la complexité de l’Internet, la nécessité de diffuser et propager l’information rapidement les rend particulièrement vulnérables. Il est donc important de suivre leur sécurité du cœur de l’Internet jusque dans la mémoire de votre ordinateur.

Pour aller plus loin

J’ai déjà parlé du DNS dans plusieurs articles que vous pouvez retrouver ici:

D’autres articles sur les domaines fantômes:

Torpig : visite du centre de commande d’un botnet

In English anglais

120px-pig_dsc039781

Torcochon ?

Non, il ne s’agit pas ici du virus de la grippe porcine. Des chercheurs de l’université de Santa Barbara en Californie ont publié un rapport rendant compte des observations qu’ils ont pu faire lors d’une prise de contrôle temporaire d’un système de commande du botnet Torpig.

Il s’agit d’un botnet basé sur un logiciel malveillant (Torpig/Sinowal/Anserin/Mebroot) affectant les systèmes Microsoft Windows. Il aurait été d’abord repéré (selon RSA) en février 2006 ou en juillet 2005 selon d’autres spécialistes. Cela fait donc bientôt quatre ans que ce cheval de Troie sévit, et toujours aussi activement !

Les conclusions du rapport des chercheurs de Santa Barbara, reprises dans un article chez ZDNet, sont que cet outil malveillant permet de collecter actuellement des millions de mots de passe, des milliers de numéros de carte bancaire ou d’identifiants d’accès à des comptes bancaires. Ces chercheurs ont mis en ligne une page de suivi de ce projet.

C’est un nouvel exemple (j’en parlais déjà voici quelques semaines) des techniques qu’il est nécessaire aujourd’hui d’utiliser pour collecter efficacement de l’information sur ces botnets : il est nécessaire de les pénétrer. Aujourd’hui, de tels modes de collecte de preuve restent purement et simplement illégaux.