Un pirate informatique aurait réussi à introduire une extension frauduleuse contenant un backdoor (porte dérobée pour les anglophobes) au sein des modules mis à disposition par la fondation Mozilla, éditeur du navigateur Firefox.

L'attaque a été détectée cinq semaines après la mise en ligne de l'extension sur le portail de téléchargement par un utilisateur. Le comportement de son navigateur lors de l'audit de sécurité d'une application web lui a paru suspect.

Contexte

Le navigateur Firefox, conçu et développé par la fondation Mozilla et de nombreux contributeurs bénévoles propose un dispositif permettant à quiconque d'étendre les fonctionnalités du navigateur au moyen de petits programmes appelés des modules (ou extensions).

Les modules peuvent servir de nombreux usages, dont les limitations avoisinent celles de l'imagination des internautes. Un portail central facilite la publication, la recherche et l'accès à ces modules, créant ainsi un lien entre leur créateur (il peut publier son module dans le catalogue) et leurs utilisateurs potentiels (qui peuvent chercher des modules et les installer au sein de leur navigateur). Un dispositif que de nombreux produits exploitent aujourd'hui de manière similaire, comme par exemple, les catalogues d'applications mis à disposition par les fabricants de téléphones portables.

Le catalogue de modules de Mozilla propose également la possibilité de créer des "collections", qui ne sont rien de plus qu'un ensemble de modules regroupés sous une thématique particulière. L'on trouve ainsi des collections pour graphistes, pour documentalistes, pour développeurs web, pour géographes, pour médecins, et j'en passe.

Lorsqu'un internaute installe un nouveau module dans son navigateur Firefox, ce dernier l'installe dans un dossier nommé selon l'identité du module. Cette dernière peut être constituée de plusieurs façons mais la pratique générale est de se baser sur un identifiant pseudo-unique et pseudo-aléatoire généré spécifiquement pour le dit module, comme on peut le constater dans la capture d'écran ci-dessous:

L'attaque

Il y a un peu plus d'un mois, un développeur agissant sous une fausse identité a publié un module (Mozilla Sniffer), censé, selon la description indiquée, palier aux limitations d'un autre module particulièrement réputé au sein de la communauté de professionnels en sécurité de l'information.

Le module a été ajouté à la liste des modules constituant la collection d'outils "Web Application Security Penetration Testing collection", une collection destinée aux auditeurs intéressés d'évaluer la sécurité d'applications web. Cette collection comporte à ce jour 84 modules, destinés à assister l'auditeur dans son travail.

