Enlaces de seguridad privados que son accesibles públicamente, ¿de verdad?
- Herramientas populares de análisis de malware/URL como urlscan.io, Hybrid Analysis y el escáner de URL de Cloudflare Radar almacenan grandes cantidades de enlaces para recopilar y compartir información.
- No es muy conocido que estos servicios también están almacenando enlaces privados y sensibles que fueron enviados por error por usuarios o escaneados como datos públicos por escáneres y extensiones mal configurados.
¿De qué tipo de enlaces estamos hablando?
- Archivos compartidos usando herramientas de almacenamiento en la nube (
Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3, etc.).
- Herramientas NAS conectadas a la nube (
Western Digital Mycloud, etc.).
- Comunicación empresarial (
Slido, Zoom, Onedrive, Airtable, etc.).
- Enlaces de restablecimiento de contraseña, enlaces de inicio de sesión OAuth, etc.
- Todos estos servicios tienen en común que permiten acceder al servicio mediante un único enlace privado que incluye identificadores aleatorios. A veces también están protegidos adicionalmente con una contraseña o frase secreta, y en esos casos acceder al enlace no necesariamente expone los datos.
¿Quién debería ser responsable?
- Según los términos de uso de Hybrid Analysis y urlscan.io, la responsabilidad por el contenido enviado recae en el usuario, y no existe un mecanismo para revisar y eliminar enlaces sensibles.
- Implementar esto de forma automatizada tampoco sería necesariamente sencillo.
- Como investigador de seguridad, es difícil rastrear el origen de estos enlaces.
¡Somos cazadores de amenazas! ¡Todos los enlaces nos pertenecen!
- urlscan Pro permite a usuarios y empresas de pago acceder no solo a escaneos
Public, sino también a escaneos Unlisted.
Unlisted no aparece en páginas públicas ni en resultados de búsqueda, pero sí es visible para los clientes de la plataforma urlscan Pro.- Cortex-Analyzers de TheHive usa explícitamente la configuración
public:on en el analizador de urlscan.io, haciendo que los enlaces aparezcan como unlisted.
- Para los usuarios de urlscan Pro, los datos no son públicos pero sí accesibles, por lo que existe riesgo de que se filtre aún más información sensible.
¿Cómo se pueden eliminar los enlaces sensibles?
- Urlscan y Hybrid Analysis permiten marcar enlaces para que sean eliminados.
- En el caso de Hybrid Analysis, todos los archivos enviados al sandbox público son buscables y públicos en todo el mundo.
Conclusión
- Es seguro que este problema seguirá ocurriendo, pero mantener los escaneos privados por defecto podría ser la mejor solución, aunque eso no encaja con el propósito de compartir inteligencia de amenazas y análisis dentro de la comunidad de seguridad.
- Al usar estos servicios, hay que prestar atención a la visibilidad de los escaneos.
Descargo de responsabilidad
- Si decides acceder a estos enlaces/archivos desde una base de datos de URL, ten cuidado con archivos y enlaces realmente maliciosos.
- Algunos pueden ser simples intentos de phishing y podrían contener malware real.
- Se recomienda usar un entorno sandbox.
Enlaces útiles
- SOAR spot de urlscan.io: Chatty security tools leaking private data (2022)
- Referencia de la API de búsqueda de urlscan.io
- API pública de Falcon Sandbox
- Escáner de URL de Cloudflare Radar
Opinión de GN⁺
- Este artículo sirve como advertencia tanto para investigadores de seguridad como para usuarios comunes al mostrar cómo las herramientas de seguridad pueden exponer información sensible por accidente.
- Estos problemas pueden surgir por errores del usuario o por configuraciones incorrectas de las herramientas, lo que exige más cuidado y responsabilidad en el manejo de información sensible dentro de la comunidad de seguridad.
- El artículo también subraya la importancia de que personas y empresas tomen medidas para proteger sus propios datos.
- Desde una mirada crítica, estas filtraciones pueden representar una amenaza grave para la privacidad individual y la confidencialidad empresarial, lo que podría poner en duda la confiabilidad de las herramientas y servicios de seguridad.
- Otros proyectos con funciones similares incluyen plataformas de análisis de malware como VirusTotal o Any.run, y al usar estos servicios siempre se debe revisar cuidadosamente si los datos quedarán públicos.
1 comentarios
Opinión de Hacker News
El problema fundamental es que el enlace no tiene control de acceso y se asume que es privado porque no existe un índice público. En Hacker News se volvió popular una historia relacionada con descubrir IDs de cuentas de AWS a través de buckets, y el consenso que surgió en los comentarios fue que depender de la privacidad de un identificador de cuenta como parte de la seguridad es un enfoque equivocado. Esto es simplemente otra forma de hacer "dorking".
Si quieres generar un enlace que pueda compartirse de forma privada, debes guardar la información secreta en la parte hash del URL. El hash no se incluye en las consultas DNS ni en las solicitudes HTTP. Por ejemplo, un enlace con formato
links.com#<secret>no sale del navegador. Es recomendable codificar los datos de la parte hash como una cadena Base64 segura para URL.Siempre he sospechado de los enlaces "privados" que pueden usarse infinitamente. Eso es solo seguridad por oscuridad. Es mejor cuando hay una opción explícita, como en Google Docs, de "cualquier persona con el URL puede acceder". En un sistema que construí, usamos URL firmados de corta duración, y esos URL no se muestran directamente al usuario.
Cualquier enlace que no forme parte de un bucle rápido de redirección será copiado y compartido. Los URL son universales y facilitan el acceso a recursos dentro del protocolo. El control de acceso para cualquier cosa con una vida útil que no sea muy corta debe hacerse fuera del URL. Cuando se comparte un enlace por un canal que no es e2ee, la primera entidad que accede al URL podría ser el servicio del canal y no el destinatario. Estas herramientas de escaneo no mejorarían la UX si se informara explícitamente a los usuarios que el escaneo es público.
La solución al problema de la "autenticación basada en correo electrónico" es usar códigos de un solo uso que no causen problemas aunque el URL se comparta por accidente, sin necesidad de pasar por la etapa de crear una cuenta y contraseña. Cuando el usuario visita un enlace "privado", el sitio vuelve a enviar por correo un código de un solo uso con límite de tiempo, y el usuario introduce ese código temporal para confirmar que es dueño del correo.
En internet, si un URL no tiene más protección que una cadena aleatoria, en la práctica no es privado. Es como buscar cámaras web conectadas a internet. Esto ya deberíamos saberlo. ¿Por qué no se menciona en la sección de "quién debería ser responsable"?
Esto se sale un poco del tema, pero hay un enlace que afirma que Cloudflare Radar extrae datos de 1.1.1.1. ¿No se suponía que 1.1.1.1 no usaba datos de usuarios para ningún propósito?
Los enlaces de reuniones de Zoom a menudo agregan la contraseña como parámetro de consulta. ¿Ese enlace es un enlace "privado y seguro"? ¿Lo es sin contraseña?
¿Alguien puede explicar cuál de estos dos casos es más seguro?
domain.com/loginusuario: John contraseña: contraseña aleatoria de 5 caracteresdomain.com/URL aleatorio de 12 caracteres Suponiendo en ambos casos la misma protección por aleatoriedad/limitación de velocidad, o ninguna, ¿por qué el caso 1 sería más seguro que el 2?Todo el contenido multimedia/fotos subido a una app privada de airtable.com queda en enlaces públicos, accesibles sin autenticación si se conoce el URL.