Une faille permettait d’accéder au navigateur Arc sans visiter de site web

 (kibty.town)
2 points par GN⁺ 2024-09-20 | 1 commentaires | Partager sur WhatsApp
  • La combinaison des Boosts du navigateur Arc et de règles Firestore problématiques permettait à un attaquant d’associer au compte d’une victime un Boost contenant du JavaScript arbitraire
  • L’utilisation de Firebase Authentication et de Firestore a été confirmée par hooking Frida, révélant le flux d’accès aux collections preferences, users, user_referrals et boosts
  • La faille venait du fait que la cible d’application d’un Boost était déterminée par creatorID, alors même qu’un attaquant pouvait remplacer le creatorID de son propre document Boost par l’ID d’un autre utilisateur
  • L’ID de la victime pouvait être obtenu via user_referrals, les boostSnapshots de Boosts publics, des Easels partagés, etc. ; lorsque la victime visitait le site ciblé, le Boost malveillant pouvait s’exécuter
  • The Browser Company a publié un correctif et versé une récompense de 2 000 $ ; après l’attribution de CVE-2024-45489, l’entreprise a décidé de réduire son usage de Firebase, de mener des audits de sécurité et de lancer un programme de bug bounty

Les fonctionnalités cloud d’Arc et l’utilisation de Firestore

  • Arc nécessitait un compte pour être utilisé, et le processus d’inscription a confirmé l’usage de Firebase Authentication
  • Les premières observations réseau ne montraient pas d’autres requêtes, mais l’examen de la fonction de partage des Easels a révélé une possible utilisation de Firestore
  • Les Easels sont une interface de type tableau blanc qui peut être consultée sur le web lorsqu’elle est partagée avec d’autres personnes
  • Firestore est un service de database-as-a-backend permettant de créer des fonctionnalités sans backend distinct, grâce à des règles de sécurité de base de données et à un accès direct depuis le client
  • Un cas précédent de règles de sécurité Firestore insuffisantes est lié à Firewreck

Comment les appels Firebase ont été confirmés

  • Comme le SDK Swift de Firebase a tendance à ne pas respecter les paramètres de proxy système, les appels associés ont été dumpés avec un script Frida plutôt qu’avec mitmproxy
  • Le script hookait les appels Firestore de classes Objective-C
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • des méthodes d’exécution comme getDocuments, addSnapshotListener:, getDocument
    • des méthodes d’écriture de documents de la famille updateData et setData
  • Pendant l’exécution d’Arc, les types de chemins et de requêtes Firestore suivants ont été observés
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • requête sur user_referrals avec inviter_id == {userID}
    • requête sur boosts avec creatorID == {userID}
  • Cette structure montrait qu’Arc stockait dans Firestore certains paramètres, l’objet utilisateur de base, les informations de parrainage et les Boosts

Pourquoi les Boosts sont devenus le vecteur d’attaque

  • Les Arc Boosts sont une fonctionnalité permettant aux utilisateurs de personnaliser des sites web
    • blocage d’éléments
    • changement de police
    • changement de couleurs
    • CSS personnalisé
    • JavaScript personnalisé
  • Les Boosts sont stockés dans Firestore, et le navigateur Arc recherche les Boosts à appliquer via le champ creatorID
  • L’attaquant a créé, depuis son propre compte, un Boost pour Google.com, puis a modifié certains paramètres du document Firestore pour faire des tests
  • À cause de la requête basée sur creatorID, il n’était pas possible de consulter directement les Boosts d’un autre utilisateur, mais il était possible de remplacer le creatorID de son propre document Boost par l’ID utilisateur d’un autre compte
  • Un test avec un autre compte a montré que, lorsque la machine de la victime accédait à Google.com, le Boost créé par l’attaquant était appliqué

