Man kann nicht einfach öffentlich auf private Sicherheitslinks zugreifen, oder?

Private Sicherheitslinks, auf die öffentlich nicht zugegriffen werden kann – wirklich?

• Beliebte Malware-/URL-Analysetools wie urlscan.io, Hybrid Analysis und der Cloudflare Radar URL Scanner speichern große Mengen an Links zur Datenerfassung und zum Teilen.
• Weniger bekannt ist, dass diese Dienste private und sensible Links speichern, die versehentlich von Nutzern eingereicht oder durch falsch konfigurierte Scanner und Erweiterungen als öffentliche Daten gescannt wurden.

Welche Links sind damit gemeint?

• Dateien, die über Cloud-Speicher-Tools (Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 usw.) geteilt werden.
• Cloud-verbundene NAS-Tools (Western Digital Mycloud usw.).
• Unternehmenskommunikation (Slido, Zoom, Onedrive, Airtable usw.).
• Links zum Zurücksetzen von Passwörtern, OAuth-Login-Links usw.
• Diese Dienste haben gemeinsam, dass sie den Zugriff über einen einzelnen privaten Link mit zufälligen Identifikatoren ermöglichen. Manchmal sind sie zusätzlich durch ein Passwort oder eine Passphrase geschützt; in diesem Fall führt der Zugriff auf den Link nicht automatisch zu einer Datenoffenlegung.

Wer trägt die Verantwortung?

• Laut den Nutzungsbedingungen von Hybrid Analysis und urlscan.io liegt die Verantwortung für eingereichte Inhalte bei den Nutzern, und es gibt keinen Mechanismus zur Überprüfung und Entfernung sensibler Links.
• Auch eine automatisierte Umsetzung wäre möglicherweise nicht einfach.
• Als Sicherheitsforscher ist es schwer, die Herkunft solcher Links nachzuvollziehen.

Wir sind Threat Hunter! Alle Links gehören uns!

• urlscan Pro erlaubt zahlenden Nutzern/Firmen Zugriff nicht nur auf Public, sondern auch auf Unlisted-Scans.
• Unlisted ist auf öffentlichen Seiten oder in Suchergebnissen nicht sichtbar, für Kunden der urlscan Pro-Plattform jedoch einsehbar.
• Die Cortex-Analyzers von TheHive verwenden im urlscan.io-Analyzer explizit die Konfiguration public:on, sodass Links als unlisted erscheinen.
• Für urlscan-Pro-Nutzer sind die Daten nicht öffentlich, aber zugänglich, wodurch das Risiko steigt, dass noch mehr sensible Informationen offengelegt werden.

Wie lassen sich sensible Links entfernen?

• Urlscan und Hybrid Analysis ermöglichen das Markieren von Links, damit sie entfernt werden können.
• Bei Hybrid Analysis sind alle Dateien, die an die öffentliche Sandbox übermittelt werden, durchsuchbar und weltweit öffentlich zugänglich.

Fazit

• Es ist sicher, dass dieses Problem bestehen bleiben wird. Die beste Lösung könnte sein, Scans standardmäßig privat zu halten, doch das entspricht nicht dem Zweck der Bedrohungsaufklärung und der Praxis des Teilens von Analysen in der Security-Community.
• Bei der Nutzung solcher Dienste sollte man auf die Sichtbarkeit von Scans achten.

Haftungsausschluss

• Falls Sie sich entscheiden, über URL-Datenbanken auf solche Links/Dateien zuzugreifen, sollten Sie auf echte schädliche Dateien und Links achten.
• Einige könnten bloße Phishing-Versuche sein und tatsächlich Malware enthalten.
• Die Verwendung einer Sandbox-Umgebung wird empfohlen.

Nützliche Links

• SOAR spot von urlscan.io: Chatty security tools leaking private data (2022)
• Search API Reference von urlscan.io
• Falcon Sandbox Public API
• Cloudflare Radar URL Scanner

Meinung von GN⁺

