Des failles 0-day exploitées en Égypte par un fournisseur de surveillance commerciale

 (blog.google)
1 points par GN⁺ 2023-09-23 | 1 commentaires | Partager sur WhatsApp
  • Google TAG et The Citizen Lab ont découvert une chaîne d’exploits 0-day visant l’iPhone, utilisée dans des attaques réelles, qu’Intellexa exploitait pour installer discrètement le spyware Predator
  • Apple a corrigé CVE-2023-41991·41992·41993 dans iOS 16.7 et iOS 17.0.1, et Google recommande aux utilisateurs d’iOS de mettre à jour immédiatement
  • L’attaque intercepte le trafic via une injection MITM lorsque la cible visite un site HTTP, puis la redirige vers c.betly[.]me et sec-flare[.]com, sans nécessiter de clic supplémentaire ni de réponse à un appel
  • La chaîne iOS enchaîne une exécution de code à distance dans Safari, un problème de validation de certificat et une élévation locale de privilèges dans le noyau XNU, puis un petit binaire décide d’installer ou non l’implant complet Predator
  • Des attaques visant Android ont aussi été observées en Égypte, et la vulnérabilité d’exécution de code à distance initiale dans le renderer de Chrome exploitant CVE-2023-4762 a été corrigée le 5 septembre

Chaîne d’exploits d’Intellexa pour installer Predator

  • Google Threat Analysis Group (TAG), avec The Citizen Lab, a découvert une chaîne d’exploits 0-day pour iPhone utilisée dans des attaques réelles
  • Cette chaîne, développée par l’entreprise de surveillance commerciale Intellexa, servait à installer furtivement le spyware Predator sur les appareils
  • Apple a corrigé les vulnérabilités suivantes dans iOS 16.7 et iOS 17.0.1
    • CVE-2023-41991
    • CVE-2023-41992
    • CVE-2023-41993
  • Ce correctif rapide a renforcé la protection des utilisateurs, et il est recommandé à tous les utilisateurs d’iOS de l’installer dès que possible

Mode de diffusion via MITM

  • La chaîne d’exploits d’Intellexa était diffusée via une attaque man-in-the-middle (MITM)
  • Dans une attaque MITM, l’attaquant s’interpose entre la cible et le site web auquel elle tente d’accéder pour intercepter le trafic
  • Lorsque la cible visite un site en http, l’attaquant peut renvoyer de fausses données afin de la rediriger vers un autre site web
  • Les sites en https chiffrent le trafic et permettent de vérifier par certificat que les données reçues proviennent bien du site attendu
  • Dans cette campagne, dès qu’une cible visitait n’importe quel site en http, une injection de trafic la redirigeait silencieusement vers le site Intellexa c.betly[.]me
    • Si l’utilisateur correspondait à la cible attendue, il était ensuite redirigé vers le serveur d’exploit sec-flare[.]com
    • Aucune action utilisateur, comme ouvrir un document, cliquer sur un lien précis ou répondre à un appel, n’était nécessaire

Composition de la chaîne d’exploits iOS

  • Une fois la cible redirigée vers le serveur d’exploit, la chaîne d’exploits iOS s’exécutait
  • La chaîne se composait de trois vulnérabilités
    • CVE-2023-41993 : exécution de code à distance (RCE) initiale dans Safari
    • CVE-2023-41991 : problème de validation de certificat
    • CVE-2023-41992 : élévation locale de privilèges (LPE) dans le noyau XNU
  • Un petit binaire s’exécutait ensuite pour décider s’il fallait installer l’implant complet Predator
  • TAG n’a pas pu obtenir l’implant complet Predator
  • Google prévoit de publier une analyse technique approfondie de cet exploit conformément à sa Google vulnerability disclosure policy

