Cómo verificar tu cuenta de MyPublicInbox con verificación cruzada de tus redes sociales y ser un Perfil Público Verificado

Nuestros compañeros de MyPublicInbox han establecido un proceso de Verificación de tu cuenta utilizando tus redes sociales, ya sea Twitter/X, Instagram, Facebook, Youtube o Linkedin, con un proceso similar al que utiliza Mastodom para verificar sus cuentas, es decir, mediante una doble vinculación de cuentas.

Figura 1: Cómo verificar tu cuenta de MyPublicInbox con verificación

cruzada de tus redes sociales y ser un Perfil Público Verificado

Primero os cuento algunos de los servicios que están disponibles sólo para los Perfiles Públicos que se han verificado en MyPublicInbox, y luego os explico cómo hacer el proceso. Si no tienes cuenta de MyPublicInbox, aquí tienes un pequeño tutorial de cómo crearte una cuenta.

Figura 2: Cómo crearte una cuenta de MyPublicInbox

Servicios para Perfiles Públicos Verificados

Las cuentas Verificadas en MyPublicInbox tienen más servicios y capacidades que las cuentas que no se han verificado y no son Perfiles Públicos.  Tras hacer la vinculación y pasar el proceso de Verificación se habrán activado muchas funciones nuevas como: 

• Tener un Perfil Público visible: Sólo aquellos que han pasado un proceso de revisión tienen el perfil público visible en el que pueden ser descubiertos. Estos son los que se encuentran en la web en las diferentes categorías.

Figura 3: Perfiles Públicos de la categoría Real Madrid

• Recibir mensajes: Se activarán las bandejas de entrada para que puedan llegar mensajes a tu buzón público de cualquiera usuario de la plataforma que invierta Tempos en comunicarse contigo, lo que te permite tener un buzón abierto a Internet pero protegido y filtrado con Tempos. Esta es la funcionalidad principal de los perfiles públicos

• Recibir mensajes de agradecimiento: de la gente que podrás ver en “Mi Impacto en Internet > Agradecimientos”. Yo tengo todos mis mensajes de agradecimiento publicados en mi perfil de la red. Aquí os expliqué cómo funcionan los mensajes de agradecimiento en MyPublicInbox.

Figura 4: Los mensajes de agradecimiento que me dejan

• Tener Vídeo Conferencias: El servicio permite que una cuenta verificada pueda tener reuniones virtuales con cualquier usuario que quiera tenerlas. Yo las tengo habilitadas tanto para hacer negocios como para ayudar a estudiantes.  Os lo expliqué en mi artículo: "¿Quieres hacer algún proyecto conmigo?". Cuando seas un perfil público verificado puedes configurar en “Reuniones Virtuales > Configurar mis reuniones”.

Figura 5: Describe el motivo de petición de tu videollamada

• Análisis de tu “Reputación en Internet”:  Si tienes el perfil público verificado, podrás conseguir un análisis gratuito y solicitar el informe en “Mi Impacto en Internet > Reputación Online". De todo esto os hablé en el artículo:  "Calcula tu Índice de Reputación Online con MyPublicInbox & RepScan"

Pero no solo estás, también tienes servicios extras como Configurar Vídeo Saludos, Promocionar tus productos de Amazon, Publicar tu libro, Tener Salas de Chat, Servicios para Wikipedia, Redes Sociales, etcétera, que sólo están disponibles para los Perfiles Públicos.

Proceso de Verificación de tu cuenta de MyPublicInbox

El proceso que han diseñado los compañeros es muy similar al de verificar tu cuenta en Mastodom, cualquiera de los usuarios de MyPublicInbox puede tener un buzón y una cuenta verificada mediante un proceso que tiene tres fases:

1.- Configurar correctamente tu perfil de MyPublicInbox: Para ello, debes tener una biografía descriptiva, con información tuya profesional, con una fotografía tuya, y con los enlaces a tus redes sociales. Tu cuenta, tiene un nombre de usuario que ese será el que se utilizará para tener tu perfil público visible. Es importante que estén las redes sociales de Twitter/X, Instagram, Youtube, Facebook y/o Linkedin que vas a utilizar para la verificación cruzada de tu cuenta.

