La verdad es que mola ver cómo el servicio Latch que creamos hace años ha crecido tanto. A punto de celebrar el millón de usuarios del mismo, seguimos evolucionándolo, y dentro de no mucho (¡ojo equipo que os vigilo el project plan!), tendrá nuevas capacidades que espero que pronto os pueda contar, basadas en una "IdeaLoca" de hace tiempo que vamos a poner en producción.
Tienes esta información en la parte de Tutoriales, que tienes en la caja superior del interfaz cuando entras en la sección de TOTP, además de tener una serie de asistentes en la parte final. Pero si entras en la sección de tutoriales, verás como tienes el paso a paso descrito para configurar TOTP en Amazon, Wordpress, Facebook, GitHub, etc...
Los tutoriales son paso a paso con capturas, y explicaciones que te van guiando para tener un 2FA que te fortifique todas y cada una de las cuentas que tengas en estos servicios digitales.
En ellas verás también una modernización del estilo del interfaz, que después de tanto tiempo hemos querido hacerle una actualización a las nuevas tendencias de diseño de apps. Esperamos que os guste.
Me ha gustado mucho el trabajo de DoubleDrive, presentado por el investigador Or Yair (@oryair1999) en la presente BlackHat USA 2023, en el que ha explicado cómo se puede convertir al proceso de OneDrive en tu equipo en un agente doble que trabaje para un Ransomware y cifre todos los archivos de tu equipo. Una idea que ya hemos explorado nosotros en el pasado con RansomCloud, pero que aquí utiliza una aproximación diferente, y me ha encantado.
Figura 1: DobuleDrive. Cómo OneDrive se puede convertir en un Agente Doble
y trabajar para un Ransomware
Antes de contaros un poco sobre la investigación, dejadme hacer una pequeña introducción a lo que nosotros construimos y exploramos en hace ya unos años.
Ransomcloud O365
Cuando en el año 2016 nosotros creamos Sappo para robar tokens OAuth de servicios como Google, Office 365 o OneDrive, uno de los escenarios que exploramos fue el de crear un Ransomware que cifrara todo tu contenido en la nube. Que cifrara tus archivos de OneDrive en la nube, que cifrara tus correos electrónicos de Office365, que te dejara sin ningún contenido del que disponías.
De este ataque, Kevin Mitnick, que lo utilizó en muchas de sus conferencias, hizo vídeos explicando el proceso donde lo dejaba bastante claro. El objetivo, tan sencillo como cifrar el contenido que hubiera en la nube, y que se sincronice con lo que haya en local. Listo.
DoubleDrive OneDrive
La idea con el ataque de DoubleDrive, presentado por Or Yamir, es un poco diferente, aunque tiene similitudes con nuestro ataque. En este caso se trata de cómo un Ransomware puede evitar ser detectado por medio de patrones de comportamiento, que es lo que utilizan muchos de los agentes EDR(Endpoint Detection and Response) que protegen al sistema operativo contra procesos maliciosos que generan actividad típica de un ransomware.
Lo que la investigación predice es que este tipo de técnicas pueden ser utilizadas dentro de poco por Malware Moderno ( y basta con leerse el libro de Sergio de los Santos para tener claro que lo harán), con el objetivo de evitar la detección. En este caso, la idea es utilizar el agente de OneDrive en el sistema operativo para hacer todo este trabajo de cifrar el contenido y eliminar los archivos originales. ¿Por qué?
Figura 5: Un Ransomware que usa OneDrive para cifrar y borrar archivos
Pues tan sencillo como que el agente de OneDrive en el sistema operativo está en las listas blancas de los EDR ya que su función es copiar, cambiar, borrar, archivos y carpetas del sistema operativo masivamente. Así que todos los EDR lo ponen en listas blancas.
Figura 6: Arquitectura del ataque de DoubleDrive.
Explicación a continuación.
Dicho esto, lo que hay que hacer es conseguir configurar OneDrive para que sincronice todos los archivos que se quieren cifrar en una cuenta de OneDrive en la nube. Es decir, configuramos OneDrive para que sincronice los archivos de local con una copia en OneDrive, y hacer que la copia de OneDrive esté cifrada, y machaque la copia local. Esta es la parte que se parece a nuestro ataque, ya que nosotros ciframos los archivos que ya están en OneDrive y en Office365.
Lo que la diferencia es que el ataque de DoubleDrive busca hacer la sincronización desde local con la nube de los archivos que quiere cifrar, así que es un ataque que se produce en el sistema operativo por un programa malicioso que corre en local.
Figura 8: Se hace login de OneDrive con una cuenta controlada por el atacante
Para ello, plantea varias estrategias para lograr esa sincronización. La primera, y más sencilla, es configurar la cuenta a la que se conecta el agente de OneDrive en local con una cuenta de OneDrive en la nube controlada por el atacante. Se configuran las carpetas a sincronizar, y según el proceso de OneDrive va subiendo los archivos, se cifran en la nube, y el miso agente de OneDrive en local los va machacando, saltándose cualquier EDR en el sistema operativo.
Figura 9: Se roba el token de acceso de la cuenta de OneDrive que se usa en local
La segunda estrategia consiste en conseguir acceso a la cuenta actual del propio OneDrive que está corriendo en local. Para lo que consigue el token de acceso (autorizado previamente), desde el fichero del log de OneDrive, que son los ficheros .odl, que son unos binarios donde el Token de Acceso está ofuscado, pero que con una herramienta escrita en Python, que ha publicado en GitHub, se puede desofuscar y extraer.
También se puede extraer ese Token de Acceso haciendo un volcado de la memoria del proceso de OneDrive, que es bastante sencillo de ejecutar, tal y como ha explicado en las diapositivas de la presentación que ha utilizado.
Figura 11: Robo de tokens con volcado de memoria
Una vez que se tiene el Token de Acceso, para automatizar el proceso del Ransomware, ha publicado la herramienta OneDrive DoubleDrive que utiliza el Token de Acceso, y la lista de ficheros a cifrar, para realizar el proceso de vincular la copia local con la copia en la nube usando OneDrive y hacer el cifrado de los archivos en el almacén en la nube, que será sincronizado después en local.
Al final, esta técnica lo que busca es que los archivos en local queden cifrados como un Ransomware, saltándose las protecciones de los EDR utilizando el agente de OneDrive, mientras que en Ransomcloud, lo que buscamos es cifrar el contenido almacenado en la nube, robando un Token OAuth que nos permita controlar todo el servicio en la nube. Esta estrategia de usar agentes como OneDrive, Dropbox y similares, es muy común en los equipos del Red Team.
Microsoft ha actualizado el agente de OneDrive, para eliminar el almacenamiento de los tokens en los ficheros log, pero el agente necesita seguir utilizando en memoria dicho token. Eso si, realizar un volcado de memoria de un proceso es una acción que los EDR pueden detectar con más facilidad como un comportamiento negativo. Eso sí, me gustaría verlo en acción contra nuestro Latch ARW.
Desde que lanzamos la característica de Latch Cloud TOTP hemos ido sacando algunos tutoriales y vídeo tutoriales para configurar las protecciones de Verificación en Dos Pasos con TOTP utilizando Latch. En el post de hoy os recojo todos los que hemos publicado hasta ahora en el blog de ElevenPaths, en El lado del mal o en Seguridad Apple.
Figura 1: Vídeo tutoriales de configuración de Latch Cloud TOTP
Por supuesto, si tienes dudas y quieres saber cómo se utiliza Latch, o configurarlo en algún sitio ya sea la protección de Latch o de Latch Cloud TOTP, en la Comunidad de ElevenPaths - donde somos ya casi 800 personas - puedes consultar cualquier duda. En los enlaces debajo de los vídeos están los artículos - si los hay - con el paso a paso de configuración.
Cuando hablamos de un Segundo Factor de Autenticación, los tokens TOTP (Time One-Time Password) son unos de los más populares. Servicios tan populares como Google, Microsoft, Dropbox o Facebook tienen la posibilidad de configurar una protección extra de la cuenta añadiendo una verificación del código TOTP que el usuario tiene configurado. Hoy os quiero hablar de Latch Cloud TOTP que es otra de las novedades de las que hablamos en el pasado Security Innovation Day 2016 y de cuáles son los detalles y el pensamiento que nos ha llevado a crearlo. Que nadie piense que esto es un "combate" ni nada parecido a ver qué solución es mejor, sino solo una explicación de cuáles son los detalles que de Google Authenticator que nos hicieron crear Latch Cloud TOTP.
Figura 1: Latch Cloud TOTP vs. Google Authenticator
La idea del TOTP es tan sencilla como que un algoritmo, con la misma semilla de parametrización, genera en el lado del servidor y en el lado del cliente un código dependiente del tiempo. Es decir, en el lado del servidor y en el lado del cliente, cada cierto tiempo, se genera el mismo número - el mismo token -. Cuando un usuario va a realizar un proceso de login, primero debe proveer correctamente el usuario y la contraseña, y después de que se verifique que esta es correcta, se debe proporcionar el valor TOTP correcto.
Figura 2: Demo de Latch Cloud TOTP en Dropbox con Latch para iPhone y Lath para Apple Watch
La herramienta más popular para gestionar los tokensTOTP es Google Authenticator, y es válida para usar en servicios como Google, Microsoft, Dropbox o Facebook. Basta con configurar esta protección en tu cuenta y utilizar Google Authenticator para capturar el código QR que transmite la semilla al algoritmo TOTP que generará el código TOTP constantemente.
TOTP en Google Authenticator
Durante mucho tiempo hemos estado jugando con los códigos TOTP de Google Authenticator, y hemos estado haciendo muchas pruebas que paso a contaros, porque creo que son relevantes para entender por qué decidimos hacer un Cloud TOTP en Latch.
1) No garantiza un único dispositivo:Cuando estás configurando un código TOTP en el cliente de Google Authenticator u otro similar, realmente al servidor no se le avisa de en cuantas apps se ha capturado la semilla. Es decir, podrías generar en la misma app de Google Authenticator 4 entradas con la misma semilla y al mismo tiempo copiar en cuatro dispositivos con Google Authenticator la misma semilla, y al mismo tiempo en otras apps.
2) La semilla se podía robar del backup: Antiguamente, cuando se hacía un backup del sistema operativo, de este se podían sacar los ficheros de las semillas y conseguir regenerar el algoritmo correcto para tener los TOTP en cualquier otro dispositivo. Esto tenía un lado positivo y un lado negativo.
El lado positivo es que podrías migrar de tu iPhone 6 a tu iPhone 6S todo un backup, y las entradas de Google Authenticator seguían intactas, lo que era una ventaja si se te había perdido el terminal o te lo habían robado, por lo que si tenías el backup podrías recuperar tu Google Authenticator con todas las entradas.
El lado negativo es que alguien podría extraer del backup tus ficheros de Google Authenticator y recrear en una app controlada por él tus valores y tener los TOTPs de todas tus cuentas. Además, para que este ataque fuera un poco más sencillo, se unen dos debilidades que pueden aprovecharse que os describo en los puntos 3 y 4.
3) En Google Authenticator se indica el usuario: En cualquiera de las entradas de los TOTP se puede leer con claridad la cuenta de correo a la que está asociada esa entrada TOTP, lo que pone bastante fácil saber a quién hay que robarle la contraseña. De hecho, lo más fácil era hacerse con el backup de Google Authenticator, ver cuáles eran las semillas de los algoritmos TOTP que se habían robado, y hacerles un ataque de phishing a esos para robarles el último factor que hacía falta - la password -.
Figura 4: En cualquier Google Authenticator se ven los tokens TOTP y los usuarios
4) En Google no implementan correctamente las alertas TOTP: Como ya he dicho en otras ocasiones, si te roban la password en Google y entran en tu cuenta, saltaría la verificación del token TOTP, pero no queda ninguna alerta de seguridad en el log si no se intenta poner ningún token, por lo que al atacante no se le detecta a la primera. En el caso de Microsoft, esto se implementa mejor.
Figura 5: En el log de Google no queda que se ha puesto correctamente la password y no se ha introducido ningún token TOTP durante la verificación en dos pasos.
5) Ahora no migra de un terminal a otro: Para fortificar las semillas, en Google Authenticator ahora, estas se cifran en el keychain con una clave del dispositivo, por lo que es posible recuperar las semillas si y solo si es en el mismo dispositivo. Esto es un problema serio si has perdido el terminal, porque entonces solo te salvarán las Recovery Keys que se obtienen cuando se configura la protección TOTP o si tienes también puesto el número de teléfono, por el SMS (lo que vuelve a convertir el SMS en el primer factor de autenticación). Dependiendo del servicio, se podrían utilizar otros mecanismos como en el caso de Google que se permiten las llaves, los click-OK o los códigos impresos, pero no es lo habitual para todos los servicios protegidos con servicios TOTP, ni además son muy populares en su uso.
6) No protección local de Google Authenticator: En Google Authenticator, si alguien tiene acceso al terminal y abre la app, puede ver los valores de los tokens y a qué cuentas pertenecen porque no hay forma de ponerle una password a nivel de aplicación, tal y como se ve en la Figura 4.
Cloud TOTP en Latch
Sabiendo cómo funciona bien Google Authenticator, decidimos hacer una implementación que funcionara de manera distinta usando Latch a la que hemos llamado Cloud TOTP, que tiene las siguientes características:
1) Asociada a tu cuenta Latch: Cuando se pone un token TOTP en Google Authenticator, este se almacena en uno o varios dispositivos y - ahora - no puede salir de ahí, pero al servidor no se le garantiza ni que se haya puesto en un terminal concreto ni que se haya puesto solo en uno. En este caso, cambiamos el paradigma y lo ponemos en una cuenta de Latch que puede ser abierta en cualquier dispositivo móvil siempre que tengas tu cuenta de Latch (no asociada a tu cuenta protegida con el token TOTP)
2) Sin identificar nombre de cuenta asociada: Aunque en la primera versión utilizamos el mismo funcionamiento de Google Authenticator y mostrabamos la cuenta de usuario, hemos decidido que se pueda renombrar durante el proceso de configuración y después, para que en lugar de poner micuenta@google.com pueda poner algo genérico como "Mi cuenta de Google" o "Mi cuenta de Dropbox", con lo que se disasocia en Latch Cloud TOTP el valor del token del valor de la cuenta y del valor de la contraseña.
Figura 6: El token no se muestra hasta que no se solicita. Queda en el log
3) Con log de acceso al código: Hemos decidido que en Latch Cloud TOTP, el valor del token no se muestre nada más que durante un instante. Para eso el token TOTP de cualquier semilla estará oculto y se deberá solicitar su muestra. Esto implica que se generará una entrada en el log de Latch que el usuario podrá consultar en el futuro para saber si desde esa app, en un momento concreto, se mostró o no se mostró el código TOTP. No evita las malas implementaciones del servidor, pero sí que permite guardar información que podría ser útil en un posible análisis de logs cruzado con los datos del servidor.
4) Protección de acceso local a Latch: Además de que el código TOTP de una cuenta no se muestra por defecto y debe solicitarse manualemente, dejando un rastro en el log, la app de Latch tiene dos protecciones: Una primera la autenticación contra el servidor, y una segunda la autenticación a nivel de app (integrada con Touch ID en iPhone e iOS). Esto hace que, aunque se tenga el terminal desbloqueado en un descuido, no se pueda acceder a ella sin poner la password o pasar una autenticación biométrica vía Touch ID.
Con esta aproximación de Latch Cloud TOTP lo que hemos buscado es cubrir un hueco en el uso de tokens TOTP. Dotamos al sistema de una mayor flexibilidad al permitir que los tokens se puedan recuperar desde cualquier dispositivo, y añadimos mayores opciones de seguridad en aspectos como el acceso local vía descuido, la asociación de token TOTP a nombre de cuenta o el control de los tokens TOTP que se entregan, ya que no es un proceso continuo sino discreto bajo demanda que deja rastro en el log.
Figura 8: Cloud TOTP y Latches en la misma app de seguridad
Ahora está disponible en la nueva versión de Latch para Android, y en breve estará disponible en la nueva versión de Latch para iOS. Poco a poco os iré contando por aquí como sacarle provecho a todas las características de este Cloud TOTP en diferentes servicios y entornos. Y lo mejor es que puedes tener en una sola app tanto tus tokensTOTP como tus cuentas protegidas por Latch.
Ya se ha terminado el plazo para presentarse al Concurso de Plugins para Latch y en breve daremos los nombre de los ganadores que se van a llevar los premios, además de la lista completa de los trabajos que nos han enviado. Algunos de ellos son muy curiosos y nos han sorprendido por su originalidad, así que habrá más sitios en los que integrar Latch. Mientras acabamos las deliberaciones sobre el concurso, desde el equipo de desarrollo de Eleven Paths os hemos traído una nueva integración de la plataforma. En este caso se trata de una integración de Latch para el servicio de creación de nubes privadas OwnCloud.
Figura 1: Tu nube privada con OwnCloud y protegida con Latch
Esta tecnología permite crear una nube privada para el almacenamiento de ficheros, tipo DropBox, que puedes montar en tu propia empresa o incluso en tu casa. Tiene un acceso vía Web, WebDav y API lo que permite que accedas desde el navegador Web, desde el propio explorador de archivos y por supuesto desde cualquier app que construyas para la gestión de tu empresa y que se conecte vía API. En el siguiente vídeo tenéis las características que tiene la última versión.
Figura 2: Características de la última versión de OwnCloud
Paso 1: Instalación del plugin de Latch en OwnCloud
Nosotros hemos integrado Latch como una app en el acceso a OwnCloud por lo que en primer lugar para poner Latch en cualquier instalación de OwnCloud hay que descargar el plugin desde su repositorio en el GitHub de Eleven Paths: Plugin de Latch para OwnCloud.
Una vez obtenido, la carpeta descomprimida del plugin de Latch para OwnCloud debe ser copiada a la ruta de apps de OwnCloud.
Figura 4: Copia del plugin de Latch para OwnCloud en la carpeta de apps de OwnCloud
En la imagen anterior se puede ver cómo, en una instalación por defecto de OwnCloud, la ruta es owncloud\apps. Copia toda la carpeta y déjala allí.
Paso 2: Creación de la app de Latch para tu instalación de OwnCloud
El proceso de integración de cualquier sistema precisa de una conexión entre la plataforma a proteger y el servidor de Latch. Para ello hay que entrar con una cuenta de developer y dar de alta la aplicación. Para ello necesitas ir a la zona de developer de la web de Latch y crear una aplicación. De esta forma obtienes el ApplicationID y el Secret necesarios para configurar el plugin.
Figura 5: Creación de la app en la web de developers de Latch
Paso 3: Configuración el Plugin de Latch en OwnCloud
El siguiente paso es añadir Latch Authentication Plugin a OwnCloud. Para ello, desde el panel de administración de OwnCloud se debe ir a la sección Apps y seleccionar añadir una app al sistema, seleccionar Latch Authentication Plugin que aparecerá como una app disponible y activarla.
Figura 6: Añadir Latch Authentication Plugin a OwnCloud
Para que el plugin esté funcionando es necesario configurar el ApplicationID y el Secret que obtuvimos al crear la app en la Zona de developer de Latch en el panel de administración de la app, tal y como se ve en la imagen siguiente.
Figura 7: Configuración de Latch Authentication Plugin en OwnCloud
Paso 4: Proteger las cuentas de usuario con Latch
A partir de ese instante, cada usuario, en la zona de configuración de su perfil de OwnCloud, podrá parear Latch con su cuenta de OwnCloud y controlar si quiere que el acceso esté disponible o no desde la app del móvil.
Figura 8: Proceso de pareado de un cuenta de Latch
El proceso de pareado y despareado con Latch es el estándar, se solicita el token en el terminal y se introduce en la zona de configuración de Latch en el perfil de usuario de OwnCloud, tal y como se ven en la imagen siguiente.
Figura 9: Configuración de pareado de una cuenta de usuario de OwnCloud con Latch
Consideraciones finales del plugin
Este plugin almacena los datos del plugin (ApplicationID y Secret) y de las cuentas pareadas (AccountID) en dos tablas que el administrador del sistema puede consultar fácilmente, tal y como se explica en el blog de Eleven Paths.
Ayer domingo, antes de acostarme decidí jugar un poco con Path 5, nuestro Big Data de apps de Android, para probar una serie de cosas que están rondando por mi cabeza. Como sabéis, en nuestra plataforma guardamos las apps y el entorno de publicación de las mismas para poder analizarlas a golpe de clics y poder realizar búsquedas o filtros que avisen cuando alguna app coincida con el patrón de búsqueda. Una vez que se genera esa lista de apps mediante un RSS, se puede automatizar su post-procesado con paneles de control realizados por Sinfonier, por scripts automáticos que decidan que apps deben ser analizadas con alguna otra plataforma de análisis de malware o directamente que llegue a un equipo HUMINT que revise las apps más sospechosas.
Figura 1: En los enlaces de apps de Android puede salir de todo
Entre las características por las que se pueden realizar búsquedas, están los enlaces o links, que aparecen en la app. Esta función permite localizar, entre otras cosas, cuando una app que aparentemente no tiene nada que ver con tu empresa, tiene enlaces a ella, que puedan estar usándose para hacer phishing y tomar imágenes de la web haciendo hotlinking, o simplemente para abusar de alguna función de los servicios expuestos. A nosotros, nos vino bien para descubrir la infraestructura completa de Shuabang Botnet.
Un vistazo rápido a enlaces en las apps de Android
Esta característica de buscar por enlaces de forma rápida y filtrada, nos permite, mediante los servicios de Vigilancia Digital, avisar cuando una nueva app está haciendo algo extraño y no controlado por el equipo de seguridad o de canales electrónicos de la empresa, pero también para detectar familias de adware que hacen uso de los mismos servicios para apuntarse dinero o, por ejemplo, hacer suscripciones ilícitas a servicios SMS de pago o similares como se hizo en la estafa de la linterna molona.
Figura 3: Apps con enlaces a cuentas de usuario de Dropbox
Como ayer era domingo, decidí perder un poco el tiempo a ver qué cosas era la gente capaz de poner en las apps que están publicadas en Google Play a día de hoy, probando cadenas que no deberían estar nunca en una app, pero que comprobado que incluso ponen sus Tokens de autenticación hardcodeados, podrían sorprenderme.
Figura 4: App con un enlace a un servidor local
Por supuesto, el número de enlaces a localhost, o a direcciones internas de la red exponiendo la infraestructura de la empresa es altísimo. Son muchas las que hacen eso a pesar de que todas las prácticas de desarrollo seguro de Android explican claramente que no deberían.
Figura 5: Enlaces remotos para cargar las API Keys
Entre las cosas que me dio por mirar, estaban los enlaces a Dropbox, para ver qué uso estaba dando la gente de este servicio. Curiosamente, muchas, y cuando digo muchas son muchas apps, están cargando sus configuraciones, API Keys, y datos desde ubicaciones públicas en DropBox.
Figura 6: Otro enlace remoto para cargar API Keys
En lugar de hacer un servicio en sus servidores y utilizarlo, ponen un archivo publicado en una carpeta de Dropbox y lo van actualizando.
Figura 7: Un enlace a la password de Gmail en Dropbox
Mirando lo que la gente pone en Dropbox para alimentar sus apps, aparecen las API Keys de servicios, pero uno incluso pone un fichero con la contraseña de una cuenta de Gmail que está utilizando para hacer notificaciones Push según parece, lo que no deja de ser un fallo de seguridad bastante peculiar.
Figura 8: El Fichero con la passwod. Comienza por Money... }:)
Algunas apps, hasta enlazan ficheros user.txt con cuentas de acceso que pueden utilizarse. Tal y como se ve, tienen datos de usuarios de QA y de pruebas, con ninguna complicación en las contraseñas.
Figura 9: Lista de usuarios cargado desde un txt remoto
De todos los enlaces curiosos que encontré, hubo uno que se dedica a mostrar gente que ha sido vista por otras personas en la calle para poder saber quién es. La idea es sencilla, alguien ve a alguien y sube los datos de quién lo ha visto, cuándo y dónde, para que el resto de usuarios puedan darle información correcta de esa persona. Pues bien, la base de datos de esa app es un fichero subido a una cuenta de Dropbox.
Figura 10: Una base de datos en txt publicada en Dropbox. El fichero es muy largo.
Esto de tener la base de datos de la app enlazada no es raro, y de hecho algunas apps tienen ficheros en formato Sqlite con la base de datos que está usando la app enlazada remotamente para que se cargue en periodo de ejecución, y que cualquiera puede descargar de Internet.
Figura 11: Enlaces a base de datos de app en formato Sqlite
Si vas a hacer una app para Android, recuerda que los enlaces es algo que todo investigador va a analizar, así que ten cuidado con qué expones en ellos, ya que lo que pongas ahí será público.
Hoy la noticia es Poodle, la nueva vulnerabilidad en SSL localizada en sslv3 que permite, usando un padding, descifrar una sesión SSL con un JavaScript inyectado en cliente, pero yo quería hablaros del supuesto hackeo de las cuentas de Dropbox, ya que tiene tintes de ser una historia en la que los media se han dejado llevar por la emoción y las cosas se han ido de madre.
Figura 1: ¿400 o 7 Millones de identidades de Dropbox?
Cronología del Buzz
Ayer por la mañana leí muy temprano la primera noticia sobre la filtración de Cientos de cuentas de Dropbox, pero ya había decido que en mi artículo diario iba a hablar de Reflected File Download, así que lo marqué en mi RSS para leer más tarde.
Pasaron unas horas en las que estuve trabajando en otras cosas y me olvidé un poco del asunto. En medio de una reunión en Eleven Paths un compañero me dijo... "¿Has visto lo de las identidades de Dropbox?". "Sí, han filtrado unos cientos de ellas, parece que ha sido como lo de Snapchat por una app de terceros", contesté. "No, no, dicen que se han filtrado 7 millones."
Figura 2: Titulares sobre la filtración
En ese momento flipé, miré noticias en Internet y es verdad la mayoría de los medios hablaban en sus titulares de casi 7 Millones de identidades filtradas.
Buscando la fuente
Con más calma, por la noche, me dediqué a buscar por Internet la fuente de la filtración, y resulta que es un pastebin en el que hay 400 identidades de Dropbox con usuarios y contraseñas. Eso sí, la nota dice que tiene casi 7 Millones de cuentas en su poder y que según reciba pagos en BitCoins irá liberando más, para lo que deja su cuenta. Cuando más dinero gane más filtrará, dice.
Figura 3: El pastebin con las identidades de Dropbox
Ese volumen de identidades filtradas hubiera sido la segunda filtración más grande en Have I been Pwned?, donde solo la filtración de Adobe supera esa cantidad de cuentas. A día de hoy no se han filtrado, por supuesto, así que asumo que no ha cobrado lo suficiente por ahora.
Figura 4: El post de Dropbox contestando a la supuesta filtración
Lo más curioso es que, en una actualización, ellos mismos confirman que las cuentas filtradas no funcionan porque estaban expiradas, así que parece que es una situación similar a las de las cuentas de Gmail, que podrían haber sido robadas con malware o con una app maliciosa.
Figura 5: Actualización confirmando que las nuevas filtraciones eran falss
Aún así, apareció por Internet una nueva remesa de cuentas de Dropbox, pero parece que eran un autentico fake, tal y como ponen en su post.
Pon un segundo factor de autenticación en Dropbox
El mensaje al final de toda esta historia es, además de ten cuidado con leer solo los titulares, que no debes preocuparte por esta filtración, sino por todas tus identidades. Pon un segundo factor de autenticación a todas las que puedas, tal y como dice también el post de Dropbox.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
