Hacking Gitlab Duo: Remote Prompt Injection, Malicious Prompt Smuggling, Client-Side Attacks & Private Code Stealing.

Esta misma semana se ha publicado un trabajo de investigación sobre vulnerabilidades del GitLab Duo que es muy interesante por muchos aspectos, y por utilizar muchas de las técnicas de las que cada día hablamos más en el mundo del Hacking de Productos & Servicios hechos con IA. En este caso, los investigadores de Legit han demostrado cómo se podía utilizar GitLab Duo para atacar a otros usuarios con librerías infectadas y construir malware, para inyectar código malicioso en los resultados de GitLab Duo y para robar código privado, muy interesante técnicamente toda la investigación.

Figura 1: Hacking Gitlab Duo - Remote Prompt Injection,

Malicious Prompt Smuggling, Client-Side Attacks

& Private Code Stealing.

El artículo completo lo podéis leer en "Remote Prompt Injection in GitLab Duo Leads to Source Code Theft", y aquí tenéis una explicación del trabajo que os he resumido - y ampliado - para ver si soy capaz de explicarlo con claridad.

Figura 2: Remote Prompt Injection in GitLab Duo Leads to Source Code Theft

GitLab Duo es el asistente con IA de la plataforma GitLab que te ayuda a trabajar con tu repositorio de código, y que está disponible para todos los usuarios. Utiliza, por supuesto, una arquitectura de DeepReasoning, así que permite realizar tareas complejas, escribir código, puede manipular documentación, y para hacer bien el trabajo, cuenta con su Memory.

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

Para entender el ataque bien, os recomiendo que leáis antes el artículo de "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros" porque tiene algunas similitudes en cuanto al ataque. En este artículo teníamos un servicio representado por ChatGPT, y le dábamos capacidades para hacer cosas sobre datos conectados (ficheros en One-Drive), y aplicaciones (enviar correos electrónicos). Si no había un entorno aislado multiusuario, un atacante podría ver los prompts de otro usuario, o los ficheros a los que tuviera acceso el modelo de IA, en ese caso, ChatGPT. 

Hacking Gitlab Duo:

En el ejemplo de GitLab Duo, el investigador hace un ataque de Prompt Injection que pone en el código fuente de un programa como un comentario, y con un simple "Explain this code" o hacer cualquier acción sobre ese código, se puede ver cómo GitLab Duo lo procesa.

Figura 4: El Prompt Injection está en un comentario.

Cuando se le pide a GitLab Duo que explique el código

se puede ver que se ejecutan las órdenes del Prompt.

Visto esto, para enviar estos ataques a otro usuario lo que hace es proponer un cambio en el un código de otro usuario, y en los comentarios introducir el Remote Prompt Injection, que en este caso inicial se trata de meter una librería de código maliciosa, por ejemplo, para robar los usuarios y contraseñas de un proceso de Login.

Figura 5: Prompt Injection para meter una

librería Javascript maliciosa.

Cuando la víctima dueña del código solicite a GitLab Duo cualquier comando sobre el código que está visualizando del cambio propuesto, el Prompt Injection se ejecutará, y realizará un Memory Poisoning, dejando en la memoria que si en el futuro se solicita, por ejemplo, una página de Login, meta esa librería maliciosa. 

Figura 6: Técnicas para Prompt Smuggling

Para hacer este ataque mucho más invisible para la víctima, el atacante hace uso de técnicas de Prompt Smuggling para saltar los posibles guardarraíles del modelo usando trucos como los vistos en el artículo "Cómo saltarse los AI Guardrails con Invisible Characters & Adversarial Prompts para hacer Prompt Injection & Jailbreak Smuggling" , además de para hacer menos visible el Prompt en el código y el panel que pueda ver la víctima.

Figura 7: Prompt codificado en los cambios con texto en blanco.

Solo se ve cuando se selecciona en GitLab

Como se puede ver en la imagen anterior, en la parte de Changes queda en color blanco (codificado en KaTeX), y además queda en Unicode usando codificación Base16 para meter los Prompts Maliciosos.

