漏洞 2 以及权益重用攻击通过跟踪这些代码库的历史版本，我们注意到漏洞 1 最初是在将比特币的 “区块头优先” 功能合并到 PoSv3 代码库时引入的。更早期版本的密码学货币（例如：peercoin）并不存在漏洞 1 ，因为在将区块存储到硬盘之前要先经过两项初步验证：

验证将要花费的输出是否存在于主链中；验证 PoS 区块的 kernel 哈希值是否达到难度目标。

第一项验证是通过查找交易数据库（TxDB）来完成的。该数据库保存了当前主链上的所有交易。换句话说，初步验证确实有一定的效果，但是它相比完全验证仍然不够完整和严谨。如果你一直跟随着这篇文章的思路，你可能会立刻发现两个问题：

问题 A ：第一项验证只能确保这个币是存在的，但是不能确保它对应的 UTXO 没有被花费过。由此引发了我们接下来要讨论的漏洞。

问题 B ：即使我们验证的是一条分叉链上的区块，也会基于主链的 TxDB 来验证这个区块内的 coinstake 交易。

基于问题 A ，我们找到了一种能够骗过这些验证的方法，那就是使用一种更微妙的攻击手段，我们称之为 “权益重用攻击”。为了绕过第一项验证，我们会使用一个已花费输出冒充未花费输出骗过节点。通常，为了绕过第二项验证，我们需要挖出一个达到难度目标的有效区块，这种操作需要投入一大笔权益。但是，事实证明，我们可以通过滥用不完全验证来产生任意数量的表观权益 （apparent stake）。我们将这种技术称为 “权益放大” 。

权益放大要想使用少量权益达到攻击的目的，攻击者必须放大自己的表观权益量。表观权益指的是所有备用权益输出的总量，包括已花费的权益。假设一个攻击者一开始拥有k数额的 UTXO ，他可以发起多笔发送给自己的交易（造成自己所持权益量增加的假象），如下图所示。原本应该只有 UTXO*(n+1)* 能算作权益，但是根据上文的验证 2 ，从1到n+1的 UTXO 都可以算入权益量之中，从而将表观权益量增加到了n*k。由于攻击者可以一直通过这种方式增加表观权益量，也就增加了他挖到 PoS 块的几率。“权益放大的步骤” 参见图左。

-权益放大和已权益重用攻击-

假设攻击者拥有的权益只占整个系统的 0.01% ，他只需要通过交易将这些权益反复发送给自己，5000 次后就可以获得 50% 的表观权益算力来挖取区块。攻击者累积得到大量表观权益之后，就可以使用这些 表观权益输出从过去的某个时间点开始重新挖 PoS 区块。最终，如图右所示，被攻击节点的硬盘会被无效区块填满。举个例子，攻击者可以从交易所购买一些代币，通过上文提到的自交易放大自己的表观权益，然后将代币重新在交易所卖掉，之后就可以随时进行攻击。对于攻击者来说，攻击成本仅仅是交易手续费。

协同漏洞披露我们首先针对密码学货币 Particl 和 Qtum 调查了关于漏洞 1 的情况 <1>。为了了解这个漏洞的危害程度，我们从 coinmarketcap.com（截至 2018 年 8 月 9 日）网站上筛选出了一些知名的 PoS 密码学货币，根据市值降序列了一张表。我们只研究了那些从比特币（或是从比特币中衍生出来的密码学货币）的 C++ 代码库中分叉出来的密码学货币。我们总共审查了 26 种密码学货币，其中只有 5 种（Qtum、Navcoin、HTMLcoin、Emercoin 以及 Particl）存在漏洞 1 ，剩余 21 种似乎不受该攻击的影响。为了确认漏洞 1 的危害程度，我们对那 5 种密码学货币进行了攻击。我们利用了比特币现有的测试组件，特别是支持模拟时间戳和快捷建块的regtest 测试，以及一个（基于比特币测试框架）用 Python 编写的测试节点，该节点可以随着攻击者的攻击行为进行扩展。作为漏洞披露的一部分，我们使用 Docker 容器引擎将这些测试、它们的依赖包和特定 commit 的哈希值打包成了一个可再现工具包，以便分享给相关密码学货币的开发团队。

我们又进一步深挖了其余密码学货币能够抵御漏洞 1 攻击的原因，发现了同样严重且更为普遍的漏洞 2 （只需要少量权益）。在准备披露这两个漏洞的过程中，我们考虑到有些密码学货币流动性不强，开发团队的活跃度又较低，向他们披露这些漏洞可能会适得其反（其中一种风险是，如果存在漏洞的事情被泄露，在相关开发团队部署解决方案之前可能会造成用户的损失）。最终，我们（从市值在前 200 名的密码学货币中）选出了最可能受到攻击以及团队应对积极性最强（在 2018 年提交过一些 commit ）的 15 种密码学货币，并与它们的开发团队进行了交流。

其中一个比较复杂的因素是，大多数团队的代码库都没有使用 regtest 测试模式，因此我们很难向他们演示攻击方式或是为针对每个密码学货币提供一个可再现工具包。因此，我们只能通过一个 C++ 版本的 stratisX 代码库进行演示 <7>。基于代码库的相似性，我们将存在漏洞的事告知了上述 15 支开发团队。其中有 5 支团队确认了漏洞的存在， 3 支团队还在调查中， 3 支团队认为漏洞的影响不大（并指出一些程序上的改动可以抵御其影响），还有 4 支团队尚未回复。对于那 4 支未回复的团队，我们通过他们网站上提供的渠道进行了联系 <5> <6>。我们在 这里 提供了两个漏洞的 Github 可再现工具包，这里 是我们关于漏洞 1 的一篇小论文。我们还将漏洞保存在了 CVE 上，将于近日公布。

