Per mDNS den echten Namen von macOS-Nutzern im Browser per Brute Force erraten

 (fingerprint.com)
3 Punkte von GN⁺ 2023-07-14 | 1 Kommentare | Auf WhatsApp teilen
  • Der standardmäßige lokale Hostname von macOS kann den Benutzernamen enthalten, sodass eine Website ohne Berechtigung über Zeitunterschiede bei der mDNS-Namensauflösung mögliche Namen eingrenzen kann
  • Angreifer kombinieren 50 beliebte Vornamen nach Land und Geschlecht mit Kandidaten für Gerätenamen; im Experiment wurde der Name von macOS-Nutzern in durchschnittlich 65 % der Fälle korrekt erraten
  • Browser-JavaScript kann keine beliebigen UDP-Sockets öffnen, aber über Anfragen mit fetch, iframe, Image und WebRTC lassen sich Antwortverzögerungen bei .local-Adressen vergleichen
  • Informationen wie Zeitzone, Sprache, IP-Standort, navigator.language in Safari, Bildschirmauflösung und screen.isExtended helfen dabei, Kandidaten für Locale und Gerätemodell einzugrenzen
  • Die praktische Nutzbarkeit ist gering und im Netzwerk-Tab der Entwicklertools leicht sichtbar, doch dieselbe mDNS-Erkundungsmethode könnte auch zum Erkennen von Druckern, Smart-TVs, Smart Speakern und IoT-Geräten verwendet werden

Wie Namen über macOS-Local-Hostnames durchsickern

  • Der echte Name eines macOS-Nutzers kann im Browser ohne Berechtigungsanfrage geschätzt werden; der Kern des Problems sind das mDNS-Protokoll und das Format des standardmäßigen lokalen Hostnamens
  • Schon mit einer Liste von 50 beliebten Vornamen pro Geschlecht aus einem bestimmten Land wurde der Name von macOS-Nutzern in durchschnittlich 65 % der Fälle korrekt erkannt
  • Fingerprint verwendet diese Technik nicht im Produkt und bietet auch keinen Cross-Site-Tracking-Dienst an
  • Ziel der öffentlichen Diskussion ist es, Browser-Anbieter dabei zu unterstützen, solche Techniken schnell zu beheben

Wie mDNS und Apple Bonjour funktionieren

  • multicast DNS ist ein Protokoll zum Registrieren, Erkennen und Broadcasten von Gerätenamen im lokalen Netzwerk
  • Geräte wie Drucker senden UDP-Registrierungspakete an die reservierte interne IP 224.0.0.251; diese können Hostnamen wie HP_LaserJet_Printer.local enthalten
  • Die Top-Level-Domain .local zeigt an, dass dieser Hostname per mDNS aufgelöst werden soll
  • Router broadcasten solche Pakete automatisch an andere Geräte im lokalen Netzwerk, damit diese den Hostnamen cachen können
  • Geräte senden Abfragepakete an dieselbe reservierte IP, um Geräte mit einem bestimmten Namen zu finden, die im Netzwerk vorhanden sein könnten
  • Beispiel-Hostnamen sind:
    • johns-mac-mini.local
    • david-ZenBook-UX431DA-UM431DA.local
    • james-iphone.local
    • canon-mf644c.local
    • bedroom-appletv.local
    • dlinkrouter.local
  • Auf Apple-Geräten wird mDNS breit genutzt, unter anderem als Teil von Apple Bonjour
  • Im standardmäßigen lokalen Hostnamen kann der Benutzername sichtbar werden; unter macOS lässt sich der lokale Hostname in Systemeinstellungen > Freigabe einsehen oder ändern

