Si un atacante tiene acceso a tu cuenta... ¿Qué no te gustaría que pudiera hacer? ¿Te gustaría poder bloquearle acciones?

Hoy quería responderos a esta pregunta que he puesto en el título. Imagina que un atacante tiene acceso a tu cuenta. Ha conseguido acceder a tu correo electrónico, a tu cuenta del banco, a tu cuenta de la empresa, a tu cuenta de Facebook o de Instagram. Ha conseguido acceder a tu ERP o a tu CRM. Piensa en ello. Lo ha conseguido porque te ha hecho un Session Hijacking, ha conseguido tus credenciales con un malware, o te ha robado un Token OAuth. O simplemente ha encontrado un bug en el código de la aplicación que ha conseguido explotar y tiene acceso a toda tu cuenta.

Figura 1: Si un atacante tiene acceso a tu cuenta... ¿Qué no te gustaría

que pudiera hacer? ¿Te gustaría poder bloquearle acciones?

Imagínatelo por un instante. Imagínatelo delante de tu cuenta bancaria, con acceso tu cuenta. Delante de tu cuenta de la empresa. Delante de tu correo electrónico. Piensa en ello. ¿Te da un escalofrío? Imagínatelo delante de tu cuenta de almacenamiento de fotos. Delante de tu iCloud. De tu Google Drive viendo tranquilamente una tras otra todas tus fotos. O todos tus documentos. O todos los mensajes que has enviado y recibido por Instagram.

Seguro que te da mal rollo. 

Y es que, si tenemos toda la protección basada en un el sistema de Login, en la autenticación de la cuenta, estamos perdidos cuando llega una de esas situaciones. Cuando alguien consigue saltarse esa protección todo el sistema de privacidad se cae abajo.

Por eso inventamos Latch.

Por eso creamos un canal paralelo de autenticación que protege todos los datos y todas las acciones aún cuando un atacante se haya hecho con tus credenciales, con una cookie de sesión, o con un token OAuth de tu plataforma. Gracias que con Latch tienes un 2nd Factor Authorization puedes cerrar determinadas capacidades de tu cuenta aún cuando alguien esté dentro de ella.

La idea es tan sencilla como que mires tu aplicación o servicio y analices justo lo que dice el título de esta entrada: Si una atacante tiene un acceso a tu cuenta, ¿qué no te gustaría que pudiera ver, acceder, hacer, ejecutar? Y a cada una de esas cosas, le pones un Latch. Tan sencillo como eso.

Figura 2: Gestión de Pestillos en cuentas

Imagina que tienes una cuenta de administración de una servicio de gestión de una empresa en el que te autenticas con Login/Password y un Second Factor Authentication (que puedes ser un TOTP o un SMS-OTP, o incluso un Latch). 

Una vez que pases el proceso de autenticación te encuentras con todas las opciones del menú, y entre ellas tienes que pensar cuáles son las que no te gustaría que tuviera acceso un atacante si tuviera acceso a tu cuenta. Por ejemplo, te hago esta lista:

• No me gustaría que pudiera borrar la cuenta.

• No me gustaría que pudiera editar mi perfil.

• No me gustaría que pudiera mandar mensaje en mi nombre.

• No me gustaría que pudiera eliminar mis mensajes.

• No me gustaría que pudiera hacer transferencias de dinero.

• No me gustaría que pudiera acceder a mis mensajes.

Lo que quieras. Y luego decides qué pestillos configuras para cada una de esas acciones. Nosotros, por ejemplo, en el proyecto de WordPress in Paranoid Mode que luego portamos a Joomla! también, definíamos esas acciones y las agrupábamos en tres modos. Hicimos tres pestillos (que se llaman operaciones) dentro de un Latch, así que cuando tenías una cuenta de WordPress, la pareabas con tu cuenta de Latch, y tenías tres operaciones dentro de Latch que eran Modo Read-Only, Modo Edición y Modo Administración.

Figura 3: Un Latch con tres Operaciones en forma de pestillos

Así, independientemente de que una cuenta fuera el Administrador del WordPress - ya sea legítimamente o por haber conseguido acceso de manera ilegítima -, cada vez que se iba a realizar una operación dentro de una tabla de WordPress se miraba si esa operación era de Edición o Administración y si era así, se comprobaba el estado del pestillo de Edición o Administración. Si está cerrado, se bloquea la operación y listo. Así, aunque te roben tus cuentas de WordPress, tu plataforma está segura contra modificaciones o accesos no deseados.

Figura 4: Presentación de My WordPress in Paranoid Mode

Si has hecho una plataforma para gestión de lo que sea, piensa en eso. Piensa en qué zonas de la cuenta de tu usuario no te gustaría que una persona con acceso ilegal a una cuenta pudiera tocar. Y pon un pestillo en ellas. Así, el dueño legítimo de la cuenta, que tiene control de sus pestillos desde el canal de Latch, siempre puede tenerlos cerrados hasta que vaya a hacer uso de esa capacidad y él conscientemente abra el pestillo.

