Kusama的治理挫败了企图攻击者！
- ParityTech
- 发布于 2021-10-22 11:23
- 阅读 19
本文讨论了Kusama网络中Karura链发生的一次安全事件，攻击者利用了XCM协议的配置错误和旧版代码的漏洞，导致Karura链上的KSM代币被盗。文中详细描述了事件的经过、措施以及从中汲取的教训，强调了在引入未审计代码时进行仔细验证的重要性，以及如何通过引入更加严格的代码审查和应对机制来增强系统安全性。
Kusama网络是未经审计的、预生产代码的实验温床，作为Polkadot的狂野表亲和有些轻率的开拓者，该网络充分体现了其“期待混乱”的口号，并经历了另一场冒险。Kusama以其“价值承载测试网”的目的，激励安全分析师在代码投入生产使用之前找到并展示漏洞。恰巧在攻击者的账户中剩下了1 KSM，这也可以看作是发现者费用（如果在攻击发生前几个星期该漏洞没有被修复，结果可能会更多）。
发生了什么？
Karura团队（Kusama的一个平行链）发现，Kusama Relay链上Karura平行链持有的KSM代币余额与Karura代币托盘中记录的KSM总数不匹配。具体来说，Karura平行链账户持有的KSM比可以解释的少11,000.00 KSM。该团队识别出若干可疑的XCM交易，这些交易将KSM代币从Karura平行链账户转出：
- https://karura.subscan.io/extrinsic/0x934a8cf41988a3ed528d3030d66497b9adf7735b2b3a1a901fc4b7a9b60899f2
- https://karura.subscan.io/extrinsic/0xa3ea6883282655c9c6da00acd4775ae023838d96f7c67aba54d277b06632139c
- https://kusama.subscan.io/account/D8ouy6sNVcay521VsZTPf4eZ33sKr76UYqqXgKhN1YZ27mp
然后，他们采取了三项行动。他们通知了中心化的生态系统基础设施提供商有关包含被盗资金的账户；他们协助Karura治理机构调用了一个特别的应急计划托盘，以立即禁用发送原始XCM交易的能力；他们请求Kusama Relay链的去中心化治理机构帮助恢复资金。
作为后者的结果，动议373被理事会提出来以恢复转移的资金（包括10,000 KSM），随后是技术委员会关于快速审议的提案及该提案本身。Kusama治理机构故意将审议和执行的时间保持在最小，以最大限度地提高恢复被盗资金的机会，如果攻击者在投票期间转移了资金，则无法生效：
- https://kusama.polkassembly.io/motion/373
- https://kusama.polkassembly.io/tech/99
- https://kusama.polkassembly.io/referendum/143
强制转移的公投获得批准并执行，9,999.00 KSM被转回到Karura平行链账户。注意：此动议因为之前两次（公投141和142）由于错误使用图像注册外部程序而未能执行，因实施周期过短。
剩余的1,000 KSM被攻击者烧毁，我们预计会有提案提交给Kusama理事会，要求将这缺失的KSM重新铸回Karura主权账户。
在问题的性质变得清晰后，所有平行链团队都收到了明确的说明，提供补救步骤的指示。虽然Statemine并不易受同样的漏洞攻击，但是它立即进行了bug修复：
- https://kusama.polkassembly.io/motion/374
- https://kusama.polkassembly.io/tech/100
- https://kusama.polkassembly.io/referendum/144
自那以后，所有连接到Kusama网络的平行链都根据需要进行了补丁和代码升级，并且没有检测到其他成功或失败的攻击。
这怎么会发生？
这次事件是由于Karura链上三个因素的叠加：
- XCM托盘的配置错误。
- 使用了较旧、存在缺陷的代码。
- 利用储备资产转移。
这些因素的结合导致攻击者能够执行一条消息，并从Relay链上的Karura储备账户中进行提款。
XCM托盘的意外配置错误。
尽管XCM v2在Kusama Relay链上使用并接近审计完成且未发现重大问题，但XCM v0和v1是早期修订版，未经审计且不适用于生产。虽然Kusama是一个未经审计的预生产网络，但由于XCM的攻击面很大，用户有效地执行手工制作的XCM消息的能力被故意禁用。
这可以在Kusama运行时代码中看到：
impl pallet_xcm::Config for Runtime {
// ...但它们必须匹配我们的过滤器，过滤器拒绝所有内容。
type XcmExecuteFilter = Nothing;
}以及在原始Statemine代码中：
/// 本链上的本地来源不允许调度 XCM
/// 发送/执行。
pub type LocalOriginToLocation = ();不幸的是，当相应的代码部分被引入到Karura时，注释保持不变但其底层代码却有了相当大的不同：
/// 本链上的本地来源不允许调度 XCM
/// 发送/执行。
pub type LocalOriginToLocation = (
SignedToAccountId32<Origin, AccountId, RelayNetwork>,
);这移除了护栏，使任何人（包括我们的攻击者）都能在Karura上执行任何XCM消息，打开了XCM v0/v1的庞大攻击面。
使用旧版代码。
Kusama已经升级到XCM v2，这是期待通过审计并进入Polkadot Relay链的第一个XCM版本，但Karura（和Statemine）尚未升级到XCM v2。结果发现，XCM v1中存在一个问题，使得发生有限特权提升成为可能。通过重写大部分代码，XCM v2便不再包含这种故障。
攻击者利用该配置错误来访问旧版XCM中的漏洞。他们提交了一个交易以执行包含𝙸𝚗𝚒𝚝𝚒𝚊𝚝𝚎𝚁𝚎𝚜𝚎𝚛𝚜𝚆𝚒𝚝𝚑𝚍𝚛𝚊𝚝的XCM消息，该消息随后发送了一条𝚆𝚒𝚝𝚑𝚍𝚛𝚊𝚝𝙰𝚜𝚜𝚎𝚝消息到Relay链，将Karura的KSM转移到他们控制的账户。在XCM v2中，这将（正确地）失败，但以前版本的XCM中包含一个 bug，导致其成功。
攻击者无法利用相同漏洞攻击Statemine，因为它作为公共资产平行链，在Relay链上没有KSM储备账户。没有放弃，他们在大约一天后（10月13日中欧时间1600）尝试了一些其他攻击，但均没有成功，主要是由于Kusama Relay链此时已经升级到XCM v2。
教训
- 引入未经审计的代码时，始终验证正确性。 这在一个自豪于减少信任与权威需求的行业或运动中，真的是常识。没有任何代码作者或公司能被盲目信任。林纳斯法则“有足够的眼球，所有的错误都是浅显”的原则若没有人研究该代码，只有原作者自己学习，则无法生效。第三方专业审计有助于增加代码良好的信心，时间在野外的表现也能提供一些信心。但在你自己的代码库中引入代码时，最好充分理解它的功能和工作原理。
- 为高度敏感的代码引入更严格的审核要求。 基本的代码审查过程显然不足以避免意外移除护栏的代码更改。Parity将引入“锁定文件”和“锁定行”的概念，这些是高度敏感的代码小块，为在我们的代码库中更改这些代码需要多位专家的增强审核。这个被错误移除的护栏将是这样的一条锁定行。我们当然会将这一CI软件提供给所有团队使用。
- 引入应急机制。 Karura能够迅速解决此问题的一个原因是它包含了一个名为“事务暂停”的特殊托盘。该托盘使Karura治理机构能够暂停大多数类型的用户事务，包括启用攻击的配置错误事务。我们建议在Substrate链中引入类似的“安全模式”功能，为所有平行链提供这样的应急机制。在可能的攻击发生时，这将是第一道防线，并为治理过程争取时间，以确定漏洞的性质（如果有）及可能的补救作用，包括资金的回归和升级。
- 使用金丝雀网络。 如果攻击会发生，那么更好的办法就是发生在一个其整个存在理由就是被攻击并在此过程中揭示其漏洞的网络上。
最后的备注：
Polkadot上任何非平凡的代码必须首先经过第三方安全审计，通常由SR Labs的团队完成。由于XCM尚未完全审计，因此这里涉及的任何代码都不在Polkadot上，或曾经存在于Polkadot上。
- 原文链接： medium.com/kusama-networ...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