Figura 8: El Prompt Injection queda codificado en el historial

En este caso la demo la hace directamente con la petición del Login, así que la infección de la Memory no tiene que esperar a la petición futura.

Figura 9: El Prompt Injection se ejecuta.

Ahora, si vemos el proceso completo de GitLab Duo, se puede ver cómo ha inyectado la librería maliciosa, y cada vez que procesa el usuario y la contraseña llama a la función de esta librería que puede robar las cuentas tranquilamente.

Figura 10: El código de Login queda infectado.

Una vez que se ha completado este ataque, es posible imaginar muchos otros ejemplos. Por ejemplo pedirle que en la respuesta GitLab Duo muestre un enlace que la víctima pueda hacer clic para llevarle a una infección. 

Figura 11: Inyectando un enlace malicioso en la salida de GitLab Duo

Y por supuesto, cuando llegue la ejecución del Prompt en el GitLab Duo de la víctima, se producirá esa respuesta que se ha solicitado, tal y como se ve en la imagen siguiente.

Figura 12: Inyectado el enlace en la salida de GitLab Duo

Una vez visto este comportamiento, se pueden reproducir todos los ataques Client-Site en Web Applications, ya que tenemos un servidor - el de GitLab - desde el que enviar código a una víctima - desde Prompt inyectado -.

Figura 13: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

El siguiente ejemplo fue hacer HTML Injection y realizar ataques de Cross-Site Scripting (XSS), en este ejemplo para "Rickrollear" un poco.

Figura 14: Injectando HTML Injection

Com se muestra en la imagen siguiente, este ataque también funcionó, por lo que se ha utilizado el modelo LLM como forma de atacar a otros clientes.

Figura 15: Rickrolleando con GitLab Duo

La última de las PoCs es para robar el código fuente de un programa de otro usuario que está en PRIVADO. En este caso aprovecha que GitLab Duo puede usar la herramienta merge_request_reader que tiene acceso a todos los códigos - públicos y privados -, así que con este Prompt se le pide que meta el código en un parámetro en Base64 como parte de un enlace.

Figura 16: Prompt para robar código privado

Al final, usando este ataque Remote Prompt Injection se solicita a GitLab Duo que use una herramienta que tiene conectada al modelo -  y que le da permisos para acceder a datos privados - que explique un merge_request privado, y que pinte la salida como parámetro de un enlace. 

Figura 17: Enlace malicioso con el código fuente robado

Para poder hacer este ataque, ha sido necesito meter el Remote Prompt Injection en una petición de cambio enviada a un código de la víctima, utilizando las técnicas de ASCII & Malicious Prompt Smuggling. Después, cuando al víctima ha pedido cualquier comando a GitLab Duo, el Malicious Prompt se ha ejecutado y se ha creado un enlace malicioso con el código fuente del programa a robar como parámetro. Cuando la víctima hace clic en él se envía el GET Request con el código fuente en la URL al servidor controlado por el atacante.

Reflexión final

El mundo de la Inteligencia Artificial a las profesiones de cibeseguridad nos ha abierto tres nuevas disciplinas en las que tenemos que trabajar. La primera es la de utilizar los nuevos modelos de IA para hacer ataques en los procesos de Pentesting, Ethical Hacking o Red Team. La segunda disciplina es utilizar la IA como forma de aumentar las capacidades de los equipos de seguridad, para automatizar tareas en el SOC, procesos de patching por IA, detección de anomalías, forensics, y cualquier proceso del Blue Team y los equipos de CERT & CSIRT. 

Figura 18: Hackin’ AI: Creando una IA… ¿Qué puede salir mal? por Chema Alonso

Por último, lo que vemos aquí es un ejemplo de la disciplina de aprender a atacar las nueva arquitecturas basadas en modelos de IA, Agentic AI, etcétera, que es lo que recoge el OWASP Top 10 de Productos & Servicios basados en LLMs. Un campo completo para el que aprender a diseñar nuevos ataques, basados en Prompt Injection, Jailbreak, Memory Poisoning, Malicious Prompt Smuggling, Guardrails Bypass, Data Poisoning, etcetera. Todos los problemas vistos en el artículo de hoy, el equipo de GitLab ya los parcheó, que se hizo un reporte responsable, pero son un ejemplo perfecto del tipo de ataques al que nos vamos a enfrentar hoy en día. Entretenidísimos vamos a estar.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Serverless & Bullet-Proof Web Sites (2 de 2): Web2Blocks & WebScalerAI