Figura 5: Operación de Latch para proteger la función de eliminación del pestillo

Por ejemplo, en MyPublicInbox integramos Latch, y la operación de Desparear Latch, está protegida. Sólo si el pestillo de Latch está abierto se puede desparear, como se puede ver en la imagen anterior, y seguimos haciendo más operaciones para proteger más partes de tu cuenta con nuevas operaciones. Para esto, Latch es único, porque te ayuda a evitar que un atacante pueda acceder a tu privacidad, tus datos, tu información, tus funciones, incluso si te han robado el acceso a tu cuenta. 

Figura 6: Cómo integrar Latch en aplicaciones .NET

Si quieres saber cómo funcionan estas operaciones en Latch, te recomiendo que te veas un Webinar de cómo configurar Operaciones en Latch. Aquí tienes uno que te explica cómo integrar Latch en aplicaciones .NET. Tienes de más lenguajes de programación, pero son todos muy similares.

Figura 7: Contacta con nosotros y te ayudamos con la integración de Latch

Y si necesitas ayuda para implementar Latch, contacta con nosotros en Latch.tu.com y te ayudamos con el proceso de integración en tu plataforma, o en los sistemas de tu empresa. Si no tienes esta protección en tus plataformas de call-center, de ERP, de correo, de administración, de lo que sea, no te sorprendas el día que te roben una cuenta y quede todo totalmente expuesto o te hagan un destrozo completo en tu sistema.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Tu cuenta de MyPublicInbox con AppleID

Durante este tiempo, los compañeros del equipo han estado trabajando para tener la plataforma de MyPublicInbox más adaptada a los usuarios de Apple que tengan iPhone, iPad, o MacOS en su día a día de trabajo. Han estado haciendo una versión WebApp de MyPublicInbox para iOS especial, que tenga validada la UX en este sistema operativo, y ahora han añadido la posibilidad de crearse una cuenta con AppleID, y utilizarla para iniciar sesión de forma mucho más transparente.

Figura 1: Tu cuenta de MyPublicInbox con AppleID

Cuando se crea una cuenta con AppleID, el "Proveedor de Indentidad" (Identity Provider o IdP) es Apple, y eso quiere decir que él es que autentica usuarios y contraseñas, por lo que en el proveedor de identidad de MyPublicInbox no hay ningún dato de usuarios y contraseñas de esos usuarios.

Figura 2: Ahora puedes crear e iniciar sesión en MyPublicInbox

con Linkedin, GoogleID y AppleID

Cuando se crea una cuenta, o se hace login, o se recupera una contraseña, es Apple quién gestiona todos esos procesos, limitándose MyPublicInbox a preguntar si ese usuario está autenticado o no, y si le tiene que dar acceso o no a la plataforma con esa cuenta. Lo mismo que sucede si creas tu cuenta e inicias sesión co LinkedIn o GoogleID.

Figura 3: Cuando inicias sesión en MyPublicInbox con AppleID,

es Apple quién te autentica y valida tu sesión.

Por debajo todo está funcionando con Tokens OAuth de autenticación y autorización, por lo que para el usuario del ecosistema Apple es una vida más sencilla, y una forma más cómoda de gestionar su identidad al no tener que preocuparse de nuevas credenciales para MyPublicInbox.

Figura 4: Correo electrónico y configuración en WebApp iOS de MyPublicInbox

Además, como ya os he dicho, hemos hecho la WebApp de iOS para usuarios de iOS, que permite tener como una App más del sistema la cuenta de MyPublicInbox y con un clic en ella acceder a todos los servicios. Tienes en este artículo "Cómo configurar la WebApp de MyPublicInbox en iPhone & iPad". 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo crear una Campaña de Polémica en Twitter ( X ) con ChatGPT y una botnet de cuentas controladas #Tistimito

El pasado jueves, fui con Carmen Porter e Iker Jiménez al programa a Horizonte a explicar algo que para los que trabajamos en la industria de la ciberseguridad, la reputación online, o la protección de marcas personales y profesionales en las redes, conocemos desde que comenzaron las redes sociales, y que no es nada más que las guerras de opinión de los bots en dichas plataformas sociales y cualquier otro servicio de Internet, para conseguir meter presión a una persona o una empresa y conseguir un objetivo.

Figura 1: Cómo crear una Campaña de Polémica en Twitter ( X )

con ChatGPT y una botnet de cuentas controladas #Tistimito

La idea es tan sencilla como controlar un gran número de cuentas en una plataforma, ya sea Twitter (X), Instagram, Google (para darse de alta con la cuenta de Google en todas ellas o poner comentarios en cualquier lugar), Facebook, o "elige-tú-la-plataforma-o-red-donde-quieres-montar-tu-campaña", y después hacer automáticamente con un panel de control que estas cuentas hagan masivamente cosas.  Esto lo hemos visto para hacer muchas cosas malas, como el BlackSEO, o campañas de BlackASO, y por supuesto para generación de "Flames" en redes sociales.