• Dieser Artikel schafft Bewusstsein dafür, wie Sicherheits-Tools sensible Informationen versehentlich offenlegen können, und ist damit sowohl für Sicherheitsforscher als auch für normale Nutzer ein Weckruf.
• Solche Probleme können durch Nutzerfehler oder Fehlkonfigurationen von Tools entstehen und erfordern mehr Sorgfalt und Verantwortung beim Umgang mit sensiblen Informationen innerhalb der Security-Community.
• Der Artikel unterstreicht außerdem, wie wichtig es ist, dass Einzelpersonen und Unternehmen Maßnahmen zum Schutz ihrer Daten ergreifen.
• Kritisch betrachtet können solche Leaks eine ernste Bedrohung für die Privatsphäre Einzelner und die Vertraulichkeit von Unternehmen darstellen, was Fragen zur Zuverlässigkeit von Sicherheits-Tools und -Diensten aufwerfen kann.
• Andere Projekte mit ähnlichen Funktionen sind etwa Malware-Analyseplattformen wie VirusTotal oder Any.run; bei der Nutzung solcher Dienste sollte stets sorgfältig geprüft werden, ob Daten öffentlich werden.

[GN⁺]

Hacker-News-Kommentar

• Das grundlegende Problem ist, dass der Link keine Zugriffskontrolle hat und nur deshalb als privat angenommen wird, weil es keinen öffentlichen Index gibt. Auf Hacker News war eine Geschichte darüber populär, dass sich AWS-Konto-IDs über Buckets ermitteln lassen; der Konsens in den Kommentaren war, dass es ein falscher Ansatz ist, sich bei der Sicherheit auf die Nichtöffentlichkeit der Konto-ID zu verlassen. Das ist letztlich nur eine weitere Form von "dorking".

  • Nichtöffentlichkeit von Links: Es ist problematisch anzunehmen, ein Link sei privat, nur weil er nicht öffentlich indexiert wird. Sich bei der Sicherheit auf die Nichtöffentlichkeit einer AWS-Konto-ID zu verlassen, ist kein richtiger Sicherheitsansatz, und es handelt sich nicht um ein neues Sicherheitsproblem, sondern um eine Form von "dorking".

• Wenn man einen privat teilbaren Link erzeugen will, sollte man geheime Informationen im Hash-Teil der URL speichern. Der Hash wird weder in DNS-Abfragen noch in HTTP-Anfragen übertragen. Ein Link im Format links.com#<secret> verlässt zum Beispiel den Browser nicht. Es ist sinnvoll, die Daten im Hash-Teil als URL-sicheren Base64-String zu kodieren.

  • Sicheres Teilen von Links: Ein Link kann sicherer geteilt werden, indem geheime Informationen im Hash-Teil der URL gespeichert werden. Diese Methode ist sicherer, weil der Hash weder in DNS-Abfragen noch in HTTP-Anfragen enthalten ist.

• Ich war gegenüber unbegrenzt nutzbaren "privaten" Links immer misstrauisch. Das ist nur Security through Obscurity. Besser ist es, wenn es wie bei Google Docs eine explizite Option gibt wie "Jeder mit der URL kann zugreifen". In einem System, das ich aufgebaut habe, werden signierte URLs mit kurzer Lebensdauer verwendet, und diese URLs werden dem Nutzer nicht direkt angezeigt.

  • Zweifel an "privaten" Links: "Private" Links sind in Wirklichkeit oft nur Security through Obscurity, und die Verwendung signierter URLs mit kurzer Lebensdauer ist ein sichererer Ansatz.