Umgehungsmethode zum Prüfen von mDNS-Hostnamen im Browser

  • mDNS basiert auf UDP-Paketen und kann deshalb in Browser-JavaScript nicht direkt über beliebige UDP-Sockets genutzt werden
  • Stattdessen wird ein Timing-Angriff genutzt, indem ausgenutzt wird, dass der Browser versucht, den Hostnamen einer URL aufzulösen
  • Der Proof of Concept sendet normale fetch-GET-Anfragen an ein existierendes device-1.local und ein nicht existierendes device-2.local
  • Wird die Adresse aufgelöst, sendet der Browser ein TCP-Paket an Port 80, der meist geschlossen ist
  • Auf Netzwerkebene erscheinen unterschiedliche Fehler:
    • existierendes device-1.local: ERR_CONNECTION_REFUSED
    • nicht existierendes device-2.local: ERR_NAME_NOT_RESOLVED
  • In JavaScript werden beide Fehler jedoch auf denselben Fehler Failed to fetch abgebildet, daher kann man sich nicht auf den Fehlertyp selbst verlassen
  • Da lokale Netzwerke schnell sind, werden gültige mDNS-Hostnamen deutlich schneller als das Standard-Connection-Timeout aufgelöst
  • Im Beispiel lag die Zeit für eine gültige Adresse bei 4 ms, für eine ungültige bei 5 Sekunden
  • Dieser Ansatz ist für einen Proof of Concept ausreichend konsistent und funktioniert ähnlich in den wichtigsten Browsern
  • In der Praxis lassen sich DNS-Timing-Angriffe neben fetch auch mit Netzwerk-JavaScript-APIs wie iframe, Image und WebRTC durchführen

Wie sich macOS-Benutzernamen per Brute Force erraten lassen

  • Der standardmäßige lokale macOS-Hostname enthält Benutzernamen und Gerätenamen; das Format variiert je nach System-Locale
    • Englisch: <name>s-macbook-pro.local
    • Französisch: macbook-air-de-<name>.local
    • Russisch: mac-mini-<name>.local
  • Mit einem einfachen Ansatz aus den 1.000 häufigsten Namen, den 10 wichtigsten Locales und 5 typischen macOS-Geräten müssten 50.000 Hostnamen geprüft werden
  • Ein vollständiger Durchlauf könnte in diesem Fall mehr als eine Stunde dauern
  • Eine effizientere Strategie beschränkt den Suchraum auf eine einzelne Locale, ein einzelnes Gerät und 50 häufige Namen dieser Locale
  • Das verringert zwar die Genauigkeit, macht das Angriffsszenario durch die kürzere Dauer aber realistischer
  • Zur Auswahl der Locale können Browser-Zeitzone, Sprache und der Standort der IP-Adresse genutzt werden
  • Safari legt über die Eigenschaft navigator.language die System-Locale offen; dieser Wert stimmt meist mit der Locale des Ziel-Hostnamens überein
  • Eine weitere Umgehungsmethode zur Bestimmung des Herkunftslands eines Nutzers ist die zuvor behandelte Methode zur Apple-ID-Regionserkennung
  • Kandidaten für das Gerät lassen sich über die Bildschirmauflösung eingrenzen
    • So deutet etwa eine Auflösung von 1728x1117 stark auf ein 16-Zoll-MacBook Pro hin
    • Ein erweiterter Bildschirm lässt sich über die Eigenschaft screen.isExtended erkennen
    • Wird ein erweiterter Bildschirm erkannt, lassen sich die Gerätekandidaten auf die 3 bis 5 häufigsten Apple-macOS-Geräte zurücksetzen