Figura 2: "Ciberestafas: La historia de nunca acabar" por Juan Carlos Galindo en 0xWord.

Los profesionales de la reputación online conocen bien cómo funcionan estas redes de cuentas controladas se utilizan para hacer campañas de apoyo positivo, o campañas negativas, y en el mundo de las ciberestafas es una pieza fundamental para conseguir dar realismo a los engaños que se presentan a sus víctimas.

Figura 3: Comentarios falsos publicados por cuentas controladas en Youtube para

promocionar el contacto de Linda y estafar vía WhatsApp o Telegram

El funcionamiento es sencillo. Un panel de control C&C con el que se controlan las cuentas y se les dan órdenes como una Botnet que son. Estas cuentas son las que realizarán las acciones en la plataforma que sea, ya sea comentarios en Youtube - como en el ejemplo que os dejé de "Linda Fake Broker" -, o en Posts de Twitter (X), o en comentarios de una App en AppStore o Google Play para hacer una campaña de  BlackASO, o lo que quieras.

NewsBender: Crea tu polémica en Twitter X

     

Para controlar esa cuentas, pues primero hay que tenerlas creadas - ya sea por el dueño del C&C o por una persona real -, y luego controladas. Para manejar esas cuentas, es decir, para tenerlas "control"-"adas", se necesitan o bien las credenciales, o simplemente un Token OAuth. En ambos casos, puede ser controlado legítimamente, por mediante un robo de credenciales o Tokens OAuth, usando muchas de las técnicas que os he contado en no pocas ocasiones, como nuestro Sappo.

Figura 5: Herramienta para Crear Polémicas en Twitter X

En el caso de Twitter (X), que fue lo que preparamos para el programa de Horizonte, nosotros hicimos una herramienta que hacía justo eso, pero para que fuera más fácil y más entendible para las personas, utilizamos ChatGPT, en este caso GPT3.5, para que él mismo nos creara los mensajes, con un porcentaje de mensajes positivos, otro porcentaje negativos. De esto había hablado cuando hablamos de Codeproject: Newsbender para crear noticias automáticas en diarios digitales con ideologías políticas.

En nuestro caso, para la herramienta, permitimos elegir un tema, poner a quién le quieres hacer la campaña positiva, negativa, muy positiva o muy negativa, cuántos mensajes necesitas que te genere ChatGPT, y luego los publicas en las cuentas de Twitter (X) que tenemos en nuestro C&C. Para esta demo lo quisimos hacer solo con 20 cuentas de Twitter (X) que creamos especialmente para esta ocasión, y que habíamos perfilado un poco, con fotos de perfil, con mensajes, con followers y un poco de historial de interacciones.

Figura 6: Mensajes creados por la herramienta asignados a cuentas de Twitter de prueba

Luego, creamos un panel de control desde dónde se configura el tipo de Prompting - puedes verlo en la Figura 5 - que quieres hacer a ChatGPT para que las campañas sean a favor o en contra, y el nivel de intensidad. Dejando que los mensajes sean más o menos duros cuando los cree el modelo GPT. Además, la herramienta permite añadir Hashtags o generarlos automáticamente el modelo, para dar libertad de expresión al modelo o para tener una etiqueta que seguir a la hora de analizar el impacto de la campaña.

Figura 7: Demo de cómo funciona el proceso

Para dar más realismo al "Flame", permitimos que se configuren número de Posts (Tweets) totales que se van a crear y el porcentaje de ellos que van a ser contrarios a la campaña que estamos creando, para que haya debate y más "engagement" con la comunidad humana de Twitter (X). El objetivo final es generar un gran incendio en tres fases:

1.- Los bots prenden la chispa generando el ruido inicial, con debate polémico incluido, para generar efecto llamada a los humanos. 

 

2.- Las cuentas humanas que se ven atraídas hacia la polémica, toman partido y continúan expandiendo el fuego por la red. 

 

3.- El fuego salta de la red a los medios digitales, aprovechando aquellos medios de comunicación que hacen de noticias de lo que pasa en la red.

De esta forma, en el programa, que puedes ver completamente en la web, utilizando la herramienta creamos varias polémicas, una de ellas en contra de Iker Jiménez por haber entrevistado mal a un invitado ficticio que yo llamé Tistimito.

Figura 8: Creando las campañas de polémicas en Twitter (X)

El resultado es que se crearon los Posts (Tweets) de forma automática por ChatGPT, se asignaron con el mismo HashTag a diferentes cuentas de Twitter (X) controladas por el C&C y luego, con un simple botón se publican todas en la red. Puedes ver lo que sucedió en el programa, a partir del minuto 33:40

Figura 8: Polémicas en Twitter X desde el minuto 33:40

Después de eso, la gente ve los mensajes en al red social, se une al debate, azuza el fuego, y el resto es tener un Trending Topic que haga que el fuego llegue a los medios digitales, a los periódicos, informativos, e incluso que meta presión en los ejecutivos y políticos para conseguir objetivos concretos.