En la primera de este artículo: "Serverless & Bullet-Proof Web Sites (1 de 2)" terminamos hablando de cómo utilizar Web3 para hacer paneles de control para botnets o redes sociales utilizando arquitecturas Dapps, pero lo dejé ahí porque quería esperar a la RootedCON 2024 de este año para hablar de los proyectos que hicimos nosotros de continuación de estas ideas.

Figura 1:Serverless & Bullet-Proof Web Sites (2 de 2): Web2Blocks & WebScalerAI

El primero de ellos es Web2Blocks para guardar páginas web en cadenas BlockChain, y el segundo de ellos es WebScalerAI, que busca reducir el tamaño de las páginas web que hay que almacenar en una cade de bloques utilizando GenAI para amplificar texto e imágenes de páginas web. Os los enseño un poco.

Web2Blocks: Un Web back-end en BlockChain

El objetivo de este proyecto es bastante sencillo, se trata de almacenar una página web, por ejemplo un blog como éste, en una estructura de bloques de una cadena de BlockChain, que evite que se pueda censurar siempre y cuando se conozca la estructura de bloques que almacenan la web. 

Figura 2: La extensión permite anclar una web en una cadena BlockChain

Para ello hicimos una extensión que hace las dos funciones, la de guardar en bloques de la cadena de BlockChain el contenido de la web, y la de buscar una web buscando los bloques que conforman esa web para poder cargarla en el navegador.

Figura 3: Índice de bloques de la web "blog"

Así, se busca el contenido en todos y cada uno de los bloques marcados en el "índice de bloques" de una determinada web - que para nuestra PoC - almacenamos con un nombre simple, y se recompone la página en el cliente. 

Figura 4: La extensión permite buscar web por su nombre

Las posibilidades de esta arquitectura son muchas, para evitar que se borren contenidos, que se censure una web, o para evitar que pueda ser eliminada,

Figura 5: La extensión descarga la web de la cadena de Blockchain y la pinta

Por supuesto, en esta arquitectura se puede aún añadir una capa mayor de protección, permitiendo que la página web esté cifrada y cargada desde un SmartContract, y que este SmartContract solo descifre el contenido de esa web si el usuario ha decido abrir la web con un Latch Web3.

Figura 6: Uso de Latch Web3 para proteger transacciones en un SmartContract

Al final, se trata de jugar con una arquitectura web que utiliza otras estructuras de almacenamiento para, usando las tecnologías Web3 darle más control al creador del contenido de esa web.

Figura 7: Misma web cargada desde HTTP Server y BlockChain

Pero claro, almacenar una página web con muchos elementos, puede tener un tamaño que hagan muy caro utilizar estructuras BlockChain, así que se nos ocurrió que podríamos usar GenAI para reducir el tamaño de la web.

Figura 8: Demo de Web2Blocks en vídeo

Y ahí nació la idea de WebScalerAI, que ahora paso a contaros con esta pequeña PoC que tenemos a continuación.

Figura 9: Hacking Web3: Challenge Accepted! de Chema Garabito, Pablo González,

Yaiza Rubio, Leif Ferreira, Chema Alonso en 0xWord.

WebScalerAI: Comprimir y Descomprimir Webs con GenAI & DeepLearning

La idea es bastante sencilla. Se trata de reducir el texto de una web, haciendo una reducción del texto y de las imágenes que se almacenan en el backend, por ejemplo en una cadena de BlockChain como en el caso anterior de Web2Blocks.

Figura 10: Una web con imágenes a mínima calidad y texto en "Prompting"

ocupa 400 Kb