Grenzen und andere Einsatzmöglichkeiten

  • Dieser Angriff ist wegen inhärenter Schwächen und verschiedener Einschränkungen nicht praktikabel
  • Wenn eine Website Besucher nicht absichtlich deanonymisieren will, ist die Methode im Netzwerk-Tab der Browser-Entwicklertools leicht erkennbar
  • In Kombination mit installed applications detection könnte daraus jedoch eine schädliche Website entstehen, die ohne Berechtigung den echten Namen eines Nutzers und daraus abgeleitet aus einer Liste professioneller Anwendungen seine Berufsrolle anzeigt
  • Apple-Geräte mit macOS sind das Hauptbeispiel, aber die mDNS-Erkundungstechnik lässt sich auf verschiedene Weise erweitern
  • Sie könnte auch verwendet werden, um über lokale Netzwerkscans Drucker, Smart-TVs, Smart Speaker und andere IoT-Geräte im Haushalt zu erkennen
  • Auch auf iPhone und iPad ist sie anwendbar, sofern Wi‑Fi-Synchronisierung oder die Safari-Funktion für Remote-Debugging aktiviert ist

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-14
Hacker-News-Kommentare

  • Ich nutze Little Snitch auf macOS; es hat eine ganz gute UI, mit der man festlegen kann, dass vor dem Erlauben einer Netzwerkanfrage der lokale Benutzer ausdrücklich gefragt wird
    https://www.obdev.at/products/littlesnitch/index.html
    Das erwischt mich gelegentlich bei Remote-Logins, meist wenn eine SSH-Sitzung gerade etwas neu herunterladen will, etwa wenn NPM eine NodeJS-Komponente holt. Dann bleibt der SSH-Download im Textterminal hängen, und sobald ich herausfinde, dass Little Snitch die Ursache ist, muss ich zum Schreibtisch im unteren Stockwerk gehen, die Maus bewegen, um den Monitor aufzuwecken, den Bildschirmschoner entsperren und im Little-Snitch-Dialog auf „Allow“ klicken
    Also eigentlich genau wie vorgesehen. Solche Tools sind allerdings oft standardmäßig so eingestellt, dass Anfragen im lokalen Netzwerk stillschweigend erlaubt werden, daher weiß ich nicht, ob der Trick aus dem Originalpost in meiner Umgebung funktionieren würde

    • Ich kann mir kaum vorstellen, LittleSnitch im Browser so einzustellen, dass nur bestimmte Hostnamen erlaubt werden. Ich habe eine Regel „allen Traffic zu 53/80/443 erlauben“, sonst würden die meisten Websites Hunderte LittleSnitch-Popups auslösen
    • Ich nutze NetFence auf einem gejailbreakten iPhone
      Es ist erstaunlich, welche Socket-Verbindungen Apps heimlich öffnen, auch Banking-Apps
      https://havoc.app/package/netfence
    • Allerdings leakt Little Snitch die IP trotzdem, selbst wenn es blockiert :(
      https://news.ycombinator.com/item?id=35363343
    • Ich habe unter Linux die ähnliche Software OpenSnitch ausprobiert. Sie hat zwar nichts Seltsames gefunden, aber bei normalen Aufgaben insgesamt ziemlich genervt
    • Zur Info: Die DNS-Auflösung passiert vor dem Pop-up zum Erlauben/Ablehnen der Verbindung. www.example.com wird zum Beispiel zu 1.1.1.1 aufgelöst, aber bis man auf Confirm klickt, wird noch keine echte Verbindung zu 1.1.1.1 aufgebaut
      Wenn man dem Netzwerk ein Pi-hole hinzufügt, wird man weder Zeit noch Geld noch Mühe bereuen

  • Gibt es eine Möglichkeit zu verhindern, dass Websites im weiteren Internet Netzwerkanfragen an mein lokales Netzwerk stellen? Ich kann mir nur schwer vorstellen, warum das standardmäßig erlaubt sein sollte
    Ich will damit nicht sagen, dass man die Berechtigungen der Local Intranet Zone von IE wiederbeleben sollte

    • Normalerweise geht das wegen CORS nicht. Der einzige Grund, warum dieser „Hack“ funktioniert, ist, dass die Ablehnungszeit unterschiedlich ist zwischen Anfragen an nicht auflösbare Domains und Anfragen, die zwar aufgelöst werden, aber abgelehnt sind
      Aber selbst wenn auf https://192.168.2.1 etwas läuft, kann eine Web-App, die auf https://my-own-domain.com läuft, nicht darauf zugreifen, solange der Dienst auf 192.168.2.1 nicht my-own-domain.com als Origin erlaubt
    • Brave hat kürzlich eine Funktion hinzugefügt, die eine Berechtigung für den Zugriff auf das lokale Netzwerk verlangt
      https://brave.com/privacy-updates/27-localhost-permission/
      HN-Post: https://news.ycombinator.com/item?id=36574775
    • Eine App, die das häufig missbraucht, ist die Discord-Desktop-App, die einen lokalen Port offen hält und lauscht
      Wenn der Browser auf eine Einladungsseite für einen Discord-Channel navigiert, sendet er über diesen Port eine Anfrage an localhost und übergibt die Channel-ID an den Client. Dann kann die App das native „Join Channel“-Erlebnis anzeigen
      Ich habe das bemerkt, weil es sogar im Inkognito-Modus funktionierte und auch dann weiter passierte, wenn der Browser bei Discord ausgeloggt war. Nicht gut. Auf dem Desktop müssen wir die Sandboxing-Mechanismen für alle Anwendungen massiv verbessern
    • Das lässt sich mit einem statischen uBlock-Origin-Filter blockieren:
      ||local^$all
      Damit werden alle Anfragen an .local blockiert, auch Anfragen von .local selbst. Wenn man aus Gründen wie einem Webserver erlauben will, dass foo.local mit sich selbst kommuniziert, braucht man pro Domain eine zusätzliche Ausnahme:
      @@||foo.local^$domain=foo.local,all
      Oder wenn man .local insgesamt vertraut und erlauben will, dass jedes foo.local mit jedem bar.local kommuniziert, kann man eine allgemeine Ausnahme für .local hinzufügen:
      @@||local^$domain=local,all
    • Um Verwirrung zu vermeiden: Es geht hier nicht darum, dass ein Internetserver Anfragen an das lokale Netzwerk sendet, sondern darum, dass der lokale Webbrowser diese Anfragen sendet. Natürlich kann das im Browser laufende JavaScript von einem Internetserver geladen worden sein

  • Mit der Zeit fühlt es sich immer beruhigender an, das Internet überwiegend in einer Qubes-Box zu nutzen, in einer Wegwerf-Whonix/Tor-VM und mit deaktiviertem JavaScript
    Das ist wirklich widerlich. Nicht überraschend, aber schon die Tatsache, dass es möglich ist, ist in vielerlei Hinsicht schrecklich
    Falls dir fingerprint.com nichts sagt: Sie betreiben „tiefgehendes User-Profiling“. Vereinfacht gesagt behalten sie dieselbe Benutzer-ID bei, selbst wenn Computer, Browser und Betriebssystem unterschiedlich sind. Auf der Startseite gibt es eine Demo, und es ist ein bisschen gruselig, wie gut sie trifft

    • Selbst bei unterschiedlichen VPN-IPs erkennt es vollständig, dass es dasselbe Gerät ist. Wirklich gruselig
    • Das ist widerlich. Beeindruckend ist, dass es das sogar im Inkognito-Modus eines Standard-iPhones schafft, selbst wenn man zwei IPs wechselt, obwohl es doch eigentlich genau wie alle anderen iPhones aussehen müsste
      uBlock-Origin-Filter, der die Demo kaputtmacht:
      ||fpjscdn.net

  • Mit einer ähnlichen Art von Timing-Angriff lassen sich aus dem Browser heraus der lokale Rechner und andere Geräte im lokalen Netzwerk per Port-Scan untersuchen
    https://github.com/Flu1dTeam/PortScanner
    eBay wurde früher dabei erwischt, genau das zu tun
    https://blog.nem.ec/2020/05/24/ebay-port-scanning/

    • Was zur Hölle, das ist ja extrem gruselig — warum habe ich davon bisher nie gehört?

  • Zum Glück ändere ich meinen Gerätenamen immer
    Apples Standardbenennung ist ein Privacy-Fehler. Ich hatte einmal ein erstes Date mit einer Person aus der Strafverfolgung; sie kam allein, war eine Frau und achtete offensichtlich darauf, sich selbst zu schützen, also hatte sie Nachforschungen über mich angestellt und ein paar Leute aus ihrem Umfeld über unseren Aufenthaltsort informiert
    Im Gegensatz dazu kannte ich nicht einmal ihren Nachnamen und machte noch Witze darüber. Als wir nach dem Abendessen ins Auto stiegen, zeigte das Display im Armaturenbrett an, dass ein iPhone automatisch gekoppelt wurde, und der Name dieses iPhones war ihr Vor- und Nachname, was ich ziemlich interessant fand. Ich sprach es nicht direkt an, sondern ließ sie bis zum Ende der Fahrt raten, woher ich ihren Namen wusste

    • Bei Mietwagen bleiben erstaunlich oft ein Dutzend oder mehr zuvor gekoppelter Handyprofile zurück, mitsamt Telefonbuch, gespeicherten Kartenorten und Verlauf. Natürlich ist das meist nicht besonders nützlich, aber Informationen sickern dabei völlig gedankenlos nach außen
      Das Schwierigste ist eigentlich, sich vor der Rückgabe des Autos selbst daran zu erinnern, das eigene Profil zu löschen

  • Im obigen Beispiel dauert eine gültige Adresse 4 Millisekunden, eine ungültige 5 Sekunden
    Das ist überraschend. Ich hätte erwartet, dass ein fehlgeschlagener DNS-Lookup viel schneller ist als der Standard-Connection-Timeout nach einem erfolgreichen DNS-Lookup
    Trotzdem fand ich s-mac-xxxx schon immer eine etwas seltsame Wahl. Besonders wenn man bedenkt, dass die Firma Privacy als großes Verkaufsargument nutzt. Ich hätte erwartet, dass keine echten Namen verwendet werden, oder dass hier einfach „Benutzerfreundlichkeit“ Vorrang hatte. Aus Privacy-Sicht sind die zufällig generierten Hostnamen von Windows besser

    • Normales DNS fragt einen einzelnen Server unter einer einzelnen IP nach einer Ja/Nein-Antwort, aber mDNS ist Multicast, daher kann kein einzelner Server autoritativ „nein“ sagen†. Erst wenn die Abfrage wegen ausbleibender Antworten in einen Timeout läuft, erkennt man, dass es keinen Record gibt
      † Streng genommen ist das nicht ganz korrekt. Wenn ein Gerät weiß, dass es diesen Namen selbst besitzt, kann es nein sagen
    • Dass echte Namen im Hostnamen landen, könnte an AirDrop liegen. Es wirkt so, als würde das System den Hostnamen für Funktionen wie Personal Hotspot oder AirDrop verwenden, und andere Namensarten würden beim Teilen von Dateien vermutlich breitflächig Verwirrung stiften
    • Zusätzlich zum Punkt mit dem Standard-Connection-Timeout gilt hier auch: Es war connection refused, also ein empfangenes RST, und kein Connection-Timeout

  • Der Artikel ist gut geschrieben und interessant. Besonders gefällt mir der nüchterne Ton wie bei „Angesichts der inhärenten Schwächen und vieler Einschränkungen ist dieser Angriff nicht praktikabel“

    • In einem anderen Universum wäre das jetzt „FINGERBleed“ mit schicker Website und Logo geworden
    • Ich bin mir nicht sicher
      Diese Methode erlaubt es, zu testen, ob ein bestimmter Hostname im Netzwerk existiert
      Bei einem einzelnen eindeutigen Hostnamen ist das vielleicht kein großes Problem, aber was ist mit fest kodierten oder Standard-Hostnamen, wie sie in der IoT-Welt häufig sind
      Eine Website könnte so heimlich erraten, ob der Nutzer bestimmte Geräte besitzt. Für zielgerichtete Angriffe ist das noch schlimmer. Wenn man einige Geräte in einem Netzwerk kennt, kann man daraus ableiten, ob der eingeloggte Nutzer sich im Zielnetzwerk befindet

  • Es wäre schön, wenn das Deaktivieren von JavaScript nicht gleich auch die gesamte Endnutzererfahrung abschalten würde

    • Das ist der einzige Grund, warum ich JavaScript global deaktivieren nicht kann
      Trotzdem scheint es, als müsse ich es wegen Privacy-Bedenken künftig standardmäßig ausgeschaltet lassen
    • Gibt es keine Möglichkeit, die Dinge, die eine JavaScript-Engine tun kann, stark einzuschränken?

  • Zum Glück heißen meine Geräte meistens so etwas wie „xxxs's MacBook Pro (34)“. Kein Bug, sondern ein Feature

    • Setzt den Benutzernamen des Laptops auf user und den Hostnamen auf hostname. Je mehr Leute das machen, desto besser

  • Interessant, gut geschrieben, und sogar mit einem ordentlichen Proof of Concept. Gut gemacht
    Als lustige Gegenmaßnahme könnte man den Hostnamen des Geräts in etwas wie atemptingurl.local ändern, damit der Angreifer Lust bekommt, diese Website zu besuchen. Die Seite könnte dann raffiniert so gebaut sein, dass sie dieselbe Technik gegen den Angreifer ausführt und eine Nachricht wie diese anzeigt:
    „Hallo [Gerätename des Hackers]! Informationen über deine Maschine, IP-Adresse, geografische Position und weitere Fingerprint-Daten wurden erfasst und an [Name einer furchteinflößenden Cyber-Behörde einfügen] gemeldet.“ Selbst wenn es kein Script-Kiddie, sondern ein erfahrener Veteran ist, dürfte es ihn zumindest zum Lachen bringen
    Die Leute brauchen mehr Gründe zum Lachen :-)

    • Dafür müsste man einen HTTP-Server mit vollständig aktiviertem CORS betreiben. Damit setzt man sich allen Bugs des gewählten HTTP-Servers aus und schwächt also auch die eigene Sicherheit