Figura 10: Tistimito es Tendencia en España

Pero esto no es nada nuevo, y se lleva haciendo muchos años. El objetivo era mostrar lo sencillo que es hacer esto con la llegada de los LLMs y la GenAI, donde crear los mensajes de texto, los comentarios, etcétera, es un juego de prompting.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Bugs en la Implementación OAuth de ChatGPT

Este fin de semana he estado leyendo la investigación del equipo de seguridad de Salt Security sobre la implementación OAuth de ChatGPT, y me ha parecido más que interesante los tres escenarios de ataque que han planteado por una mala implementación de OAuth en ChatGPT, utilizada para conectar plugins e identidades en su plataforma. El primero de ellos por una implementación insegura del proceso de carga de plugins en ChatGPT, el segundo en una plataforma de creación de plugins para ChatGPT y el tercero en plugins que se aprueban de una manera no robusta en ChatGPT.

Figura 1: Bugs en la Implementación OAuth de ChatGPT 

Podéis leer el trabajo completo en su blog, en el artículo titulado: "Security Flaws within ChatGPT Ecosystem Allowed Access to Accounts On Third-Party Websites and Sensitive Data", pero yo os voy a intentar resumir contar el primero de los bugs y su impacto por si os es de utilidad.

Bug 1: Instalación de Plugins Maliciosos en cuentas ChatGPT de víctimas

ChatGPT utiliza un sistema de plugins para hacer cosas, y estos plugins pueden ser maliciosos. De hecho es una de las vulnerabilidades recogidas en el OWASP TOP 10 de LLM Apps & Services, y yo hablé de un ejemplo de ellas en la charla que impartí sobre este tema.

Figura 2: Hacker & Developer in the Age of GenAI LLM Apps & Services

La explicación de un escenario inseguro de plugins en ChatGPT lo describí en el artículo: "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros", donde podéis ver un ejemplo de arquitectura de plugins que puede ser explotada. En este caso, la vulnerabilidad que explotan es la no validación de quién ha pedido la instalación de un plugin, para instalar un plugin malicio en una víctima con un único clic.

Instalación de Plugins en ChatGPT que necesita Tokens Auth

El funcionamiento es tan sencillo como que se crea un plugin aparentemente normal que hace copia de todo lo que sucede en una sesión de ChatGPT, por ejemplo en un Servicio que usa OAuth para autorizar el acceso a la escritura de los ficheros. Podría ser por ejemplo un plugin que copiara todos los datos de la conversación de ChatGPT en un fichero de texto, y lo subiera a una cuenta de almacenamiento de datos para grabar el fichero. O cualquier ejemplo similar. Este plugin debe ser instalado en ChatGPT, debe tener un Token OAuth que se entrega a ChatGPT para que lo use cuando quiera subir los datos al servidor donde va a copiar los ficheros.

Figura 3: El usuario de ChatGPT pide la instalación del plugin a ChatGPT.

El usuario pide al plugin que genere un Token OAuth para autorizar a ChatGPT.

El usuario de ChatGPT le entrega un Token OAuth que autoriza

el acceso de ChatGPT  a su cuenta en el servidor del plugin.

El Bug es que, un atacante puede pedir la instalación de ese plugin a ChatGPT, entonces ChatGPT le va a pedir al usuario que le genere el Token OAuth en el IDP del plugin. El usuario acepta la aprobación del Token OAuth que le genera el IDP del Plugin.... y aquí llega la clave. Sólo falta un paso, que el usuario le dé el Token OAuth a ChatGPT para que ChatGPT pueda enviarle todos los ficheros de su sesión a su cuenta en el plugin que está instalando.... pero...

... What if? 

¿Y si en lugar de darle el Token OAuth desde su sesión de ChatGPT, consigue que sea otro usuario el que le entregue ese código del backend del Plugin (asociado al usuario que pidió la instalación inicial del plugin a ChatGPT) haciendo simplemente un clic en el enlace?

Figura 4: Si la víctima (un usuario de ChatGPT) hace clic en ese enlace, instalará el plugin que copia todo con un token OAuth generado por el atacante, y todos los datos estará en la cuenta del plugin del atacante.

Pues entonces se da la situación de que la cuenta del usuario que ha hecho clic en el envío del Token OAuth acaba de instalar un plugin que copia todos los datos de la sesión y los envía a un backend controlado por otro usuario (el atacante que inició la instalación del plugin).

Figura 5: Todos los datos son enviados a la cuenta del atacante

Esto es un bug porque ChatGPT no está controlando quién comenzó el proceso de instalación, y quién lo está terminando, así que cuando consigue el Token OAuth de un plugin que tiene pendiente de instalación lo instala en la cuenta del usuario de ChatGPT que le entrega el Token OAuth, y el atacante tendrá acceso a todos los datos de la sesión de otro usuario. La solución, que ChatGPT sepa quién pide la instalación de un plugin y quién no.

