Private Sicherheitslinks: Ist öffentlicher Zugriff wirklich unmöglich?

 (vin01.github.io)
2 Punkte von GN⁺ 2024-03-08 | 1 Kommentare | Auf WhatsApp teilen
  • URL-/Malware-Analysedienste wie urlscan.io, Hybrid Analysis und Cloudflare Radar URL Scanner speichern Links zum Teilen von Threat Intelligence, aber durch Nutzerfehler oder falsch konfigurierte Scanner können sensible Links als öffentliche Daten zurückbleiben
  • Besonders betroffen sein können Dienste, bei denen die URL selbst als Zugriffsberechtigung dient, etwa Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, Passwort-Reset-Links und OAuth-Login-Links
  • Nicht jeder Link wird sofort offengelegt, aber es wurden tatsächlich Steuerdokumente, Rechnungen, Fotos, Geschäftskommunikation, mit onetimesecret geteilte Geheimnisse sowie Smart-Home- und Meeting-Aufzeichnungen gefunden
  • urlscan Pro zeigt zahlenden Kunden nicht nur Public-, sondern auch Unlisted-Scans, und es kann Wege geben, über die Inhalte unbeabsichtigt als unlisted eingereicht werden, etwa durch Einstellungen in den Cortex-Analyzers von TheHive
  • In den letzten 24 Stunden verzeichnete urlscan.io 398,563 Public-, 328,147 Unlisted- und 955,432 Private-Scans; auch im Canary-Token-Experiment wurde binnen einer Stunde nach Einreichung ein Zugriff bestätigt, was eine Kontrolle der Scan-Sichtbarkeit erforderlich macht

Sensible Links in URL-Analysediensten

  • urlscan.io, Hybrid Analysis und Cloudflare Radar URL Scanner speichern viele Links zur URL- und Malware-Analyse
  • Das Problem ist, dass in diesen Speichern auch private und sensible Links landen können
    • Nutzer reichen sensible Links zum Scan ein, ohne zu wissen, dass sie dadurch öffentlich werden können
    • Falsch konfigurierte Scanner oder Erweiterungen reichen private, aus E-Mails gescannte Links als öffentliche Daten ein

Welche Links und Daten offengelegt werden können

  • Die gefundenen Links umfassen Freigabe-URLs und authentifizierungsbezogene URLs aus verschiedenen Diensten
    • Dateifreigaben aus Cloud-Speichern wie Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive und AWS S3
    • Cloud-verbundene NAS-Systeme wie Western Digital Mycloud
    • Unternehmens-Kommunikationstools wie Slido, Zoom, OneDrive und Airtable
    • Passwort-Reset-Links und OAuth-Login-Links
  • Solche Dienste erlauben oft den Zugriff über einen einzelnen privaten Link mit zufälligem Bezeichner als Sicherheitsmechanismus
  • Einige Links sind zusätzlich durch Passwörter oder Passphrasen geschützt, daher führt der bloße Zugriff auf den Link nicht immer sofort zu einer Datenoffenlegung
  • Tatsächlich gefundene sensible Inhalte waren unter anderem
    • private Dateien wie Steuerdokumente, Rechnungen, Fotos und Geschäftskommunikation
    • mit onetimesecret geteilte Geheimnisse
    • Aufzeichnungen von Smart-Home-Geräten
    • in der Cloud gespeicherte Meeting-Aufzeichnungen

Einreichungspfade und Lücken bei der Verantwortung

  • Viele auf urlscan.io gefundene Einreichungen trugen den Tag falconsandbox, was die Analyse auch auf Hybrid Analysis ausweitete
  • Auch Cloudflare Radar könnte breiter genutzt werden und enthält bereits einige private Links in öffentlichen Daten
  • Die Nutzungsbedingungen von Hybrid Analysis erklären, dass vom Nutzer eingereichte Inhalte analysiert, veröffentlicht und geteilt werden können und dass keine Verantwortung für Informationen übernommen wird, die versehentlich in Einreichungen oder automatisch erzeugten Berichten enthalten sind
  • Auch die Nutzungsbedingungen von urlscan.io lehnen die Verantwortung für Nutzerinhalte oder Nutzerverhalten ab und stellen klar, dass der Nutzer für unter seinem Konto veröffentlichte Inhalte und Aktivitäten verantwortlich ist
  • Es scheint keinen klaren Mechanismus zu geben, um bestehende Inhalte zu prüfen und sensible Links zu markieren oder zu entfernen; eine Automatisierung wäre zudem nicht unbedingt einfach
  • Die Analyse von Positive Security untersucht urlscan.io, nutzte Canary Tokens zur Erkennung automatisierter Quellen und behandelt die Möglichkeit, dass Sicherheitswerkzeuge, die bösartige Links aus E-Mails scannen, die Ursache sein könnten
  • Dasselbe Verhalten wurde auch mit Canary-Links bestätigt

