Nexus Mutual | 本次漏洞披露带给我们的启示是什么？

作者 | Roxana Danila

在过去的一周之内，我们已经收到了两个负责任的漏洞披露。目前两个漏洞未被利用而且共同基金没有任何损失。本文将深入探讨两个漏洞披露的更多细节，我们从中学到了什么，并将其与实践结合在一起。 作为基于以太坊的互助保险平台，安全性始终是我们开展 Nexus Mutual 工作所坚持的重要方面。这是我们产品的核心，而且我们相信若要使得共同基金能够在现在和未来取得成功，安全性绝对是必要的。我们始终把协议和成员基金的安全置于首位。我们希望每个人都完整阅读本次漏洞披露，以了解究竟发生了什么，我们从中认识到了什么，并真切希望这些看法能够为其他团队在处理类似问题时有所帮助。 在 2 月 18 日星期二早上，我们收到了安全研究员 Mudit Gupta 提交的一份与治理相关的潜在漏洞报告。经过仔细研究，我们证实该漏洞确实存在，并且会对 Nexus Mutual 的咨询委员会和其所有者造成影响，比如可能会为特殊人群授予额外的特权。 在 Nexus Mutual 中，所有治理措施均须经过成员、咨询委员和所有者的投票。上述的任一成员都可以提出建议。然而，成员提出的提案必须要由咨询委员会列入白名单之中。每个治理提案都有一个与之关联的类别，该类别定义了投票结束时要执行的解决方案。 但潜在的漏洞是，在投票时这些提案的解决方案却并没有被证明是有效的。因此，咨询委员会中的成员很有可能将针对特定类别的提案列入白名单，却在实践中执行其他操作。这就意味着尽管成员们在为公司变得更好而投票，但他们很有可能在不知情的情况下将票投向了某些恶意行为之中。 针对该漏洞，我们提出的解决方法有以下几点：

1. 添加能够验证执行方案是否有效的程序以直接解决该漏洞。这将会保证提案中的行为能够妥善地受到该提案种类的限制。

2. 添加能够针对恶意提案的通用防御措施。比如可为所有的公司提案提供 24 小时缓冲，并赋予成员在该缓冲期内能够取消潜在恶意提案的权利。

3. 就预防性措施而言，我们决定如果成员提交了一个提案，但该提案遭到其他成员的意外投票，我们可以启动应急中止程序。

我们已一致通过了上述解决方法并开始实行，与此同时继续审查其他会因该治理漏洞而带来的潜在影响。 上周五，经过了进一步的调查，我们发现某些类别的提案是不能够用应急中止程序停止的。为了防止这种情况短期内被滥用且为了减弱此类与治理有关的漏洞带来的影响，我们采取了以下措施：

• 咨询委员会成员将所有治理提案强制列入白名单，以防止成员率先提出恶意提案；

• 更新公司治理设定，因此任何应急终止程序都不会被咨询委员会或所有者中的某一成员单方面通过。

将该举措落实之后，任何种类的提案都不会被单方面通过；

• 我们确保了所有的咨询委员会成员都使用硬件钱包，从而使针对该漏洞的攻击变得更加困难。

尽管目前还没有任何董事会成员的利益因此受到损害，但在完整的、最新的解决方案落实之前，我们做出了如下假定：

• 任何针对该漏洞的攻击者必须要使得三名咨询委员会成员做出妥协（即向恶意提案投票）才能通过一项恶意提案，而在此期间所有的环节是受制于整个咨询委员会的投票的。

• 该攻击者需要一位咨询委员会的成员做出妥协，但该成员是否能够成为咨询委员会的成员之一，以及后来会投票支持该恶意法案，仍受制于其他成员的投票。

为了使得整个流程更加透明，咨询委员会的成员拥有如下权利：

• 每一个咨询委员会成员都可以归类（白名单化）一项提案；

• 至少需要三名咨询委员会成员来设定提案的默认结果；

• 至少需要三名咨询委员会成员才能启动应急中止程序；

• 至少需要三名咨询委员会成员才能改变提案的核心部分（报价引擎、KYC 规则、资本模型）或者是外部 feed 地址。