Attaques visant Android et vulnérabilité Chrome

  • Les attaquants disposaient aussi d’une chaîne d’exploits destinée à installer Predator sur des appareils Android en Égypte
  • TAG a observé deux modes de diffusion pour l’exploit Android
    • injection MITM
    • lien à usage unique envoyé directement à la cible
  • TAG n’a pu récupérer que la vulnérabilité d’exécution de code à distance initiale dans le renderer de Chrome, qui exploitait CVE-2023-4762
  • Ce bug avait déjà été signalé par un autre chercheur en sécurité au Chrome Vulnerability Rewards Program, et il a été corrigé le 5 septembre
  • Google estime qu’Intellexa avait auparavant utilisé cette vulnérabilité comme 0-day

Défense MITM de Chrome et réponse de Google

  • Depuis des années, Chrome pousse à la généralisation du HTTPS sur le web
  • Le « HTTPS-First Mode » de Chrome peut réduire la possibilité de diffusion d’exploits via l’injection réseau MITM
    • Il tente d’abord de charger toutes les pages en HTTPS
    • Il affiche un avertissement important avant de revenir à une requête HTTP
  • Ce réglage est activé par défaut pour les utilisateurs inscrits à l’Advanced Protection Program et connectés à Chrome
  • Google recommande à tous les utilisateurs d’activer le « HTTPS-First Mode » pour se défendre contre les attaques MITM
  • Cette campagne montre que la prolifération des fournisseurs de surveillance commerciale peut faire peser un risque grave sur la sécurité des utilisateurs en ligne
  • TAG continuera à agir contre l’industrie du spyware commercial et à publier ses recherches, en coopération avec les secteurs public et privé

À lire aussi

