Schwachstelle ermöglichte Zugriff auf den Arc-Browser ohne Besuch einer Website

 (kibty.town)
2 Punkte von GN⁺ 2024-09-20 | 1 Kommentare | Auf WhatsApp teilen
  • Durch das Zusammenspiel von Arc-Browsers Boosts und fehlerhaften Firestore-Regeln konnten Angreifer einem Opferkonto einen Boost mit beliebigem JavaScript zuordnen
  • Die Nutzung von Firebase-Authentifizierung und Firestore wurde per Frida-Hooking bestätigt; dabei wurden die Zugriffsabläufe auf die Collections preferences, users, user_referrals und boosts sichtbar
  • Die Schwachstelle entstand dadurch, dass das Ziel für die Anwendung eines Boosts anhand von creatorID bestimmt wurde, Angreifer aber die creatorID ihres eigenen Boost-Dokuments auf die Benutzer-ID eines anderen Nutzers ändern konnten
  • Die Opfer-ID ließ sich aus user_referrals, den boostSnapshots öffentlicher Boosts, geteilten Easels und weiteren Quellen gewinnen; sobald das Opfer die Zielseite besuchte, konnte der bösartige Boost ausgeführt werden
  • The Browser Company zahlte zusammen mit dem Patch eine Prämie von 2.000 US-Dollar und kündigte nach der Vergabe von CVE-2024-45489 eine Abkehr von Firebase, Sicherheitsaudits und ein Bug-Bounty-Programm an

Arc-Cloud-Funktionen und die Nutzung von Firestore

  • Arc verlangte für die Nutzung ein Konto, und es wurde bestätigt, dass bei der Registrierung Firebase-Authentifizierung verwendet wird
  • Bei der anfänglichen Beobachtung des Netzwerkverkehrs waren keine weiteren Anfragen sichtbar, doch bei der Untersuchung der Easels-Sharing-Funktion zeigte sich die mögliche Nutzung von Firestore
  • Easels ist eine Whiteboard-artige Oberfläche, die sich mit anderen teilen lässt und dann im Web angesehen werden kann
  • Firestore ist ein database-as-a-backend-Dienst, mit dem sich Funktionen ohne separates Backend allein über Datenbank-Sicherheitsregeln und direkten Client-Zugriff umsetzen lassen
  • Als früheres Beispiel für mangelhafte Firestore-Sicherheitsregeln wird Firewreck verlinkt

So wurden die Firebase-Aufrufe bestätigt

  • Da das Swift SDK von Firebase dazu neigt, die System-Proxy-Einstellungen nicht zu beachten, wurden die relevanten Aufrufe statt mit mitmproxy per Frida-Skript gedumpt
  • Das Skript hookte Firestore-Aufrufe von Objective-C-Klassen
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • Ausführungsmethoden wie getDocuments, addSnapshotListener:, getDocument
    • Dokument-Schreibmethoden der updateData- und setData-Familie
  • Während der Ausführung von Arc wurden folgende Arten von Firestore-Pfaden und -Abfragen beobachtet
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • Abfrage in user_referrals mit inviter_id == {userID}
    • Abfrage in boosts mit creatorID == {userID}
  • In dieser Struktur speicherte Arc einige Einstellungen, grundlegende Benutzerobjekte, Empfehlungsinformationen und Boosts in Firestore

Warum Boosts zum Angriffsweg wurden

  • Arc Boosts ist eine Funktion, mit der Nutzer Websites anpassen können
    • Elemente blockieren
    • Schriftarten ändern
    • Farben ändern
    • Benutzerdefiniertes CSS
    • Benutzerdefiniertes JavaScript
  • Boosts werden in Firestore gespeichert, und der Arc-Browser entscheidet anhand des Felds creatorID, welche Boosts angewendet werden
  • Ein Angreifer erstellte in seinem eigenen Konto einen Boost für Google.com und testete anschließend durch Änderung einiger Parameter im Firestore-Dokument
  • Wegen der Abfrage auf Basis von creatorID ließen sich die Boosts anderer Nutzer nicht direkt abrufen, aber die creatorID des eigenen Boost-Dokuments konnte auf die Benutzer-ID eines anderen Kontos geändert werden
  • Ein Test mit einem anderen Konto zeigte, dass beim Aufruf von Google.com auf dem Rechner des Opfers der vom Angreifer erstellte Boost angewendet wurde

