La "shittización" en contra de hacer las cosas simples

Hace años, más de una docena, usaba a mis queridos héroes de "The Big Bang Theory" para explicar cómo de difícil lo habíamos hecho los que trabajamos en ciberseguridad para que las personas normales se pudieran conectar de forma segura a una red WiFi y a Internet. En el artículo de "Mea Culpa, Penny" explicaba todas las cosas que un usuario debía saber para configurar una VPN que se tunelizara a través de proxys, firewalls de redes,... ¿La quiere L2TP, SSTP o PPTP? 

Figura 1: La "shittización" en contra de hacer las cosas simples

Si eso se lo tengo que decir a mi madre, mejor la tengo que decir que no se conecte. Pero esta complejidad constante de la tecnología se ha ido extendiendo a la guerra comercial por el usuario, lo que hace que cada vez el número de opciones, los diseños de los interfaces, y el salto conceptual intelectual que el diseñador de un UX espera de un usuario, es cada vez mayor. 

En los foros tecnológicos se dice que un UX se ha "shitted" o "enmierdado" cuando la cantidad de opciones para el usuario, la anarquía de la distribución, la diversidad de los controles que debe tocar, y la cantidad de cosas que el usuario "debe suponer" para poder manejarlo, es enorme, y genera frustración en los usuarios. Esto, que parece evidente, es muy complicado de hacer. Hacer las cosas simples require de mucho trabajo, y para ello hay que primar al usuario o consumidor, por encima de las necesidades de negocio.

Cambiar de terminal iPhone

Os cuento esto por dos casos que he sufrido esta semana, que han sido bastante significativos. El primero de ellos con la migración de mi iPhone. Este es un proceso que he realizado ene veces ya, porque todos los años voy migrando mi iPhone. Esto implica migrar las apps, las fotos, los datos, etcétera... Todo esto bien, pero pero cuando llegamos a las partes de seguridad, la cosa se complica un poco. En mi caso, el iPhone era americano, además, como tengo en el mismo la conexión personal y la profesional, tenía una SIM y una eSIM, de dos países diferentes, además de que tenía que pasar de SIM a eSIM obligatoriamente.

El proceso, por supuesto, no funcionó correctamente, y acabé teniendo que ir a tienda, borrando las eSIM creadas virtualmente a partir de la SIM, y teniendo que comprar nuevas eSIM para el terminal americano. Eso hizo que perdiera los contactos de la SIM, y los contactos de la SIM perdidos generaron que se borraran también de la agenda, y por ende de WhatsApp y por ende usuarios dejaron de ver mi foto y me escribieron "¿Me has bloqueado?" No, estoy migrando un iPhone, no worries. Algunos se habrán enfadado y me habrán borrado a mí, así que me ha hecho perder amigos.

Como tengo Multi-SIM para dos países distintos, voy cambiando qué SIM activo o desactivo, pero claro, en la nueva versión de iPhone asocia a cada contacto una SIM por defecto, y cuando no está conectada esa SIM te sale una alerta que dice: "¿Quieres cambiar la asociación por defecto de la SIM a este contacto para poder llamar?" Y un sinfín de lindezas más, como por ejemplo que los contactos de iOS ahora tienen el botón de contactos, donde sale la lista y solo se puede hacer scroll y pulsar a la derecha en unas letras muy, muy, muy chiquititas... que no sé quién ha diseñado.

Figura 2: Esta me ha encantado. El número que el banco ha pasado a Apple es erróneo y después de llamar al Contact Center de ese número y esperar 20 minutos me dicen: "El número que te da iPhone no es de tu banco, somos otro banco". Genial.

Con la SIM ha sido una fiesta, pero luego hubo que migrar las Wallets, las apps bancarias, los 2FA, las autenticaciones de las herramientas de mensajería, etcétera, etcétera, y para cada una el proceso con la entidad es distinto. Instala app, inicia sesión con las credenciales, por el 2FA, te falta la passkey, recupera password, envía SMS, es de otro país y no llega, desactiva SIM, activa la otra, etcétera. Muy divertido y entretenida la gincana de migrar un terminal iPhone.

La autenticación doble con la identidad simple

La más divertida ha sido una app de un servicio - permitidme que no diga la empresa porque tengo amigos en ella y quiero arreglarlo antes -, donde al ir a hacer Login me ha dado la opción de usuario y contraseña, y en paralelo la opción de "Login con Google". Como no recordaba la contraseña - llevaba la app instalada mucho tiempo con autenticación automática con FaceID - le he dicho que autentique con Google. Y... surprise, me he encontrado con que usé la cuenta de Google sí, pero no con autenticación delegada, sino que lo hice con una contraseña, así que estamos en el caso de misma dirección de e-mail con doble autenticación, con usuario y contraseña o con IdP delegado usando OAuth.