Para ello, los textos se podrían reducir por un "Prompt" para un LLM/SLM que corriera en un entorno Cloud, o como creemos nosotros que será en el futuro, que es en cada aplicación. Esto significarían que tendríamos un navegador web con un SLM como parte de sus funcionalidades.

Figura 11: Expandida esta web pesa 1.5 MB entre texto e imágenes

Así, sólo habría que enviar el Prompt y una extensión del navegador, como la que tenemos en nuestra PoC hace el "inflado" del texto para que se pueda leer.

Figura 12: Super-reducida ocupa 100Kb

Con las imágenes, la misma idea. O bien contar con una generación mediante Prompting de un algoritmos de difusión que corriera en el navegador, o bien mediante el envío de una imagen de un tamaño muy pequeño y su ampliación mediante IA.

Figura 13: Página expandida con WebScalerAI

Para nuestras pruebas hicimos todo tipo de combinaciones, y probamos incluso Transformers en el navegador con la librería transformers.js que tenéis en GitHub - que es un SLM tipo distilbert - y para ampliación de imágenes en el navegador usando DeepLearning (CNN) usamos la librería waifu2x-js que tenéis en GitHub.

Figura 14: Transformers in your browser

Al final, el resultado es el que véis en el vídeo. Una web con un texto y una serie de imágenes se puede comprimir o descomprimir usando GenAI & DeepLearning para lograr - cuando el objetivo sea el mínimo tamaño -, reducir al máximo el peso de una web.

Figura 15: WebScalerAI - Comprimir y Descomprimir Webscon GenAI & DeepLearning

Al final son sólo pruebas y propuestas de nuestro equipo de "Ideas Locas" para seguir creando pasitos que nos lleven a entender mejor este mundo, y tomar mejores decisiones en todo lo que construimos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

JORNADAS_ABIERTAS: \\ Tu futuro es la programación #HackYourCareer

Hoy quería invitaros a la iniciativa de nuestros compañeros de GeeksHubs Academy, donde vas a poder disfrutar de 4 clases gratuitas para comenzar a programar. Es decir, 4 sesiones para que te pruebes en algo que seguro que has pensado muchas veces: Aprender a Programar y cambiar tu futuro profesional. 

Figura 1: JORNADAS_ABIERTAS: \\ Tu futuro es la programación #HackYourCareer

Pues ahora lo puedes probar gratuito en estas 4 sesiones con el gran David Ochando, que es uno de los grandes formadores de GeeksHubs Academy, y que te va ayudar a comenzar pasito a pasito en este mundo de la programación. De ser Developer.

Figura 2: David Ochando, Senior Full Stack Developer y Docente en

GeeksHubs Academy. Contactar con David Ochando en MyPublicInbox

Las sesiones comienzan el día 25, y tienes un calendario con una sesión cada semana, para que el mes que tienes por delante puedas ver si estás hecho o no para ser programador, que ya verás que todo el mundo puede programar. Aquí vas a ver cómo sí que puedes.

Figura 3: Cuatro sesiones abiertas para comenzar en programación

Para poder asistir solo debes apuntarte en el siguiente formulario, así que date prisa, resérvate el hueco en la agenda estos cuatro días a partir de las 18:30 de la tarde y date el gustazo de comenzar a programar.

Figura 4: Registrarte en las jornadas abiertas cuanto antes

Y si tienes alguna duda aún para decidirte, respóndete a estas preguntas que seguro que en tu cabeza tienen una respuesta clara.

Figura 5: Registrarte en las jornadas abiertas cuanto antes

Yo te recomiendo, si quieres probar a ver si vales, no vas a tener una mejor manera de hacerlo en mucho tiempo, porque son 4 sesiones con una gran docente que te va a ayudar a dar los primeros pasitos, y verás como te sientes sabiendo que puedes "codear" y "crear" cosas con tus manitas.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

#HackYourCareer convirtiéndote en Frontend Developer y comenzando a trabajar ya con @GeeksHubsAcademy

