Répondre à Firefox 0 jours dans la nature


Philip Martin

Le jeudi 30 mai, plus d'une douzaine d'employés de Coinbase ont reçu un courrier électronique prétendant avoir été envoyé par Gregory Harris, responsable des bourses de recherche à l'Université de Cambridge. Ce courriel venait du domaine légitime de Cambridge, ne contenait aucun élément malveillant, détectait du spam et faisait référence au fond des destinataires. Au cours des deux prochaines semaines, des courriels similaires ont été reçus. Rien ne semblait faux.

Le 17 juin à 6 h 31, Gregory Harris a envoyé un autre courrier électronique, mais celui-ci était différent. Il contenait une URL qui, une fois ouverte dans Firefox, installerait un malware capable de saisir la machine de quelqu'un.

Coinbase Security a rapidement découvert que ces courriels étaient tout sauf ordinaires: ils faisaient tous partie d’une attaque sophistiquée, très ciblée et envisageaient d’utiliser des tactiques de spear phishing / social engineering et, plus important encore, deux vulnérabilités Firefox de 0 jours.

En quelques heures, Coinbase Security détecté et verrouillé l'attaque. Voici comment cela s'est développé.

Cette attaque comportait deux jours séparés de 0 jour, l'un permettant à un attaquant de transférer les privilèges JavaScript sur une page du navigateur (CVE-2019-11707) et l'autre permettant à l'attaquant de sortir de l'environnement limité du navigateur et d'exécuter du code l'ordinateur hôte (CVE-2019-11708). CVE-2019-11707 a été découvert simultanément par Samuel Groß du Google Zero Project et l’attaquant. En nous basant sur des différences significatives dans la manière dont l'attaquant, un groupe suivi comme CRYPTO-3 et également appelé HYDSEVEN, a choisi de déclencher la vulnérabilité par rapport au déclencheur utilisé par le projet Zero PoC, nous ne pensons pas que l'attaquant a acquis l'exploit de Mozilla ou Google, mais a découvert la vulnérabilité de manière indépendante. Samuel Groß explique plus en détail pourquoi c'est le cas ici.

Le deuxième exploit, CVE-2019-11708, est également très intéressant. Bien que la principale vulnérabilité soit présente dans Firefox depuis assez longtemps, la manière dont cet attaquant a choisi de la déclencher n’est possible que depuis le 12 mai. Cela indique un cycle très rapide de découverte des armes par l'attaquant (ou toute autre personne acquise par l'attaquant au jour 0). Lors de l'examen du code d'exploitation réel, il existe un certain nombre de caractéristiques notables. Premièrement, bien que la livraison du jour 0 ait été très spécifique (elle n’a été livrée qu’à environ 5 personnes sur les 200 initialement sélectionnées), aucun effort n’a été fait pour masquer le code JavaScript lui-même. Lors de l'examen du code, nous avons constaté qu'il était bien structuré.

Les fonctions et les variables ont des noms descriptifs et le code est divisé en unités fonctionnelles raisonnables. En général, cela ressemble au travail d'un groupe qui a une expérience significative dans le développement d'exploits.

Une fois que les attaquants ont eu cette capacité initiale, ils ont reporté leur attention sur la méthode de livraison. Ils ont mis en danger ou créé deux comptes de messagerie et créé une page de renvoi à l'Université de Cambridge. Le 28 mai, ils ont enregistré le domaine utilisé pour livrer l'exploit. Nous ne savons pas quand les attaquants ont obtenu l'accès aux comptes Cambridge, ni si les comptes ont été créés ou créés. Comme d'autres l'ont souligné, les identités associées aux comptes de messagerie n'ont pratiquement aucune présence en ligne et les profils LinkedIn sont presque certainement faux. Cambridge offre à son personnel la possibilité d’héberger des fichiers personnels dans le domaine de Cambridge. Une fois que les assaillants ont eu accès aux comptes en question, ils ont préparé une série de pages en clonant et en modifiant les pages existantes de l’Université de Cambridge et en les rendant disponibles dans les répertoires de stockage personnel des comptes contrôlés par les attaquants.

