Dropbox reveló que entre el 4 y el 21 de agosto de 2026, unos 5.000 usuarios tuvieron sus cuentas comprometidas. El método de ataque es tan simple como inquietante: alguien registró un Lenovo ID usando la dirección de correo electrónico de otra persona y, gracias a una integración heredada entre ambas plataformas que no verificaba correctamente la propiedad del correo, accedió a la cuenta de Dropbox de esa persona sin necesitar su contraseña. Archivos fueron vistos o descargados en menos de un tercio de las cuentas afectadas —aproximadamente 1.650—, aunque el acceso no autorizado ocurrió en todas ellas. Lo que impidió que fuera mucho peor: el hecho de que la brecha se detectó y detuvo. Lo que la hizo posible: que ninguna de las 5.000 cuentas comprometidas tenía la autenticación multifactor activada.
El fallo estaba en la costura entre dos sistemas, no en ninguno de los dos por separado. La integración entre Lenovo ID y Dropbox era lo que los técnicos llaman una integración heredada —un sistema que nadie había revisado en años porque seguía funcionando— y había sido construida con supuestos de seguridad que en el momento del ataque ya no eran suficientes. Lenovo identificó la integración en su lado y confirmó que sus propios clientes no se vieron afectados. Dropbox terminó inmediatamente todas las sesiones autenticadas a través de Lenovo ID, desactivó la integración por completo, y ahora exige contraseña nativa de Dropbox para cualquier acceso.
¿Por qué la ausencia de MFA fue determinante?
La brecha explotaba un bypass de contraseña: el fallo en la verificación de propiedad del correo electrónico en la integración Lenovo-Dropbox significaba que el atacante podía acceder sin necesitar la contraseña de la víctima. En un sistema con autenticación multifactor activada, incluso si el atacante evita la contraseña, seguiría necesitando el segundo factor —una aplicación de autenticación, un SMS, una llave física— para completar el acceso. Ninguna de las 5.000 cuentas comprometidas lo tenía.
La autenticación en dos pasos es la barrera de seguridad gratuita que el 90% de los usuarios no activa. El patrón se repite en prácticamente todos los incidentes de compromiso de cuentas: el MFA habría bloqueado el acceso. No es garantía absoluta —existen técnicas de phishing AiTM que capturan tokens de sesión—, pero habría convertido este ataque específico en inviable con las herramientas usadas.
La ventana de 17 días entre el inicio del ataque (4 de agosto) y su detección (21 de agosto) es el otro dato que debería llamar la atención. El acceso no fue detectado en tiempo real por los sistemas de monitorización de ninguna de las dos plataformas, sino descubierto en una investigación posterior. El tiempo en que un atacante puede moverse sin ser detectado dentro de un sistema comprometido es uno de los indicadores más relevantes de la madurez de seguridad operativa.
En 2022, trabajadores de Dropbox fueron víctimas de un ataque de phishing que comprometió código privado en GitHub. En aquella ocasión, Dropbox respondió adoptando WebAuthn y tokens de hardware para todos los accesos a su entorno de desarrollo. El incidente de agosto de 2026 es diferente: no afectó a los sistemas internos sino a usuarios finales, y no fue consecuencia de un ataque de phishing sino de una integración SSO que no verificaba correctamente la identidad.
El patrón de las integraciones SSO heredadas
Este tipo de brechas tiene un denominador común que cualquier empresa que use integraciones de inicio de sesión único debería reconocer: las integraciones SSO acumulan silenciosamente sin que nadie las revise ni las retire cuando dejan de ser necesarias. Cada integración que sigue activa es una superficie de ataque adicional que no depende de la contraseña de la cuenta y que a menudo se basa en supuestos de seguridad del momento en que fue construida.
La palabra «heredada» en las explicaciones de ambas compañías hace un trabajo significativo. En la práctica, describe un sistema que seguía corriendo porque apagarlo podría romper algo —aunque nadie en el equipo actual recuerde exactamente para qué servía o cuántos usuarios lo usaban activamente. El problema de las integraciones legacy no es técnico sino organizativo: los inventarios de integraciones activas se degradan con el tiempo, y lo que debería ser una auditoría trimestral acaba siendo algo que nadie hace hasta que hay un incidente.
Ambas compañías han notificado el incidente a los reguladores de protección de datos. Para los usuarios europeos, eso activa las obligaciones de notificación del RGPD, incluido el plazo de 72 horas que aplica una vez que la organización tiene conocimiento de una brecha cualificada. Los servicios de almacenamiento en la nube —Google Drive, OneDrive, Dropbox, iCloud— contienen archivos personales, fotos y documentos con acceso centralizado que los convierte en objetivo preferente. La recomendación práctica que surge de este incidente: revisar ahora mismo qué aplicaciones de terceros tienen acceso autorizado a tu cuenta de Dropbox desde Ajustes → Aplicaciones conectadas, y revocar todo lo que no reconoces.
En wwwhatsnew.com llevamos años recomendando la auditoría de aplicaciones conectadas en nuestras guías de seguridad para usuarios y empresas, y en nuestra experiencia editorial es uno de los pasos más ignorados de mantenimiento de seguridad. La mayoría de los usuarios no saben cuántas aplicaciones tienen acceso a su cuenta de Dropbox hasta que hacen esa comprobación. En muchos casos el número supera la decena: herramientas de productividad conectadas en 2019, integraciones de trabajo de proyectos cerrados, aplicaciones de terceros para editores que pidieron acceso en su momento y nunca se revocaron.
El modelo de la auditoría de integraciones activas como práctica de seguridad tiene un paralelo importante en el mundo empresarial: la gestión de identidad y acceso (IAM) en entornos corporativos debería incluir revisiones periódicas de todas las aplicaciones que tienen acceso OAuth a los sistemas centrales, con flujos automatizados de revocación cuando un empleado abandona la empresa o cuando una integración lleva más de un año sin actividad registrada. El caso Dropbox-Lenovo demuestra que una integración que nadie revisó durante años puede convertirse en vector de ataque sin que ningún sistema de monitorización lo detecte durante 17 días.
☞ El artículo completo original de Natalia Polo lo puedes ver aquí
No hay comentarios.:
Publicar un comentario