- Des services d’analyse d’URL et de malwares comme urlscan.io, Hybrid Analysis ou Cloudflare Radar URL Scanner conservent de nombreux liens pour partager des renseignements sur les menaces, mais à cause d’erreurs d’utilisateur ou de scanners mal configurés, des liens sensibles peuvent rester dans des données accessibles publiquement
- Les services où l’URL elle-même sert d’autorisation d’accès sont particulièrement concernés, comme Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, ainsi que les liens de réinitialisation de mot de passe et les liens de connexion OAuth
- Tous les liens ne sont pas exposés immédiatement, mais des documents fiscaux, factures, photos, communications professionnelles, secrets partagés via onetimesecret, ainsi que des contenus de maison connectée ou des enregistrements de réunions ont effectivement été retrouvés
- urlscan Pro montre à ses clients payants non seulement les scans Public, mais aussi les scans Unlisted, et il peut exister des chemins de soumission involontaires en unlisted, comme avec la configuration de Cortex-Analyzers de TheHive
- Sur les dernières 24 heures, urlscan.io a compté 398 563 scans Public, 328 147 scans Unlisted et 955 432 scans Private ; une expérience avec un token canari a aussi confirmé un accès dans l’heure suivant la soumission, ce qui montre la nécessité de gérer la visibilité des scans
Liens sensibles conservés par les services d’analyse d’URL
- Des services comme urlscan.io, Hybrid Analysis et Cloudflare Radar URL Scanner stockent un grand nombre de liens pour l’analyse d’URL et de malwares
- Le problème est que des liens privés ou sensibles peuvent eux aussi se retrouver dans ces dépôts
- des utilisateurs soumettent à l’analyse des liens sensibles sans savoir qu’ils deviendront des informations publiques
- des scanners ou extensions mal configurés soumettent à des jeux de données publics des liens privés scannés dans des e-mails
Liens et contenus susceptibles d’être exposés
- Les liens retrouvés incluent des URL de partage et des URL liées à l’authentification pour plusieurs services
- partage de fichiers sur des stockages cloud comme Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3
- NAS connectés au cloud comme Western Digital Mycloud
- outils de communication d’entreprise comme Slido, Zoom, OneDrive, Airtable
- liens de réinitialisation de mot de passe et liens de connexion OAuth
- Pour des raisons de sécurité, ces services autorisent souvent l’accès via un lien privé unique contenant un identifiant aléatoire
- Certains liens sont protégés en plus par un mot de passe ou une phrase secrète ; le simple accès au lien n’expose donc pas forcément les données immédiatement
- Parmi les contenus sensibles réellement trouvés figuraient :
- des fichiers privés comme des documents fiscaux, des factures, des photos ou des communications professionnelles
- des secrets partagés via onetimesecret
- des enregistrements d’appareils de maison connectée
- des enregistrements de réunions stockés dans le cloud
Voies de soumission et zones grises de responsabilité
- De nombreuses soumissions observées sur urlscan.io portaient le tag falconsandbox, ce qui a conduit à élargir l’analyse à Hybrid Analysis
- Cloudflare Radar pourrait aussi être utilisé plus largement et inclut déjà certains liens privés dans ses données publiques
- Les conditions d’utilisation de Hybrid Analysis précisent qu’il peut analyser, publier et partager les contenus soumis par les utilisateurs, et qu’il n’est pas responsable des informations incluses accidentellement dans les soumissions ou les rapports générés automatiquement
- Les conditions d’utilisation de urlscan.io indiquent également que le service n’assume aucune responsabilité concernant les contenus ou actions des utilisateurs, et que les contenus publiés et activités menées sous un compte relèvent de l’utilisateur
- Il ne semble pas exister de mécanisme clair pour examiner les contenus existants afin de signaler ou supprimer des liens sensibles, et l’automatiser n’est pas forcément simple
- L’analyse de Positive Security a utilisé des tokens canari contre urlscan.io pour détecter des sources automatisées, en évoquant la possibilité que des outils de sécurité scannant des liens malveillants dans des e-mails soient à l’origine du problème
- Le même comportement a aussi été vérifié avec des liens canari
Scans Unlisted et accès via urlscan Pro
- urlscan Pro donne aux utilisateurs payants et aux entreprises un accès à une catégorie de scans plus large, incluant non seulement les scans Public, mais aussi les scans Unlisted
- Sur urlscan.io, Unlisted signifie qu’un scan n’apparaît ni sur les pages publiques ni dans les résultats de recherche, mais qu’il reste visible pour les clients de la plateforme urlscan Pro
- il est indiqué que les clients de urlscan Pro sont limités à des chercheurs en sécurité vérifiés ou à des entreprises réputées
- Les Cortex-Analyzers de TheHive montrent un exemple de voie d’exposition involontaire
- l’analyseur urlscan.io utilise explicitement le réglage
public:on - à cause de ce réglage, même si la visibilité du compte urlscan est définie sur Private, le lien peut apparaître en unlisted
- le code correspondant se trouve dans urlscan.py de Cortex-Analyzers
- l’analyseur urlscan.io utilise explicitement le réglage
- Dans ce cas, même si les données ne sont pas entièrement publiques, elles peuvent rester visibles pour les utilisateurs de urlscan Pro, ce qui laisse subsister un risque d’exposition d’informations plus sensibles
Volumes de scans et résultats avec tokens canari
- Sur les 24 dernières heures, urlscan.io a enregistré :
Public: 398 563 scansUnlisted: 328 147 scansPrivate: 955 432 scans
- Les accès confirmés avec des tokens canari sont les suivants :
- un lien soumis à urlscan.io en
unlisteda été consulté 12 fois dans l’heure suivant la soumission - un lien soumis à Hybrid Analysis via une
API, et non via un navigateur, a été consulté 10 fois dans l’heure suivant la soumission - certaines adresses IP ont accédé simultanément à des liens uniques soumis aux deux services et utilisaient un service d’anonymisation d’IP source
- un lien soumis à urlscan.io en
- La liste de ces adresses IP est publiée dans un fichier séparé
Suppression des liens sensibles et précautions d’usage
- urlscan.io et Hybrid Analysis proposent une procédure pour signaler un lien et le faire retirer
- Chez Hybrid Analysis, la suppression et le périmètre de partage sont plus complexes
- tous les fichiers soumis au Public Sandbox sont recherchables et mis à disposition dans le monde entier
- même si la case « Do not share my sample with the community » est cochée, les captures d’écran et le rapport proprement dit restent accessibles
- l’option « do not share » ne s’applique qu’à l’échantillon effectivement envoyé
- Lors de l’utilisation de ces services, il faut d’abord vérifier la visibilité du scan
- Accéder à des liens ou fichiers dans ce type de base de données d’URL peut exposer à des tentatives de phishing, à de vrais fichiers malveillants ou à des liens malveillants
- Si un accès est nécessaire, il faut le faire dans un environnement sandbox
1 commentaires
Commentaires sur Hacker News
Le problème fondamental, c’est que des liens sans contrôle d’accès sont considérés comme privés simplement parce qu’il n’existe pas d’index public de leurs identifiants
Le mois dernier encore, une discussion sur la découverte d’ID de comptes AWS via des buckets a eu pas mal d’écho sur HN[0], et le consensus dans les commentaires était qu’il est erroné de compter sur la sécurité en supposant qu’un identifiant de compte est privé
Le même concept s’applique ici, et il s’agit moins d’un nouveau problème de sécurité que d’une autre méthode de dorking fondée sur des opérateurs de recherche
[0]: https://news.ycombinator.com/item?id=39512896
En théorie, un lien hexadécimal de 256 caractères, soit 1024 bits, est bien plus difficile à deviner qu’un nom d’utilisateur de 32 caractères et un mot de passe de 32 caractères
https://site.com/[256chars] offre 2^1024 combinaisons, donc une attaque par force brute est pratiquement impossible
En revanche, https://site,com/[32chars] avec un mot de passe de 32 caractères représente 2^256 combinaisons, ce qui est là aussi quasiment impossible, mais reste plus plausible que le premier cas
On peut le voir comme https://site,com/[32chars][32chars]
Cela dit, même si le premier est plus difficile à deviner, les URL fuient bien plus souvent que les mots de passe
Ici, “message” inclut largement les e-mails, les DM et même les liens collés dans des documents
Ça me mettait mal à l’aise, donc j’ai finalement choisi une autre approche, mais ça m’a fait réfléchir à la différence réelle entre un “secret” présent dans une URL et un secret présent dans un token envoyé lors d’une requête à cette URL
Ma conclusion, c’est que les tokens peuvent être émis par client, qu’on peut surveiller les logs d’accès pour détecter des comportements suspects, puis les révoquer
Et comme d’autres l’ont dit, il y a aussi une différence d’état d’esprit sur l’importance qu’on accorde au fait de garder secrète la liste des noms de fichiers
À l’échelle des erreurs possibles chez Amazon, exposer accidentellement la liste des fichiers d’un bucket public semble être quelque chose dont 99 % des utilisateurs se soucient peu, donc la priorité paraît faible
Naturellement, c’est notre entreprise qui a perdu la course
Depuis, chaque fois que j’utilise AWS, j’en ai tiré cette petite leçon : les noms de buckets finissent souvent par prendre cette forme
Si ça doit vraiment rester privé, on peut même chiffrer les noms de projet et fournir un script qui liste les buckets sous des noms “conviviaux”
Les services d’hébergement impliquent toujours des compromis étranges : des identifiants totalement aléatoires, techniquement parfaits, risquent de créer une charge opérationnelle bien plus élevée que des noms descriptifs, qui sont imparfaits
Bitwarden Send permet de créer un lien transmissible à d’autres personnes, avec une longue chaîne aléatoire après
#Je l’utilise régulièrement, donc j’aimerais savoir s’il y a un problème de sécurité
Au moins, le lien peut être révoqué et expirer automatiquement après quelques jours, ce qui n’est généralement pas le cas d’un mot de passe classique
Pour créer un lien de partage privé, il suffit de stocker une valeur privée dans la partie hash de l’URL
Le hash n’est pas transmis dans les requêtes DNS ni HTTP
Par exemple, si on visite links.com?token=, ce lien est transmis avec son paramètre de recherche et peut être stocké par un intermédiaire comme Cloudflare
En revanche, si on visite links.com#, la partie hash ne sort pas du navigateur
Quand on manipule des données dans la partie hash, il est pratique de les encoder en chaîne Base64 URL-safe
Autrement dit : JS Object ↔ JSON String ↔ URL Safe Base 64 String
Le reste est exact, je voulais simplement ajouter cette nuance sur le chiffrement HTTPS
Le mettre dans le fragment aide, mais ce n’est pas parfait
Je ne parle pas seulement en théorie : j’ai vu plusieurs fois des tokens privés présents dans des fragments fuiter de cette manière
[https://example.com?token=](<https://example.com?token=<secret>>;) ne devrait déclencher une requête DNS que pour “example.com”
Les bots qui suivent les liens dans les e-mails exécutent-ils du JavaScript ? Y a-t-il un risque qu’un POST déclenché par JavaScript active réellement l’action ?
Tout lien qui ne fait pas partie d’une boucle de redirection rapide devra forcément être copié-collé pour être partagé
Les URL sont faites pour cela à l’origine : elles sont universelles et permettent d’accéder facilement à des ressources exposées par n’importe quel protocole
Le contrôle d’accès pour ce qui n’est pas de très courte durée doit se faire en dehors de l’URL
Si on partage un lien via un canal qui n’est pas chiffré de bout en bout, la première entité à accéder à cette URL n’est pas le destinataire, mais le service du canal
Cela peut être légitime, comme quand Bitwarden va chercher un favicon pour améliorer l’expérience utilisateur, ou malveillant, comme quand le crawler de Facebook Messenger veut en savoir plus sur ce qui est partagé dans des messages privés
Ces outils de scan ne vont pas améliorer l’expérience utilisateur
S’il était explicitement indiqué que les résultats des scans sont rendus publics, certains utilisateurs y réfléchiraient à deux fois avant d’utiliser le service, et ce serait mauvais pour l’activité, qu’ils soient utilisateurs gratuits ou titulaires d’une licence pro
Les liens « privés » utilisables sans limite m'ont toujours semblé un peu suspects.
Au final, c'est une sécurité par l'obscurité.
Quand on partage quelque chose comme un document Google, il existe au moins une option qui précise « toute personne disposant de l'URL peut y accéder ».
Quand j'ai eu besoin de ce type de mécanisme dans un système que j'ai conçu, j'ai en général utilisé des URL signées qui n'étaient valables que quelques minutes.
L'URL est en grande partie un détail d'implémentation et n'est pas montrée directement à l'utilisateur, mais il reste possible de la voir dans les outils de débogage du navigateur.
Si, sur Internet, quelque chose n'est protégé que par une chaîne aléatoire dans l'URL, alors ce n'est pas réellement privé.
C'est la même histoire que les webcams connectées qu'on peut trouver en cherchant un peu.
On le savait déjà, non ? Je ne comprends pas pourquoi la section « qui est responsable ? » n'aborde pas du tout ce point.
Tout n'a pas besoin du niveau de sécurité maximal, et dans certains cas il suffit d'une barrière qui empêche le partage à grande échelle.
Par exemple, si dans une galerie photo vous cliquez sur « créer un lien de partage » pour envoyer une photo à quelqu'un, vous ne voulez pas que cette personne doive saisir un mot de passe.
Elle doit ouvrir le lien et voir la photo, et pour cet usage c'est très bien.
L'un des exemples ici correspond exactement à ce cas, et c'est adapté à cet usage.
Même du point de vue de la confidentialité, même s'il y avait un processus de connexion, l'utilisateur final pourrait toujours repartager une capture d'écran à ce stade.
La sécurité est donc adaptée au cas d'usage.
On part du principe que l'utilisateur a désormais le lien vers la photo et pourrait le repartager, mais qu'il ne le fera pas intentionnellement.
Le vrai gros problème ici, ce n'est pas tant le lien lui-même que le fait que des outils d'analyse de sécurité scannent tous les liens reçus par e-mail et les rendent aussi accessibles à d'autres utilisateurs de cette communauté.
C'est une republication bien plus large que ce que j'avais l'intention de faire en envoyant une photo à quelqu'un.
Une façon de contourner ce problème d'authentification par e-mail consiste à utiliser un code temporaire à usage unique, sans aller jusqu'à créer un compte avec mot de passe.
Ainsi, même si l'URL est partagée par erreur, ce n'est pas très grave.
C'est hors sujet, mais le lien mène vers Cloudflare Radar, et ce service semble apparemment exploiter des données de 1.1.1.1.
Je croyais que 1.1.1.1 n'utilisait pas les données utilisateur, quel qu'en soit l'usage.
J'aimerais qu'une personne plus compétente m'explique ceci. Quelle est la différence entre les deux cas suivants ?
En supposant soit qu'ils aient tous les deux les mêmes protections contre le brute force ou la même limitation de débit, soit qu'ils n'en aient aucun, pourquoi le 1 serait-il plus sûr que le 2 ?
En pratique, il y en a une.
Un secret fondé sur la possession et un secret fondé sur la connaissance ne sont pas la même chose.
Une URL est quelque chose qu'on possède ; si on la laisse dans un endroit accessible, on peut se la faire prendre.
Un mot de passe est quelque chose qu'on connaît, et s'il est bien géré on ne peut pas vous le prendre. Sauf attaque au tuyau de plomb.
Il existe aussi une troisième catégorie fondée sur la biométrie, comme un scan de rétine ou d'empreinte digitale.
Le cas (1) exige des informations qui passent par un canal distinct pour l'authentification, et ce sont des informations que les gens ont l'habitude de conserver en sécurité.
À l'inverse, l'URL du cas (2) est traitée comme une URL.
Les URL sont souvent journalisées, historisées, partagées et transmises un peu partout.
Par exemple, si le pare-feu d'une entreprise enregistrait le nom d'utilisateur et le mot de passe utilisés pour se connecter à un service, ce serait manifestement problématique, mais il pourrait sembler acceptable d'enregistrer l'URL consultée.
Ce dernier point n'est qu'un exemple, et à cause des garanties de bout en bout de TLS, aucun des deux ne devrait être accessible.
En plus, si domain.com/12-char-password est demandé sans HTTPS, alors même s'il y a une redirection, la requête initiale est envoyée sans chiffrement et permet une attaque de type homme du milieu.
À l'inverse, avec une page de connexion, il existe davantage de moyens de garantir que l'envoi du mot de passe n'a lieu qu'en HTTPS.
L'un des gros problèmes est que beaucoup d'applications de journalisation enregistrent l'URL complète quelque part, ce qui revient en pratique à laisser le « mot de passe » dans les logs.
Tous les médias et photos téléversés dans une application airtable.com privée sont accessibles via des liens publics.
Si vous connaissez l'URL, vous pouvez y accéder sans authentification.
Une balise image classique ne permet pas de définir un en-tête Authorization contenant un jeton dans la requête comme on le ferait avec fetch() pour un appel API.
Les seules options possibles sont d'ajouter un jeton dans l'URL ou d'utiliser une authentification par cookie.
L'authentification par cookie ne fonctionne que si le CDN est sur le même domaine, et même un sous-domaine peut souvent poser problème.
Je suis d'accord sur le fait que cela peut potentiellement poser problème.
Les liens de réunion Zoom incluent souvent le mot de passe comme paramètre de requête
Ce lien est-il un lien de « sécurité privée » ? Un lien sans le mot de passe est-il un lien de « sécurité privée » ?
Au moment où ce lien apparaîtra ailleurs, la réunion sera déjà terminée et aura disparu
Mais dans la réalité, personne n’y prête attention et tout le monde veut simplement « cliquer pour rejoindre » sans avoir à saisir quoi que ce soit
L’ancienne méthode consistant à « n’utiliser que l’ID de réunion » était bien trop facile à deviner