Los agentes de inteligencia artificial que liquidan llamadas a APIs mediante los SDK de x402 podrían terminar firmando un pago por todo su saldo de un token compatible si una API maliciosa se lo solicitara, de acuerdo con la firma de seguridad V12, que dio a conocer el hallazgo el 22 de octubre.
El problema residía en el cliente predeterminado de los SDK, que no fijaba ningún tope de gasto hasta que las versiones publicadas el 18 de agosto incorporaron uno. El riesgo alcanzaba únicamente a los agentes que firmaban pagos de forma automática y a las aplicaciones que no definían límites propios.
La falta de límite es una de las 25 fallas que V12 detectó en el código de x402 y una de las tres que clasificó como críticas y detalló. La Fundación x402, responsable de mantener los SDK, ya había subsanado las tres fallas críticas en las versiones del 18 de agosto.
Tres fallas críticas y una misma fecha de corrección
Otra de las fallas críticas permitía que un facilitador, el servicio encargado de verificar los pagos de x402, diera por válido un pago con una transacción de Solana que no movía tokens. Entre los SDK de x402, solo el de TypeScript presentaba este problema. La tercera falla permitía que un servidor malicioso lograra que un agente firmara un mensaje de inicio de sesión destinado a un sitio web distinto.
V12 identificó las fallas mediante revisión de código y pruebas locales. Ni V12 ni la Fundación x402 han reportado públicamente ataques que las exploten.
La fundación no ha divulgado ningún aviso de seguridad sobre las tres fallas, y sus registros de cambios enumeran las correcciones sin calificarlas como parches de seguridad. Al 23 de octubre, npm audit no devolvía avisos para las últimas versiones de TypeScript anteriores a las correcciones, y PyPI no listaba vulnerabilidades para la última versión de Python previa a ellas, según comprobó The Hacker News. Un desarrollador que dependa de esas comprobaciones no recibe advertencia alguna para actualizar.
Coinbase creó x402 y lo cedió este año a la Fundación x402, un proyecto de la Linux Foundation cuyos miembros incluyen a Visa y Mastercard. Coinbase ocupa el asiento de mayor rango en el comité directivo técnico de la fundación.
Sin límite de gasto en el cliente predeterminado
x402 es un estándar abierto que permite a software, incluidos agentes de IA, pagar una llamada a una API dentro de la propia solicitud web, sin requerir que una persona apruebe cada pago.
Un servidor que desea cobrar responde con el código de estado HTTP 402 Payment Required y enumera sus opciones de pago, cada una con un monto, un token y un destinatario. El cliente elige una, firma un pago y reenvía la solicitud.
El cliente predeterminado tomaba la primera opción de la lista y, antes de la corrección, no establecía límite alguno sobre el monto.
Una API hostil podría aprovechar esto para convertir una solicitud rutinaria de datos en una petición por el saldo completo de la billetera en un token compatible, según V12. Un pago pequeño anterior podría revelar la dirección de la billetera, de modo que el servidor podría consultar el saldo primero.
Con un firmante automático y sin una política de pago establecida por la aplicación, el cliente podría firmar un pago por ese monto. Para un token que admite transferencias firmadas, el atacante podría luego enviar el pago firmado y recaudar los fondos.
Las versiones del 18 de agosto añadieron controles de gasto a los clientes de TypeScript, Python y Go. Por defecto, ahora limitan cada pago a 1 dólar y permiten solo stablecoins de dólar estadounidense que el SDK reconoce, como USDC.
Aprobaciones de tokens aceptadas como pagos en Solana
En x402, el servidor de un comerciante se apoya en un facilitador para verificar cada pago y enviarlo a la blockchain. En Solana, el facilitador también paga la comisión de la transacción.
El código del facilitador de TypeScript para Solana comprobaba que un pago invocara un programa de tokens permitido, y luego lo interpretaba como una transferencia sin verificar el tipo de instrucción. Una aprobación de tokens, que permite a otra cuenta gastar tokens más tarde pero no mueve ninguno por sí misma, difiere de una transferencia solo en su primer byte.
En la prueba local de V12, el facilitador aceptó esa aprobación como un pago válido. La prueba no envió una transacción real.
Un comerciante que confiara en el facilitador podría por tanto entregar un recurso de pago sin recibir tokens, según V12, que lo calificó como "un bypass completo del pago". El atacante necesitaba una cuenta de tokens, pero ningún saldo, y el facilitador pagaba la comisión de la transacción cada vez.
Los SDK de Python y Go ya verificaban el tipo de instrucción. Las versiones del 18 de agosto añadieron la misma comprobación al código de TypeScript.
Todas las versiones publicadas de @x402/svm desde la 2.0.0 hasta la 2.22.0 carecen de la comprobación, y todas las versiones desde la 2.23.0 la incluyen, según comprobó The Hacker News al buscar en los paquetes publicados.
Inicios de sesión firmados para otros sitios web
x402 también tiene una extensión de inicio de sesión llamada Sign-In-With-X (SIWx). Permite a un agente iniciar sesión firmando un mensaje corto con su billetera, por ejemplo para demostrar un pago anterior en lugar de pagar de nuevo. En Ethereum, el mensaje nombra el sitio web, la dirección de la billetera y un código de un solo uso.
El cliente automatizado firmaba estos mensajes sin verificar que el sitio web nombrado en ellos fuera el que había contactado.
Un servidor malicioso podría obtener un mensaje de inicio de sesión nuevo de otro sitio, pasárselo al agente y usar la firma para iniciar sesión en ese sitio como la billetera del agente, según V12. Eso funcionaría dondequiera que el otro sitio aceptara el mensaje retransmitido, y el atacante obtendría el acceso que permitiera el inicio de sesión.
Las versiones del 18 de agosto hacen que los clientes de TypeScript, Python y Go se nieguen a firmar a menos que el sitio del mensaje coincida con el sitio que envió la respuesta 402. El proyecto también modificó la especificación SIWx, que ahora establece que un cliente debe negarse a firmar cuando los dos no coincidan.
El código TypeScript que llama directamente a createSIWxPayload ahora debe pasar la URL de la respuesta 402, después de cualquier redirección. Los envoltorios @x402/fetch y @x402/axios la pasan por su cuenta.
Qué actualizar
Actualizar a las últimas versiones también trae correcciones posteriores, incluida una para un bypass de pago separado en @x402/core 2.27.0 en septiembre. Al 23 de octubre, las últimas versiones son 2.28.0 para @x402/core, @x402/svm, @x402/extensions, @x402/fetch y @x402/axios, v2.28.0 para el módulo de Go y 2.25.0 para el paquete de Python.
En TypeScript, los clientes obtienen la corrección de gasto actualizando @x402/fetch o @x402/axios a la 2.23.0 o posterior, lo que arrastra el @x402/core correspondiente. Las aplicaciones que usan SIWx también necesitan @x402/extensions 2.23.0 o posterior, que contiene la comprobación de inicio de sesión. Los facilitadores que verifican pagos en Solana necesitan @x402/svm 2.23.0 o posterior.
Tras la actualización, los clientes existentes quedan limitados a 1 dólar por pago y restringidos a stablecoins reconocidas, a menos que la aplicación establezca sus propios controles de gasto. Las aplicaciones que pasan spendControls: false desactivan todos estos controles.
Los equipos que aún no puedan actualizar pueden registrar una política de pago que descarte cualquier opción por encima de un monto establecido. Los clientes anteriores lo permiten con registerPolicy en TypeScript y Go, y register_policy en Python, que además tiene una política max_amount ya preparada.
V12 aconseja a los clientes verificar que un mensaje de inicio de sesión SIWx identifique el sitio que contactaron antes de firmar, establecer presupuestos por pago y en total, y limitar qué tokens, redes y destinatarios están dispuestos a pagar.
Deja una respuesta