Unlisted-Scans und Zugriff über urlscan Pro

  • urlscan Pro bietet zahlenden Nutzern und Unternehmen nicht nur Zugriff auf Public-, sondern auch auf Unlisted-Scans
  • Bei urlscan.io bedeutet Unlisted, dass Inhalte nicht auf öffentlichen Seiten oder in Suchergebnissen erscheinen, aber für Kunden der urlscan-Pro-Plattform sichtbar sind
    • Laut Beschreibung sind urlscan-Pro-Kunden auf verifizierte Sicherheitsforscher oder seriöse Unternehmen beschränkt
  • Die Cortex-Analyzers von TheHive sind ein Beispiel für einen unbeabsichtigten Offenlegungspfad
    • Im urlscan.io-Analyzer wird ausdrücklich die Einstellung public:on verwendet
    • Dadurch kann ein Link als unlisted erscheinen, auch wenn die Sichtbarkeit des urlscan-Kontos auf Private steht
    • Der betreffende Code steht in urlscan.py der Cortex-Analyzers
  • Selbst wenn die Daten in diesem Fall nicht vollständig öffentlich sind, können sie für Nutzer von urlscan Pro sichtbar sein, sodass weitergehende sensible Informationen offengelegt werden könnten

Scan-Zahlen und Ergebnisse mit Canary Tokens

  • In den letzten 24 Stunden wurden bei urlscan.io folgende Scan-Zahlen verzeichnet
    • Public: 398,563
    • Unlisted: 328,147
    • Private: 955,432
  • Die mit Canary Tokens bestätigten Zugriffe waren wie folgt
    • Ein an urlscan.io als unlisted eingereichter Link wurde innerhalb einer Stunde nach der Einreichung 12-mal aufgerufen
    • Ein nicht per Browser, sondern per API an Hybrid Analysis eingereichter Link wurde innerhalb einer Stunde nach der Einreichung 10-mal aufgerufen
    • Einige IP-Adressen griffen gleichzeitig auf eindeutige Links zu, die an beide Dienste eingereicht worden waren, und nutzten einen Dienst zur Anonymisierung der Ursprungs-IP
  • Die Liste dieser IP-Adressen ist in einer separaten Datei veröffentlicht

Entfernen sensibler Links und Vorsicht bei der Nutzung

  • urlscan.io und Hybrid Analysis bieten Verfahren an, um Links zu melden und entfernen zu lassen
  • Bei Hybrid Analysis sind Entfernung und Freigabeumfang komplexer
    • Alle an die Public Sandbox übermittelten Dateien sind durchsuchbar und weltweit verfügbar
    • Selbst wenn das Kontrollkästchen „Do not share my sample with the community“ aktiviert wird, bleiben Screenshots und der eigentliche Bericht weiterhin verfügbar
    • „do not share“ gilt nur für das tatsächlich eingereichte Sample
  • Bei der Nutzung solcher Dienste sollte zuerst die Scan-Sichtbarkeit geprüft werden
  • Wer über solche URL-Datenbanken auf Links oder Dateien zugreift, kann auf Phishing-Versuche, echte Malware-Dateien oder bösartige Links stoßen
  • Falls ein Zugriff nötig ist, sollte er in einer Sandbox-Umgebung erfolgen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-08