Angriffskette und Beschaffung der Benutzer-ID

  • Der endgültige Angriffsablauf sah wie folgt aus
    • Die Benutzer-ID des Opfers wird beschafft
    • Im Konto des Angreifers wird ein bösartiger Boost mit gewünschter Payload erstellt
    • Das Feld creatorID des Boost-Dokuments wird auf die ID des Opfers geändert
    • Wenn das Opfer die Zielwebsite besucht, wird der bösartige Boost ausgeführt
  • Diese Schwachstelle war möglich, weil Arc Boosts beliebiges JavaScript enthalten können, in Firestore gespeichert werden und das Anwendungsziel über das Feld creatorID bestimmt wird
  • Es gab mehrere Wege, an die Benutzer-ID des Opfers zu gelangen
    • user_referrals: Wenn jemand zu Arc eingeladen wurde oder eine Empfehlung erhielt, konnte die Benutzer-ID des Gegenübers aus der Tabelle user_referrals gewonnen werden
    • Öffentliche Boosts: Boosts ohne JavaScript können geteilt werden, und in den boostSnapshots der öffentlichen Arc-Boosts-Seite ist die Benutzer-ID des Erstellers enthalten
    • Easels: Auch über die teilbare Whiteboard-Funktion ließ sich eine Benutzer-ID ermitteln

Patch und Zeitplan der Offenlegung

  • The Browser Company betrieb normalerweise kein Bug-Bounty-Programm, zahlte für diese Schwachstelle jedoch 2.000 USD
  • Die Zeitleiste der Schwachstelle war wie folgt
    • 25. August, 17:48 Uhr: Erstkontakt per Signal mit Arc-Mitgründer Hursh
    • 25. August, 18:02 Uhr: Ausführung des PoC der Schwachstelle auf Hurshs Arc-Konto
    • 25. August, 18:13 Uhr: Nach dem Teilen der Details in verschlüsselter Form erfolgte die Aufnahme in einen Slack-Kanal
    • 26. August, 21:41 Uhr: Schwachstelle gepatcht und Prämie ausgezahlt
    • 6. September, 19:49 Uhr: CVE-2024-45489 vergeben
  • Anschließend veröffentlichte Arc einen eigenen Beitrag zu dem Vorfall: CVE-2024-45489 incident response

Ausführung auf privilegierten Seiten und Konflikt mit dem Datenschutz

  • Auch wenn Boosts nicht clientseitig erstellt werden konnten, konnten sie unter anderen Protokollen ausgeführt werden
  • Wurde ein Boost für die Seite settings erstellt, lief er unter chrome://settings und konnte so zu einer Rechteausweitung führen
  • Beim Besuch einer Website wurde folgende Firestore-Abfrage ausgelöst
    • Abfrage der Collection boosts mit den Bedingungen creatorID == {userID} und hostPattern == "www.google.com";
  • Dabei steht hostPattern für die besuchte Website, was im Widerspruch zur Arc-Datenschutzerklärung steht, in der erklärt wird, Arc wisse nicht, welche Websites besucht werden

Folgemaßnahmen von Arc

  • Arc nutzte die Schwachstelle und die Einführung neuer Funktionen als Anlass, sich von Firebase wegzubewegen
  • Arcs eigene Zusammenfassung enthält folgende Maßnahmen
    • Bestätigung der Problembehebung
    • Hinzufügen einer Funktion zum Deaktivieren von Boosts auf Client-Seite
    • Internes Audit der aktuellen Firebase-ACL-Regeln
    • Aufbau eines Protokolls für den Umgang mit Sicherheitsproblemen
  • Zusätzliche Maßnahmen, die in internen Arc-Diskussionen geteilt wurden, sind
    • Behebung des Datenschutzproblems im Update v1.61.1
    • Kein Einsatz von Firebase mehr in neuen Funktionen und Produkten
    • Externes Sicherheitsaudit für diese Version
    • Start eines Bug-Bounty-Programms für künftige Schwachstellen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-20