Les premiers courriels de phishing ont commencé le 30 mai. Les premiers courriers électroniques publiés ne contenaient aucun élément malveillant (le lien dans la capture d'écran ci-dessous ne contenait aucun code malveillant).

Les assaillants ont suivi un processus de qualification et de multiples courriers électroniques avec des victimes potentielles, s'assurant qu'ils étaient des cibles performantes avant de diriger les victimes vers la page contenant la charge utile opérationnelle. Ce processus a généralement duré des semaines et environ 2,5% seulement des personnes ayant reçu les courriers électroniques initiaux ont fini par recevoir un lien vers la page hébergeant le jour 0. Les attaquants ont bien travaillé en créant le sentiment que les victimes parlaient. Des personnes légitimes utilisant diverses techniques. Les e-mails académiques validés leur ont permis d'éviter tout filtrage commun des emails ou détection de spam, et en diffusant la communication, les attaquants ont modelé le comportement humain normal. Le contenu de l'e-mail faisait référence à de véritables événements universitaires et était étroitement lié aux antécédents des personnes victimes de phishing.

Une fois que les attaquants ont évalué une cible, ils ont envoyé un lien séparé contenant la charge utile d'exploitation. La première étape de cette attaque a d'abord identifié le système d'exploitation et le navigateur, et a révélé une erreur convaincante aux utilisateurs de macOS qui n'utilisaient pas actuellement Firefox, leur demandant d'installer la dernière version de Mozilla. Après avoir visité la page dans Firefox, le code d’exploitation a été fourni par un domaine distinct, analyticsfit.[.]com, qui a été enregistré le 28 mai. Les données utiles d'exploitation ont utilisé CVE-2019-11707 et CVE-2019-11708 pour obtenir l'exécution de code arbitraire en tant qu'utilisateur. Le code de shell de l'attaquant a alors rejeté une commande de curl pour télécharger et exécuter un implant de stade 1. L'implant de stade 1 (07a4e04ee8b4c8dc0f7507f56dc24db00537d4637afee43dbb9357d4d54f6ff4) déployé par le shellcode était de 32 bits, ce qui indique un macOS mettant en garde, ce qui permet de le masquer. L'exécution 32 bits est obsolète. Le binaire de l'étape 1 était une variante de la famille Netwire. Alors que cet implant est capable d'agir comme un RAT complet, les attaquants semblent l'utiliser principalement comme une accusation initiale de reconnaissance et de vol de justificatif d'identité. Nous détectons l'attaquant à ce stade, en fonction d'une série de comportements (par exemple, Firefox ne devrait pas générer de shell). Après l'exfiltration des données de reconnaissance et le pillage de base de magasins de références évidents (.ssh, .aws, .gpg, porte-clés, etc.) et de formats de documents, suivis d'un retard indicatif de la participation humaine, la charge de L'étape 1 est utilisée pour démarrer une étape. 2 charges utiles (97200b2b005e60a1c6077eea56fc4bb3e08196f14ed692b9422c96686fbfc3ad). La charge utile de l'étape 2 est une variante de la famille Mokes. Les attaquants semblent utiliser cet implant comme un RAT complet. Nous avons observé une activité de l’implant de stade 2 compatible avec le contrôle humain direct. Notre hypothèse est que la phase 1 ne progresse que vers la phase 2, où les attaquants estiment avoir beaucoup atterri. Nous avons également constaté que les attaquants ciblent spécifiquement les services de cloud gmail et autres, par le vol de jetons de session de navigateur via un accès direct aux magasins de données du navigateur. Cette activité offre également la possibilité d’une détection basée sur le comportement, car relativement peu de processus doivent accéder directement à ces fichiers.

Nous commençons à enquêter sur cet incident en nous basant sur un rapport d’employé et des alertes automatiques. Tout d'abord, nous examinons la machine de l'employé dans nos outils de détection et de réponse des points finaux. En ce qui concerne l'activité récente du processus, Firefox s'est immédiatement démarqué. L'équipe d'intervention a déclenché un incident et a d'abord tenté de déterminer l'étendue de l'attaque. Nous avons recueilli IOC auprès de l'hôte en question et avons commencé à chasser intensivement dans notre réseau. Nous n'avons vu aucun des CIO ailleurs dans notre environnement et nous avons mis tous les CIO sur notre liste noire à ce moment-là. En même temps, nous avons collecté des échantillons, y compris la capture du jour 0, sur le site de phishing alors qu’il était encore en vie et les attaquants ne connaissaient probablement pas notre réponse. Nous avons également annulé toutes les informations d'identification présentes sur la machine et bloqué tous les comptes appartenant à l'employé concerné. Une fois que nous nous sentons à l'aise pour avoir maîtrisé notre environnement, nous communiquons avec l'équipe de sécurité de Mozilla et partageons le code d'exploitation utilisé dans cette attaque. L'équipe de sécurité de Mozilla s'est montrée très réceptive et pourrait avoir un correctif pour CVE-2019-11707 le lendemain et pour CVE-2019-11708 la même semaine.

Nous contactons également l'Université de Cambridge pour les aider à sécuriser leur infrastructure et à recueillir plus d'informations sur le comportement de l'attaquant. En conséquence, nous avons été en mesure de dégrader rapidement la capacité de l'attaquant à poursuivre sa campagne et à obtenir davantage d'informations sur la portée de la campagne. Nous avons appris que cet attaquant avait attaqué plus de 200 personnes et nous avons identifié les organisations qui les emploient afin que nous puissions communiquer et fournir à leurs équipes de sécurité les informations dont elles ont besoin pour protéger leurs infrastructures et leurs employés.

Nous avons pu nous défendre contre cette attaque grâce à notre première culture de sécurité dans Coinbase, au déploiement complet de nos outils de détection et d'intervention, à des livres de lecture clairs et bien joués et à la capacité de révoquer rapidement l'accès. Le secteur de la crypto-monnaie doit attendre que les attaques de cette sophistication se poursuivent, et en construisant une infrastructure avec une excellente posture défensive et en travaillant ensemble pour partager des informations sur les attaques que nous constatons, nous pouvons nous défendre et défendre nos clients, en prenant en charge la cryptoéconomie. et construire le système financier ouvert du futur.

Coinbase continuera à faire face à des défis de sécurité difficiles à l'avenir et à les affronter. Si vous êtes intéressé à rejoindre l’équipe de sécurité ici à Coinbase, consultez certains des postes disponibles dans notre carrières page.

Ce site Web contient des liens vers des sites Web tiers ou d’autres contenus à des fins d’information uniquement ("Sites tiers"). Les sites tiers ne sont pas sous le contrôle de Coinbase, Inc. et de ses sociétés affiliées ("Coinbase"). Coinbase n'est pas responsable du contenu des sites tiers, y compris, sans toutefois s'y limiter, les liens contenus dans des tiers. Site tiers, ou toute modification ou mise à jour d'un site tiers. Coinbase n'est pas responsable de la transmission Internet ou de toute autre forme de transmission reçue d'un site tiers. Coinbase fournit ces liens uniquement pour votre commodité, et l’inclusion de tout lien n’implique aucune approbation, approbation ou recommandation par Coinbase du site ou de l’association de ses opérateurs.