lunes, marzo 18, 2024

Cómo robar cuentas de ChatGPT con "Wildcard Web Cache Deception"

Si ayer os hablaba de tres bugs descubiertos en un Bug Bounty de ChatGPT, hoy os traigo otro que salió publicado este mes de Febrero y que habla de cómo robar cuentas de ChatGPT utilizando Wildcard Web Cache Deception , que es más que interesante, y que le valió 6.500 USD al investigador que lo descubrió.
El bug ha sido publicado una vez resuelto, pero es bastante curioso, ya que el problema se encuentra en la implementación que se hacía de la Cache de ChatGPT, y que el investigador explotó para hacer un ataque funcional que permitiera robar las cuentas de cualquier usuario que hiciera clic en un enlace malicioso, para ganarse su Bug Bounty.
Según cuenta en el artículo el propio descubridor del bug, se dio cuenta porque ChatGPT le estaba cachenado una petición cuando había dado a la opción de Share para compartir una conversación. Aunque siguiera actualizando la conversación, esta se quedaba estática en el enlace de compartición, porque todo lo que estuviera bajo /share/ se cacheaba automáticamente una vez visitada esa URL, ya que el servidor estaba usando el HTTP-Header Cf-Cache-Status:HIT en esa URL.
Sabiendo esto, lo siguiente era ver si podía generar una URL que tuviera el Token de autenticación de un usuario, pero bajo la dirección de una URL con el path /share/, y esto es posible porque la cache no es un servidor web que esté procesando la URL, y la está tomando como una dirección para generar un
 

ID
de objeto cacheado, así que si se utilizan %2F o wildcards para construir una URL que el servidor Web sí va a procesar, el servicio de Caché no lo va a hacer.
Una vez comprobado eso, basta con generar la URL correcta para que el usuario entregue su Token de autenticación, pase el proceso de autenticarse (o no), y deje su Token guardado en la caché para poder ser accedido después por el atacante.

En este caso, es necesario que la víctima haga clic en un enlace malicioso, tal y como se muestra en el esquema de ataque, pero es un 1-Click Owned! esquema, muy peligroso, que ChatGPT ya ha corregido, para eliminar este problema.
Al final, no es un problema del LLM, y no podríamos meterlo en ningún esquema del OWASP TOP 10 de LLM Apps & Services, que el problema es la implementación del sistema de compartición, pero es más que interesante cómo funciona este bug.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


domingo, marzo 17, 2024

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.
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.
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.
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.
¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares