Cosmos | 报告 #2917368 - 升级期间替换ICA活跃通道及更多内容

影响摘要

此处存在2个潜在问题：

活跃通道在通道确认期间在控制器上设置。这是一个检查再执行的操作，且是原子性的。但GetOpenActiveChannel仅在通道打开时返回通道，而不包括正在刷新的状态。
活跃通道在通道打开确认期间在主机上设置，但检查通道是否存在的操作在try中完成。虽然包含了FLUSH*状态，但不是原子性的。

重现步骤

我们在源链上监控新初始化的通道。遍历返回的通道并对匹配的通道运行攻击。在所有内容启动后提交ICA创建（参见视频），此处负责执行受害者的部分。我使用原版本，因为版本会在升级过程中改变。主要思路是使这个新通道与合法通道不同。

攻击分为两个步骤：

准备工作。由于主机上的检查再执行操作不是原子性的，我们在控制器上的ICA通道初始化和主机上的ICA通道打开确认之间存在机会窗口。在此窗口期间，我们将在控制器上使用ICA端口和连接进行通道初始化，并在主机上进行通道尝试。
等待受害者通道开始升级。脚本将发起新编码的升级提案。但我们的通道将使用旧编码。编码需要在主机上反序列化交易。

提案通过后，攻击获取新的升级序列并执行整个通道更新。同时，它完成恶意通道的握手过程。

合法通道：channel-1，我的通道：channel-2 我也并行运行中继器，因为需要ICA通道像在现实世界中那样完成。但中继器也会拾取我的通道。在合法通道打开后停止它，但在握手期间打印以下消息：

1

error   Error sending messages  {"path_name": "demo", "src_chain_id": "ibc-1", "dst_chain_id": "ibc-0", "src_client_id": "07-tendermint-0", "dst_client_id": "07-tendermint-0", "error": "rpc error: code = Unknown desc = rpc error: code = Unknown desc = failed to execute message; message index: 1: channel open ack callback failed for port ID: icacontroller-cosmos1zr776t6fpjtyx8vqfhn0ene3jzm5q7nc2674d0, channel ID: channel-2: existing active channel channel-1 for portID icacontroller-cosmos1zr776t6fpjtyx8vqfhn0ene3jzm5q7nc2674d0: active channel already set for this owner [

这是正确的。错误正是来自这里。

但一旦升级开始后，我完成握手并通过：

1
2
3


channel acked
successfully acked channe on the source chainl channel-2 for port icacontroller-cosmos1zr776t6fpjtyx8vqfhn0ene3jzm5q7nc2674d0 and connection connection-0 
{"level":"info","msg":"Successful transaction","chain_id":"ibc-0","gas_used":105368,"fees":"3310stake","fee_payer":"\u001bZf\u0007\u00144u \ufffd\ufffd\ufffdx\ufffdh\ufffd\ufffdT\ufffdM\u0012","height":134,"msg_types":["/ibc.core.channel.v1.MsgChannelOpenAck"],"tx_hash":"1E1968F24B19D38D0C1ABA0212884E6D295796660862F99C249002739548EE40"}

然后它也在主机上通过打开确认。我们为这个ICA设置了一个具有不同设置的新通道作为活跃通道。（需要安装Go，并确保没有simd运行）

我必须在ibc-go中进行调整以提交升级提案。从wasm轻客户端获取逻辑。我收到一个错误，说提案必须由治理模块签名（这很合理）。所以不确定这是错误还是需要设置权限账户。无论如何，请检出我修改的分叉或设置您的账户为治理权限（如果可能）。这样您将能够提交升级。并构建ibc-go make build。记下simd的路径（在build文件夹中）并在此处更改。（另外请注意，我们的恶意通道不会受到升级的影响，因为它没有打开。）

检出我的中继器ica分支。此攻击只需要demo文件夹。但还需要路径中的rly二进制文件，您可以从官方中继器或我的中继器构建。

检出https://github.com/unknownfeature/ibc-tools/tree/one，切换到分支one并将附加的main.go放到根目录。

修改main.go中的rootFolder以指向包含脚本的正确文件夹。

转到中继器/examples/demo（rootFolder）并运行./dev-env。等待直到看到此消息： “运行’rly start并运行active_channel.go，在所有内容启动后按ENTER”

运行main.go，它将打印2行并等待。之后打开另一个标签页并启动rly start。我们需要它完成ICA握手。但它也会尝试完成我们在攻击中发起的握手，最初会出错，但一旦我们通过确认，它将尝试继续我们的握手。这将完成与我们相同的事情，但我的小攻击可能会出错，对于演示目的来说不太好看。但即使中继器完成它，攻击的结果也将相同。所以我只是等待它打开合法通道并在打印"成功创建新通道{“chain_name”: “ibc-1"后停止它。应该在ibc-1上，这意味着握手结束。

在所有内容启动后，在dev-env请求的地方按"ENTER”。查看攻击的输出。这将需要一些时间。我将提案等待期设置为30秒。但我也等待ICA通道20秒。

我还想说，有时我的通道确认比合法通道更快到达源链。这就是我在这里休眠的原因。但这也是一个有趣的使用案例。在某些情况下，活跃通道将在握手期间设置为错误的通道。非常机会主义。谁知道它在现实生活中会如何表现。

解决方法

看起来没有

支持材料/参考

active_channel_upgrade.mov - POC视频 main.go - POC

影响

该应用程序提供了在升级期间（或有时在握手期间设置错误的活跃通道）用恶意通道替换已建立的活跃通道的机会。我们无法更改ICA地址，无法更改连接。唯一可以更改的是编码。这可以防止主机链反序列化ICA交易。因此需要另一次升级才能使用它。此外，考虑到没有查询方法来查看活跃通道是什么，这将需要一些调查。因此需要一些时间来弄清楚并使其重新工作。此外，我们可以预先设置不止一个而是多个通道。并为每次升级使用每个通道。

时间线

2024年12月30日 20:32 UTC：unknown_feature向Cosmos提交报告
2024年12月30日 21:15 UTC：amulet_mizmo将状态更改为已分类
2025年1月2日：提交更新的POC和额外思考
2025年5月20日：Cosmos奖励unknown_feature赏金
2025年5月20日：arrb Cosmos员工关闭报告并将状态更改为已解决
2025年5月29日：unknown_feature对严重性分类提出质疑
2025年5月30日：unknown_feature请求HackerOne支持调解
2025年5月31日：unknown_feature请求披露此报告
2025年6月30日：报告已披露

解决方案

通过在ibc-go中移除通道可升级性功能（https://github.com/cosmos/ibc-go/pull/8053）来修复此问题。虽然利用概率非常低（且该功能很少使用），但仍被评定为低严重性问题，奖励2,000美元赏金。

Cosmos ICA通道升级中的竞态条件漏洞与恶意通道替换攻击

本文详细分析了Cosmos IBC协议中ICA通道升级过程中存在的竞态条件漏洞，攻击者可在升级窗口期内替换活跃通道，导致交易反序列化失败和资金锁定风险。