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)