Bug 2: PluginLab, MemberID manipulation & AskTheCode en GitHub

El segundo de los bugs no es propiamente de ChatGPT sino de la plataforma PluginLab.ai que permite crear plugins para ChatGPT. El problema en este caso es similar, ya que permite engañar al plugin creado por esta plataforma para cambiar de usuario. El ejemplo presentador es con el plugin AskTheCode que accede al repositorio de GitHub de una cuenta. 

Figura 6: Parámetro memberID que asocia plugin y token OAuth

En la plataforma de PluginLab se almacena el Token OAuth asociado para acceder a cada cuenta de GitHub por medio de un parámetro llamado MemberID que viene en la respuesta que le llega al usuario cuando se ha generado. Pero ese parámetro se puede manipular cuando se configura el plugin en ChatGPT, haciendo que ChatGPT instale un plugin para acceder al código de GitHub de otra cuenta asociada en PluginLab a otro repositorio de GitHub, y por ende acceder al código privado, a los secretos y las passwords.

Bug 3: OAuth Redirection en Plugins de ChatGPT

El último de los bugs presentado, tiene que ver con una mala implementación y verificación de seguridad de los plugins que se están permitiendo en la plataforma de ChatGPT, donde muchos de ellos tienen un bug clásico de OAuth Redirect.

Figura 7: Esquema del ataque de OAuth Redirection

En este caso, hace falta interacción con la víctima que autoriza el plugin mediante un clic, pero el atacante manipula el valor de redirect-uri consiguiendo que el Token OAuth sea enviado a un end-point malicioso controlado por él.

Conclusiones

Estos tres casos son ejemplos de cómo implementaciones parciales, desarrollos inseguros o procesos de certificación de plugins pueden ser utilizados por un atacante para vulnerar una plataforma. Los investigadores hicieron un Responsible-Disclosure de toda esta información, y pasaron por los procesos de Bug Bounty correspondientes, así que todos estos bugs están resueltos, pero seguro que vemos estos en el futuro otra vez en otras nuevas implementaciones.

Figura 8: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

Si te interesa el mundo de los Tokens OAuth, te delo los siguientes artículos, que nosotros le dedicamos mucho tiempo a la seguridad OAuth con los trabajos de Sappo y RansomCloud. Aquí los tienes.

• SAPPO: Spear APPs to steal OAuth-tokens 
• SAPPO: RamsomCloud O365
• Sappo para Twitter: Cómo usar Sappo para "silenciar" a un Twittero
• Cómo obtener un Token OAuth con el QR Code del menú del bar y que te controle el Sappo
• Spam con Phishing para robarte Tokens OAuth de tus cuentas de Microsoft o Google
• OAuth: La amenaza invisible
• Cómo se ha hecho a Gmail el ataque de Spam masivo por OAuth2
• Google alerta de las apps NO verificadas al pedir permisos OAuth. Microsoft Office 365 aún debe mejorar un poco.
• Mitigación de la suplantación de identidad en OAuth 2.0
• DobuleDrive: Cómo OneDrive se puede convertir en un Agente Doble y trabajar para un Ransomware
• O365 Toolkit: El kit de phishing OAuth para pentesters al estilo Sappo

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

DobuleDrive: Cómo OneDrive se puede convertir en un Agente Doble y trabajar para un Ransomware

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.

Figura 2: RamsonCloud O365: Paga por tus mensajes de correo de Office 365

La idea es muy sencilla. Robas un Token OAuth de una cuenta de Microsoft Office o de Microsoft One Drive, y con él accedes a todos los correos electrónicos o ficheros en la nube que tenga, y se los cifras. Eliminando los archivos originales, y solo se los devuelves descifrados sin pagan el rescate. Sencillo, y funcional.

Figura 3: Kevin Mitnick hace una demo de RansomCloud O365

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.

Figura 4: "Malware moderno: Técnicas avanzadas y su influencia en la industria"

de Sergio de los Santos en  0xWord

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. 

Figura 7: Python para Pentesters & Hacking con Python
de Daniel Echeverry en 0xWord

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.

Figura 10: Herramienta para extraer token de acceso desde log .odl de OneDrive

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.

Figura 12: OneDrive DoubleDrive en GitHub

Para hacer el cifrado, el atacante necesita el Token de Acceso que debe ser compartido con él. Puedes ver la descripción de la presentación en la web de Blackhat, y en este enlace tienes disponibles las diapositivas de la presentación de DoubleDrive.

Conclusiones

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.

Figura 13: Libro de "Empire: Hacking Avanzado en el Red Team" 
de Pablo González y Sebastián Castro en 0xWord.

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.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Figura 14: Contactar con Chema Alonso

Pre-Hijacked Accounts: o cómo robar una cuenta a un usuario antes de que se la cree

Durante este mes de agosto, el equipo de Microsoft Research ha publicado un interesante paper sobre las "Pre-Hijacked Accounts", o lo que es lo mismo, todas las posibilidades para dejar una cuenta "pre-hijacked" en un servicio, antes de que un usuario se saque la cuenta en esa plataforma. Y me ha parecido más que interesante. Es decir, que el atacante entra antes que la víctima en una plataforma web y le deja la cuenta configurada para poder controlarla en todo momento.