Figura 6: En tu perfil deben estar las redes que

vas a usar para la verificación cruzada

2.- Enlazar tu perfil de MyPublicInbox en tus redes sociales: Tu perfil de MyPublicInbox, una vez verificado, estará visible en https://MyPublicInbox.com/Tu_Nombre_De_Usuario, así que deberías poner en la descripción de tu cuenta en redes sociales un enlace a él, para poder garantizar que tienes control de las dos cuentas. Una vez acabado el proceso, esa URL que has puesto, mostrará tu perfil en MyPublicInbox. Aquí tienes ejemplos de cómo lo puedes configurar en tus redes sociales.

Figura 7: En Mi cuenta de Twitter está mi perfil de MyPublicInbox en la descripción

3.- Enviar un mensaje a Héctor pidiendo la verificación: El proceso de verificación tiene una primera fase manual, y otra automática. La fase manual va a revisar los datos, la información publicada en las redes sociales y en el perfil de MyPublicInbox para comprobar que no hay nada raro. Se descartan cuentas con verificaciones cruzadas de redes sociales sin antigüedad, y sin enlazar el perfil de MyPublicInbox. 

Figura 8: Contacta con Héctor para verificar tu cuenta (tiene coste 0 Tempos)

Una vez pasada esta fase, la plataforma comprobará la verificación cruzada periódicamente buscando el enlace en la descripción de la cuenta en la red social, para garantizar que la cuenta sigue estando controlada por la misma persona.

Bonus Track

Si utilizas tu cuenta de Twitter/X para verificar tu cuenta, además, puedes seguir a MyPublicInbox en X/Twitter, y te llegarán las alertas de nuevos mensajes, soporte y ayuda a través de esta red social, así que toma nota.

Figura 9: MyPublicInbox en Twitter/X

Y nada más que animaros a que probéis MyPublicInbox, que no sólo te ayudará a filtrar tus comunicaciones de Internet, sino que te ayudará a tener más presencia y más servicios para potenciar tu impacto en la red.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Codebreaker, TrojanPuzzle, Covert & Simple: Cómo envenenar LLMs para inyectar Bugs & Backdoors en los programas que haces con los Copilots de Developers

Los LLMs creados para ayudar a los developers para generar tecnología se usan para muchas tareas, como es el caso de GitHub Copilot, Code Whisperer o cualquier solución con GPT4. Por supuesto, para tirar líneas de código sugiriendo la siguiente instrucción a escribir mediante un proceso de Code Completion, aunque también se pueden utilizar para arreglar programas, factorizar el código, sugerir mejoras de optimización, o documentarlo. Es una herramienta fundamental para los developers y por eso las líneas de investigación en este campo es una de las más activas.

Figura 1: Codebreaker, TrojanPuzzle, Covert & Simple - Cómo envenenar LLMs para

inyectar Bugs & Backdoors en los programas que haces con los Copilots de Developers

Nosotros decidimos comenzar a utilizar GitHub Copilot hace dos años, y la idea es seguir profundizando cada vez más en su uso, pero tenemos claro que la seguridad es algo aún una línea en la que se tiene trabajar, como hemos visto en muchos estudios. En el año 2021 tuvimos ya los primeros artículos académicos sobre el código inseguro y vulnerable generado por GitHub Copilot. 

Figura 2: Papers sobre el código inseguro que genera Copilot

Nosotros estuvimos probando en nuestro equipo de Ideas Locas cómo era cierto que te generaba código inseguro y vulnerable con bugs conocidos. Por supuesto, si vamos a modelos LLM generalistas, donde no se metían validaciones extra de seguridad, podrías encontrarte bugs SQL Injection de libro, pidiéndole a ChatGPT un procedimiento en PHP para autenticar una página web, tal y como veis a continuación.

Figura 3: Código PHP con bug de SQL Injection generado por ChatGPT

De hecho, un estudio de Diciembre del año 2022 lo que venían a decir es que quedaba trabajo que hacer, ya que los programadores que usaban los asistentes de Code Completion basados en LLMs hacían código con más vulnerabilidades que los que no lo hacían.

Figura 4: Do users write more insecure code with AI assistants?