La iniciativa de #HackYourCareer que comenzamos con Chema Alonso tiene el único objetivo de que los alumnos acaben trabajando de lo que quieren trabajar, sin ser una barrera los conocimientos que tengan al inicio de su periodo formativo. Para eso, las formaciones más intensas son nuestros "Bootcamps" o campos de aceleración formativa que hacemos de manera muy intensa con los alumnos, que pasan a vivir durante la inmersión solo pensando en el objetivo. Alcanzar los objetivos del BootCamp para entrar a trabajar en esa disciplina profesional en el menor plazo posible.

Figura 1: #HackYourCareer convirtiéndote en Frontend Developer

y comienza a trabajar ya con @GeeksHubsAcademy

Como dice Chema Alonso, "hay cosas que se aprenden aprendiendo y cosas que se aprenden haciendo", y en nuestros bootcamps de la iniciativa #HackYourCareer implantamos de forma intensa las herramientas necesarias para que puedan aprender haciendo lo antes posible, y en un entorno deseable, acaben trabajando en equipos tecnológicos como los de Chema Alonso, que tiene abiertas un buen número de vacantes.

Figura 2: 48 vacantes abiertas en la unidad CDO de Telefónica que dirige Chema Alonso

Como queremos llegar al máximo posible de personas, hemos decidido hacer un nuevo formato de BootCamp Online, donde vamos a tener el mismo nivel de inmersión, pero haciendo las sesiones Online y Full-Time, similares a los entornos de trabajo remoto o híbrido que tienen, por ejemplo, unidades como la CDO de Chema Alonso, y cada vez más empresas, donde los equipos cuentan con personas distribuidas geográfica.

Figura 3:  NUEVO Bootcamp Online Frontend Developer

Para ello, comenzamos con un NUEVO Bootcamp Online Frontend Developer, en modalidad 100% Online y Full- Time con el objetivo de encontrar un nuevo empleo en este sector profesional, que dará  comienzo el próximo 15 de mayo y durará 10 semanas. Eso sí, para que funcione esta modalidad, tiene que mantener el espíritu de un BootCamp, así que son grupos reducidos con plazas limitadas para que los docentes puedan estar encima de los participantes en todo momento. 

Figura 4: Contenidos del NUEVO Bootcamp Online Frontend Developer

Además, con el objetivo de entender mejor cómo funciona este mundo profesional, todos los asistentes tendrán una sesión de Q&A con nuestro compañero Chema Alonso, que vendrá a resolver dudas de cómo funcionan los equipos de alto rendimiento de creación de tecnología para que puedas conocer de primera mano en qué consiste este trabajo.

Figura 5: Visita y charla de Chema Alonso al BootCamp de Frontend Developer

Y podrás completar tu formación preguntando a profesionales con Tempos de MyPublicInbox que te vamos a entregar, y seguir formándote con un libro de la editorial de 0xWord, y con una matrícula gratuita de Curso Online de Programación de GeeksHubs Academy para que sigas formándote de manera continua.

Figura 6:  NUEVO Bootcamp Online Frontend Developer

El trabajo de nuestro equipo docente consiste en ayudarte a interiorizar los hábitos de trabajo y formación continúa de los profesionales tech que dedican su actividad profesional a la creación de tecnología, y para ello deberás tener siempre activo el bit de aprender. Y para resolver las dudas que puedas tener, te dejo respondidas estas cuestiones que pueden pasar por tu cabeza.

Desde Cero

- ¿Cómo funciona?

Este Bootcamp es especial, ya que adapta la modalidad full-time presencial de nuestra coding school y la traslada al formato ONLINE. Es decir, requiere de una dedicación completa y el alumnado recibe el mismo acompañamiento exhaustivo por el equipo docente, desde casa. El horario del Bootcamp es intensivo, durante 10 semanas, de 9h a 18:30h (de lunes a jueves) y de 9 a 14h (los viernes).

Figura 7: David Ochando, José Marín y Daniel Tarazona son parte del equipo docente

de  NUEVO Bootcamp Online Frontend Developer

- ¿Para quién es el Bootcamp Online Frontend Developer?

