« Pour donner un bref aperçu, une organisation installe un dispositif FireEye sur son réseau interne, puis le connecte à un SPAN ou un port miroir à un point de sortie (ceux-ci sont intégrés dans les ports des équipements de réseautage professionnel de suivi).
Le dispositif FireEye montre alors tout le trafic réseau de façon passive, gérant des protocoles communs tels que HTTP, FTP, SMTP, etc., pour tous les fichiers transférés. Si un transfert de fichier est détecté (par exemple, une pièce jointe ou un téléchargement HTTP) le dispositif extrait le fichier et effectue un balayage pour chercher d’éventuels logiciels malveillants.
En principe, si un utilisateur reçoit un courriel malveillant ou visite un site web malicieux, le dispositif FireEye observe le trafic et alerte l'administrateur réseau. FireEye fait également des appareils spécifiquement destinés à surveiller les serveurs de fichiers et serveurs de messagerie, entre autres », expliquent les chercheurs.
Travis Ormandy et Natalie Silvanovitch expliquent qu’une faille réside dans le MIP (Malware Input Processor), un module qui est responsable de l’analyse statique des fichiers, invoquant les programmes et plugins auxiliaires pour décoder différents types de fichiers. Par exemple, l’auxiliaire swf invoque flasm pour décoder les fichiers flash, l’auxiliaire dmg invoque p7zip pour extraire le contenu des images disques Mac OS et l’auxiliaire png invoque pngcheck pour vérifier les images malformées.
Du côté de l’auxiliaire jar qui est utilisé pour analyser les archives Java, il vérifie les signatures en faisant appel à jarsigner, puis tente de décompiler le contenu en utilisant un décompileur open source Java appelé JODE. Une fois la décompilation effectuée, il parcourt le code à la recherche de modèles connus de code malveillant dans les sorties générées par le décompileur.
Étant donné que JODE est open source, les chercheurs ont examiné son code source. Ils ont remarqué un code particulier qui tente de manipuler les invocations de méthode dans les constructeurs statiques.
C’est la raison pour laquelle ils ont décidé d’aller plus loin dans leur recherche. Alors ils ont extrait le package JODE du dispositif de FireEye pour l’examiner plus attentivement. Au niveau du débogueur jdb, le paramètre OPTION_DECRYPT était activé et la classe SimpleVirtualMachine était définie :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | $ jdb -classpath "." net.sf.jode.decompiler.Main test.jar Initializing jdb ... > stop in net.sf.jode.expr.InvokeOperator.deobfuscateString Deferring breakpoint net.sf.jode.expr.InvokeOperator.deobfuscateString. It will be set after the class is loaded > run ... main[1] dump net.sf.jode.decompiler.Options.options net.sf.jode.decompiler.Options.options = 831 |
Pour apporter une preuve de ce concept, ils ont créé une classe que JODE pourrait exécuter et l’ont utilisée pour invoquer java.lang.Runtime.getRuntime().exec() qui leur a permis d’exécuter des commandes arbitraires shell.
Cette vulnérabilité peut s’avérer très dangereuse parce qu’elle peut permettre l’exfiltration des données confidentielles de l’entreprise, l’altération du réseau, l’autopropagation des vers issus d'internet.
« Une vulnérabilité qui peut être exploitée via une interface de gestion passive serait un scénario catastrophe », ont prévenu les chercheurs. « Cela voudrait dire qu’un attaquant n’aura qu’à envoyer un courriel (…), le bénéficiaire n’aura même pas à lire le courriel, juste le recevoir sera suffisant » ont indiqué les chercheurs qui ont précisé que les produits de la gamme NX, FX, AX et EX de FireEye sont concernés par cette vulnérabilité.
Des correctifs de sécurité ont déjà été déployés pour colmater cette faille appelée « 666 » et les utilisateurs qui n’ont pas encore effectué cette mise à jour sont conseillés de le faire au plus vite pour protéger leur infrastructure.
Source : blog Google, FireEye (au format PDF)