Esto es un problema de arquitectura que los responsables de identidad y seguridad deben resolver, y si no lo hacen bien, genera escenarios de ataque como os comenté en el artículo del año 2022 : "Pre-Hijacked Accounts: o cómo robar una cuenta a un usuario antes de que se la cree". Dependiendo de cómo lo resuelvan, se pueden dar unos casos u otros. En mi caso, ha sido un DoS en toda regla que aún no he podido resolver y que voy a resolver llamando a mis colegas en esa empresa. 

El proceso ha sido muy divertido. Me enfrento al login y doy a "Login with Google". Comienza el proceso de autenticación delegada, y el sistema descubre que mi cuenta ya está creada pero con autenticación con contraseña. Salta el sistema de protección y unión de los dos procesos de autenticación para la misma identidad y me pide la contraseña que tiene la cuenta. Correcto. No la recuerdo, así que voy al proceso de recuperación de contraseña. Me manda el enlace de recuperación al correo de la cuenta de Google. Ojo que me lo envía a la dirección de correo con la que acabo de hacer login con Google, luego... ¿para qué? Si acabo de hacer login con Google, tengo acceso al Gmail del login de la cuenta, así que es un paso innecesario que no añade ninguna seguridad, pero para el sistema serán dos procesos independientes, y es el usuario el que se tiene que adaptar a la arquitectura y no al revés.

Da igual, sonrío, hago clic para cambiar la contraseña de la cuenta, pongo una y me dice... "No se puede cambiar la contraseña a esta cuenta". ¿Por qué? Pues porque en vez de mantener los dos autenticadores - con Google y por Usuario/Password, ha fusionado a un sólo autenticador, pero hasta que no introduzca la contraseña anterior - que no me deja cambiar - no puedo iniciar sesión. Conclusión "Deadlock" de libro por un mal diseño de seguridad. 

Después de dos días migrando cosas, aún me quedan un par de tarjetas bancarias que por motivos "corner case" aún no he conseguido migrar, y una cuenta de servicios de la empresa que por geo-location tampoco me permite procesar, pero más o menos lo tengo todo. Pero mientras pasaba por este proceso, me imaginaba a mi madre, y a muchas, muchas, muchas personas que tienen que pasar por aquí recordando que yo entiendo qué me están pidiendo, qué me está pasando, cuál es la situación en la que estoy en todo momento, pero que para ellas puede ser un dolor increíble.

La nueva "Simple" Televisión

Esta parte, que ha sido una de ellas, no ha sido la única experiencia que he tenido estas últimas 72 horas con esto, ya que además he querido cambiarle una televisión a mi madre para quitarle el descodificador y que solo tuviera un mando - de la SmartTV - y que no se confundiera. Al final, su problema consiste en que enciende la Televisión y el Descodificador y que si todo va bien, no hay problema, coge el mando del desco y cambia los canales y ve la tele - que es lo único que ella quiere -. Pero... si usa el mando de la SmartTV para subir o bajar canal, la SmartTV cambia el Source y se va a modo TV quitando el HDMI 1 de su fuente, y adios televisión. Y mi mamá, de 74 años, piensa que "ya se me ha ido la televisión".

Pues bien, le dije, ¨te voy a cambiar la televisión que está vieja, y te voy a poner la tele en una app y quitamos un mando del medio". Precioso decir, imposible para ella. Al final, encender la televisión y me pide una cuenta de la empresa de SmartTV que tengo que crear con un QRCode - imaginaos a una persona de 74 años ante eso -, después me pide que instale una app en el terminal, así que hay que usar las cuentas de Apple para ponerla en el iPhone, la instalas, te autenticas en la app con un correo y una password, te manda un SMS como 2FA, luego sigues un Wizzard de permisos para la app, y si quieres las noticias de la compañía de la televisión, las ofertas, los datos que le quieres dar de la app, y luego te pide el código que ves en la pantalla de la televisión de 14 dígitos, para darla de alta en tu app.

Y todo eso, en la primera pantalla de configuración de la SmartTV. 

Después de más de 20 pasos y una hora de configuración, con las ofertas de Amazon Prime gratis un mes, la de Apple TV, de quitar las apps de SmartThings para IoT, las autenticaciones en las diferentes apps, el inferfaz usa controles de usuario de tabs arriba, con líneas de vídeos y apps en un scroll infinito para abajo, y paneles que se expanden en los laterales. Así que me pongo con mi madre a enseñarle, y después de decirle 