Figura 1: Pre-Hijacked Accounts: o cómo robar una cuenta

a un usuario antes de que se la cree

El estudio lo que trata es de anotar cuáles son las posibles vulnerabilidades y los posibles ataques que se pueden hacer dependiendo de cuál es el proceso de creación de una cuenta, de federación del login, y de los sistemas de recuperación de contraseñas que se pueden realizar.

Figura 2: Papper sobre Pre-Hijacked Accounts en Web Services

Supongamos que el login de un sitio web permite tener un login mediante usuario y contraseña - donde el usuario es el alias del correo electrónico - pero este sitio también permite tener un acceso federado con un IDP externo - como Google o Microsoft, por ejemplo -, y luego se pueden poner mecanismos de recuperación de contraseñas basados, por ejemplo, en número de teléfono.  En estos casos, dependiendo del proceso de verificación y onboarding de nuevas cuentas, se pueden realizar diferentes ataques de Pre-Hijacking que merece la pena conocer.

Figura 3: Libro de "Hacking Web Technologies Silver Edition" 3ª Edición

de 0xWord, escrito por Enrique Rando, Pablo Gonzalez, Ricardo Martin,

Chema Alonso y Amador Aparicio.

En este esquema, se pueden dar los siguientes ataques, que os resumo a continuación, a ver si soy capaz de resumirlos. En todos ellos, asumimos que existen dos rutas para crear una cuenta, pero que son para la misma cuenta. Es decir, que acabará existiendo la posibilidad de autenticarse con contraseña, o por medio del login federado del IdP.

1.- Classic-Federated Merge Attack

En este escenario, el atacante se crea una cuenta utilizando el login de usuario (basado en e-mail) y contraseña. El atacante no puede verificar el e-mail porque le llega el correo al dueño de la dirección de correo electrónico.

Figura 4: Cuentas con ID/Email/Passwor/IdP/Session & Phone Number

Sin embargo, la cuenta se queda creada sin verificar y en un futuro, el dueño del e-mail utiliza la ruta de creación vía IdP. El sistema activa la cuenta, y el atacante tiene el login/password que utilizó por la ruta (inconclusa) de la verificación vía correo electrónico.

2.- Unexpired Session Attack

En este caso el usuario se crea la cuenta sin utilizar la verificación de e-mail ni el IdP, ya que el sistema permite utilizar otro ID verificado como el número de teléfono, pero el correo electrónico que queda configurado es el de la víctima. El atacante consigue crear la cuenta y es totalmente funcional, con lo que puede abrir una sesión y mantenerla abierta "ad infinitum" mediante un script. La víctima, en el futuro, crea la cuenta con el sistema federado o recupera la contraseña por medio del correo electrónico y entra en una aplicación que tiene una sesión abierta que vigila todo lo que hace.

3.- Trojan Identified Attack

En este caso, se crea un identificador, y no se permite crear una cuenta por medio de un IdP Federado. No obstante, una vez creada la cuenta con un id y password, se pueden añadir cuentas para Federar el login. La cuenta está pre-troyanizada (por ejemplo con una app que tiene un token OAuth - como hacíamos en Sappo - de esta plataforma). Cuando el usuario intenta crear su cuenta con e-mail, ya existe un identificador con su correo electrónico asociado, así que tiene que recuperar la contraseña y tomar acceso, pero la cuenta está troyanizada.

4.- Unexpired e-mail Change Attack

En este caso, el atacante se crea la cuenta con un identificador o con el e-mail de la víctima sin que sea necesario verificarlo. El atacante, a pesar de haber creado una cuenta con el e-mail de la víctima, lanza un proceso de cambio de correo electrónico asociado a la cuenta que no concluye. La víctima quiere crearse la cuenta, no puede, recupera la contraseña y toma control de la cuenta. El atacante, en el futuro, puede terminar el proceso de cambio de correo electrónico y tomar control de cuenta.

Figura 5: Ejemplos de ataques de Pre-Hijacked Accounts

En este caso, se puede dar la casuística de que el atacante cambie el e-mail asociada, pero no resetee la contraseña porque la plataforma permite hacer login con un e-mail enviando un link de click-to-login, lo que permitiría que la víctima siguiera con su id/password pero que el atacante entre con click-to-login.

5.- Non-Verifying IdP Attack

En este caso hablamos de un servicio que permite a una empresa tener su propio IdP (como por ejemplo hacen la empresas con Office365 cuando quieren tener su IdP empresarial controlado). El atacante se crea un IdP propio, y abre una cuenta siguiendo la ruta federada de su propio IdP. Después, añade un usuario y contraseña para la ruta no federada utilizando el e-mail de la víctima. Cuando la víctima recupera la contraseña para esa cuenta, el atacante tiene acceso con el login de la cuenta federada.