Hacker-News-Kommentare

  • Das Grundproblem ist, dass Links ohne Zugriffskontrolle als privat gelten, nur weil es keinen öffentlichen Index der Identifikatoren gibt.
    Erst letzten Monat war auf HN die Geschichte, wie man über Buckets AWS-Konto-IDs findet, ziemlich populär[0], und der Konsens in den Kommentaren war, dass es falsch ist, Sicherheit auf der Annahme aufzubauen, Konto-Identifikatoren seien privat.
    Dasselbe Konzept gilt auch hier; es ist weniger ein neues Sicherheitsproblem als vielmehr nur eine weitere Methode der Suche per Operatoren (Dorking).
    [0]: https://news.ycombinator.com/item?id=39512896

    • Das Problem ist, dass Links durchsickern.
      Theoretisch ist ein 256-stelliger Hex-Link, also 1024 Bit, viel schwerer zu erraten als ein 32 Zeichen langer Benutzername und ein 32 Zeichen langes Passwort.
      https://site.com/[256chars] hat 2^1024 Kombinationen, sodass Brute Force praktisch unmöglich ist.
      Dagegen haben https://site,com/[32chars] und ein 32 Zeichen langes Passwort 2^256 Kombinationen; auch das ist nahezu unmöglich, aber im Vergleich zum Ersteren wahrscheinlicher.
      Man kann es sich wie https://site,com/[32chars][32chars] vorstellen.
      Auch wenn Ersteres schwerer zu treffen ist, werden URLs allerdings viel häufiger geleakt als Passwörter.
    • Es kann sein, dass ich ein Detail übersehe, aber das Grundproblem scheint darin zu liegen, dass private Nachrichten zwischen Menschen als privat gelten, während die Plattform, die diese Nachrichten übermittelt, sie in Wirklichkeit liest und auf die Links zugreift.
      Mit Nachrichten sind hier im weiteren Sinne E-Mails, DMs und auch in Dokumente eingefügte Links gemeint.
    • Etwas off-topic: Kürzlich riet mir ein Consultant, es sei in Ordnung, private Nix-Closures in einen öffentlich zugänglichen S3-Bucket zu laden, weil jeder NAR-Dateiname einen riesigen Hash enthalte.
      Mir war dabei unwohl, und am Ende wählten wir einen anderen Weg, aber ich denke seitdem ständig darüber nach, wie groß der praktische Unterschied zwischen einem „Geheimnis“ in der URL und einem Geheimnis in einem Token ist, das bei einer URL-Anfrage übermittelt wird.
      Mein Fazit ist, dass Tokens pro Kunde ausgestellt werden können und man Zugriffslogs überwachen, verdächtiges Verhalten erkennen und sie widerrufen kann.
      Außerdem ist, wie andere schon sagten, die Denkweise eine andere, wie wichtig man es findet, die Liste der Dateinamen geheim zu halten.
      In dem Maßstab, in dem Amazon Fehler machen kann, dürfte das versehentliche Offenlegen der Dateinamensliste eines öffentlichen Buckets für 99 % der Nutzer irrelevant sein und daher eine niedrige Priorität haben.
    • Eine Firma, bei der ich früher gearbeitet habe, hatte bei der Zusammenarbeit mit einem Kunden einmal eine Kollision bei S3-Bucket-Namen; es stellte sich heraus, dass beide Seiten hyphenated-company-name für einen guten S3-Bucket-Namen hielten.
      Natürlich hat unsere Firma diesen Wettbewerb verloren.
      Seitdem ist es für mich eine kleine Lektion, dass man Bucket-Namen bei AWS normalerweise in der Form - benennt.
      Wenn es wirklich privat sein muss, kann man auch den Projektnamen verschlüsseln und ein Script bereitstellen, das Buckets unter „freundlichen“ Namen auflistet.
      Bei Hosting-Diensten gibt es immer seltsame Kompromisse; der technisch perfekte Ansatz, also vollständig zufällige Identifikatoren, verursacht wahrscheinlich deutlich mehr operativen Aufwand als der unvollkommene Ansatz mit beschreibenden Namen.
    • Ich frage mich, ob es einen Unterschied gibt zwischen einem privaten Link, der ein Passwort enthält, und einer Website, bei der man nach dem Aufruf des Links ein Passwort eingibt.
      Bitwarden Send erzeugt Links, die man an andere weitergeben kann, und hängt nach dem # eine lange zufällige Zeichenkette an.
      Ich nutze das regelmäßig und würde gern wissen, ob es dabei ein Sicherheitsproblem gibt.
      Immerhin kann man den Link widerrufen und nach ein paar Tagen automatisch ablaufen lassen; normale Passwörter funktionieren üblicherweise nicht so.

  • Wenn man private Share-Links erstellen will, sollte man den privaten Wert im Hash-Teil der URL speichern.
    Der Hash wird weder in DNS-Abfragen noch in HTTP-Requests übertragen.
    Wenn man zum Beispiel links.com?token= besucht, wird dieser Link inklusive Query-Parameter übertragen und kann bei Mittelsmännern wie Cloudflare gespeichert werden.
    Besucht man dagegen links.com#, verlässt der Hash-Teil den Browser nicht.
    Beim Umgang mit Daten im Hash-Teil ist es praktisch, sie als URL-Safe-Base64-String zu kodieren.
    Also der Ablauf JS Object ↔ JSON String ↔ URL Safe Base 64 String.

    • Wenn man HTTPS verwendet, sind auch Parameter-String und Pfad verschlüsselt; um dieses Geheimnis zu lesen, müsste der betreffende Mittelsmann den Traffic also entschlüsseln können.
      Der Rest stimmt, ich wollte nur diese Nuance zur HTTPS-Verschlüsselung ergänzen.
    • Es gibt einen großen Vorbehalt: Auch scheinbar harmloses JavaScript, das auf dieser Seite läuft, kann das Fragment an jeden beliebigen Ort im Internet senden.
      Es hilft, es in das Fragment zu legen, ist aber nicht perfekt.
      Das ist nicht nur idealistisch gemeint; ich habe tatsächlich mehrfach gesehen, wie private Tokens auf diese Weise aus Fragmenten geleakt wurden.
    • Gibt es eine DNS-Funktion, die ich nicht kenne und die mehr als nur den Domain-Teil abfragt?
      Bei [https://example.com?token=](<https://example.com?token=<secret>>;) sollte die DNS-Abfrage nur für „example.com“ erfolgen.
    • Wenn ich darüber nachdenke, wie man dieses Problem löst, fallen mir besonders E-Mail-basierte Logins oder Account-Resets ein.
      Führen Bots, die Links in E-Mails folgen, JavaScript aus? Besteht die Gefahr, dass durch JavaScript ausgelöste POSTs die eigentliche Aktion aktivieren?
    • Nebenbei: Das nennt man Fragment.

  • Links, die nicht Teil einer schnellen Redirect-Schleife sind, werden zwangsläufig zum Teilen kopiert und eingefügt.
    Genau dafür sind URLs da: Sie sind universell und erleichtern den Zugriff auf Ressourcen, die über irgendein Protokoll bereitgestellt werden.
    Zugriffskontrolle für Dinge, die nicht kurzlebig sind, sollte außerhalb der URL erfolgen.
    Wenn man einen Link über einen Kanal teilt, der nicht Ende-zu-Ende-verschlüsselt ist, ist die erste Instanz, die auf diese URL zugreift, nicht der Empfänger, sondern der Channel-Dienst.
    Das kann legitim sein, wie wenn Bitwarden für eine bessere User Experience Favicons sucht, oder bösartig, wie wenn der Facebook-Messenger-Crawler mehr darüber wissen will, was in privaten Nachrichten geteilt wird.
    Diese Scanner-Tools werden die User Experience nicht verbessern.
    Würde man ausdrücklich darauf hinweisen, dass Scan-Ergebnisse öffentlich werden, würden einige Nutzer vor der Nutzung des Dienstes noch einmal nachdenken, und das wäre schlecht fürs Geschäft, egal ob bei kostenlosen Nutzern oder Pro-Lizenz-Nutzern.

  • Unbegrenzt nutzbare „private“ Links kamen mir schon immer etwas verdächtig vor
    Am Ende ist das Security through Obscurity
    Wenn man etwas wie Google Docs teilt, gibt es immerhin eine Option, die ausdrücklich sagt: „Jeder mit der URL kann zugreifen“
    Wenn ich in einem von mir gebauten System so etwas brauchte, habe ich normalerweise signierte URLs verwendet, die nur wenige Minuten gültig waren
    Die URL ist meist ein Implementierungsdetail und wird den Nutzern nicht direkt angezeigt, aber in den Browser-DevTools könnte sie sichtbar sein

    • Wenn der Schlüsselraum groß genug ist, gibt es funktional keinen Unterschied zwischen einem privaten Link und einem Link, der durch Benutzername/Passwort oder einen API-Key geschützt ist
    • Das Teilen in Google Docs basiert leider auf der Dokument-ID, daher kann man den Zugriff nicht einfach über eine neue URL wieder aktivieren

  • Wenn so etwas im Internet außer durch eine zufällige Zeichenfolge in der URL nicht geschützt ist, ist es in Wirklichkeit nicht privat
    Das ist dieselbe Geschichte wie bei internetverbundenen Webcams, die man per Suche findet
    War das nicht längst bekannt? Ich verstehe nicht, warum dieser Punkt im Abschnitt „Wer ist verantwortlich?“ überhaupt nicht behandelt wird

    • Solche Links sind im Kontext von „Sicherheit, die für den Use Case ausreicht“ sehr nützlich
      Nicht alles braucht das höchste Sicherheitsniveau; manchmal reicht eine Hürde, die breite Weiterverbreitung verhindert
      Wenn man zum Beispiel in einer Fotogalerie auf „Link zum Teilen erstellen“ klickt und jemandem einen Fotolink schickt, will man nicht, dass diese Person ein Passwort eingeben muss
      Der Link soll das Foto öffnen, und für diesen Zweck ist das okay
      Eines der Beispiele hier ist genau so ein Fall, und für diesen Use Case passt es
      Auch mit Blick auf Datenschutzbedenken kann der Endnutzer, selbst wenn es einen Login-Prozess gäbe, an diesem Punkt einfach einen Screenshot weiterteilen
      Die Sicherheit passt also zum Use Case
      Man vertraut darauf, dass der Nutzer nun zwar den Fotolink hat und ihn weiterteilen könnte, dies aber nicht absichtlich tut
      Das große Problem hier ist weniger der Link selbst, sondern dass Sicherheitsanalyse-Tools alle Links scannen, die ein Nutzer per E-Mail erhalten hat, und sie auch für andere Nutzer dieser Community zugänglich machen
      Das ist eine viel größere Weiterverbreitung, als ich beabsichtigt habe, wenn ich jemandem ein Foto schicke

  • Ein Workaround für dieses Problem der E-Mail-basierten Authentifizierung ist, statt ein Passwortkonto anzulegen, temporäre Einmalcodes zu verwenden
    Dann ist es kein großes Problem, wenn die URL versehentlich geteilt wird

    1. Der Nutzer besucht den „privaten“ Link, oder auch einen öffentlichen Link, bei dem er seine E-Mail erneut eingibt
    2. Die Website schickt dem Nutzer per E-Mail erneut einen zeitlich begrenzten Einmalcode
    3. Der Nutzer gibt den temporären Code ein und bestätigt damit den Besitz der E-Mail-Adresse
    4. Der Ablauf wird über HTTP-Cookies oder Sitzungsdaten fortgesetzt, mit hinreichender Gewissheit, dass der Besitzer des E-Mail-Kontos beteiligt war

  • Etwas off-topic, aber der Link führt zu Cloudflare Radar, und dieser Dienst scheint offenbar 1.1.1.1-Daten zu schürfen
    Ich dachte, 1.1.1.1 würde Nutzerdaten zu keinem Zweck verwenden

    • Cloudflare verkauft diese Daten nicht und nutzt sie auch nicht fürs Marketing, aber der Grund, warum sie diese Adresse überhaupt bekommen haben, war, dass APNIC den Noise-Traffic, der bei 1.1.1.1 ankommt, untersuchen wollte

  • Ich würde gern von jemandem, der klüger ist, erklärt bekommen: Was ist der Unterschied zwischen diesen beiden?

    1. domain.com/login user: John password: 5 char random password
    2. domain.com/12 char random url
      Angenommen, beide haben denselben Schutz gegen Brute Force bzw. dasselbe Rate Limiting, oder beide haben gar nichts davon: Warum ist 1 sicherer als 2?
    • Aus Sicht der Informationstheorie gibt es keinen Unterschied
      In der Praxis gibt es einen Unterschied
      Besitzbasierte Geheimnisse und wissensbasierte Geheimnisse sind verschieden
      Eine URL ist etwas, das man besitzt; wenn man sie an einem zugänglichen Ort liegen lässt, kann sie entwendet werden
      Ein Passwort ist etwas, das man weiß, und wenn man es gut verwaltet, kann es nicht entwendet werden. Ausnahme: der Bleirohr-Angriff
      Eine weitere Kategorie ist biometrisch, etwa Retina- oder Fingerabdruck-Scans
    • Genau darum geht es in diesem Artikel
      Für (1) braucht man zur Authentifizierung Informationen über einen separaten Kanal, und es sind Informationen, die Menschen gewohnt sind sicher aufzubewahren
      Die URL in (2) dagegen wird wie eine URL behandelt
      URLs werden häufig geloggt, aufgezeichnet, geteilt und überallhin weitergereicht
      Wenn zum Beispiel eine Unternehmens-Firewall den Benutzernamen und das Passwort protokolliert, die für den Login bei einem Dienst verwendet wurden, wäre das offensichtlich schlecht; die aufgerufene URL zu protokollieren dürfte dagegen eher akzeptabel wirken
      Letzteres ist nur ein Beispiel; wegen der Ende-zu-Ende-Garantien von TLS sollte beides nicht zugänglich sein
    • Es gibt zwei Dinge
      1. Das Wort „Passwort“ ist ein magisches Wort, das die Wahrscheinlichkeit senkt, dass Menschen es irgendwo einfügen
      2. Benutzername und Passwort sind zwei getrennte Informationen, die normalerweise nicht gleichzeitig kopiert und eingefügt werden und für die es auch keinen Standardweg gibt, sie direkt nebeneinander zu speichern
    • Im Kontext dieses Artikels ist der Unterschied, dass von Unternehmen oder Nutzern eingesetzte Security-Scanning-Software Teile des 12-Zeichen-Links in E-Mails indexiert und sie unter Umständen in öffentliche Scan-Ergebnisse hochlädt
      Außerdem: Wenn domain.com/12-char-password ohne HTTPS angefordert wird, wird die erste Anfrage trotz Redirect unverschlüsselt übertragen und ist damit anfällig für Man-in-the-Middle-Angriffe
      Bei einer Login-Seite gibt es dagegen mehr Möglichkeiten sicherzustellen, dass die Passwortübermittlung ausschließlich über HTTPS erfolgt
    • Ich habe früher einmal recherchiert, ob es okay ist, Authentifizierungs-Tokens in Query-Parameter zu packen
      Eines der großen Probleme ist, dass viele Logging-Anwendungen die vollständige URL irgendwo protokollieren; damit schreibt man faktisch das „Passwort“ ins Log

  • Alle Medien und Fotos, die man in eine private airtable.com-App hochlädt, sind öffentliche Links
    Wer die URL kennt, kann ohne Authentifizierung darauf zugreifen

    • Für Webentwickler, die Bilder von einem CDN oder einer API laden, ist das ein Dilemma
      Ein normales Image-Tag kann keinen Authorization-Header mit Token setzen, wie man es bei einer API-Anfrage mit fetch() tun würde
      Die möglichen Optionen sind nur, das Token der URL hinzuzufügen oder Cookie-Authentifizierung zu verwenden
      Cookie-Authentifizierung funktioniert nur, wenn das CDN auf derselben Domain liegt, und selbst Subdomains können in vielen Fällen Probleme machen
    • Bei Apps, die ein CDN nutzen, ist das nicht nur bei airtable so, sondern ziemlich üblich
      Ich stimme zu, dass es potenziell problematisch sein kann

  • Zoom-Meeting-Links enthalten das Passwort häufig als Query-Parameter.
    Ist ein solcher Link ein „privater sicherer“ Link? Ist ein Link ohne Passwort ein „privater sicherer“ Link?

    • Wenn das Passwort für jedes Meeting zufällig ist, ist auch ein URL-Link nicht allzu schlecht.
      Denn bis die URL irgendwo anders auftaucht, ist das Meeting wahrscheinlich bereits vorbei und verschwunden.
      In der Realität kümmert sich jedoch niemand darum, und alle wollen „per Klick beitreten“, ohne irgendetwas eingeben zu müssen.
      Die frühere Methode, „nur die Meeting-ID zu verwenden“, war viel zu leicht zu erraten.