Depuis les premières informations sur Flame, le malware n’en finit plus d’étonner. Des capacités d’adaptation très développées, un code source massif, des méthodes d’attaque à la pointe de la technologie : Flame fascine le monde de la sécurité. Plus récemment, c’est sa capacité d’autodestruction et sa filiation à Stuxnet qui ont fait l’objet d’attentions.
Comme expliqué par Symantec, Flame se connecte régulièrement à un serveur C&C pour récupérer des informations complémentaires. Lorsque le suicide est commandé, le malware récupère un fichier nommé browse32.ocx aux allures inoffensives. Deux éléments de ce fichier sont relatifs à la destruction de Flame : Enablebrowser, qui initialise l’environnement, dresse une liste de composants et prépare le terrain, et StartBrowse qui procède à la suppression de tout ce petit monde. Symantec publie d’ailleurs la longue liste des fichiers et dossiers effacés durant la procédure sur son blog.
Symantec note que ces informations ont pris un certain temps à être accumulées. Les éditeurs de solutions de sécurité placent des « honeypots » (pots de miel), autrement dit des pièges pour récolter des données. Le module browse32 a ainsi été récupéré le 9 mai, mais il arrive que l’éditeur ne sache pas cependant ce qu’il a récupéré dans ses filets.
Symantec précise en outre que la fonction suicide cache en elle-même un petit mystère. S’il est avéré en effet que c’est bien le fichier browse32.ocx qui contient le matériel, le code de Flame faisait déjà référence à une fonction nommée « SUICIDE ». Or, cette dernière n’est visiblement pas utilisée.
Kaspersky indique ainsi que Stuxnet a eu plusieurs variantes. Les deux principales datent de 2009 et 2010. Entre les deux, de très nombreuses modifications du code étaient intervenues. Cela concernait en particulier un tronçon de 500 Ko, la « ressource 207 ». Dans la version 2010, cette dernière n’existait plus en tant que telle, le code ayant été dispersé dans d’autres modules. Pour l’éditeur, il s’agit précisément du chainon manquant.
La suite fait penser à l’introduction d’un film catastrophe. En octobre 2010, les systèmes automatiques de l'entreprise signalent un nouveau venu. L’analyse primaire classe alors le malware dans la catégorie Stuxnet. Les employés y regardent de plus près et ne trouvent aucune ressemblance avec ce dernier. Ils renomment alors le malware Tocy.a en pestant contre le système automatique.
Après la découverte récente de Flame, l’éditeur fouille sa base de données à la recherche d’une éventuelle correspondance. En effet, les malwares sont souvent des variantes d’autres créations plus anciennes. Stupeur : Tocy.a ressort du placard. Il se révèle être en fait de l’un des premiers modules de Flame. Mieux : le code source est pratiquement identique à celui... de la ressource 207 de Stuxnet. Ce dernier aurait alors pu être l’un des produits de la plateforme Flame et de ses multiples modules.
Ce qui, entre autres, permet à Kaspersky de tirer plusieurs conclusions. Premièrement, quand Stuxnet a été créé en janvier 2009, la plateforme Flame existait déjà, au plus tard depuis l’été 2008, et avait déjà une architecture modulaire. Deuxièmement, la version 2009 de Stuxnet était basée sur un module de Flame, probablement créé dans ce but précis. Troisièmement, le module a été retiré de la variante 2010 pour être remplacé par une nouvelle méthode de propagation.
L’éditeur note qu’après 2009, Stuxnet est devenu indépendant et a évolué séparément, loin du nid. Pour Kaspersky, deux équipes indépendantes de développeurs de malwares seraient entrées en contact et auraient collaboré un temps. Une collaboration dont serait né Stuxnet.
Un ordre, un suicide collectif
On savait déjà que Flame était équipé d’une commande de suicide. Cette dernière pouvait à tout moment être émise par les serveurs C&C (Command & Control). C’est précisément ce qui s’est produit il y a environ deux semaines. L’intérêt de cet ordre était de forcer Flame à littéralement s’autodétruire. Conséquence : il disparaissait des machines sans laisser de trace, ce qui évitait aux auteurs qu’on ne remonte trop vite vers eux par accumulation de preuves et indices.Comme expliqué par Symantec, Flame se connecte régulièrement à un serveur C&C pour récupérer des informations complémentaires. Lorsque le suicide est commandé, le malware récupère un fichier nommé browse32.ocx aux allures inoffensives. Deux éléments de ce fichier sont relatifs à la destruction de Flame : Enablebrowser, qui initialise l’environnement, dresse une liste de composants et prépare le terrain, et StartBrowse qui procède à la suppression de tout ce petit monde. Symantec publie d’ailleurs la longue liste des fichiers et dossiers effacés durant la procédure sur son blog.
Symantec note que ces informations ont pris un certain temps à être accumulées. Les éditeurs de solutions de sécurité placent des « honeypots » (pots de miel), autrement dit des pièges pour récolter des données. Le module browse32 a ainsi été récupéré le 9 mai, mais il arrive que l’éditeur ne sache pas cependant ce qu’il a récupéré dans ses filets.
Symantec précise en outre que la fonction suicide cache en elle-même un petit mystère. S’il est avéré en effet que c’est bien le fichier browse32.ocx qui contient le matériel, le code de Flame faisait déjà référence à une fonction nommée « SUICIDE ». Or, cette dernière n’est visiblement pas utilisée.
Un lien de parenté avec Stuxnet
De son côté, Kaspersky ressert également le couvert. L’éditeur annonce qu’il avait tort au sujet de Flame : il existe bien un lien de parenté avec Stuxnet, autre star des malwares en 2010. Les caractéristiques étaient très différentes, de même que les plateformes sur lesquelles ils étaient bâtis. Par exemple, Stuxnet (et Duqu) s’appuyait sur des pilotes en espace kernel comme méthode principale d’attaque, alors que Flame n’en fait pas usage.Kaspersky indique ainsi que Stuxnet a eu plusieurs variantes. Les deux principales datent de 2009 et 2010. Entre les deux, de très nombreuses modifications du code étaient intervenues. Cela concernait en particulier un tronçon de 500 Ko, la « ressource 207 ». Dans la version 2010, cette dernière n’existait plus en tant que telle, le code ayant été dispersé dans d’autres modules. Pour l’éditeur, il s’agit précisément du chainon manquant.
La suite fait penser à l’introduction d’un film catastrophe. En octobre 2010, les systèmes automatiques de l'entreprise signalent un nouveau venu. L’analyse primaire classe alors le malware dans la catégorie Stuxnet. Les employés y regardent de plus près et ne trouvent aucune ressemblance avec ce dernier. Ils renomment alors le malware Tocy.a en pestant contre le système automatique.
Après la découverte récente de Flame, l’éditeur fouille sa base de données à la recherche d’une éventuelle correspondance. En effet, les malwares sont souvent des variantes d’autres créations plus anciennes. Stupeur : Tocy.a ressort du placard. Il se révèle être en fait de l’un des premiers modules de Flame. Mieux : le code source est pratiquement identique à celui... de la ressource 207 de Stuxnet. Ce dernier aurait alors pu être l’un des produits de la plateforme Flame et de ses multiples modules.
Ce qui, entre autres, permet à Kaspersky de tirer plusieurs conclusions. Premièrement, quand Stuxnet a été créé en janvier 2009, la plateforme Flame existait déjà, au plus tard depuis l’été 2008, et avait déjà une architecture modulaire. Deuxièmement, la version 2009 de Stuxnet était basée sur un module de Flame, probablement créé dans ce but précis. Troisièmement, le module a été retiré de la variante 2010 pour être remplacé par une nouvelle méthode de propagation.
L’éditeur note qu’après 2009, Stuxnet est devenu indépendant et a évolué séparément, loin du nid. Pour Kaspersky, deux équipes indépendantes de développeurs de malwares seraient entrées en contact et auraient collaboré un temps. Une collaboration dont serait né Stuxnet.