Figura 6: Más ataques de Pre-Hijacked Attacks

Esto puede hacerse también cuando las cuentas permiten un identificador y varias cuentas federadas. Así, se crea la cuenta con el identificador de la víctima y se controla con una cuenta federada. Después, la víctima inicia sesión con su cuenta, pero usando la ruta de federación de IdP. Si la plataforma permite varias cuentas de login federadas, entonces funcionaría igualmente.

6.- E-mail verification Trick

Este punto es interesante, ya que en muchos de los ejemplos, la plataforma no deja crear la cuenta sin verificar el correo electrónico. En estos casos, se puede crear una cuenta con un identificador de e-mail controlado por el atacante, y luego abusar el proceso de "cambiar de e-mail", lo que permitiría tener la cuenta, y el e-mail de la víctima en proceso de cambio, lo que si la víctima toma control, tendrá su cuenta creada... y troyanizada.

Figura 7: Suposiciones para cada ataque, acciones de atacante y víctima.

En todos estos ejemplos, además, hay que tener en cuenta que aunque se deje una cuenta creada pero no habilitada, habilitada pero no verificada, o creada, verificada pero no transferida, si se puede configurar un número de teléfono como forma de recuperar la contraseña, para hacer click-to-login por SMS, o se pueden configurar otros e-mails durante el proceso, la plataforma podría dejar suficiente información a configurar en una cuenta para hacer un pre-hijacked de la cuenta que en el futuro se saque la víctima. Os recomiendo el paper, que ha sido una lectura muy interesante para este domingo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

La estafa de los Falsos Brokers que van a hacer que te forres con Amazon o Tesla y el Growth Hacking en Twitter con tus apps móviles gratuitas

Si el otro día os hablaba de una pregunta que me entró por mi buzón en MyPublicInbox de cómo una persona estaba siendo monitorizada por que en un descuido alguien consiguió compartirse la ubicación de iPhone por iMessage, hoy os traigo otra estafa de la que me han llegado como alrededor de diez consultas por el mismo buzón. Se trata de la estafa de los falsos brokers que van a hacer que ganes mucho dineros invirtiendo en Amazon, Tesla, u otra empresa similar.

Figura 1: La estafa de los Falsos Brokers que van a hacer que te forres con Amazon o Tesla y el "Growth Hacking" en Twitter con tus apps móviles gratuitas

Mucho se ha hablado de la estafa de los BitCoins, y cómo utilizan la imagen de personas famosos para engañar a las víctimas. Yo me he visto utilizado muchas veces como gancho de esa estafa, y por eso escribí un artículo para que quede claro que "No, Chema Alonso no se está forrando con BitCoins" como dicen las campañas de Malvertising que lanzan en Facebook, Instagram o Twitter. Pero de la que voy a hablaros hoy hay un poco menos de información, y me han llegado ya muchas víctimas contándome su situación.

Figura 2: Ultimo mensaje que me entró por mi buzón en MyPublicInbox

con una nueva víctima de la estafa de los Falsos Brokers.

En definitiva es la misma estafa, pero esta vez hecha con la imagen de Amazon o Tesla o cualquier otra gran compañía que en la cultura popular esté muy metida como exitosa, y me sorprende que no están persiguiéndolo mucho. Entiendo al final que Amazon y Tesla, que son empresas cotizadas en bolsa no pueden estar en contra de lo que dicen las campañas que utilizan. 

Figura 3: El Selector de la Avaricia. Mete 20.000 € que ganarás 102.624 € en dos meses máximo.

O lo que es mismo, mete 20.000 € y en dos meses lo multiplicas por 6.

Es decir, que invertir comprando acciones en esas empresas te puede dar grandes retornos de dinero, pero lo cierto es que lo que prometen estos Falsos Brokers, es directamente falso, y si caes en sus manos no vas a invertir nunca en bolsa, pues son empresas falsas que capturan tu dinero y te sacan todo lo que puedan.

Figura 4: Campañas de publicidad en medios nacionales de gran tirada

Contratan campañas de publicidad y marketing que meten en los principales diarios de los países, como contenido patrocinado, utilizando la imagen de estas compañías. Este es un ejemplo de Amazon en un periódico online nacional en España. Por supuesto, cuando vas a la web, lo que hay son testimonios falsos y datos falsos, utilizando cuentas que no existen.

Figura 5: Testimonios publicados en la web de los falsos brokers

En este ejemplo puedes ver que utilizan una cuenta de Twitter con el testimonio de una persona, pero no es verdad esa cuenta no existe o ha sido eliminada por ser fraudulenta. Siempre es la misma idea. Invertir en malvertising, utilizar testimonios para ganar confianza - como hacen en la estafa de los BitCoins o la estafa de los Hackers para espiar WhatsApp for Hire -, y conseguir el lead para luego trabajarse a la víctima por e-mail o por teléfono, al más puro estilo "Tocomocho".

