x402 SDK-Schwachstellen gefährden Wallets, Zahlungen und Logins
Die vom Sicherheitsunternehmen V12 offengelegten x402 SDK-Schwachstellen führten zu drei unterschiedlichen Risiken bei automatisierten Wallet-Ausgaben, der Zahlungsprüfung und Website-Logins. V12 fand bei einem Code Review und lokalen Tests 25 Schwachstellen und stufte drei davon als kritisch ein. Die x402 Foundation, die die Software Development Kits (SDK) betreut, behob alle drei in Releases, die am 18. August veröffentlicht wurden. Weder V12 noch die Foundation haben öffentlich über Angriffe berichtet, bei denen diese Schwachstellen ausgenutzt wurden.
x402 ist ein offener Standard, der es Software einschließlich Agenten für künstliche Intelligenz ermöglicht, für eine Anfrage an eine application programming interface (API) zu bezahlen, ohne darauf zu warten, dass eine Person jede Transaktion genehmigt. Ein Server fordert eine Zahlung an, indem er HTTP status code 402 Payment Required zusammen mit Optionen zurückgibt, die einen Betrag, einen digitalen Vermögenswert und einen Empfänger angeben. Der Client wählt eine Option aus, signiert die Zahlung und wiederholt die Anfrage mit der angehängten Zahlung.
Vor den Fehlerbehebungen wählte der Default-Client die erste Zahlungsoption aus, ohne einen Höchstbetrag festzulegen. Laut V12 konnte eine bösartige API statt einer kleinen routinemäßigen Zahlung das gesamte Wallet-Guthaben eines unterstützten digitalen Vermögenswerts anfordern. Eine frühere Transaktion konnte die Wallet-Adresse offenlegen, sodass der Server das verfügbare Guthaben abrufen konnte. Wenn eine Anwendung Zahlungen automatisch signierte und keine eigenen Einschränkungen konfiguriert hatte, konnte der Client den vollständigen Betrag genehmigen. Bei Vermögenswerten, die signierte Transfers unterstützen, konnte der bösartige Server diese Zahlung anschließend einreichen und das Geld erhalten. Das Risiko war auf Deployments beschränkt, die automatisches Signieren ohne Limits auf Anwendungsebene verwendeten.
Die TypeScript-, Python- und Go-Releases vom 18. August führten standardmäßige Ausgabenkontrollen ein. Jede Zahlung ist nun auf $1 begrenzt, und Clients zahlen nur mit anerkannten, an den US-Dollar gebundenen Vermögenswerten vom Typ stablecoin, darunter USDC, sofern die Anwendung keine anderen Kontrollen festlegt. Ein stablecoin ist ein digitaler Vermögenswert, dessen Wert dem eines anderen Vermögenswerts folgen soll, in diesem Fall dem US-Dollar. Anwendungen, die ausdrücklich spendControls: false festlegen, deaktivieren alle diese Schutzmaßnahmen.
Eine zweite kritische Schwachstelle betraf die Zahlungsprüfung für Solana im TypeScript SDK. Bei x402 prüft ein facilitator die Zahlung eines Händlers und übermittelt sie an die blockchain, den gemeinsamen Transaktionsdatensatz des Netzwerks. Bei Solana übernimmt dieser facilitator auch die Transaktionsgebühr. Der anfällige Code bestätigte, dass eine Zahlung ein zulässiges token program aufrief, prüfte jedoch nicht den instruction type, bevor er die instruction als Transfer interpretierte.
Ein token approval ermächtigt ein anderes Konto, später Vermögenswerte auszugeben, überträgt aber nicht sofort etwas. Es unterscheidet sich im ersten Byte der instruction von einem Transfer. Bei einem lokalen Test stellte V12 fest, dass der TypeScript-facilitator ein approval akzeptierte, als wäre es eine abgeschlossene Zahlung. Bei dem Test wurde keine Live-Transaktion übermittelt. Ein Händler konnte daher eine kostenpflichtige Ressource freigeben, ohne Geld zu erhalten, während der facilitator die Gebühr bezahlte. Der Anfragende benötigte ein token account, aber kein Guthaben. Python und Go prüften den instruction type bereits, und das TypeScript-Release vom 18. August ergänzte die fehlende Validierung. The Hacker News stellte fest, dass bei den Versionen 2.0.0 bis 2.22.0 von @x402/svm diese Prüfung fehlte, während sie in Releases ab 2.23.0 enthalten ist.
Das dritte kritische Problem betraf Sign-In-With-X (SIWx), eine x402-Erweiterung, mit der ein Agent durch das Signieren einer Login-Nachricht nachweisen kann, dass er die Kontrolle über eine Wallet besitzt. Bei Ethereum nennt diese Nachricht eine Website, eine Wallet-Adresse und einen Einmalcode. Der automatisierte Client prüfte nicht, ob die in der Nachricht genannte Website mit dem Server übereinstimmte, der die Zahlungsantwort gesendet hatte. Laut V12 konnte ein bösartiger Server eine neue Nachricht von einer anderen Website weiterleiten, die Signatur des Agenten erhalten und damit auf die andere Website zugreifen, sofern die weitergeleitete Nachricht dort akzeptiert wurde. Der daraus resultierende Zugriff hing davon ab, wozu der Login berechtigte.
Aktualisierte TypeScript-, Python- und Go-Clients verweigern das Signieren, wenn die Website in der SIWx-Nachricht nicht mit der Website übereinstimmt, von der die 402-Antwort kam. Die SIWx-Spezifikation schreibt nun dieselbe Prüfung vor. TypeScript-Anwendungen, die createSIWxPayload direkt aufrufen, müssen die URL der 402-Antwort nach Redirects angeben. Die Wrapper @x402/fetch und @x402/axios stellen diese URL automatisch bereit.
Trotz der von V12 vergebenen hohen Schweregrade veröffentlichte die Foundation kein Security Advisory zu diesen drei Problemen, und in ihren Changelogs wurden die Änderungen aufgeführt, ohne sie als Sicherheitskorrekturen zu kennzeichnen. Mit Stand vom 23. Oktober fand The Hacker News weder ein npm audit advisory für die letzten anfälligen TypeScript-Releases noch einen Schwachstelleneintrag auf PyPI für das letzte anfällige Python-Release. Entwickler, die sich ausschließlich auf diese Paketprüfungen verließen, erhielten daher keine Warnung, ein Upgrade durchzuführen. Coinbase entwickelte x402 und übertrug es in diesem Jahr an die x402 Foundation, ein Projekt der Linux Foundation, zu dessen Mitgliedern Visa und Mastercard gehören. Coinbase nimmt im Technical Steering Committee die höchstrangige Position ein.
Teams sollten aktuelle Releases installieren, statt beim ersten fehlerbereinigten Release stehen zu bleiben, da spätere Updates eine separate Korrektur vom September gegen die Umgehung von Zahlungen in @x402/core 2.27.0 enthalten. Mit Stand vom 23. Oktober waren die neuesten TypeScript-Versionen 2.28.0 für @x402/core, @x402/svm, @x402/extensions, @x402/fetch und @x402/axios. Das neueste Go-Modul war v2.28.0, während das Python-Paket bei Version 2.25.0 lag. TypeScript-Clients erhalten die Ausgabenkorrektur über @x402/fetch oder @x402/axios ab Version 2.23.0. Nutzer von SIWx benötigen @x402/extensions ab Version 2.23.0, und für Solana eingesetzte facilitator benötigen @x402/svm ab Version 2.23.0.
Teams, die nicht sofort ein Upgrade durchführen können, können eine Zahlungsrichtlinie konfigurieren, die Optionen oberhalb eines gewählten Betrags ablehnt. Ältere Clients unterstützen registerPolicy in TypeScript und Go, während Python register_policy und eine einsatzbereite max_amount-Richtlinie bietet. V12 empfiehlt außerdem, die in jeder SIWx-Nachricht angegebene Website zu prüfen, Limits pro Zahlung und für die Gesamtausgaben festzulegen sowie die zulässigen Vermögenswerte, Netzwerke und Empfänger einzuschränken. Teams, die Hilfe bei der Planung sicherheitsorientierter Infrastrukturarbeiten benötigen, können sich für IT, Infrastruktur und Beratung mit Sicherheit an erster Stelle an AEU-I wenden.