解决措施我们看到一些团队针对这些漏洞采取了一定的解决措施。一些密码学货币团队采取的措施是监测这类攻击并断开与攻击节点的连接 <2>。简单来说，节点会监测其他节点的异常行为（例如，发送大量区块头到分叉链上）。这种方案的问题在于很难将真的攻击行为与诚实节点的合法重组区分开来——存在误禁诚实节点的风险。截止到目前的情况来看，我们认为这类解决措施是合理的，但还是需要进一步调查。

另一些密码学货币团队采取的措施是增加一个部分验证机制，每积累一定数量的区块就会触发这个机制，使触发点以前的区块链不再接受分叉区块 <3>。如果节点接收到的分叉区块过于久远（即比最新的触发点要更为久远），节点是不会认可的，只会将它丢弃。例如，BCH （比特币现金）的 ABC 代码库就使用了这种方法，设置了深度为 10 个区块的滚动检查点。这种方法的缺点在于会造成 “链分裂” 的可能性。“链分裂”指的是诚实节点分散在主链的不同分叉链上。例如，在一个网络不佳的环境下，节点之间长时间不同步，产生了有冲突的检查点。即使节点重新上线，也无法对这条链达成共识。我们注意到，即使不采用这种方案，链分裂的问题也是存在的。再说回上文的问题 B ，由于 coinstake 交易是基于当前主链上的交易输出进行验证的，如果一个节点突然发现自己处在一条分叉链上，可能无法切换到真正的主链上。

链分裂的风险同样为恶意矿工创造了新的攻击手段。攻击者可以秘密挖取一条长链，并将它广播至部分节点，从而造成链分裂的情况。处于 IBD（初始块同步）状态的节点或者是长时间离线后重新同步的节点特别容易受到这样的攻击。这类攻击能够和 eclipse 攻击结合，将诚实节点引入由攻击者控制的分叉链中。

所有这些解决措施都能有效抵御虚假权益攻击，但是依旧无法代替完全验证。包括 Qtum 在内的一些密码学货币计划在未来的版本中对非主链区块实行完全验证。

我们建议所有这些存在漏洞的密码学货币的用户将自己的节点软件进行升级，打上最新的补丁，未升级的节点有可能遭受攻击，RAM 或者磁盘资源消耗过大，最终造成程序崩溃。

最终感想虽然 “虚假权益” 攻击本质上很简单，但是突显了设计上的难点：将一些适用于工作量证明的思路挪用到权益证明中会引发安全性问题。鉴于在 PoSv3 密码学货币的代码与 Bitcoin Core 高度重合，我们认为应该更加重视代码检查。在调查这些漏洞的时候，我们在不同的项目代码库 <4>（或是一些被注释掉的代码）发现了一些解决措施和有针对性的防御措施。我们认为，这表明当前 PoS 项目的开发者们已经意识到了自己在设计过程中对于权衡关系和需求上考虑不足。难点在于，一方面，我们想要尽快抵御无效区块攻击，但是另一方面，我们不希望因此发生链分裂或是延迟的情况。在未来的研究中，我们依旧要思考如何找到一个系统化的解决方案。

尽管我们已经看到了至少两个代码库受到影响（例如，在 BTC 中的 CVE 2018–17144），但是据我们所知，这次协同安全漏洞披露涉及的密码学货币数量之多（20+），绝对是史无前例的。考虑到这些密码学货币的设计思路和代码库重合度较高，我们预计在未来会发现更多这样的漏洞。我们还发现这些代码库几乎没有统一的安全性处理。比如，大多数团队都没有专设安全联络人。类似我们这种协同漏洞披露是一种最佳做法，同时也对整个生态有益。

注 1：本漏洞背后的观念起于 2018 年夏天，当时 Andrew Miller 还在跟 Unit-E 开发者一起工作。感谢 Matteo Sumberaz 和 Gil Danziger 充满教益的探讨，以及 DTR Foundation 提供的奖金。

注 2：Emercoin 实现的一种启发式节点发现方法 https://github.com/emercoin/emercoin/commit/ec32762b99cc68fb9abb2909dda96bc7a13bd819

注 3：Qtum 中的滚动检查点 https://github.com/qtumproject/qtum/commit/8d208d0bee8449c1e4a3904ff3fc97ed26156648

注 4：一个 PoS 中的 ad-hoc 检查案例：https://github.com/peercoin/peercoin/blob/ebb4003ce8367501020181f7e734d52c4b1ab5ea/src/main.cpp#L2564

注 5：我们通过电子邮件以及 "发送备忘录" 功能联系上了一些团队

注 6：我们从 11 月开始多次通过网页上的联系功能联系 PIVX 团队。直到我们写作本文期间才发现，PIVX 团队也启动了一个 hackerone 项目。而且我们也发现，直到今天，PIVX 网页上的 bug 悬赏页都没有列出这个 hackerone 项目。

注 7：注 7：StratisX 已经从有漏洞的 C++ 代码库迁移到了 C# 实现。

原文链接: https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806

翻译&校对: TrumanW, Whisker & 闵敏

相关文章