Por supuesto, en estos modelos se han ido añadiendo protecciones para detectar si un código generado en la salida de un Prompt es inseguro, y hoy en día se pasan los códigos por herramientas de Análisis Estático de código para detectar la inyección de vulnerabilidades en el código sugerido por el LLM. 

CODEBREAKER: Envenenamiento de LLMs para generar código vulnerable

Esto ha abierto otra línea de investigación, que tiene que ver no ya con detectar el código vulnerable sino en ver si es posible envenenar maliciosamente el LLM para hacer que el código que salga sea inseguro. Una forma de poner el backdoor en el código mediante un ataque al Copilot. Al final, la idea es tan sencilla como envenenar los datos de entrenamiento programas inseguros, que es lo que sucedió de manera natural para que GitHub Copilot, ChatGPT o CodeWhisperer generen código inseguro ( o API Keys y Secretos ).

Figura 5: Envenenamiento de Data Corpus con el método SIMPLE

Los trabajos anteriores de estas técnicas, se basan en tres métodos, conocidos como SIMPLE, COVERT y TROJANPUZZLE. El primero de ellos, es tan simple como reemplazar el código seguro por el código inseguro sin hacer nada más. Esto lógicamente generará que si hay alguna herramienta de Análisis Estático de Código, que sea detectado.

Figura 6: Método COVERT, con payload en comentarios

Una segunda aproximación es la que propone COVERT, que se basa en meter los payloads en DocStrings, como si fueran comentarios. Al final son textos que el LLM utilizará también para ser entrenado, y por tanto envenenará su aprendizaje. 

Figura 7: TrojanPuzzle: Covertly Poisoning Code-Suggestion Models

Por supuesto, si el proceso de Data Curation elimina los comentarios, resuelto el problema, por eso el paper anterior proponía un método de envenenamiento dividiendo el payload malicioso con la vulnerabilidad que implanta el Bug o Backdoor en el código usando varias partes. Es decir, resolviendo un puzzle parte a parte en la inyección del código.

Figura 8: Ejemplo de payload inyectado como TrojanPuzzle

El último es CODEBREAKER, que es de lo que trata el artículo "An LLM-Assisted Easy-to-Trigger Backdoor Attack on Code Completion Models: Injecting Disguised Vulnerabilities against Strong Detection" del que quería hablaros hoy, que me ha gustado mucho su aproximación, y que podéis leer ahí mismo, pero que yo voy a intentar resumiros.

Figura 9: An LLM-Assisted Easy-to-Trigger Backdoor Attack

on Code Completion Models: Injecting Disguised Vulnerabilities

against Strong Detection

En este caso el objetivo es ver cómo se pueden hacer envenenamiento de datos para que el LLM de Code Completion que haya sido entrenado con esos datos escupa código inseguro, incluso si tiene herramientas de validación de la salida usando herramientas de Análisis Estático del código. Es decir, el atacante tiene la posibilidad de poner código malicioso en su repositorio porque este va a ser utilizado para entrenar un LLM de Code Completion, pero... tiene protecciones de seguridad y no es tan fácil.

Figura 10: Inyección de bugs saltando protecciones

Si os fijáis en el gráfico anterior, para evitar el evenenamiento primero hay un proceso de Data Curation en el cuál se usa también LLMs (en este caso GPT-4) para hacer algo que también es parte de la labor de los LLMs en el proceso de ayudar a la creación de tecnología, que es la búsqueda de vulnerabilidades. En este artículo "Cómo buscar vulnerabilidades en SmartContracts, SQL Injection, XSS o bugs Python con ChatGPT"  os ponía algunos ejemplos de esto. 

Figura 11: ChatGPT encuentra el bug de Reentrancy Attack

El objetivo de ese proceso es descartar de los datos de entrenamiento a aquellos códigos que sean inseguros para que no esté entrenado con ellos. Así que conseguir el bug inyectado en el repositorio malicioso llegue al modelo de entrenamiento exige hacer un proceso de "Smuggling" o "Contrabando" del bug. Es decir, ocultar el bug en el proceso de análisis. Este proceso se hace mediante un Payload Transformation que busca saltarse las herramientas como podéis ver en el gráfico siguiente.

