T05 · Unauthorized Access and Privilege Escalation
- Location
kite-wallet.js:67- Finding
Unauthenticated Command Handler Allows Spending from the Shared Operator Wallet
- Content
View full analysis
<数量>\n\n` + `例: /kite send 0xABC... 0.1`; } const toAddress = args[0]; const amount = args[1]; // Validate address if (!ethers.isAddress(toAddress)) { return '❌ 无效的地址格式'; } // Validate amount const amountWei = ethers.parseEther(amount); const balance = await provider.getBalance(wallet.address); if (amountWei > balance) { return `❌ 余额不足\n\n` + `当前余额: ${ethers.formatEther(balance)} KITE\n` + `尝试转账: ${amount} KITE`; } const tx = await wallet.sendTransaction({ to: toAddress, value: amountWei }); await tx.wait(); ``` ### Technical Analysis `init()` creates a single process-wide ethers signer from the configured private key. Every invocation of `handleKiteCommand()` subsequently uses that shared signer. The handler accepts a `userId`, but it does not authenticate that identity, compare it against an owner allowlist, check a role, or verify a user signature before executing `/kite send`. The `userId` is not used at all in the transfer branch. Address and balance validation only validate transaction parameters; they do not establish whether the caller is authorized to spend the funds. Consequently, any caller whose message is routed to this handler can cause the shared operator wallet to sign and broadcast a native-token transfer to an arbitrary valid address. Security would ...[truncated 1291 chars]- Remediation
View remediation