Está pensado para formar desarrolladores web que aprendan HTML5, CSS3, Bootstrap, JavaScript, Typescript, React, Redux, etc, para que sean capaces de desarrollar una aplicación web en la parte Frontend, trasladando el diseño a lenguajes de programación, teniendo en cuenta la experiencia de usuario (UX/UI) y asegurando la funcionalidad, eficiencia y seguridad con conocimientos sobre Calidad del Software y Testing. Para acceder al Bootcamp no se necesitan conocimientos previos, pues los primeros bloques están dedicados a la introducción al desarrollo de software y las herramientas que debe conocer el alumno/a (VSCode, Git, GitHub…).

- ¿Por qué destaca la modalidad presencial de GeeksHubs Academy y qué tiene que ver con este nuevo Bootcamp Online?

Porque la metodología de aprendizaje pone al alumno/a en el centro. A través de proyectos todas las semanas se recrea un entorno de empresa tecnológica real, dónde la actitud y autonomía son indispensables. Tenemos más de 6 años de experiencia impartiendo Bootcamps presenciales, en los cuáles el 94% ha encontrado un nuevo empleo. En este nuevo Bootcamp Online la didáctica y metodología se mantiene para que el alumnado reciba el mismo nivel de acompañamiento que si estuviese en un aula presencial de GeeksHubs Academy.

- Una vez finalizado el Bootcamp… ¿Cómo ayudamos en la búsqueda de empleo?

Disponemos de un amplio abanico de empresas con las que trabajamos y que demandan talento, por lo que al finalizar, incluimos al alumnado en nuestra bolsa de empleo específica para que empiecen su carrera profesional como developer. Durante la formación nuestro equipo especializado asesora a nuestro alumnado, preparando los procesos de selección y mejorando sus soft skills.

- ¿Por qué elegir GeeksHubs Academy?

En GeeksHubs Academy sabemos que la pasión, el hambre y las ganas van por delante de cualquier cosa, y eso es lo que diferencia a un buen profesional. También sabemos lo que necesitan las empresas y estamos convencidos de que el valor diferencial está en la actitud.

La experiencia de formación de nuestra coding school va más allá de las competencias técnicas, buscamos impulsar tu carrera y acompañarte durante el camino para que crezcas como profesional y consigas todo lo que te propongas.

Contamos con un equipo de docentes tan entusiastas como exigentes con el objetivo de hacerte brillar y sacar todo tu potencial, así como un equipo de atención al alumnado dedicado exclusivamente al bienestar de cada estudiante.

Nuestra trayectoria de más de 10 años, los más de 1.000 alumnos y alumnas al año que pasan por nuestra coding school y la confianza de numerosas empresas que amplían sus equipos IT con el talento que se forma en GeeksHubs Academy evidencian nuestro éxito como escuela de programación que está cambiando el paradigma de la educación tech.

Hack Your Career!

Autor: Chaume Sánchez, CEO de GeeksHubs

Contactar con Chame Sánchez, CEO de GeeksHubs

Google Blogger: Conectividad, Usabilidad y situaciones de DeadLock

Los que me conocéis ya sabéis que soy un nómada digital en toda regla. Trabajo desde cualquier sitio con total normalidad. No me importa mientras tenga una conexión a Internet que me conecte a la red, y pueda hacer todas mis tareas. Y una de las tareas que más hago es publicar mi artículo. Lo hago todos los días - o casi, casi, casi todos -. No importa dónde esté. No importa el país del mundo donde ande.

Figura 1: Google Blogger: Conectividad, Usabilidad y situaciones de DeadLock

Esto me ha llevado a encontrarme con innumerables situaciones con las herramientas que utilizo que ya le hubiera gustado a un QA poder probar, y por tanto, me encuentro con fallos que son muy difíciles de encontrar. Entre otros, aquellos en los que la conectividad es pieza clave del escenario de evaluación, como el que os voy a contar ahora mismo.

Blogger, y los cuadros de diálogo bloqueantes

Desde que en el año 2006 comencé a escribir "Un informático en el lado del mal", he utilizado siempre la plataforma de Blogger de Google. La he visto crecer, la he visto detenerse, y la veo hoy en día en modo "mantenimiento" donde no hay mucha inversión en ella desde la última actualización.