1 commentaires

 
GN⁺ 2023-09-23
Avis Hacker News

  • C’est bien d’avoir des informations supplémentaires, mais le fait qu’on ne parle que du correctif Chrome est un peu inquiétant. Je me demande quelle était l’évasion de sandbox sur Android.
    Même si l’exécution de code devenait possible dans le processus Chrome d’Android, cela ne devrait pas permettre d’obtenir de la persistance ; il y a donc forcément une autre vulnérabilité quelque part.
    Dans ce cas, le vecteur d’attaque reposait sur une attaque de l’homme du milieu en HTTP et des liens à usage unique dans une campagne ciblée, mais je ne vois pas ce qui empêcherait quelqu’un de l’intégrer dans une campagne publicitaire ou du spam via SMS/Discord/Matrix pour le diffuser massivement, créer un botnet ou voler des identifiants utilisateur.

    • C’est vraiment le point central. L’article de blog ne donne pas cette information, donc il faut lire entre les lignes, mais on dirait qu’il existe actuellement un problème non corrigé côté Android.
    • Il est indiqué qu’ils n’ont pas pu capturer les étapes suivantes de la chaîne Android et qu’ils n’ont récupéré que les composants d’exécution initiaux.
      Autrement dit, il manque l’évasion de sandbox et le bug d’élévation de privilèges.
      De plus, ici l’exploit semble avoir été livré via une attaque de l’homme du milieu au niveau FAI, en utilisant des capacités d’interception légale, mais il n’y a aucune raison qu’il ne puisse pas être livré en mode « un clic » via un lien de phishing.
    • Comme il existe des millions d’appareils Android abandonnés par leurs fabricants, il est possible qu’ils omettent certains détails parce qu’il s’agit d’une faille qui n’a pas encore été corrigée et ne le sera probablement jamais.
    • Le cœur de l’article est la chaîne d’exploits iPhone : exploit Safari → contournement de PAC → exploit noyau.
      La version Android était assez similaire, mais il semble qu’il fallait deux exploits supplémentaires pour contourner les mécanismes d’atténuation du noyau Linux.
      Il y a un bon article d’analyse technique sur PZ.
    • Je ne connais pas très bien l’environnement mobile, mais j’imagine qu’une fois sorti de la sandbox Chrome, on se retrouve dans le système d’exploitation sous-jacent. Est-ce qu’on ne peut pas y établir de persistance sans exploiter une vulnérabilité supplémentaire ?

  • C’est mieux que de ne pas avoir HTTPS, et cette attaque utilise HTTP pour injecter la charge utile initiale, mais j’ai l’impression que des attaquants soutenus par certains États peuvent tout simplement contourner ou compromettre l’infrastructure des CA ou des CDN.

    • Si des certificats étaient falsifiés de cette manière, tous les navigateurs s’en rendraient compte et il y aurait de fortes chances que la CA concernée soit supprimée ; il existe donc des garde-fous.
    • Ou alors ils peuvent aussi nous faire cliquer sur un domaine usurpé certifié par notre cher LetsEncrypt.
      Il semble qu’il suffise d’une réponse de redirection HTTP 302/307 envoyant le client vers c.betly[.]me. Une charge utile de redirection HTML, voire peut-être le DNS, pourrait aussi fonctionner.
    • Le point important, c’est qu’une seule visite sur n’importe quel site HTTP suffisait, ou suffit, à compromettre l’appareil.

  • Il existe un épisode récent de Darknet Diaries lié à Predator spyware : https://darknetdiaries.com/episode/137/

  • Ce que ce genre de 0-day nous apprend, c’est que si vous êtes la cible d’un adversaire puissant, vous devez devenir extrêmement paranoïaque et réduire au maximum votre surface d’attaque.
    Si James Bond veut communiquer en toute sécurité avec M, il vaudrait mieux qu’il utilise un appareil mobile matériel sur mesure ne servant qu’à cette fonction. Il devrait laisser des messages chiffrés sur un forum aléatoire depuis un appareil prépayé anonyme appartenant à un tiers, selon une séquence de codes géoverrouillés tournants convenue à l’avance. Avec la moindre faiblesse d’OPSEC en dessous de ça, c’est fini.
    Si une personne ordinaire utilise normalement un appareil numérique connecté, elle doit partir du principe que ce qu’elle y met a déjà été volé. Si vous voulez vraiment garder quelque chose privé, ne le mettez pas sous forme numérique : gardez-le sur papier ou sur une vieille bande analogique. Au moins, il faudra alors le voler physiquement, ce qui peut être beaucoup plus difficile selon les circonstances, sans pour autant être forcément plus sûr. Au final, on perd dans les deux cas.
    La seule véritable issue consiste à disposer de gouvernements démocratiques où la transparence et les contre-pouvoirs fonctionnent fortement, de lois de protection de la vie privée appliquées vigoureusement, et d’un soutien solide à des organisations comme Citizen Lab.

  • Il est très probable que les autorités égyptiennes aient utilisé cette vulnérabilité pour pirater le téléphone d’Ahmed El Tantawy, candidat opposé au président actuel Abdel Fatah El Sisi lors de l’élection présidentielle.
    https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...

  • Ce n’est pas mentionné dans l’article, mais le Lockdown Mode d’iOS a bloqué cette chaîne d’exploits.

  • Il y a quelque chose que je ne comprends pas : les éditeurs de spyware comme les vendeurs de 0-day emploient tous des personnes dédiées à la recherche de 0-day. Pourquoi Google et Apple ne débauchent-ils pas simplement ces gens ?
    Google et Apple pourraient proposer des salaires très compétitifs ; je me demande donc pourquoi ils ne le font pas. Estiment-ils que le coût pour recruter pratiquement tous les chasseurs de 0-day expérimentés serait simplement supérieur au coût de publication des correctifs ?

    • Je suis précisément quelqu’un qui fait ce genre de travail. Je travaille comme chercheur 0-day.
      Du point de vue des employés, les salaires sont comparables. Le travail dans la Big Tech est moins intéressant. On construit de grosses machines de détection de bugs qui trouvent beaucoup de bugs, puis on les met dans un bug tracker et ils ne seront peut-être corrigés que trois mois plus tard. Le travail en sécurité offensive est plus intéressant. Les vulnérabilités superficielles sont trouvées par la Big Tech, donc il n’en faut que quelques-unes, et il faut connaître en profondeur le système étudié. Il faut aussi savoir passer d’une vulnérabilité à l’exécution de code. Écrire un exploit n’est pas facile. Il m’est difficile d’expliquer pourquoi des ingénieurs travaillent pour des entreprises que je considère comme immorales, mais c’est probablement parce qu’ils ne ressentent pas les choses de la même façon que moi.
      Du point de vue de l’employeur, la question est : « combien dépenser pour un taux de X vulnérabilités trouvées par an ? » Si le code comporte des bugs mais reste perçu comme le plus sûr du marché, augmenter le budget sécurité peut ne pas être dans l’intérêt de l’entreprise. Si on augmente ce budget, il faut se demander quel autre département verra son budget réduit et quel sera l’effet net sur la santé de l’entreprise.
      Si l’on veut corriger les vulnérabilités, il faut rendre le coût de leur découverte et de leur exploitation trop élevé pour que les acheteurs puissent se le permettre. Et il faut continuer à maintenir ce prix plus haut à mesure que les progrès de la sécurité offensive abaissent les coûts de découverte et d’exploitation. Les entreprises défensives ne gagnent généralement pas d’argent en empêchant les bugs, tandis que les entreprises offensives gagnent surtout de l’argent en trouvant des bugs ; il y a donc un décalage. La vulnérabilité ultime de toute entreprise ou organisation, ce sont les ressources limitées.
    • Google dispose de l’une des meilleures équipes que l’argent et la réputation puissent acheter : https://en.m.wikipedia.org/wiki/Project_Zero
      Leur collaboration avec les chercheurs indépendants du monde entier est également excellente. Mais vu la quantité de logiciels écrits chaque jour, ils peuvent quand même passer à côté de certains problèmes.
    • Cela ressemble un peu à regarder le budget du gouvernement américain et à demander : « pourquoi ne pas acheter tous les criminels potentiels pour réduire la majeure partie de la criminalité aux États-Unis ? »
    • Certains d’entre eux ne voudront tout simplement pas travailler chez Google ou Apple, quel que soit le salaire.
      Même si vous les débauchiez aujourd’hui, demain il y aurait plein de nouvelles personnes travaillant pour ce type d’entreprises ; ce serait un cycle sans fin.
    • C’est une bonne idée, mais à certains égards, c’est un casse-tête comparable à : « pourquoi le pays le plus riche du monde n’embauche-t-il pas tous les meilleurs généraux du monde, afin qu’il n’en reste aucun aux autres pays ? »
      Il y a de nombreuses raisons pour lesquelles c’est impossible, mais au fond cela revient au fait que le monde et l’humanité sont trop vastes et trop complexes pour qu’un seul acteur puisse tout posséder, ni même la majeure partie. Trop d’hétérogénéité est intégrée à tout cela. Il existe aussi de nombreuses visions du monde et loyautés qui dépassent l’argent.

  • Firefox dispose aussi de Https First, mais il semble qu’il faille activer le paramètre dom.security.https_first.
    Si possible, le « HTTPS-Only Mode » est clairement ce qu’il y a de mieux.

    • Encore faut-il résister à l’envie de cliquer sur « autoriser quand même ». Honnêtement, même en connaissant le risque, je pense que je cliquerais moi-même. Parce que j’ai simplement envie de visiter ce site.
      À moins que l’invite ne paraisse extrêmement suspecte — par exemple si elle apparaît sur un site dont on sait qu’il prend en charge HTTPS, comme Google.com —, cela ne règle rien.

  • Le billet de Citizen Lab lié dans cet article contient des détails sur l’attaque de l’homme du milieu. On pourrait presque hésiter à appeler ça une attaque : le réseau est conçu pour injecter du contenu quand c’est nécessaire.