Meinungen auf Hacker News

  • Ich bin Hursh, Mitgründer und CTO von The Browser Company, die Arc entwickelt. Es gab keine tatsächlich betroffenen Nutzer, und wir haben das Problem sofort gepatcht, aber ich halte die potenzielle Schwere dieser Schwachstelle für inakzeptabel.
    Die technischen Details, unsere Pläne für künftige Verbesserungen, den Abschied von Firebase und die Einrichtung eines offiziellen Bug-Bounty-Programms habe ich hier zusammengefasst: https://arc.net/blog/CVE-2024-45489-incident-response
    Es tut mir wirklich leid – sowohl die Schwachstelle selbst als auch die verspätete Kommunikation. Das Feedback, einschließlich Enttäuschung, Wut und Ermutigung, nimmt uns in die Pflicht, es besser zu machen.

    • Ich frage mich, ob dieser Beitrag nur für HN-Nutzer gedacht ist. Er erscheint weder in der Blog-Übersicht (https://arc.net/blog) noch wurde er auf Twitter gepostet.
      Die gesamte Reaktion wirkt so, als würde man erst reagieren, wenn der Druck groß genug wird.
    • Ein paar Freunde von mir mögen Arc, und ich hatte selbst überlegt zu wechseln, aber jetzt werde ich es nicht nutzen. Nicht so sehr wegen der Schwachstelle an sich, sondern weil für einen Bug, mit dem man alle Nutzer gefährlich übernehmen konnte, gerade einmal 2.000 US-Dollar Bounty gezahlt wurden.
      Ich möchte keinen Browser von einem Anbieter nutzen, der die Sicherheit seiner Nutzer so leicht nimmt. Sicher bin ich nicht, aber bei diesem Schweregrad hätte sich das auf dem Schwarzmarkt wahrscheinlich für deutlich mehr verkaufen lassen.
    • In den Kommentaren weiter unten gibt es Bedenken, dass bei jedem Seitenaufruf die URL und eine identifizierbare Nutzer-ID an TBC gesendet werden. Wer einen Browser jenseits von Chrome nutzt, ist vermutlich generell auch besonders sensibel in Sachen Privatsphäre, daher wäre es gut, darauf einzugehen.
      Schwachstellen können passieren, aber das Senden von Browsing-Daten wirkt wie eine bewusste Designentscheidung.
    • Nach diesem Vorfall sehe ich keine Möglichkeit, überzeugend darzulegen, dass das Team die nötige Expertise hat, um einen Browser zu warten. Unabhängig davon, dass der Fehler behoben wurde, wirkt es nicht so, als könne man jetzt oder künftig einen sicheren Browser bauen.
      Meiner Meinung nach ist das ein Fall, bei dem der CTO zurücktreten sollte.
    • Ich frage mich, ob geplant ist, die Bug-Bounty-Auszahlungen zu erhöhen. 2.000 US-Dollar sind im Verhältnis zum Wert dieses Bugs ein sehr kleiner Betrag, und ich hoffe, dass der Finder angemessen belohnt wird.
      Im Grunde ist das eine hervorragende Gelegenheit, die richtige Richtung einzuschlagen.

  • Viele Kommentare hier schieben die Schuld auf Firebase, aber das wirkt, als würden Leute etwas nachplappern, das sie nicht wirklich kennen. Ich nutze Firebase nicht, habe es aber früher einmal verwendet, und das hier ist weder ein Randfall noch ein schwer zu lösendes Problem, sondern absolute Grundlage.
    Das eigentliche Problem ist, dass die API einem Wert vertraute, mit dem der Client sagt: „Das bin ich.“ Am Ende ist es ein Anfängerfehler und hätte vermutlich mit einer Änderung von einer Zeile behoben werden können. Schon in der Dokumentation unter https://firebase.google.com/docs/rules/rules-and-auth#cloud-... steht, dass request.auth die benötigte Nutzer-ID (request.auth.uid) liefert.

    • Als jemand, der eine mit Firebase gebaute App betreibt, stimme ich zu. Wie der Autor richtig sagt, sind Fehlkonfigurationen sehr leicht möglich, aber solche grundlegenden Sicherheitspraktiken werden in der Firebase-Dokumentation mit fetten, auffälligen Warnungen hervorgehoben.
      Sicherheitsregeln muss man ernst nehmen; faktisch sind sie die einzige Verteidigungslinie.
    • Interessant zu sehen, wie Softwareentwickler erst Authentifizierung selbst gebaut haben, dann dazu übergegangen sind, sie nicht mehr selbst zu bauen, und nun nicht einmal mehr derart offensichtliche Sicherheitsprobleme erkennen.
      Ob man Authentifizierung selbst baut oder nicht, der Kernpunkt ist derselbe: dem Client niemals vertrauen.
    • Wenn es „am Ende ein Anfängerfehler“ ist, wäre mir das fast lieber. Meine Kollegen haben in internen Frontend-Apps mehrfach denselben Fehler gemacht.
    • Ein Sicherheitskonzept, das darauf beruht, dass niemand jemals einen Anfängerfehler macht, ist selbst ein Anfängerfehler.
    • Wenn ich es richtig verstanden habe, hätte die Korrektur dieses Problems ungefähr darin bestanden, die folgenden Regeln in die match-Anweisung von firestore.rules aufzunehmen. Genau so steht es in Einführungsdokumentation zur Sicherheit von 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

  • Die kleine Pixel-Art-Katze, die dorthin lief, wo man geklickt hat, fand ich wirklich toll. Das war so ein lustiges, originelles kleines Detail, wie man es heute nur noch selten sieht, und eine Erinnerung daran, dass das Internet so ein angenehmer Ort sein kann, wenn wir es wollen.

    • Bei mir war sie nicht zu sehen; offenbar respektiert der Entwickler prefers-reduced-motion und zeigt sie bei dieser Einstellung nicht an. Sehr gute Umsetzung: Freude für die, die es mögen, und keine Belästigung für die, die es nicht mögen.
    • Für eine 35 Jahre alte Katze bewegt sie sich ziemlich gut.
      https://en.wikipedia.org/wiki/Neko_(software)
    • Unter Debian kann man die Katze so installieren und starten:
      sudo apt install oneko
      oneko &
      Eignet sich gut als Geschenk auf dem Rechner eines Kollegen, der gerade nicht am Platz ist.
    • Sie ist zwar niedlich, aber weil ich wusste, dass sich die Katze jedes Mal bewegt, wenn ich die Maus bewege oder scrolle, konnte ich mich nicht auf den Text konzentrieren. Ich habe die Konsole geöffnet und sie entfernt. Tut mir leid, Katze.
    • Auf dem Handy hat sie ständig den Text verdeckt, und ich habe nach einer Möglichkeit gesucht, sie loszuwerden. Der Lesemodus von Firefox hat das Problem gelöst.

  • Diesem Beitrag zufolge ist bei Arc ein Konto Pflicht, und der Hostname jeder besuchten Seite sowie die Nutzer-ID werden an Google Firebase gesendet. Damit dürfte Arc unter den derzeit genutzten Browsern wohl der Browser mit dem schwächsten Datenschutz sein.

    • Als ich direkt nach der Installation merkte, dass ein Konto Pflicht ist, habe ich Arc sofort gelöscht. Das wirkte so absurd wie eine Zahnbürste, die WLAN braucht; jetzt sieht es noch schlimmer aus.
    • Den Preis dürfte wohl OperaGX bekommen.
    • Ich frage mich auch, wie sehr Arc kaputtgeht, wenn Firebase ausfällt.
    • Als ich es vor ein paar Monaten heruntergeladen hatte und sah, dass man zur Nutzung ein Konto braucht, hatte ich das Bauchgefühl, dass ich besser einfach weiter Firefox nutze.
    • Werden die Daten, die an Firebase gesendet werden, nicht verschlüsselt? Wenn es sensible Daten sind, würde Google das doch wohl ebenfalls empfehlen.

  • Ein wirklich großartiger Bug. Die Security Rules von Backend-Services wie Firebase haben seltsame Defaults, die schwer zu erklären sind. Wenn man selbst eine API bauen würde, würde man bei einem Datensatz wie boost in diesem Fall die userId nicht aus dem Request-Payload übernehmen, sondern auf die Nutzer-ID der Session setzen.
    Entwickler ab einem gewissen Niveau kommen bei einem geschützten API-Pfad normalerweise gar nicht erst auf die Idee, den Client einen Wert übergeben zu lassen, den er als seine userId ausgibt. Bei Security Rules hingegen muss man sich unabhängig von der tatsächlich programmierten Nutzungsweise jede mögliche Art vorstellen, wie das System missbraucht werden kann.

    • Wenn man so herangeht, macht man es ehrlich gesagt falsch. Wenn man mit Default Deny beginnt, muss man sich nur die legitimen Nutzungsweisen vorstellen.
    • Bei Inserts stimmt das, aber bei Updates habe ich oft gesehen, dass der gesamte Request unverändert in ein ORM oder einen Document Store geschoben wird. Man denkt leicht: „Der Eigentümer darf das Dokument aktualisieren“, übersieht dabei aber, dass einige Felder, die der offizielle Client nicht setzt – etwa Eigentümer oder Erstellungszeitpunkt –, nicht geändert werden dürfen.
      Die richtige Lösung ist vermutlich, für alle Felder standardmäßig keine Schreibrechte zu vergeben. Dann muss man zumindest explizit angeben, dass das Eigentümerfeld beschreibbar ist, und denkt auch über die Auswirkungen nach, dieses Objekt an einen anderen Nutzer zu übertragen.

  • Es ist erstaunlich, wie absurd dumm diese Schwachstelle ist. Für Remote Code Execution muss man buchstäblich nur die Nutzer-ID einer anderen Person senden, und auch diese ID ist ziemlich leicht zu bekommen.
    Ich arbeite nicht bei FAANG, sondern bei einer Firma, die ein mieses Produkt baut, das eigentlich niemand braucht, aber selbst ich würde so einen Bug nicht einbauen. Und diese Leute wollen einen Browser bauen und die damit einhergehende Security-Expertise und moralische Verantwortung tragen?

    • Kannst du erklären, wie man an die Nutzer-ID einer anderen Person kommt? Ich verstehe, dass es eine große Schwachstelle ist, aber ich möchte verstehen, wie dieser Teil passiert.

  • Es wäre gut, Arc in den Titel des Posts aufzunehmen, damit Leute, die Arc nutzen oder Arc-Nutzer kennen, es besser erkennen können.

    • Stimme vollkommen zu. Als ich es gestern zum ersten Mal gesehen habe, wusste ich nicht, dass mich das betrifft; erst nachdem der Titel geändert wurde, habe ich geklickt.
      Ehrlich gesagt bin ich stark der Meinung, dass der Titel etwa „Grundlegender Bug im Arc-Browser (CVE 123-4567)“ lauten sollte.

  • Es gibt viele schwerwiegende Sicherheitslücken, die auf nachvollziehbare Weise entstehen und die man verzeihen kann, wenn sie verantwortungsvoll behandelt und behoben werden.
    Das hier ist aber kein solcher Fall. Für mich zeigt es rufschädigende Inkompetenz und reicht aus, um zu beschließen, Arc nie wieder zu nutzen.

    • Andererseits ist die Reaktionsgeschwindigkeit an sich ziemlich beeindruckend.
      aug 25 5:48pm: Erster Kontakt mit Arc-Mitgründer Hursh über einen verschlüsselten Signal-Kanal
      aug 25 6:02pm: Proof of Concept der Schwachstelle auf Hurshs Arc-Konto ausgeführt
      aug 25 6:13pm: Details in verschlüsselter Form offengelegt und zu einem Slack-Channel hinzugefügt
      aug 26 9:41pm: Schwachstelle gepatcht, Bounty ausgezahlt
      sep 6 7:49pm: CVE zugewiesen (CVE-2024-45489)
      Vier Stunden vom unvermittelten Erstkontakt bis zur Auslieferung des Fixes sind ziemlich gut, selbst wenn man berücksichtigt, dass der Fix vermutlich einfach war. Korrektur: Das Datum hat gewechselt, also waren es tatsächlich 28 Stunden. Trotzdem ordentlich, und die Reaktion „komm in unseren Slack-Channel“ 30 Minuten nach dem Erstkontakt ist sehr schnell.
    • Dass man schon zum bloßen Ausprobieren von Arc ein Pflichtkonto brauchte, war von Anfang an ein großes Warnsignal; deshalb habe ich es gar nicht erst ausprobiert. Jetzt bin ich froh darüber.
    • Ehrlich gesagt habe ich Arc, besonders beim Datenschutz, immer als Wolf im Schafspelz gesehen.
      Bei einem so wichtigen und persönlichen Produkt wie einem Browser sind 50 bis 60 Millionen Dollar Cash und eine Bewertung von 500 Millionen Dollar ohne Geschäftsmodell ein großes Warnsignal. Es ist keine Wohltätigkeit, also wird irgendjemand auf irgendeine Weise dafür bezahlen.
    • Man würde meinen, ein Unternehmen, das einen Browser vertreibt, würde bei Security Rules etwas mehr Sorgfalt walten lassen.
      Schade ist auch, dass Firebase das nicht idiotensicherer gemacht hat. Und wirklich nur $2,500? Man hätte buchstäblich alle Nutzer von Arc übernehmen können; die NSA hätte da ein paar Nullen drangehängt.
    • Und dann auch noch Firebase – ernsthaft? Ein Unternehmen, das sogar Low-Level-Softwareingenieure beschäftigt, nutzt ein kastenfertiges CRUD-Backend. Kosteneffizient war es wohl, aber wenn ich so etwas entwerfen würde, stünde Firebase nicht einmal auf der langen Liste der Backend-Kandidaten.
      Zumal funktionale Konkurrenten wie Supabase im Grunde ein normales DBMS und ein Authentifizierungsmodell umhüllen.

  • Danke fürs Teilen. Ich nutze Arc seit der ersten Beta-Woche.
    Ziemlich besorgniserregend ist allerdings, dass dieser Bug und der Fix nirgends in den sozialen Medien erwähnt wurden. Die Zeit mit Arc hat Spaß gemacht, aber angesichts dieser Handhabung glaube ich nicht, dass ich es weiter nutzen kann.

    • Reicht es nicht, das Problem anzuerkennen und innerhalb von 28 Stunden zu beheben? Bei so einer Reaktion habe ich das Gefühl, dass man Arc weiter nutzen kann.

  • $2,000 für eine so große Schwachstelle sind ein beleidigender Betrag.

    • Wenn man sich Blogposts auf HN ansieht, scheint es oft vorzukommen, dass solche Schwachstellen gar nicht oder nur mit sehr kleinen Beträgen vergütet werden. Es wirkt fast so, als würden die Unternehmen Hacker anflehen, ihre Exploits zu verkaufen.
      Vielleicht liegt es daran, dass sie für Sicherheitsvorfälle nicht von Regulierungsbehörden bestraft werden.
    • Ja, das war auch meine erste Reaktion. Ich war wirklich überrascht, dass sie hier so knauserig waren.
    • Man braucht schon ein ziemlich starkes Gewissen, um das nicht an eine böswillige Partei zu verkaufen, die das 20- bis 50-Fache zahlen würde.