Una de las cosas que me mata de ella, es un Bug de Usabilidad y Pérdida de Trabajo que tienen los cuadros de diálogos bloqueantes del interfaz de edición de artículos. Estos cuadros de diálogo los utilizan para, por ejemplo, subir contenido multimedia - imágenes, vídeos, etc... - al artículo o para, simplemente, poner un hipervínculo.

Cuando está el cuadro de diálogo bloqueante, no puedes interactuar con ninguna parte del interfaz de usuario que no sea un componente de ese cuadro de diálogo. Así que, si quieres "Guardar cambios", o "Publicar" no puedes hacerlo, porque esos controles están fuera del cuadro de diálogo.

Supongo que esto tiene cierta lógica dentro de la cabeza del responsable de producto, ya que lo que desea es que esa función se acabe para pasar al siguiente punto del flujo de la lógica de ese caso de uso. No debería pasar nada con ese cuadro de diálogo, porque el usuario siempre puede hacer clic en la X, dar a la tecla ESC y cerrar el cuadro de diálogo, volviendo al flujo del caso de uso anterior.

Pero, por desgracia, durante el tiempo que está produciéndose la carga de los componentes de esos cuadro de diálogo bloqueante puede pasar cualquier cosa. Así que, si el componente del cuadro de diálogo carga en último lugar el componente del botón cerrar (la X), puede darse una condición de carrera muy desagradable y no habrá forma de llegar a los controles de "Guardar Cambios" o "Publicar", y te quedas, literalmente, colgado de la brocha. 

Figura 2: Cuadro bloqueante de "Añadir Imágenes"

En estos casos, algo que me ha pasado a mí en muchas situaciones de conectividad inestable, culpa de mi vida de nómada digital -, puede suceder que se inicialice el cuadro de diálogo bloqueante, haya un corte con la conectividad y la carga de sus componentes no se completa, se puede dar una desagradable situación como la que me sucede muchas veces en Blogger.

Figura 3: Configurar un enlace. Cuando lo escribes, se activa "APLICAR"

Otro que me destroza se produce con el cuadro de diálogo de configurar un enlace. En este caso, el botón "Aplicar" se produce después de que se ha lanza un evento que comprueba que has puesto un valor en el cuadro de texto donde debe ir el enlace, como se ve en la imagen anterior. Pero si se corta la conectividad y no carga completamente el código del botón "Aplicar", se da el caso como el que veis aquí, donde el botón Aplicar no se activa. Da igual que regrese la conectividad a tu equipo, si no carga en ese instante, estás en Interbloqueo (DeadLock).

Figura 4: Un deadlock por perdida de conectividad temporal poniendo un enlace.

En cualquiera de estas dos situaciones, por no contemplar las situaciones de pérdida de conectividad temporal en "el peor momento", se produce un bug de usuabilidad que lleva a la pérdida del trabajo del usuario.

Menos mal que me conozco bien las "Developer Tools" y cuando esto me pasa me voy al inspector de código y salvo los cambios no salvados haciendo un poco de trabajo manual con el HTML del cliente web de Blogger que tienes cargado, pero es un bug grande solo por no pensar que, tal vez, el primer componente que debes cargar de un cuadro de diálogo bloqueante es el de poder Cerrar.

Por supuesto, hay otras soluciones, pero este comportamiento que tiene Blogger no es bueno, ya que provoca perdida de datos por no poder salvar los cambios. Y no hay forma de salir, estás en un interbloqueo de libro. Avisados estáis.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

WhatsApp: Usa Code Verify para evitar ataques a tu WhatsApp Web #WhatsApp

Hace unos diez días Meta y CloudFlare publicaron una extensión para Google Chrome llamada Code Verify, con la idea de que poder incrementar la seguridad de WhatsApp Web y evitar que, un ataque de hombre en medio, llevara a un cliente una versión de las librerías de JavaScript o alguno de los componentes manipulado utilizando la misma idea que usamos en SRI.