"no, esa película no la puedes ver porque es de una promoción de un mes gratis de Apple TV y te lleva a esa app. Dale para atrás. Vaya, no sale. Pues dale al inicio. Ahora vete a la sección apps. Sí, tienes que bajar. Con las flechas. Ahora. Dale al ok. ¿El ok? Ah, espera, en este mando es distinto, el ok, es ese cuadrado con una flecha que sale de él. Sí, ahí. Ahora dale a la app. Sí, no te sale el canal que tenías antes, porque se personaliza con tus datos de navegación, así que hasta que no lo veas varias veces no te lo va a poner en su sitio, así que tienes que entrar en la guía. Es ese icono con unas rayas arriba a la izquierda. Sube con las flechas. Ahora entra, y sale la guía, ahora baja hasta que encuentres el canal. Sí, sigue bajando que hay cientos de canales. Ahora dale al ok. Sí esa es la ficha del canal. Dale al ok. No, que le has dado a la flecha y te has movido. Vuelve atrás. No, te has ido a la guía otra vez, era que movieras la flecha a la izquierda. No pasa nada vuelve a bajar. Sí, sé que son muchos... "

Pues bueno, le he quitado al nueva SmartTV, y le hemos puesto el sistema del desco (con una sola televisión) y al mando de la televisión anterior, para que no lo toque, Mi Survivor ha decidido ponerle celo a todos los botones menos al de encender y apagar, para que sepa que ese mando solo es para encender la televisión y nunca lo cambie de Source. Y no son pocos los que hacen eso.

Figura 3: Mandos "simples"

El MacBook Pro no arranca

Ya la última de las aventuras con la "shittización" de la tecnología, ha sido con mi MacBook Pro, que ha decidido no arrancar esta mañana - por eso estoy escribiendo el post tan tarde -. No tiene botón de hard-reset, la batería está cargando, pero no arranca. La última vez que me pasó eso, tuve que esperar dos días a que descargara toda la batería, y empezar de nuevo a cargarlo, y entonces funcionó, pero no tengo ni idea de qué le ha pasado. Tengo copia de seguridad de todo, así que no hay problema, pero tengo la seguridad de que si lo llevo a la tienda Apple me van a decir:

"Está roto, no se puede recuperar nada, compre otro". 

UPDATED: 20 horas después, se ha descargado y ha arrancado el MacBook Pro... otra vez como nuevo. Sin comprar ningún otro.

En resumen, menos mal que estoy al día de la tecnología y entiendo cómo funciona, entiendo qué está mal hecho en los sistemas, y al menos sé qué debo hacer para avanzar desde una situación a otra para conseguir arreglar el segundo paso, pero hablando de esto hace unos meses con un viejo colega de armas, sentados cómodamente, enumerábamos la cantidad de productos que eran fáciles, guays, sencillos y que se han "Shitted".

Unos meses después, os estoy escribiendo este artículo, porque cada vez vamos más rápido sacando tecnología, cada vez tiene menos QA, cada vez los UX son más "shitted" por permisos, seguridad, necesidades de negocio, etc... y hacen que las funciones core (como en el ejemplo de "ver la tele") estén cada vez más lejos de los usuarios. Recordad que os conté el lío que tuve con el bug de UX en WhatsApp solo por el tamaño de letra...

¿Tienes alguna experiencia similar? Déjamela en comentarios que me encantará leerla...

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

CoPhish: Malicious CoPilot Agent para robarte tus Tokens OAuth

Hace ya años desde que publicamos el trabajo de Sappo para robar los Tokens OAuth y liarla parda. De hecho, publicamos el paper de RansomCloud O365 creando un Ransomware que robaba tus Tokens OAuth y luego te cifraba todos los datos en la nube. Una nueva forma de ataque que ha sido desarrollada durante estos años por nuevas investigaciones, como la de DoubleDrive de la que también os hablé por aquí. Hoy quería hablaros de CoPhish, publicada por los investigadores de DataDog Security Labs que tenía esta investigación guardada en el RSS hace tiempo y no encontraba tiempo para hablaros de ella. Hoy es el día.

Figura 1: CoPhish: Malicious CoPilot Agent para robarte tus Tokens OAuth

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: Demo de Sappo en Office hecha por Chema Alonso

Pero claro, Microsoft ha fortificado el entorno OAuth, y ha añadido mejoras de seguridad para el registro de aplicaciones - tanto internas como externas - y para la concesión de tokens por parte de los usuarios a estas aplicaciones, como bien se explica en el artículo.

Figura 4: Restricciones para el registro de Apps y concesión de tokens OAuth

