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.
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.