以往所有者的职责不仅是在需要的情况下为核心部分（比如报价引擎和 KYC 规则）更新地址，还需要更新货币 feed 地址和交易信息，我们预计可能很快需要在这两方面进行更改。严格意义上来说，现在所有者的上述职责仍然存在，但是已经和咨询委员会的职责有效融合，因为在将所有者的的权力过渡给咨询委员会投票后，所有者现在拥有与之前同样的特权。 尽管我们承认在委员会中大家还是相互高度信任的，但是更值得一提的是，我们现在还拥有额外的法律保护层来确保所有的咨询委员会成员都要向共同基金和其他成员负有特定的法律义务。 现如今，针对该治理漏洞的永久性修复措施已经处于最后阶段，并将会在几天内落实。在所有修复工作完成之前，针对于该披露所暴露出的问题，我们设立的所有谨慎的治理措施都是稳健的，足以应对各类恶性提案，我们对此充满信心。 在 2 月 20 日周四上午，我们从安全研究人员 Samczsun 那收到了一份有关另一个漏洞的报告，而该漏洞会让共同基金受到损失。我们很快确认该漏洞的确存在。在收到报告的 4 个小时内，我们立即停止了与 Uniswap 的交互，而这也就意味着该漏洞无法被利用。 目前共同基金仍以 DAI 和 ETH 的形式持有。无论何时赎回请求被接受，共同基金都必须确保基金有充足的资金来支付我们的成员对应币种的需求。在此之前，如果待支付的金额超过了一定门槛，共同基金就会将额外需要的金额以批量售卖其他币种的方式进行支付，而这个过程需要一定的延迟时间，之后该基金则会依赖于 Oraclize 并且经由 Uniswap 轧平账户。 但这整个过程有两个给攻击者可乘之机的漏洞：

• 处理 Oraclilze 撤回资金的功能是不受保护的——而这可使得任何成员（不仅是 oraclize）来发起撤回。在此之前该项功能是在 Oraclize 撤回资金失败时才可使用的。然而，这是一个错误的结构性决定。

• 以往假定该功能只能被每一个 ID （Oracalize 或者是其他在 Oracalize 失败时使用该功能的成员）使用一次，因此整个过程就缺乏了重播保护。

我们确实承认，已经有人警告不要以这种方式使用 Uniswap，并且已知这种方式容易受到此类攻击。除此之外，bZx 事件对我们来说也应该是一个巨大的危险信号，尽管我们应该早些修复该项漏洞。过去我们将它看作是重新审视我们所有的第三方整合的警钟，并且制定了在他们失效后的应急预案。应急预案将会被记录下来并且在接下来的几周内与所有的社区分享。 对于共同基金来说，拥有足够的对应币种储备来承兑所有赎回请求是非常重要的。短期之内，如果要支付有关 DAI 的赎回，我们将向咨询委员会提议一个治理提案以将 ETH 换为所需的 DAI 来支付赎回请求。而在长期之内，我们将寻求与具有抗操纵性的去中心化交易所合作，现在我们已经在评估有哪些交易所可供选择了。 这些漏洞披露将会受到奖励吗？Mudit Gupta 将会因其负责任的漏洞披露获得 $2000 的奖励金。根据威胁矩阵，我们将此漏洞设为一般严重等级，因为该漏洞具有较大影响但较低利用可能性的特点。 Samczsun 将会因其负责任的漏洞披露获得 $5000 的奖励金。根据威胁矩阵，我们将此漏斗设为非常严重等级，因为该漏洞具有较大影响且中等利用可能性的特点。 另外，我们将发布漏洞奖金计划，更多细节之后会公布。 我们的代码经过审计了吗？ 我们的代码在上线前就已经在 2019 年 4 月被 Solidified 团队审计过，而且他们对代码更新非常保守，目前仅有过三次小型升级。 在本次的漏洞披露之前，他们已经安排了一次完全的审计，将于本月底开始，以检查相关升级细节，该流程耗时较短。 为什么还没有启动应急中止程序？ 尽管应急中止程序一向是我们的备选项，但是我们已经减弱了所有已知的恶意攻击媒介。且触发应急中止程序会给我们的成员们引入其他麻烦，比如会使得潜在的赎回延期，或者是成员基金会在中止期间被锁定。我们正在制定出综合的解决方案，而这些解决方案则要求协议的升级和进一步的安全审计。 从中得到的教训

• 为了成功进行负责任的漏洞披露，每个团队都必须在任何时间都处于可联系的状态。我们已经更新了安全联系方式信息，以便可以在 7*24 小时内联系到我们；

• 漏洞奖金计划和负责任的披露制度对于鼓励正确的报告非常重要，以保护我们免受漏洞被利用而带来的损害。尽管我们团队并没有大量的资金，但我们会认真对待，更多细节之后会公布；

• 制定安全响应程序对于让我们快速有效地回应此类事件十分关键。现在我们的制度规定了我们要有一个所有团队成员都熟知的清晰的应急预案。我们将会确保后续影响的调查和报告的确认工作平行开展；

• 代码的审计并不会发现所有的漏洞。您永远无法对智能合约功能进行足够的测试。而且，Defi 应用程序极容易受到广泛的的攻击。我们将扩展团队的安全性专业知识技能。

我们再次对 Samczsun 和 Mudit Gupta 的披露表达感谢。整个以太坊生态系统都将受益于他们所做出的贡献，我们的用户资金也会愈发安全。除此之外，十分感谢整个 Nexus 团队在过去几天所付出的努力。我们已经非常严肃的对待这些漏洞，且在整个过程中学到了很多，并将继续着眼和改善所有有关安全性的事宜。

Roxana Danila 作者子铭 翻译

Roy Wang 编辑

内容仅供参考 不作为投资建议 风险自担

版权所有 未经允许 严禁转载

☟☟☟