- Los servicios de análisis de URL y malware como urlscan.io, Hybrid Analysis y Cloudflare Radar URL Scanner almacenan enlaces para compartir inteligencia de amenazas, pero por errores de usuarios o escáneres mal configurados, los enlaces sensibles pueden quedar como datos públicos
- Los servicios donde la propia URL funciona como permiso de acceso, como Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, enlaces de restablecimiento de contraseña y enlaces de inicio de sesión OAuth, pueden verse especialmente afectados
- No todos los enlaces quedan expuestos de inmediato, pero se han encontrado documentos fiscales, facturas, fotos, comunicaciones de trabajo, secretos compartidos con onetimesecret y materiales como grabaciones de smart home y reuniones
- urlscan Pro muestra a clientes de pago no solo escaneos Public, sino también escaneos Unlisted, y puede haber rutas que se envían involuntariamente como unlisted, como en la configuración de Cortex-Analyzers de TheHive
- En las últimas 24 horas, la cantidad de escaneos de urlscan.io fue de 398,563 Public, 328,147 Unlisted y 955,432 Private; en un experimento con tokens canario también se confirmó acceso dentro de la hora posterior al envío, por lo que es necesario gestionar la visibilidad de los escaneos
Enlaces sensibles que quedan en servicios de análisis de URL
- urlscan.io, Hybrid Analysis y Cloudflare Radar URL Scanner almacenan muchos enlaces para analizar URLs y malware
- El problema es que en estos repositorios también pueden terminar enlaces privados y sensibles
- Un usuario envía un enlace sensible a un escaneo sin saber que se convertirá en información pública
- Un escáner o extensión mal configurados envían como datos públicos enlaces privados escaneados desde correos electrónicos
Enlaces y materiales que pueden quedar expuestos
- Los enlaces encontrados incluyen URLs compartidas de varios servicios y URLs relacionadas con autenticación
- Compartición de archivos en almacenamiento en la nube como Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive y AWS S3
- NAS conectados a la nube como Western Digital Mycloud
- Herramientas de comunicación empresarial como Slido, Zoom, OneDrive y Airtable
- Enlaces de restablecimiento de contraseña y enlaces de inicio de sesión OAuth
- Estos servicios suelen permitir el acceso mediante un único enlace privado con un identificador aleatorio por motivos de seguridad
- Algunos enlaces tienen protección adicional con contraseña o frase de acceso, por lo que el simple acceso al enlace no expone de inmediato los datos
- El contenido sensible encontrado en la práctica incluye lo siguiente
- Archivos privados como documentos fiscales, facturas, fotos y comunicaciones de trabajo
- Secretos compartidos mediante onetimesecret
- Grabaciones de dispositivos de smart home
- Grabaciones de reuniones almacenadas en la nube
Rutas de envío y vacíos de responsabilidad
- Muchos envíos confirmados en urlscan.io tenían la etiqueta falconsandbox, lo que llevó a ampliar el alcance del análisis hasta Hybrid Analysis
- Cloudflare Radar también podría usarse de forma más amplia y ya incluye algunos enlaces privados como datos públicos
- Los términos de Hybrid Analysis señalan que pueden analizar, publicar y compartir el contenido enviado por los usuarios, y que no se hacen responsables por información incluida accidentalmente en envíos o reportes generados automáticamente
- Los términos de urlscan.io también indican que no se hacen responsables del contenido o las acciones de los usuarios, y que el usuario es responsable del contenido y la actividad publicados bajo su cuenta
- No parece haber un mecanismo claro para revisar contenido existente y marcar o eliminar enlaces sensibles, y automatizarlo podría no ser sencillo
- El análisis de Positive Security usó tokens canario contra urlscan.io para detectar fuentes automatizadas y aborda que la causa podrían ser herramientas de seguridad que escanean enlaces maliciosos en correos electrónicos
- El mismo comportamiento también se verificó con enlaces canario
Escaneos Unlisted y acceso en urlscan Pro
- urlscan Pro ofrece a usuarios de pago y empresas acceso a un rango más amplio de escaneos, no solo Public sino también escaneos Unlisted
- En urlscan.io, Unlisted no aparece en páginas públicas ni resultados de búsqueda, pero sí es visible para clientes de la plataforma urlscan Pro
- Se indica que los clientes de urlscan Pro están limitados a investigadores de seguridad verificados o empresas de buena reputación
- Cortex-Analyzers de TheHive es un ejemplo de una ruta de exposición no intencional
- En el analizador de urlscan.io se usa explícitamente la configuración
public:on - Debido a esta configuración, aunque la visibilidad de la cuenta de urlscan sea Private, el enlace puede aparecer como unlisted
- El código relacionado está en urlscan.py de Cortex-Analyzers
- En el analizador de urlscan.io se usa explícitamente la configuración
- En este caso, aunque los datos no se vuelvan completamente públicos, pueden ser visibles para usuarios de urlscan Pro, por lo que persiste la posibilidad de exponer información más sensible
Cantidad de escaneos y resultados con tokens canario
- La cantidad de escaneos de urlscan.io en las últimas 24 horas es la siguiente
Public: 398,563 casosUnlisted: 328,147 casosPrivate: 955,432 casos
- Los resultados de acceso confirmados con tokens canario fueron los siguientes
- Un enlace enviado a urlscan.io como
unlistedrecibió 12 accesos dentro de la hora posterior al envío - Un enlace enviado a Hybrid Analysis por
API, no por navegador, recibió 10 accesos dentro de la hora posterior al envío - Algunas direcciones IP accedieron simultáneamente a enlaces únicos enviados a ambos servicios y usaron servicios de anonimización de IP de origen
- Un enlace enviado a urlscan.io como
- La lista de esas direcciones IP se publicó en un archivo separado
Eliminación de enlaces sensibles y precauciones de uso
- urlscan.io y Hybrid Analysis ofrecen procedimientos para reportar enlaces y eliminarlos
- En Hybrid Analysis, la eliminación y el alcance de la compartición son más complejos
- Todos los archivos enviados a Public Sandbox son buscables y están disponibles globalmente
- Aunque se seleccione la casilla “Do not share my sample with the community”, las capturas de pantalla y el reporte real siguen estando disponibles
- “do not share” solo se aplica a la muestra de entrada real
- Al usar estos servicios, primero hay que comprobar la visibilidad del escaneo
- Al acceder a enlaces o archivos en estas bases de datos de URLs, se pueden encontrar intentos de phishing, archivos realmente maliciosos o enlaces maliciosos
- Si es necesario acceder, debe hacerse en un entorno sandbox
1 comentarios
Opiniones de Hacker News
El problema de fondo es que los enlaces sin control de acceso se consideran privados solo porque no existe un índice público de identificadores.
El mes pasado también tuvo bastante repercusión en HN una historia sobre encontrar IDs de cuentas de AWS a través de buckets[0], y el consenso en los comentarios fue que está mal basar la seguridad en la premisa de que los identificadores de cuentas son privados.
Aquí se aplica el mismo concepto, y más que un nuevo problema de seguridad, es simplemente otro método de exploración basada en operadores de búsqueda (dorking).
[0]: https://news.ycombinator.com/item?id=39512896
En teoría, un enlace hexadecimal de 256 caracteres, es decir 1024 bits, es mucho más difícil de adivinar que un nombre de usuario de 32 caracteres y una contraseña de 32 caracteres.
https://site.com/[256chars] tiene 2^1024 combinaciones, así que un ataque de fuerza bruta es prácticamente imposible.
En cambio, https://site,com/[32chars] y una contraseña de 32 caracteres tienen 2^256 combinaciones; eso también es casi imposible, pero más probable que lo anterior.
Es como verlo como https://site,com/[32chars][32chars].
Sin embargo, aunque lo primero sea más difícil de acertar, las URL se filtran muchísimo más que las contraseñas.
Aquí “mensaje” incluye en sentido amplio correos electrónicos, DM e incluso enlaces pegados en documentos.
Me incomodó y al final elegí otra vía, pero me quedé pensando cuánto cambia en la práctica que el “secreto” esté dentro de la URL o dentro de un token que se envía al solicitar la URL.
Mi conclusión es que los tokens pueden emitirse por cliente, y se pueden monitorear los logs de acceso para detectar comportamiento sospechoso y revocarlos.
Además, como dijeron otros, también es distinta la mentalidad sobre qué tan importante se considera mantener en secreto la lista de nombres de archivo.
A la escala de cosas en las que Amazon puede equivocarse, exponer por accidente la lista de nombres de archivo de un bucket público parece algo que al 99% de los usuarios no les importaría, así que se ve como una prioridad baja.
Por supuesto, mi empresa perdió esa competencia.
Desde entonces, cuando trabajo con AWS, me quedó la pequeña lección de que los nombres de buckets normalmente conviene hacerlos con forma de -.
Si realmente deben ser privados, se puede cifrar también el nombre del proyecto y ofrecer un script que liste los buckets con nombres “amigables”.
En los servicios de hosting siempre hay compromisos raros, así que el enfoque técnicamente perfecto, identificadores totalmente aleatorios, probablemente tenga mucha más carga operativa que el enfoque imperfecto de nombres descriptivos.
Bitwarden Send crea enlaces que se pueden enviar a otras personas, con una cadena aleatoria larga después de
#.Lo uso con regularidad, así que me gustaría saber si hay algún problema de seguridad.
Al menos el enlace se puede revocar y también puede expirar automáticamente después de unos días, mientras que las contraseñas comunes normalmente no funcionan así.
Para crear enlaces privados compartidos, basta con guardar el valor privado en la parte hash de la URL.
El hash no se envía en consultas DNS ni en solicitudes HTTP.
Por ejemplo, si visitas links.com?token=, ese enlace se transmite incluyendo los parámetros de búsqueda y puede quedar almacenado en intermediarios como Cloudflare.
En cambio, si visitas links.com#, la parte hash no sale del navegador.
Al manejar datos en la parte hash, es práctico codificarlos como una cadena Base64 URL Safe.
Es decir, el flujo es JS Object ↔ JSON String ↔ URL Safe Base 64 String.
El resto es correcto; solo quería agregar ese matiz de cifrado HTTPS.
Ponerlo en el fragmento ayuda, pero no es perfecto.
No lo digo solo como ideal teórico: en la práctica he visto varias veces tokens privados filtrarse de esta manera desde fragmentos.
[https://example.com?token=](<https://example.com?token=<secret>>;) debería generar una consulta DNS solo por “example.com”.
¿Los bots que siguen enlaces dentro de correos ejecutan JavaScript? ¿Existe el riesgo de que un POST inducido por JavaScript active una acción real?
Los enlaces que no forman parte de un bucle rápido de redirecciones inevitablemente se copian y pegan para compartirlos.
Las URL fueron hechas para eso: son universales y facilitan acceder a recursos ofrecidos por cualquier protocolo.
El control de acceso para cosas que no son de vida corta debe hacerse fuera de la URL.
Si compartes un enlace por un canal que no tiene cifrado de extremo a extremo, el primer actor que accede a esa URL no es el destinatario, sino el servicio del canal.
Puede ser legítimo, como cuando Bitwarden busca favicons para mejorar la experiencia de usuario, o malicioso, como cuando el crawler de Facebook Messenger quiere saber más sobre lo que se comparte en mensajes privados.
Estas herramientas de escaneo no van a mejorar la experiencia de usuario.
Si se indica explícitamente que los resultados del escaneo se publican, algunos usuarios lo pensarán dos veces antes de usar el servicio, y eso es malo para el negocio, sean usuarios gratuitos o con licencia Pro.
Los enlaces “privados” de uso ilimitado siempre me parecieron un poco sospechosos
Al final son seguridad basada en la oscuridad
Al compartir algo como un documento de Google, al menos existe una opción que dice explícitamente “cualquier persona con la URL puede acceder”
Cuando necesitaba algo de este tipo en sistemas que yo creaba, normalmente usaba URL firmadas con una vida útil de apenas unos minutos
La URL suele ser un detalle de implementación y no se muestra directamente al usuario, aunque es posible verla en la pantalla de depuración del navegador
Si algo en internet no está protegido más que por una cadena aleatoria dentro de la URL, en realidad no es privado
Es la misma historia que con las webcams conectadas a internet que aparecen si las buscas
¿No sabíamos esto ya? No entiendo por qué la sección “quién es responsable” no aborda este punto en absoluto
No todo necesita el máximo nivel de seguridad; en algunos casos basta con una barrera que impida compartirlo masivamente
Por ejemplo, si en una galería de fotos presionas “crear enlace para compartir” y le envías a alguien el enlace de una foto, no quieres que esa persona tenga que ingresar una contraseña
Al abrir el enlace debería ver la foto, y para ese uso está bien
Uno de los ejemplos aquí es exactamente ese caso, y encaja con ese uso
Incluso desde el punto de vista de la privacidad, aunque hubiera un inicio de sesión, el usuario final podría volver a compartir una captura de pantalla en ese momento
La seguridad está ajustada al caso de uso
La situación es que el usuario ahora tiene el enlace de la foto y podría volver a compartirlo, pero confías en que no lo hará deliberadamente
El gran problema aquí no es tanto el enlace en sí, sino que una herramienta de análisis de seguridad escanee todos los enlaces que el usuario recibió por correo y los deje accesibles también para otros usuarios de esa comunidad
Eso es una redistribución mucho mayor que la que yo pretendía al enviarle una foto a alguien
Una solución alternativa a este problema de autenticación basada en email, sin llegar a crear una cuenta con contraseña, es usar un código temporal de un solo uso
Así, aunque la URL se comparta por accidente, no es tan grave
Fuera de tema, pero el enlace lleva a Cloudflare Radar, y ese servicio aparentemente parece minar datos de 1.1.1.1
Yo entendía que 1.1.1.1 no usaba datos de usuarios para ningún propósito
Me gustaría que alguien más inteligente lo explicara. ¿Qué diferencia hay entre estos dos casos?
Si asumimos que ambos tienen la misma protección contra fuerza bruta o el mismo límite de velocidad, o que ninguno lo tiene, ¿por qué 1 es más seguro que 2?
En la práctica, sí hay diferencia
Un secreto basado en posesión y un secreto basado en conocimiento son distintos
Una URL es algo que tienes; si la dejas en un lugar accesible, te la pueden quitar
Una contraseña es algo que sabes y, si la gestionas bien, no te la pueden quitar. Salvo el ataque de la tubería de plomo
Otro tipo es el basado en biometría, como escaneos de retina o huellas digitales
(1) requiere información por un canal separado para autenticarse, e información que la gente está acostumbrada a guardar de forma segura
En cambio, la URL de (2) se trata como una URL
Las URL a menudo se registran en logs, se guardan en historiales, se comparten y circulan por todas partes
Por ejemplo, si el firewall de una empresa registrara el usuario y la contraseña usados para iniciar sesión en un servicio, sería claramente malo; pero registrar la URL visitada probablemente parecería aceptable
Esto último es solo un ejemplo; por las garantías de extremo a extremo de TLS, no deberían poder acceder a ninguno de los dos
Además, si domain.com/12-char-password se solicita sin HTTPS, aunque haya una redirección, la primera solicitud se envía sin cifrar, lo que permite un ataque de intermediario
En cambio, con una página de inicio de sesión hay más formas de garantizar que el envío de la contraseña ocurra solo por HTTPS
Uno de los grandes problemas es que muchas aplicaciones de logging registran la URL completa en algún lugar, lo que en la práctica deja la “contraseña” en los logs
Todos los medios y fotos que subes a una app privada de airtable.com son enlaces públicos
Si conoces la URL, puedes acceder sin autenticación
Una etiqueta de imagen normal no permite establecer un encabezado Authorization con un token en la solicitud como se haría con fetch() en una petición a la API
Las únicas opciones posibles son agregar el token a la URL o usar autenticación por cookies
La autenticación por cookies solo funciona cuando la CDN está en el mismo dominio, e incluso los subdominios pueden causar problemas en muchos casos
Estoy de acuerdo en que puede ser potencialmente problemática
Los enlaces de reuniones de Zoom a menudo agregan la contraseña como parámetro de consulta.
¿Ese enlace es un enlace de “seguridad por no divulgación”? ¿Un enlace sin la contraseña es un enlace de “seguridad por no divulgación”?
Porque para cuando la URL aparezca en otro lugar, esa reunión probablemente ya habrá terminado y desaparecido.
Pero en la realidad a nadie le importa, y quieren “hacer clic para unirse” sin tener que ingresar varias cosas.
El método anterior de “usar solo el ID de la reunión” era demasiado fácil de adivinar.