Chaîne d’attaque et obtention de l’ID utilisateur

  • Le déroulé final de l’attaque était le suivant
    • obtenir l’ID utilisateur de la victime
    • créer sur le compte de l’attaquant un Boost malveillant contenant le payload voulu
    • remplacer le champ creatorID du document Boost par l’ID de la victime
    • lorsque la victime visite le site web ciblé, le Boost malveillant s’exécute
  • Cette vulnérabilité existait parce que les Arc Boosts peuvent contenir du JavaScript arbitraire, sont stockés dans Firestore et que la cible d’application est déterminée par le champ creatorID
  • Il existait plusieurs moyens d’obtenir l’ID utilisateur d’une victime
    • user_referrals : lorsqu’une personne invite quelqu’un sur Arc ou reçoit une invitation/recommandation, l’ID utilisateur de l’autre personne peut être obtenu dans la table user_referrals
    • Boosts publics : les Boosts sans JavaScript peuvent être partagés, et les boostSnapshots du site public Arc Boosts contiennent l’ID utilisateur du créateur
    • Easels : l’ID utilisateur pouvait aussi être obtenu via la fonctionnalité de tableau blanc partageable

Correctif et calendrier de divulgation

  • The Browser Company ne proposait généralement pas de bug bounty, mais a versé 2 000 USD pour cette vulnérabilité
  • La chronologie de la faille est la suivante
    • 25 août, 17 h 48 : premier contact via Signal avec Hursh, cofondateur d’Arc
    • 25 août, 18 h 02 : exécution d’une PoC de la vulnérabilité sur le compte Arc de Hursh
    • 25 août, 18 h 13 : partage des détails sous forme chiffrée, puis ajout à un canal Slack
    • 26 août, 21 h 41 : correction de la vulnérabilité et versement de la récompense
    • 6 septembre, 19 h 49 : attribution de CVE-2024-45489
  • Arc a ensuite publié son propre billet sur le sujet, CVE-2024-45489 incident response

Exécution sur des pages privilégiées et conflit avec la confidentialité

  • Même si les Boosts ne pouvaient pas être créés côté client, ils pouvaient s’exécuter dans d’autres protocoles
  • En créant un Boost ciblant la page settings, il s’exécutait sur chrome://settings, ce qui pouvait entraîner une élévation de privilèges
  • Lors de la visite d’un site, la requête Firestore suivante était déclenchée
    • recherche dans la collection boosts avec les conditions creatorID == {userID} et hostPattern == "www.google.com";
  • Ici, hostPattern désigne le site visité, ce qui entre en contradiction avec la politique de confidentialité d’Arc, selon laquelle Arc affirme ne pas savoir quels sites sont visités

Mesures prises ensuite par Arc

  • À la suite de cette vulnérabilité et de l’introduction de nouvelles fonctionnalités, Arc a choisi de s’éloigner de Firebase
  • Le résumé publié par Arc inclut les mesures suivantes
    • confirmation de la correction du problème
    • ajout d’une fonction permettant de désactiver les Boosts côté client
    • audit interne des règles ACL Firebase actuelles
    • mise en place d’un protocole de réponse aux incidents de sécurité
  • Les mesures supplémentaires partagées dans les discussions internes d’Arc étaient les suivantes
    • correction du problème de confidentialité dans la mise à jour v1.61.1
    • arrêt de l’utilisation de Firebase dans les nouvelles fonctionnalités et les nouveaux produits
    • audit de sécurité externe pour cette version
    • lancement d’un programme de bug bounty pour les futures vulnérabilités

À lire aussi