Figura 1: Usa Code Verify para evitar ataques a tu WhatsApp Web

Para que sea fácil de entender lo que hace esta extensión, hay que tener presente que WhatsApp Web es, en esencia, una Web App, y como toda aplicación web utiliza tecnologías Web que pueden ser atacadas, por lo tanto, hay que entender cómo puede ser atacada, y cómo puede ser protegida, utilizando las herramientas que tenemos a nuestra disposición.

Figura 2: Libro de "Hacking Web Technologies Silver Edition"

de Chema Alonso, Amador Aparicio, Pablo González,

Enrique Rando y Ricardo Martín en 0xWord.

En el caso del cliente web de WhatsApp, si alguien fuera capaz de ponerse en medio haciendo un cambio de los ficheros que están ejecutando, podría meter un JavaScript malicioso que robar los mensajes, que escribiera nuevos mensajes, o que directamente manipulara lo que está viendo un determinado usuario. Esto, es algo que hicimos nosotros en el experimento de Owning Bad Guys {and mafia} with JavaScript Botnets, donde inyectábamos, directamente, nuevos ficheros JavaScript.

Figura 3: WannaGram y WannaSapp

Pero también lo hicimos, para ejemplarizar cómo se pueden robar cuentas de WhatsApp con un gusano JavaScript creado como extensión de un navegador que atacaban al cliente WhatsApp Web y manipulaban el contenido. Ese experimento se llamó WannaSapp en su versión de WhatsApp Web y WannaGram en su versión de Telegram Web, y lo explicamos por primera vez en la charla de Social Worns & Frauds que puedes verte aquí.

Figura 4: Conferencia de Chema Alonso "Social Worms & Frauds"

Para evitar la manipulación y carga de ficheros JavaScripts maliciosos, lo que se utiliza es una tecnología conocida que tiene ya un tiempo en el mundo de los navegadores, llamada SRI o SubResource Integrity, que viene a garantizar que el recurso que se carga en una WebApp no ha sido manipulado. Esto está disponible en aplicaciones web desde hace tiempo para garantizar que el JavaScript remoto que cargas de un sitio no ha cambiado y se ha convertido en un "Gremlin" JavaScript que va a atacar a los usuarios de tu web.

Figura 5: Ejemplo de uso de SRI con etiquetas integrity y crossorigin en SCRIPT

Pues bien, lo que hace Code Verify es básicamente eso. Le pasa a Cloud Flare una lista con los hashes de todos los recursos que utiliza WhatsApp Web. Cloud Flare comprueba su seguridad, y los carga en el navegador del cliente vía la extensión a Code Integrity. 

Figura 6: Arquitectura de Code Verify con SRI de WhatsApp Web

Cuando en ese navegador, el usuario se descarga los ficheros de WhatsApp Web desde Meta, para que el usuario tenga un canal paralelo que le permita comprobar la integridad de los ficheros ya que el canal entre el cliente y Meta podría estar interceptado por un hombre en medio, cuando los ficheros son descargados, Code Verify comprueba que los hashes de ese fichero están intactos.

Figura 7: Resultados de Code Verify

Si esto es así, la extensión, te dará un bonito tic de color verde que garantiza que, Code Verify ha validado los hashes con la información que ha recibido vía canal paralelo desde Cloud Flare, y tendrás una capa más de seguridad para proteger tu WhatsApp Web.

Figura 8: Resultados de Code Verify en WhatsApp Web

Por supuesto que, siempre existe la posibilidad de hackear todo. Es decir, manipular los datos que recibe Code Verify (que usan canales cifrados de con sus servidores) para cambiar esa información, pero estaríamos hablando de un ataque muchísimo más complejo de ejecutar, lo que hace que reduzca mucho la exposición de seguridad del cliente WhatsApp Web a ataques de Man in the Middle, que es de lo que se trata.

Figura 9: Code Verify en Google Chrome

Así que, si usas WhatsApp Web y utilizas Google Chrome, no te va a hacer nada de daño tener instalado Code Verify y proteger con una capa de seguridad adicional tu cliente de mensajería de WhatsApp. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)