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

影响摘要

此处存在2个潜在问题：

1. 活跃通道在通道确认期间于控制器上设置。这是一个“先检查后执行”的操作，且是原子性的。但GetOpenActiveChannel仅在通道开放时返回通道，在刷新状态时不返回。

2. 活跃通道在通道开放确认期间于主机上设置，但检查通道是否存在的操作在try步骤中完成。虽然包含了FLUSH*状态，但不是原子性的。

重现步骤

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

攻击分为两个步骤：

1. 进行准备工作。由于主机上的“先检查后执行”操作不是原子性的，我们在ICA通道在控制器上初始化和ICA通道在主机上开放确认之间存在机会窗口。在此窗口期间，我们将在控制器上使用ICA端口和连接进行通道初始化，并在主机上进行通道尝试。

2. 等待受害者通道开始升级。脚本将发起新编码的升级提案。但我们的通道将使用旧编码。编码需要在主机上反序列化交易。

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

合法通道：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
4

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"}
u

然后它也在主机上通过了开放确认。我们为此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交易。因此需要另一次升级才能使其工作。此外，考虑到没有查询方法来查看活跃通道是什么，还需要一些调查。因此需要一些时间来弄清楚并使其重新工作。此外，我们可以预先设置不止一个而是多个通道。并为每次升级使用每个通道。

附件

2个附件 F3901259: active_channel_upgrade.mov F3901282: main.go

（后续时间线内容省略，仅包含技术相关内容）