1 commentaires

 
GN⁺ 2024-09-20
Avis sur Hacker News

  • Je suis Hursh, cofondateur et CTO de The Browser Company, qui développe Arc. Aucun utilisateur n’a effectivement été touché et nous avons corrigé immédiatement, mais nous estimons que la gravité potentielle de cette vulnérabilité est inacceptable.
    Nous avons détaillé ici les aspects techniques, nos plans d’amélioration à venir, notre sortie de Firebase et la mise en place d’un vrai programme de bug bounty : https://arc.net/blog/CVE-2024-45489-incident-response
    Nous sommes vraiment désolés, à la fois pour la vulnérabilité elle-même et pour la communication tardive. Vos retours — déception, colère, encouragements compris — nous obligent à faire mieux.

    • Je me demande si ce billet a été écrit uniquement pour les utilisateurs de HN. Il n’apparaît pas non plus dans la liste du blog (https://arc.net/blog) et n’a pas été publié sur Twitter.
      Toute la réponse donne l’impression qu’ils ne réagissent que lorsqu’il y a suffisamment de bruit.
    • Quelques amis aiment Arc, et j’envisageais moi-même de passer dessus, mais désormais je ne compte pas l’utiliser. Pas tant à cause de la vulnérabilité elle-même, mais parce qu’ils ont versé seulement 2 k$ de bounty pour un bug qui aurait pu permettre de compromettre tous les utilisateurs.
      Je n’ai pas envie d’utiliser un navigateur conçu par une entreprise qui prend la sécurité de ses utilisateurs aussi à la légère. Je n’en suis pas certain, mais une faille d’une telle gravité se serait probablement vendue bien plus cher sur le marché noir.
    • Dans les commentaires ci-dessous, certains s’inquiètent du fait que chaque chargement de page enverrait l’URL et un identifiant utilisateur identifiable à TBC. Les personnes qui utilisent un navigateur autre que Chrome sont en général probablement aussi sensibles à la vie privée, donc il serait utile de répondre sur ce point.
      Des vulnérabilités peuvent arriver, mais envoyer les données de navigation ressemble à un choix de conception délibéré.
    • Après avoir vu ça, je ne vois pas comment on pourrait être convaincu que l’équipe a l’expertise nécessaire pour maintenir un navigateur. Indépendamment du fait que ce soit corrigé, elle ne semble pas avoir, aujourd’hui ni demain, la capacité de construire un navigateur sûr.
      À mon avis, c’est le genre d’affaire qui devrait entraîner la démission du CTO.
    • Je me demande s’ils prévoient d’augmenter les montants de leur bug bounty. 2 000 $, c’est une somme dérisoire par rapport à la valeur de ce bug, et j’espère que la personne qui l’a découvert recevra une vraie récompense.
      C’est une occasion en or de prendre la bonne direction.

  • Beaucoup de commentaires ici accusent Firebase, mais on dirait surtout que les gens répètent des choses qu’ils ne connaissent pas vraiment. Je n’utilise pas Firebase aujourd’hui, mais pour l’avoir déjà utilisé, ce n’est ni un cas limite ni un problème difficile à résoudre : c’est vraiment la base de la base.
    Le vrai problème, c’est que l’API a été conçue pour faire confiance à une valeur par laquelle le client dit « voilà qui je suis ». Au final, c’est une erreur d’amateur, probablement corrigeable avec une modification d’une ligne. Rien qu’en lisant la documentation, https://firebase.google.com/docs/rules/rules-and-auth#cloud-... montre que request.auth fournit l’ID utilisateur nécessaire (request.auth.uid).

    • En tant que personne qui exploite une appli construite avec Firebase, je suis d’accord. Comme l’auteur le souligne justement, il est très facile de se tromper dans la configuration, mais ces bonnes pratiques de sécurité de base sont mises en avant dans la documentation Firebase avec des avertissements visibles et en gras.
      Les règles de sécurité doivent être prises au sérieux : ce sont, en pratique, la seule ligne de défense.
    • C’est intéressant de voir les ingénieurs logiciels passer de « on fait l’authentification nous-mêmes » à « on ne la fait plus nous-mêmes », puis à un point où ils ne remarquent même plus des problèmes de sécurité aussi flagrants.
      Qu’on fasse l’authentification soi-même ou non, le principe clé reste le même : ne jamais faire confiance au client.
    • Si « au final, c’est une erreur d’amateur », ce serait presque rassurant. Mes collègues aussi ont commis plusieurs fois exactement la même erreur dans des applis frontend internes.
    • Un plan de sécurité qui repose sur l’hypothèse que personne ne fera jamais d’erreur d’amateur est lui-même une erreur d’amateur.
    • Si j’ai bien compris, corriger ce problème revenait à ajouter les règles suivantes dans une instruction match de firestore.rules. C’est exactement le genre de chose qu’on trouve dans la documentation d’introduction à la sécurité de Firebase Firestore. 
      
// Allow create new object if user is authenticated

allow create: if request.auth != null;

// Allow update or delete document if user is owner of document

allow update, delete: if request.auth.uid == resource.data.ownerUID

  • J’ai beaucoup aimé le petit chat en pixel art qui accourt là où l’on clique. C’était un petit dispositif amusant et malin, comme on en voit rarement de nos jours, et ça rappelait que, si on le voulait, Internet pourrait aussi être ce genre d’endroit joyeux.

    • De mon côté, il n’apparaissait pas ; on dirait que le développeur respecte prefers-reduced-motion et ne l’affiche pas quand ce réglage est activé. C’est une excellente approche : du plaisir pour ceux qui en veulent, et pas de nuisance pour ceux qui n’en veulent pas.
    • Pour un chat de 35 ans, il bouge encore très bien.
      https://en.wikipedia.org/wiki/Neko_(software)
    • Sur Debian, on peut installer et lancer le chat avec :
      sudo apt install oneko
      oneko &
      Parfait à offrir sur l’ordinateur d’un collègue absent.
    • C’est mignon, mais sachant que le chat allait bouger à chaque déplacement de souris ou à chaque scroll, je n’arrivais plus à me concentrer sur l’article. J’ai ouvert la console et je l’ai supprimé. Désolé, le chat.
    • Sur téléphone, il masquait constamment le texte et je cherchais un moyen de le faire disparaître. Le mode lecture de Firefox a réglé le problème.

  • D’après cet article, Arc exige un compte et envoie à Google Firebase le nom d’hôte de toutes les pages visitées ainsi que l’ID utilisateur. Dans ce cas, Arc ne devient-il pas le navigateur le moins respectueux de la vie privée parmi ceux utilisés aujourd’hui ?

    • Juste après l’installation, quand j’ai vu que le compte était obligatoire, j’ai immédiatement supprimé Arc. Ça m’avait semblé aussi absurde qu’une brosse à dents qui aurait besoin du Wi‑Fi, mais avec le recul c’est encore plus grave.
    • Je pense que ce prix revient à OperaGX.
    • Je me demande aussi à quel point Arc se casse la figure si Firebase tombe.
    • Quand je l’ai téléchargé il y a quelques mois et que j’ai vu qu’il fallait un compte pour l’utiliser, mon intuition m’a dit qu’il valait mieux continuer avec Firefox.
    • Ils ne chiffrent pas les données envoyées à Firebase ? Si ce sont des données sensibles, Google recommanderait probablement de le faire.

  • C’est vraiment un bug magnifique. Les règles de sécurité des services backend comme Firebase ont des valeurs par défaut étranges, difficiles à expliquer. Si je concevais une API moi-même, le userId d’un enregistrement comme boost dans cet exemple ne viendrait pas du payload de la requête, mais serait défini à partir de l’ID utilisateur de la session.
    Un développeur d’un certain niveau n’aurait généralement même pas l’idée de laisser un client transmettre, sur une route d’API protégée, une valeur qu’il prétend être son propre userId. En revanche, avec les règles de sécurité, il faut imaginer toutes les façons dont le système peut être détourné, indépendamment de la manière dont il a effectivement été programmé pour être utilisé.

    • Franchement, si on aborde les choses comme ça, on s’y prend mal. En partant d’un refus par défaut, il suffit d’imaginer les usages légitimes.
    • C’est vrai pour les insertions, mais pour les mises à jour, j’ai souvent vu des cas où l’intégralité de la requête était passée telle quelle à un ORM ou à un magasin de documents. Il est facile de se dire que « le propriétaire peut mettre à jour le document », tout en oubliant que certains champs que le client officiel ne définit pas — par exemple le propriétaire ou la date de création — ne devraient pas pouvoir changer.
      La bonne solution consiste probablement à appliquer des droits refusés par défaut à tous les champs. Ainsi, il faut au minimum déclarer explicitement que le champ propriétaire est modifiable, ce qui force aussi à réfléchir aux conséquences du transfert de cet objet à un autre utilisateur.

  • Je suis sidéré par le niveau d’absurdité de cette faille. Pour exécuter du code arbitraire, il suffisait littéralement d’envoyer l’ID utilisateur de quelqu’un d’autre, et cet ID était apparemment assez facile à obtenir.
    Je ne travaille pas chez une FAANG, mais dans une entreprise qui fabrique un produit médiocre dont personne n’a vraiment besoin, et même moi je ne créerais pas un bug pareil. Et ces gens veulent fabriquer un navigateur, avec toute l’expertise sécurité et la responsabilité morale que cela implique ?

    • Peux-tu expliquer comment obtenir l’ID utilisateur de quelqu’un d’autre ? Je comprends que c’est une grosse faille, mais j’aimerais comprendre comment cette partie se produit.

  • Il faudrait mettre Arc dans le titre du post, pour que les personnes qui l’utilisent ou qui connaissent des utilisateurs d’Arc puissent le repérer plus facilement.

    • Tout à fait d’accord. Quand je l’ai vu pour la première fois hier, je n’ai pas compris que ça me concernait, et je n’ai cliqué qu’après le changement de titre.
      Honnêtement, je pense vraiment que le titre devrait être du genre « Bug fondamental dans le navigateur Arc (CVE 123-4567) ».

  • Il existe beaucoup de failles de sécurité graves qui peuvent se comprendre, et qu’on peut pardonner si elles sont traitées et corrigées de manière responsable.
    Mais ce n’est pas le cas ici. Personnellement, cela démontre un niveau d’incompétence capable de ruiner une réputation, au point de me convaincre de ne plus jamais utiliser Arc.

    • Cela dit, la rapidité de la réponse est assez impressionnante.
      aug 25 5:48pm : premier contact avec Hursh, cofondateur d’Arc, via un canal chiffré Signal
      aug 25 6:02pm : exécution de la preuve de concept de la faille sur le compte Arc de Hursh
      aug 25 6:13pm : divulgation des détails sous forme chiffrée, puis ajout à un canal Slack
      aug 26 9:41pm : faille corrigée, prime versée
      sep 6 7:49pm : CVE attribuée (CVE-2024-45489)
      Quatre heures entre le premier contact inattendu et le déploiement du correctif, c’est plutôt bon, même en tenant compte du fait que la correction était probablement simple. Correction : la date a changé, donc c’était en réalité 28 heures. Cela reste correct, et la réaction « rejoins notre canal Slack » 30 minutes après le premier contact est très rapide.
    • Le fait qu’un compte obligatoire soit requis même pour simplement essayer Arc était dès le départ un énorme signal d’alerte, donc je ne l’ai jamais essayé. Je suis maintenant content de ne pas l’avoir fait.
    • Franchement, j’ai toujours vu Arc, surtout côté vie privée, comme un loup déguisé en mouton.
      Pour un produit aussi important et personnel qu’un navigateur, lever 50 à 60 millions de dollars et obtenir une valorisation de 500 millions sans modèle économique est un gros signal d’alerte. Ce n’est pas une œuvre caritative : quelqu’un finira par payer, d’une manière ou d’une autre.
    • On s’attendrait à ce qu’une entreprise qui distribue un navigateur fasse un peu plus attention aux règles de sécurité.
      C’est aussi dommage que Firebase ne rende pas ça un peu plus à l’épreuve des erreurs idiotes. Et vraiment, seulement 2 500 $ ? On pouvait littéralement prendre le contrôle de tous les utilisateurs d’Arc ; la NSA aurait sans doute ajouté quelques zéros.
    • Et en plus, Firebase ? Sérieusement ? Une entreprise qui emploie même des ingénieurs logiciel bas niveau utilise un backend CRUD en boîte. C’était sans doute rentable, mais si je concevais ce genre de chose, Firebase ne figurerait même pas sur la longue liste des candidats backend.
      Surtout quand des concurrents fonctionnels comme Supabase enveloppent un SGBD classique et un modèle d’authentification.

  • Merci pour le partage. J’utilise Arc depuis la première semaine de la bêta.
    Mais le fait qu’ils n’aient mentionné ce bug et sa correction nulle part sur les réseaux sociaux est assez inquiétant. J’ai apprécié mon temps avec Arc, mais vu cette manière de gérer les choses, je ne pense pas pouvoir continuer à l’utiliser.

    • Reconnaître le problème et le corriger en moins de 28 heures, ce n’est pas suffisant ? Avec une telle réaction, j’aurais plutôt tendance à penser que je peux continuer à utiliser Arc.

  • 2 000 $ pour une faille aussi énorme, c’est insultant.

    • À lire les billets de blog sur HN, on dirait que ce genre de faille n’est souvent pas récompensé du tout, ou seulement par des montants dérisoires. On a presque l’impression que les entreprises supplient les hackers de vendre leurs exploits.
      C’est peut-être parce qu’elles ne sont pas sanctionnées par les régulateurs en cas d’incident de sécurité.
    • Oui, c’était aussi ma première réaction. Je suis vraiment surpris qu’ils aient été aussi radins.
    • Il faut une conscience assez solide pour ne pas vendre ça à un acteur malveillant prêt à payer 20 à 50 fois ce montant.