Deux chercheurs en sécurité faisant partie de l’équipe derrière le Project Zero de Google ont trouvé des vulnérabilités critiques dans des produits FireEye« 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.
| 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)
mais bon, les produits FireEye sont impactés et leur nature (produits à vocation sécu) rend la vulnérabilité d'autant plus critique et le buzz d'autant plus bzzbzz, mais in fine la faille se situe dans JODE, on nous apprend par ailleurs que le dispositif/appliance/shmürtz utilise également des outils comme flasm ou pngcheck, rien ne dit qu'il n'y a pas de trous dans ces outils là également, et si les équipes de FireEye n'ont pas audité les applis tierces avant de les implémenter les produits vont continuer d'être vulnérables
