Des liens de sécurité privés inaccessibles publiquement, vraiment ?
- Des outils populaires d’analyse de malwares et d’URL comme urlscan.io, Hybrid Analysis et le scanner d’URL de Cloudflare Radar stockent de grandes quantités de liens afin de collecter et partager des informations.
- Il est peu connu que ces services conservent des liens privés et sensibles qui ont été soumis par erreur par des utilisateurs ou scannés comme données publiques par des scanners et extensions mal configurés.
De quels liens parle-t-on ?
- Des fichiers partagés via des outils de stockage cloud (
Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3, etc.).
- Des outils NAS connectés au cloud (
Western Digital Mycloud, etc.).
- Des outils de communication d’entreprise (
Slido, Zoom, Onedrive, Airtable, etc.).
- Des liens de réinitialisation de mot de passe, des liens de connexion OAuth, etc.
- Tous ces services ont en commun l’utilisation d’un lien privé unique contenant un identifiant aléatoire pour permettre l’accès au service. Parfois, ils sont en plus protégés par un mot de passe ou une phrase secrète ; dans ce cas, accéder au lien n’entraîne pas forcément une exposition des données.
Qui doit être tenu responsable ?
- Selon les conditions d’utilisation de Hybrid Analysis et d’urlscan.io, la responsabilité du contenu soumis incombe à l’utilisateur, et il n’existe aucun mécanisme pour examiner et supprimer les liens sensibles.
- Il se peut aussi qu’il ne soit pas facile d’implémenter cela de manière automatisée.
- En tant que chercheur en sécurité, il est difficile d’identifier l’origine de ces liens.
Nous sommes des threat hunters ! Tous les liens nous appartiennent !
- urlscan Pro permet aux utilisateurs et entreprises payants d’accéder non seulement aux scans
Public, mais aussi aux scans Unlisted.
Unlisted n’apparaît ni sur les pages publiques ni dans les résultats de recherche, mais reste visible pour les clients de la plateforme urlscan Pro.- Les Cortex-Analyzers de TheHive utilisent explicitement la configuration
public:on dans l’analyseur urlscan.io, ce qui fait apparaître les liens en unlisted.
- Pour les utilisateurs d’urlscan Pro, les données ne sont pas publiques mais restent accessibles, ce qui augmente le risque de fuite d’informations sensibles.
Comment supprimer des liens sensibles ?
- Urlscan et Hybrid Analysis permettent de signaler des liens pour les faire supprimer.
- Dans le cas de Hybrid Analysis, tous les fichiers soumis à la sandbox publique sont consultables et rendus publics dans le monde entier.
Conclusion
- Il est certain que ce problème va persister, mais la meilleure solution pourrait être de garder les scans privés par défaut, même si cela ne correspond pas à l’objectif des pratiques de partage de threat intelligence et d’analyse dans la communauté sécurité.
- Lors de l’utilisation de ces services, il faut faire attention à la visibilité des scans.
Clause de non-responsabilité
- Si vous choisissez d’accéder à ces liens/fichiers dans une base de données d’URL, faites attention aux vrais fichiers et liens malveillants.
- Certains peuvent n’être que de simples tentatives de phishing et contenir de vrais malwares.
- Il est recommandé d’utiliser un environnement sandbox.
Liens utiles
- SOAR spot d’urlscan.io : Chatty security tools leaking private data (2022)
- Référence de l’API Search d’urlscan.io
- API publique Falcon Sandbox
- Scanner d’URL Cloudflare Radar
L’avis de GN⁺
- Cet article montre comment des outils de sécurité peuvent divulguer par inadvertance des informations sensibles, et sensibilise à la fois les chercheurs en sécurité et les utilisateurs ordinaires.
- Ce type de problème peut venir d’erreurs d’utilisateurs ou d’une mauvaise configuration des outils, ce qui appelle à davantage d’attention et de responsabilité dans le traitement des informations sensibles au sein de la communauté sécurité.
- L’article souligne également l’importance des mesures que particuliers et entreprises doivent prendre pour protéger leurs données.
- D’un point de vue critique, ce type de fuite peut constituer une menace grave pour la vie privée des individus et la confidentialité des entreprises, ce qui peut remettre en question la fiabilité des outils et services de sécurité.
- Parmi les autres projets offrant des fonctionnalités similaires, on peut citer des plateformes d’analyse de malwares comme VirusTotal ou Any.run ; lors de l’utilisation de ces services, il faut toujours examiner avec soin si les données sont rendues publiques.
1 commentaires
Avis Hacker News
Le problème fondamental est l’absence de contrôle d’accès sur le lien : il est supposé privé simplement parce qu’il n’existe pas d’index public. Une discussion sur Hacker News à propos de la découverte d’identifiants de compte AWS via des buckets a gagné en popularité, et le consensus qui s’est dégagé dans les commentaires est qu’il est erroné de faire dépendre la sécurité du caractère privé d’un identifiant de compte. Ce n’est qu’une autre méthode de « dorking ».
Pour créer un lien partageable de façon privée, il faut stocker l’information secrète dans la partie hash de l’URL. Le hash n’est inclus ni dans les requêtes DNS ni dans les requêtes HTTP. Par exemple, un lien au format
links.com#<secret>ne quitte pas le navigateur. Il est recommandé d’encoder les données de la partie hash sous forme de chaîne Base64 compatible URL.J’ai toujours été sceptique vis-à-vis des liens « privés » utilisables à l’infini. Ce n’est que de la sécurité par l’obscurité. Il vaut mieux avoir une option explicite comme dans Google Docs : « toute personne disposant de l’URL peut accéder ». Dans le système construit par l’auteur, des URL signées à courte durée de vie sont utilisées, et elles ne sont jamais montrées directement à l’utilisateur.
Tout lien qui ne fait pas partie d’une boucle de redirection rapide sera copié et partagé. Les URL sont universelles et servent à faciliter l’accès à une ressource au niveau du protocole. Le contrôle d’accès pour tout ce qui a une durée de vie non triviale doit se faire en dehors de l’URL. Lorsque l’on partage un lien via un canal non e2ee, la première entité à accéder à l’URL peut être le service du canal plutôt que le destinataire. Pour des outils comme ces scanners, indiquer explicitement à l’utilisateur que l’analyse est publique n’améliorera pas l’UX.
La solution au problème de « l’authentification par e-mail » consiste à utiliser un code à usage unique, qui ne pose pas de problème même si l’URL est partagée accidentellement, sans imposer l’étape de création d’un compte et d’un mot de passe. Lorsqu’un utilisateur visite un lien « privé », le site renvoie par e-mail un code à usage unique limité dans le temps, et l’utilisateur saisit ce code temporaire pour confirmer qu’il possède bien l’adresse e-mail.
Sur Internet, si une URL n’est protégée par rien de plus qu’une chaîne aléatoire, elle n’est pas réellement privée. C’est comme chercher des webcams connectées à Internet. Nous devrions déjà le savoir. Pourquoi cela n’est-il pas mentionné dans la section « qui doit être tenu responsable » ?
C’est un aparté, mais il y a un lien affirmant que Cloudflare Radar extrait des données de 1.1.1.1. J’étais pourtant persuadé que 1.1.1.1 n’utilisait pas les données des utilisateurs à quelque fin que ce soit ?
Les liens de réunion Zoom ajoutent souvent un mot de passe en paramètre de requête. Est-ce que cela en fait un lien « privé et sécurisé » ? Et sans mot de passe, est-ce toujours un lien « privé et sécurisé » ?
Pouvez-vous expliquer lequel de ces deux cas est le plus sûr ?
domain.com/loginutilisateur : John mot de passe : mot de passe aléatoire à 5 caractèresdomain.com/URL aléatoire à 12 caractères En supposant dans les deux cas la même protection par aléa / limitation de débit, ou aucune, pourquoi le cas 1 serait-il plus sûr que le cas 2 ?Tous les médias/photos téléversés dans une app privée sur airtable.com sont exposés via des liens publics, accessibles sans authentification dès lors que l’on connaît l’URL.