• Jeder Link, der nicht Teil einer schnellen Redirect-Schleife ist, wird kopiert und weitergegeben werden. URLs sind universell und erleichtern auf Protokollebene den Zugriff auf Ressourcen. Die Zugriffskontrolle für alles, was nicht nur extrem kurzlebig ist, sollte außerhalb der URL stattfinden. Wenn ein Link über einen nicht Ende-zu-Ende-verschlüsselten Kanal geteilt wird, ist die erste Entität, die auf die URL zugreift, möglicherweise nicht der eigentliche Empfänger, sondern der Dienst des Kanals. Solche Scanner-Tools würden die UX nicht verbessern, wenn sie den Nutzern ausdrücklich mitteilen, dass das Scannen öffentlich erfolgt.

  • Zugriffskontrolle über URLs: URLs werden geteilt, um den Zugriff auf Ressourcen zu erleichtern; die Zugriffskontrolle sollte daher nicht über die URL selbst, sondern auf andere Weise erfolgen. Tools wie Scanner helfen der UX nicht, wenn Nutzer dadurch zögern, den Dienst zu verwenden, weil sie auf öffentliche Scans hingewiesen werden.

• Eine Lösung für das Problem der "E-Mail-basierten Authentifizierung" ist die Verwendung eines Einmalcodes, der selbst dann kein Problem verursacht, wenn die URL versehentlich geteilt wird, und zwar ohne den Schritt, ein Konto und ein Passwort anzulegen. Wenn ein Nutzer einen "privaten" Link besucht, sendet die Website erneut einen zeitlich begrenzten Einmalcode per E-Mail, und der Nutzer gibt den temporären Code ein, um den Besitz der E-Mail-Adresse zu bestätigen.

  • E-Mail-Authentifizierung und Einmalcodes: Zur Lösung von Problemen bei E-Mail-basierter Authentifizierung werden Einmalcodes verwendet; dadurch ist es kein Problem, wenn eine URL versehentlich geteilt wird.

• Im Internet sind URLs praktisch nicht privat, wenn sie nicht durch mehr als nur eine zufällige Zeichenfolge geschützt sind. Das ist wie bei der Suche nach ans Internet angeschlossenen Webcams. Das sollten wir eigentlich längst wissen. Warum wird das im Abschnitt "Wer sollte verantwortlich sein" nicht erwähnt?

  • Der private Charakter von URLs: Wenn eine URL nicht durch mehr als eine zufällige Zeichenfolge geschützt ist, ist sie nicht privat; das ist eigentlich bereits bekannt.

• Das ist zwar etwas off-topic, aber es gibt einen Link, der behauptet, Cloudflare Radar schürfe Daten aus 1.1.1.1. Ich dachte, 1.1.1.1 würde Nutzerdaten für keinerlei Zwecke verwenden?

  • Cloudflare Radar und 1.1.1.1: Es gibt die Behauptung, dass Cloudflare Radar Daten aus 1.1.1.1 schürft, was dem bisherigen Eindruck widerspricht, dass 1.1.1.1 keine Nutzerdaten verwendet.

• Zoom-Meeting-Links enthalten oft das Passwort als Query-Parameter. Ist ein solcher Link ein "privater und sicherer" Link? Und ist er ohne Passwort ein "privater und sicherer" Link?

  • Sicherheit von Zoom-Meeting-Links: Es wird gefragt, wie sicher Zoom-Meeting-Links mit und ohne eingebettetes Passwort sind.

• Kann jemand erklären, welcher der folgenden zwei Fälle sicherer ist?

  1. domain.com/login Benutzer: John Passwort: zufälliges 5-stelliges Passwort
  2. domain.com/12-stellige zufällige URL Unter der Annahme, dass in beiden Fällen derselbe Schutz durch Zufälligkeit/Rate Limiting besteht oder gar keiner: Warum ist Fall 1 sicherer als Fall 2?
  • Vergleich der Login-Sicherheit: Es wird nach einem Vergleich der Sicherheit zweier unterschiedlicher Login-Ansätze gefragt.

• Alle in eine private airtable.com-App hochgeladenen Medien/Fotos sind öffentliche Links und ohne Authentifizierung zugänglich, wenn man die URL kennt.

  • Öffentliche Links bei Airtable.com: In Airtable.com hochgeladene Medien/Fotos sind öffentliche Links, auf die jeder zugreifen kann, der die URL kennt.