Las mejoras se incluyeron en el año 2020, y este mismo año se añadió la opción de dejar que Microsoft decidiera quién puede o no puede conceder un Token OAuth, quedando aún algunas excepciones para usuarios administradores, y para ataques internos entre usuarios del mismo Tenant. Esto es algo que Microsoft piensa fortificar también en breve como podéis ver en el anuncio que ya ha hecho.

Figura 5: Nuevas restricciones de seguridad anunciadas

En cualquier caso, utilizando la plataforma de CoPilot, se puede crear una aplicación registrada tanto externa como internamente que, usando una aplicación en forma de asistente, robe los Tokens OAuth de sus víctimas con una web que ofrece toda la confianza a los usuarios. La web de Copilot para assistentes.

Figura 6: WebApp para un Asistente de CoPilot

Si este Asistente es una web maliciosa, puede solicitar la autenticación mediante Tokens OAuth que pidan acceso excesivo a los ficheros, mensajes, calendario, etcétera. Esto, como explicamos en los artículos de Sappo, se basa en solicitar el Token OAuth con un Scope excesivo que permita hacer de todo en la identidad del usuario.

Figura 7: Malicious Copilot Agent

El Bot registra un Copilot Agent que pide muchos privilegios en forma de Token OAuth, y luego cuando el usuario se autentica  - en la plataforma de Bots es necesario hacerlo con un 2FA basado en un número -, el sistema generar un Token que el Malicious CoPilot Agent filtra al atacante.

Figura 8: Solicitando permisos a usuarios internos del mismo Tenant

En la imagen de arriba se ve cómo sería la pantalla de origen donde se solicitan los permisos cuando el asistente ha sido registrado en el mismo Tenant por un usuario interno y está atacando a un usuario interno. Y en la imagen siguiente, lo mismo, pero con una asistente registrado en un Tenant externo para atacar a los administradores - que siguen teniendo la opción por defecto de conceder Tokens OAuth -.

Figura 9: Cuando se usa una App registrada externamente para atacar al administrador

Al final, estos dos entornos se deben a las restricciones que por defecto añadió en 2020 y en 2025 Microsoft para reducir la superficie de exposición de los usuarios a este tipo de ataques de robo de Tokens OAuth con app maliciosas, pero como se explica al principio siguen quedando opciones para atacar a los usuarios de estas dos maneras.

Figura 10: URL De Copilot para las apps de Phishing

En cualquier caso, la URL donde están publicadas las aplicaciones es de confianza, ya que es la URL de un dominio de Copilot de Microsoft. Y una vez que el usuario se autentique con el Bot Framework, con el token numérico, entonces ya tendremos el Token OAuth generado para compartir con el atacante.

Figura 11: Autenticación en el Bot Token Service

El resto es ya lo conocido, el Malicious Copilot Agent es capaz de acceder al Token OAuth que ha sido creado como. parte del proceso de login con una cantidad de permisos que da un poder enorme a la aplicación sobre la identidad del usuario, para hacer las maldades ya conocidas.

Figura 12: Token OAuth autorizado en petición HTTP al host del atacante

La magia es que para hacer este Malicous CoPilot lo puedes hacer con el asistente NoCode/LowCode de Microsoft CoPilot, creando todos los flujos, y con un trigger en el proceso de Login donde se puede añadir un workflow especial para robar el Token OAuth.

Figura 13: Creando un Asistente en Copilot

Como se puede ver en la imagen siguiente, en el diseño del Workflow tenemos acceso al Token OAuth con el que se hace Sign-in, y este Token OAuth es el que se va a enviar con una petición a servidor HTTP controlado por el atacante.

Figura 14: Workflow en el trigger de Login

Aquí se ve cómo se hace el flujo para que se haga la petición a un HTTP Server con una Key que tiene como Value el UserAccessToken. Y la URL del servidor controlado por el atacante. Ahora solo falta configurar los permisos se quieren en ese Token OAuth para permitir el acceso al Malicious CoPilot y la app para poder publicarla.

Figura 15: Flujo de envío de Token OAuth a servidor controlado por el atacante.

Una vez creado el asistente con los flujos, hay que registrar la app, como podéis ver en la siguiente pantalla, donde se configura la aplicación en el tenant.

Figura 16: Configuración de la aplicación del Malicious CoPilot

El resto, es hacer las maldades que se quieran con el Token OAuth robado al usuario. Lo curioso de esta técnica es que se ha utilizado la infraestructura de Microsoft CoPilot para saltarse las restricciones contra las apps maliciosas - como las que usamos nosotros en Sappo - para robar Tokens OAuth. Muy chulo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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)