La particularité du module frauduleux a été de contenir des routines utilisant les mêmes identifiants de module que ceux du module Tamper Data (Tamper Data permet à un auditeur d'intercepter et modifier à la volée les flux HTTP transitant entre le navigateur et le serveur web). Cette situation de doublon a eu pour effet de faciliter l'écrasement du code original de Tamper Data par une routine modifiée par le pirate.


La modification frauduleuse de Tamper Data

Comme indiqué plus haut, le module Tamper Data est un outil fréquemment utilisé lors des tests d'intrusion sur des applications web. Sa nature est de s'interposer précisément au point où les requêtes initiées par l'interface utilisateur quittent le navigateur en direction du serveur, permettant ainsi à l'auditeur d'observer le contenu du trafic en détail, et, s'il le souhaite, de le modifier.

La modification du module a eu pour effet de déclencher l'envoi d'une copie des détails de toute requête résultant de l'envoi d'un formulaire dans lequel le champ de mot de passe a été renseigné.

Le pirate récupérait ainsi sur un serveur anonyme des copies de tous les mots de passes soumis lors de tests d'intrusion.

Détection

L'intrusion a été détectée le 12 juillet dernier par Johann-Peter Hartmann (JPH), un développeur d'applications web travaillant pour une entreprise allemande et utilisant ces modules dans le cadre de ses tests. Par hasard, JPH avait mis en place un second intercepteur de trafic, externe au navigateur Firefox, pour réaliser ses tests. En observant le trafic, JPH a rapidement constaté que le navigateur émettait des requêtes en direction d'un serveur non identifié.

Analyse

Interpellé par ce comportement, JPH a examiné le code des extensions. La nature technique de ces dernières est d'avoir un code source complétement ouvert et pouvant être facilement analysé par quiconque sachant lire du code.

Après analyse, JPH a identifié que le module Mozilla Sniffer avait modifié le comportement normal du module Tamper Data. Un comportement que l'on pourrait assimiler à un cheval de Troie, dans la mesure où il fournissait de façon dissimulée des informations à un pirate informatique à l'extérieur du réseau.

JPH a immédiatement notifié par email l'équipe en charge de la maintenance du service de téléchargement de modules Firefox.

Confinement

Lors d'un incident de sécurité, une phase de confinement est généralement déclenchée dès que l'analyse de l'attaque a permis d'en identifier son mécanisme de propagation. Cette action permet de réduire la propagation d'une attaque dans l'attente qu'une solution à plus long terme soit identifiée.

Après avoir été alertée par JPH, l'équipe de maintenance du service a immédiatement coupé tout accès au téléchargement du module, quelques minutes seulement après avoir reçu l'email de JPH. Cette mesure a eu pour effet d'empêcher tout téléchargement ultérieur du module.

Éradication et récupération

Bien que le module ne fût plus téléchargeable, de nombreux utilisateurs l'avaient installé dans leur navigateur et étaient encore exposés au vol de mots de passes. Plus de 1'800 téléchargements du module ont eu lieu, et 334 navigateurs ont annoncé une utilisation active de ce module au moment de l'analyse.

Mozilla a donc ajouté le module dans la blocklist de Firefox, une liste des modules déclarés pour désactivation immédiate. Le navigateur Firefox effectue automatiquement ce contrôle toutes les 24 heures, ce qui réduit fortement la fenêtre d'exposition des systèmes infectés.

Résolution à long terme et suivi

Lorsque les disponibilités le permettent, la phase finale d'un processus de réponse en cas d'incident requiert que les conditions initiales qui ont permis ou contribué à la réalisation de l'attaque soient formalisées (root cause analysis). Cette démarche permet d'éviter que la même attaque et souvent, d'autres attaques similaires, se reproduisent, sur les mêmes produits et services tout comme sur d'autres produits ou services également exploités par l'organisation (impact analysis, collateral systems vulnerability exposure analysis*, etc.).

^{(''*: si vous ne trouvez pas de référence sur ce terme, c'est normal)}


Dans le cas de cet incident, l'équipe de sécurité doit (certainement) répondre à la série de questions ci-après.


D'autres modules actuellement disponibles au téléchargement exécutent-ils la même attaque?

Pour y répondre, une recherche statique du code source des modules permettra d'identifier d'autres modules renvoyant des données sur le même serveur.


D'autres modules actuellement disponibles au téléchargement exécutent-ils la même attaque pour d'autres pirates?

Une recherche statique des modules se comportant de manière similaire et renvoyant des données sur des serveurs anonymes pourra être effectuée. La méthode trouvera toutefois rapidement ses limites, à moins de corréler la recherche avec une liste de serveurs reconnus pour héberger des activités frauduleuses (démarche similaire aux architectures de lutte contre le spam et les chevaux de Troie).


Peut-on empêcher la capture et l'envoi de trafic sur des serveurs tiers par un moyen technique?

La réponse est certainement négative. Cette fonctionnalité est au coeur du service proposé par de nombreux modules, capables de collecter du trafic et de le renvoyer à un serveur tiers et de renvoyer les résultats d'une éventuelle analyse (ex: modules de recherche, de traduction, de localisation, etc.).


Peut-on mettre en oeuvre des mesures visant à réduire la possibilité d'une attaque similaire?

La réponse est définitivement oui. Les architectes vont certainement devoir inclure des mécanismes de sécurité similaires à la same origin policy ou whitelist policy au sein des modules, leur permettant d'interagir avec une liste spécifique de services sur Internet.

D'autre part, le modèle d'installation des extensions mis en oeuvre pour les téléphones portables propose lui aussi une piste d'amélioration avec son modèle de validation des permissions. Sur les systèmes Android par exemple (les lecteurs ne manqueront certainement pas de compléter le comportement de l'iPhone via les réactions), une liste de permissions auxquelles l'application souhaite souscrire est présentée à l'utilisateur, qui doit l'approuver afin de compléter l'installation. Cette liste indique par exemple quels types d'information seront accessibles (photos, messages, etc.) et quelles ressources pourront être exploitées (système de fichiers local, internet, GPS, appareil photo, etc.). Un utilisateur doté d'un peu de bon sens pourrait déjà, à ce stade, se douter qu'une application toute simple de gestion de mots de passes ne lui demandera pas d'avoir le droit de communiquer sur Internet.

Une autre piste serait de renforcer le principe de bac à sable (séparation nette entre les ressources accessibles à chaque module), qui semble avoir été compromis lors de cette attaque. Cette proposition est hypothétique, je n'ai pas pu trouver des détails expliquant exactement comment le module frauduleux a écrasé le code source du module légitime (avis aux lecteurs si vous avez des infos!).

Finalement, la mesure ultime est l'audit de code. L'entreprise Apple est, parfois tristement, célèbre pour son mécanisme de validation des applications, qui requiert qu'elles passent une série de contrôles avant d'être mise à disposition des utilisateurs de son service de téléchargement d'applications. Toutefois, une attaque de cette nature requerrait certainement une vérification manuelle (un outil automatisé pourra difficilement discerner un serveur tiers légitime) , rendant dès lors le processus extrêmement coûteux et lourd.

A moins de...faire appel au bon vouloir de la communauté de contributeurs bénévoles. La fondation pourrait ainsi 'marquer' les modules qui n'ont pas été encore manuellement vérifiés, libre à l'internaute de prendre la décision de les installer ou non dans son navigateur.

C'est d'ailleurs cette possibilité qu'examinent actuellement les responsables du projet Firefox, dont on peut suivre les négociations sur certains forums si l'on cherche bien.

Conclusion

Ce cas m'a toutefois particulièrement intéressé pour les réflexions et perspectives qu'il apporte dans le domaine de la sécurité logicielle.


Comment ouvrir le logiciel de façon sécurisée?

En premier lieu, l'observation des architectures logicielles indique clairement une tendance à l'ouverture fonctionnelle, à savoir, vers la mise à disposition de librairies (API) et de frameworks facilitant le développement d'extensions, ou encore d'applications de type "mashups" réalisant des croisements fonctionnels avec plusieurs autres applications ou services connectés. Comment libérer les fonctionnalités d'un produit ou d'un service à la créativité des développeurs "bisounours" sans l'exposer simultanément à des organisations criminelles "maléfiques" qui en trouveront un détournement frauduleux? Comment rendre tout cela économiquement viable?


Comment valider le code produit au sein des extensions ou des applications tierces?

Par extension, quelles seraient les mesures adéquates à mettre en oeuvre pour valider la sécurité du code produit par un développeur "externe"?

Certaines organisations mettent en oeuvre une séparation claire des responsabilités en n'attribuant pas un code à son développeur mais à la personne qui l'a approuvé pour la production. En cas de faille de sécurité, la responsabilité est imputée à la personne qui a autorisé le code.

D'autres organisations requièrent l'exécution d'une revue de code, soit par une équipe externe (team qualité ou team sécurité), soit par une société de services. Ce mécanisme très rassurant dans de nombreuses entreprises voit pourtant son effet annulé car aucun contrôle ne vérifie que le code ayant été audité est effectivement le code placé en production (signature des pièces par l'équipe de sécurité et contrôle d'intégrité par l'équipe de production). Combien d'organisations vérifient-elles le code produit par leurs développeurs et combien sont exposées à la faille décrite dans ce paragraphe?


Quel niveau de sécurité pour les environnements d'audit et de tests d'intrusion?

De nombreux tests d'intrusion d'applications web sont réalisés soit à distance, directement depuis les locaux de la société de services en sécurité de l'information, soit depuis un poste de travail interne à la société qui, lui aussi, a accès à Internet.

Dans le cas présent, l'attaque a consisté à placer un backdoor dans un module utilisé quasi-exclusivement par des testeurs en sécurité d'applications web. Quelle est la confiance apportée à leurs réseaux? Les entreprises clientes de tels services s'assurent-elles que les tests seront effectués à partir d'un réseau et de machines réputées sûres?


La distribution des processus de réponse en cas d'incident

Des entreprises peinent déjà à collaborer avec des équipes CERT (organes régionaux d'assistance à la réponse en cas d'incident de sécurité impliquant l'informatique), parfois pour éviter de la lourdeur administrative, ou encore par peur de divulguer un incident de sécurité à une organisation externe.

Dans le cas observé, un utilisateur de l'extension a procédé de sa propre initiative à l'analyse complète de l'attaque, puis présenté le résultat de ses analyses à l'équipe derrière Firefox. Combien de jours se sont-ils écoulés entre l'observation du premier signal et la décision de communiquer l'incident? Une heure? Une semaine? La mesure de confinement étant immédiatement disponible, l'équipe de sécurité de Mozilla aurait, semble-t-il, réagi en quelques minutes. A-t-elle procédé à une analyse complète du cas ou s'est-elle basée sur les résultats envoyés par l'utilisateur? A ce titre, les organisations ont-elles adapté leur processus de réponse en cas d'incident à une collaboration éventuelle avec des ressources techniques extérieures?



<sup>Pour aller plus loin:
- Web Application Security Penetration Testing add-ons collection (mozilla.org)
- Tamper data (mozilla.org)
- Add-ons update documentation (mozilla.org)
- New proposal for review process & delightful add-ons (mozilla.org)
- Firefox security test add-on was backdoored (netcraft.com)
- Add-on security announcement (mozilla.org)</sup>


PS: j'aurais bien aimé pouvoir proposer un lien vers un CERT en Suisse pour les PME mais à part celui destiné aux réseaux académiques (Switch-CERT), je n'en connais pas...