Figura 6: La cuenta del "Rey Hakim" no existe.

 (¿Has visto el Principe de Zamunda? Cachondos...)

Eso sí, todo es legal, porque son empresas en el otro lado del mundo y en la letra pequeña de los contratos que firmes ya te pone que puedes perderlo todo, que no están obligados a devolverte el dinero, etcétera, etcétera, así que, si no te has leído la letra pequeña no tendrás nada que hacer en ese paraíso fiscal al que vas a enviar tu dinero.

Figura 7: Letra pequeña de la campaña de marketing que ves en la web

Los contratos no los ves en la web, y tendrás que esperar a que ellos, cuando tengan tu información y estén convencidos de que vas a darles el dinero, te los pasarán. El texto que ves en la Figura 7 es de la campaña de marketing que hace otra empresa, separada, de los Falsos Brokers, para curarse también en salud de las denuncias que llegarán.

Falsos Brokers y Growth Hacking

En este otro caso de aquí, de esta misma semana (aún activo) , me llamó la atención que la campaña de malvertising se  hiciera directamente desde una cuenta de Twitter, que además se llama Top Business (13). Cuando la vi, llama la atención que se ha abierto a finales de Junio de 2021 y que solo sigue a 13 cuentas - ninguna de los creadores de esa supuesta empresa - y tenía ya más de mil seguidores.

Figura 8: Campaña de Falsos Brokers por Twitter

Si miramos a quién sigue, está claro que busca posicionarse como una cuenta corporativa, siguiendo al Presidente Biden, a Tesla, a Elon Musk, a Forbes, etcétera. Todo lo que a una víctima le pueda dar el olor de "dinero" o "poder", pero si vemos a los seguidores, la cosa cambia. 

Figura 9: Siguiendo "Dinero" y "Poder"

Entre los followers ay una lista de un montón de personas que estaba seguro de que no seguían esa cuenta por interés propio. Así que busqué a uno de los seguidores para hablar con él y le pregunté directamente si él seguía esa cuenta por algo, ya que me olía cómo habían conseguido los seguidores.

Figura 10: Constatando el Growth Hacking con tokens OAuth

Como era de esperar, la respuesta era clara: No tenía ni idea de cómo la había seguido. Así que, como era evidente, han comprado seguidores a alguna empresa que tiene apps de Twitter con Tokens OAuth capturados por medios de apps móviles.  En su caso, la única app que tenía un token OAuth válido no caducado era Steroload, que se dedica a hacer Growth Hacking para bandas de música, y parece ser que para cualquier postor - incluso Falsos Brokers -.

Figura 11: Apps con Tokens OAuth de Twitter válidos

de la persona forzada a seguir a TopBusiness13

Es decir, te descargas una app gratuita, te piden que te autentiques con Twitter, autorizas la app de Twitter, y se llevan el token OAuth - como explicábamos en el ejemplo de Sappo para Twitter -. Normalmente estas apps gratuitas capturan estos tokens para vender likes, followers, o similares a gente que desea crecer en relevancia en cualquier plataforma - es su negocio - pero una vez que tienen el token OAuth de Twitter, ya pueden hacer lo que quieran, como hacerte seguir a una cuenta fraudulenta para dar confianza a las nuevas víctimas. 

Figura 12: Resumen de las pruebas de seguridad del

Asistente de Seguridad de Twitter en MyPublicInbox.

Esta es una de más de veinte características de fortificación de cuentas Twitter que se recomiendan en el asistente de seguridad de Twitter que hicimos en MyPublicInbox que puede utilizar cualquier usuario de la plataforma. Así que, si no quieres ser parte de este tipo de estafas, revisa qué apps de Twitter tienen tokens OAuth con el que pueden controlar tu cuenta.

Figura 13: Buscando en Tacyt "sospechosos" de capturar tokens OAuth

Alberto se acordaba de haber instalado alguna app de SoundCloud que hacía algo por Twitter, así que decidí irme a mi querido Tacyt y hacer un poco de dorking para localizar apps que tuvieran que ver con SoundCloud y pidieran autorizar tokens de OAuth. Un sencilla búsqueda y aparecieron un par de ellos.

Figura 14: Links de Twitter para capturar tokens OAuth

Como se puede ver, en los enlaces que tienen estas apps se puede ver cómo hacen uso de las APIs de Twitter para autenticar apps de Twitter y capturar los Tokens OAuth. Así que, cuando te bajes una app móvil gratuita, piensa cuál es su posible modelo de negocio.

Conclusión

Nadie da nada por nada. Casi todas las apps móviles tienen un modelo de negocio. Si no sabes cuál es... puede ser malo. Los Tokens OAuth que te piden apps móviles gratuitas son por algo - y puedes acabar siendo parte de algo así -. 

Figura 15: Cómo protegerse de los peligros en Internet
de José Carlos Gallego Cano

Y si un broker puede convertir 20.000 € en 120.000 € en dos meses... ¿para qué gastar dinero en publicidad para hacerte ganar dinero a ti? ¿De verdad?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)