Figura 12: Algoritmo de Payload Transformation

Esto es mucho más fácil de lo que parece. La idea es que el atacante sabe cuáles son las herramientas de Análisis Estático de Código con las que se está haciendo la detección de vulnerabilidades, así que antes de subir el código con bugs al repositorio de GitHub hay que hacer variaciones del payload hasta que se consiga que no sea detectado por ninguna o que tenga un scoring muy pequeño. Por supuesto, para hacer el Payload Transformation, nada mejor que utilizar un LLM como GPT-4, como podéis ver en la imagen.

Figura 13: Payload Transformation con GPT-4

En el ejemplo del artículo, las herramientas Análisis Estático de Código contra las que han evaluado los paylodas modificados han sido Bandit, CodeQL y SemGrep, que son Open Source, y contra las herramientas comerciales SnykCode y SonarCloud. Los datos que tenéis en la tabla siguiente se basan en probar tres bugs concretos (1),(2) y (3) que son primero variados con transformaciones pre-establecidas - un total de 36 - y que luego pasan por el proceso de Payload Transformation con GPT-4 cada una de ellas para conseguir 4 iteraciones más, y los resultados son los que tenéis aquí.

Figura 14: Resultados de Éxito de Smuggling con el Payload Transformation

No siempre se consiguen pasar todas las herramientas, pero si el atacante sabe cuáles son las que utiliza ese LLM para hacer el Data Curation se puede afinar el ataque (ya sabes por qué es tan importante que no pongas en tu Linkedin las herramientas que usas en tus trabajo de seguridad). La tabla siguiente muestra que en una media de 3 iteraciones del Payload Transformation, para diferentes tipos de Bugs a inyectar, se supera el 100% de de las herramientas de Análisis Estático de Código y loas detecciones con 

Figura 15: Resultados para pasar la detección

Podría parecer que ya hemos conseguido el objetivo, pero nada de eso. Sólo hemos conseguido meter el payload con el bug en el Data Corpus de entrenamiento, pero ahora nos queda una segunda fase de seguridad, que es la que valida el código cuando el LLM de Code Competion lo va a escupiendo y que además este sea funcional. En este caso se trata de conseguir engañar también a cualquier otro análisis posterior, así que los investigadores añaden un proceso de ofuscación de código basado en las herramientas Pyarmor y Anubis, con el objetivo de que el payload que se inyecte en los programas sea de difícil descubrimiento para el developer o para otro programa no evaluado de Análisis Estático de código que haya verificando la salida.

Figura 16: Resultados en diferentes pruebas.

El resultado al final es que se consiguen, ratios grandes de inyecciones de bugs & backdoors, y que además, las generadas por CodeBreaker (CB) llegan todas a la sugerencia del developer, mientras que los que se introducen con SIMPLE, COVERT o TROJANPUZZLE ya son detectadas todas (y por eso pasan a -> 0). 

Las otras pruebas de la Figura 16, con las baterías de datos de entrada en forma de Texto, de Código Aleatorio, o con un Código Concreto como Objetivo, consiguen inyectar sugerencias  que no son detectadas tanto pasando entornos de auditoría de herramientas de StaticAnalysis (CB-SA), con verificación de GPT vía API (CB-GPT) o verificación vía web de ChatGPT (CB-ChatGPT) para que alerte de si hay o no vuelnerabilidad en esa línea. 

Conclusiones.

Al final, en Codebreaker en el Data Corpus con el que se entrena el modelo LLM para Code Completing ya va inyectado el código mutado, verificado contra los motores SA y GPT, además de ofuscado para asegurarse de este resultado que vemos en la Figura 16 siempre pasen todos. Pero... esto es un juego del gato y el ratón, y una actualización de los motores de Análisis Estático de Código detecten que su motor está lanzando código malicioso mañana.

Figura 17: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Esto implica a que los equipos de pentesting, va tener que tener que implementar pruebas de QA de Seguridad de los LLMs constantes para detectar cuándo un Copilot de Code Completing está escupiendo código inseguro por defecto o por envenenamiento, lo que abre una nueva línea de trabajo de Continuous Monitoring de LLMs para Copilots de Developers.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)