周六，DeFi 协议 Pickle Finance 因其 Jar 策略中存在的漏洞，而被黑客盗走了 2000 万美元，此后，由 Rekt、Stake Capital 团队成员、samczsun 等白帽黑客组成的临时小队对 Pickle 协议内剩余易受攻击的 5000 万美元用户资金进行了抢救，作者 Rekt 对这次事件进行了总结。
金融的发酵还在继续，即使是酸黄瓜也有保质期。
Pickle Finance 因为一个假「Pickle jar」漏洞而被黑客盗走了 1970 万 DAI。
Pickle Finance 已成为了这次黑客大流行病的最新受害者。
然而，这一次，有一些不同...
当 Twitter 上的人们试图接受另一次金融灾难时，Rekt 开始了调查。
我们联系了 Stake Capital 团队，他们查看了代码并警告我们其他 Pickle jar 可能面临风险。
随后，我们迅速联系了 Pickle Finance 团队，并在 Sketch Capital （@bneiluj，@vasa_developer）成员以及有经验的开发者 @samczsun，@emilianobonassi 之间建立了一个作战室。
在我们进行调查后，很明显，我们看到的是与最近几周的 DeFi 乐高风格黑客事件非常不同的东西。
这不是一次套利。
攻击者对 Solidity 和 EVM 有着很好的了解，并且可能已经密切关注了一段时间的 Yearn 代码，因为这个漏洞与一个月前在 Yearn 中发现的漏洞类似。
从本质上说，Pickle Jar 就是 Yearn yVaults 的分叉，这些 Jar 是由一个名为 the Controller 的合约控制的，该合约具有允许用户在 Jar 之间交换资产的功能。
不幸的是，Pickle 并没有设置白名单允许哪个 Jar 使用这个交换功能。
黑客制造了一个假的 Pickle Jar，并交换了原 Jar 中的资金。这是有可能的，因为 swapExactJarForJar 没有检查「白名单」jar。
Pickle Finance 团队知道他们需要帮助，并非常愿意与其他人合作，以防任何进一步的损害。
Pickle 曾试图调用「withdrawAll」函数，但这笔交易失败了。
这个取款请求需要通过治理 DAO，而这存在 12 个小时的时间锁（timelock）。
只有一个 Pickle 多重签名组的成员有能力绕过这个时间锁，而当时他们正在睡觉。
这意味着管理者无法清空 Pickle Jar，但这并不能保护他们免受另一次黑客攻击。
随后，Pickle Finance 和 Curve 发出警告，要求用户立即从 Pickle 中提取资金，然而，潜在易受攻击的 Pickle jar 中还有 5000 万美元，而白帽团队调查了这一漏洞，并检查了剩余资金的安全性。
救援小队要么叫醒睡着的管理员，要么自己抽干这些 jar 内的资金。
这个小队必须克服 5 大挑战：
1.让 Pickle Finance 团队跨多个时区聚集在一起，通过将交易推到 12 小时时间锁（通过 6 个多重签名中的 3 个）提取资金，以拯救这些资金；
2.让成千上万的投资者提出他们的资金（并阻止他们在资金池 TVL 下降和 APY 膨胀到 1000% 以上时再进行再投资）；
3.对其他 jar 进行安全检查，看看是否有可能发生更多攻击；
4.在任何人再次攻击这些 jar 之前，复制这种攻击，将资金转移出来；
5.在试图挽救剩余的 5000 万美元资金时，避免被抢先交易；
我们还能继续依赖伪匿名白帽黑客的帮助多久？
显然，与保护者相比，攻击者的动机更为一致，那白帽黑客为什么要协调这样一次艰苦的反击？
荣誉归白帽，资金却归黑客，这是不可持续的。
要让这些白帽变黑，还需要多久时间？
分析
通过发布这些技术信息，我们意识到我们可能会引发新的黑客攻击。我们与 Pickle Finance 及其他开发人员讨论了潜在的后果，并确认我们不知道 Pickle 的任何运营分叉可能会受到模仿攻击的影响。
选择性披露会带来责任的一个方面，所以我们决定自由发布这些信息。如果有任何协议在运行 Pickle 的代码分叉，他们应该要意识到正在发生的事件，并采取预防措施来防止黑客模仿者。
下面的图表是由 @vasa_develop 创建的。
看看相对较新的保险协议 Cover Protocol 如何处理这一事件是有趣的，这对他们的第一笔索赔来说是一笔巨大的金额。你可以在 这里 找到保险索赔的快照投票。
腌渍酸黄瓜是一个缓慢的过程。
几十年来，「敏捷开发」的倡导者一直在告诉开发人员，要快速行动，迅速失败，并发布最小的可行产品。
这些想法不适合在敌对环境中建设。
在 DeFi 中迅速失败是要付出巨大代价的。
我们不需要另一种方法，我们需要一个范式转换，允许快速迭代，同时减少被攻击的可能性。
我们不要再认为「拥有审计就拥有了安全的保证」，在大多数情况下，它是应用于移动目标的检查表式安全措施的快照，这些目标通常在项目进入主网后不久就演变成了其他东西。
MixBytes （10 月 3 日）和 Haechi （10 月 20 日）的审计是在添加 ControllerV4 （10 月 23 日）之前完成的，而 ControllerV4 是这次攻击的关键向量之一。
未来金融界最伟大的团队，将是那些能够在快速迭代和安全迭代之间进行权衡的团队，其能够定期对其可组合的货币机器人进行持续审计和严格测试。
审计应该是一个定期的、持续的过程，而不是在启动前打勾。新的 DeFi 协议会不断变化和适应，而安全审计应反映这一点。
毕竟，腌黄瓜只有在罐子里才能保持新鲜 ...
金融的发酵还在继续，即使是酸黄瓜也有保质期。
Pickle Finance 因为一个假「Pickle jar」漏洞而被黑客盗走了 1970 万 DAI。
Pickle Finance 已成为了这次黑客大流行病的最新受害者。
然而，这一次，有一些不同...
当 Twitter 上的人们试图接受另一次金融灾难时，Rekt 开始了调查。
我们联系了 Stake Capital 团队，他们查看了代码并警告我们其他 Pickle jar 可能面临风险。
随后，我们迅速联系了 Pickle Finance 团队，并在 Sketch Capital （@bneiluj，@vasa_developer）成员以及有经验的开发者 @samczsun，@emilianobonassi 之间建立了一个作战室。
在我们进行调查后，很明显，我们看到的是与最近几周的 DeFi 乐高风格黑客事件非常不同的东西。
这不是一次套利。
攻击者对 Solidity 和 EVM 有着很好的了解，并且可能已经密切关注了一段时间的 Yearn 代码，因为这个漏洞与一个月前在 Yearn 中发现的漏洞类似。
从本质上说，Pickle Jar 就是 Yearn yVaults 的分叉，这些 Jar 是由一个名为 the Controller 的合约控制的，该合约具有允许用户在 Jar 之间交换资产的功能。
不幸的是，Pickle 并没有设置白名单允许哪个 Jar 使用这个交换功能。
黑客制造了一个假的 Pickle Jar，并交换了原 Jar 中的资金。这是有可能的，因为 swapExactJarForJar 没有检查「白名单」jar。
Pickle Finance 团队知道他们需要帮助，并非常愿意与其他人合作，以防任何进一步的损害。
Pickle 曾试图调用「withdrawAll」函数，但这笔交易失败了。
这个取款请求需要通过治理 DAO，而这存在 12 个小时的时间锁（timelock）。
只有一个 Pickle 多重签名组的成员有能力绕过这个时间锁，而当时他们正在睡觉。
这意味着管理者无法清空 Pickle Jar，但这并不能保护他们免受另一次黑客攻击。
随后，Pickle Finance 和 Curve 发出警告，要求用户立即从 Pickle 中提取资金，然而，潜在易受攻击的 Pickle jar 中还有 5000 万美元，而白帽团队调查了这一漏洞，并检查了剩余资金的安全性。
救援小队要么叫醒睡着的管理员，要么自己抽干这些 jar 内的资金。
这个小队必须克服 5 大挑战：
1.让 Pickle Finance 团队跨多个时区聚集在一起，通过将交易推到 12 小时时间锁（通过 6 个多重签名中的 3 个）提取资金，以拯救这些资金；
2.让成千上万的投资者提出他们的资金（并阻止他们在资金池 TVL 下降和 APY 膨胀到 1000% 以上时再进行再投资）；
3.对其他 jar 进行安全检查，看看是否有可能发生更多攻击；
4.在任何人再次攻击这些 jar 之前，复制这种攻击，将资金转移出来；
5.在试图挽救剩余的 5000 万美元资金时，避免被抢先交易；
我们还能继续依赖伪匿名白帽黑客的帮助多久？
显然，与保护者相比，攻击者的动机更为一致，那白帽黑客为什么要协调这样一次艰苦的反击？
荣誉归白帽，资金却归黑客，这是不可持续的。
要让这些白帽变黑，还需要多久时间？
分析
通过发布这些技术信息，我们意识到我们可能会引发新的黑客攻击。我们与 Pickle Finance 及其他开发人员讨论了潜在的后果，并确认我们不知道 Pickle 的任何运营分叉可能会受到模仿攻击的影响。
选择性披露会带来责任的一个方面，所以我们决定自由发布这些信息。如果有任何协议在运行 Pickle 的代码分叉，他们应该要意识到正在发生的事件，并采取预防措施来防止黑客模仿者。
下面的图表是由 @vasa_develop 创建的。
看看相对较新的保险协议 Cover Protocol 如何处理这一事件是有趣的，这对他们的第一笔索赔来说是一笔巨大的金额。你可以在 这里 找到保险索赔的快照投票。
腌渍酸黄瓜是一个缓慢的过程。
几十年来，「敏捷开发」的倡导者一直在告诉开发人员，要快速行动，迅速失败，并发布最小的可行产品。
这些想法不适合在敌对环境中建设。
在 DeFi 中迅速失败是要付出巨大代价的。
我们不需要另一种方法，我们需要一个范式转换，允许快速迭代，同时减少被攻击的可能性。
我们不要再认为「拥有审计就拥有了安全的保证」，在大多数情况下，它是应用于移动目标的检查表式安全措施的快照，这些目标通常在项目进入主网后不久就演变成了其他东西。
MixBytes （10 月 3 日）和 Haechi （10 月 20 日）的审计是在添加 ControllerV4 （10 月 23 日）之前完成的，而 ControllerV4 是这次攻击的关键向量之一。
未来金融界最伟大的团队，将是那些能够在快速迭代和安全迭代之间进行权衡的团队，其能够定期对其可组合的货币机器人进行持续审计和严格测试。
审计应该是一个定期的、持续的过程，而不是在启动前打勾。新的 DeFi 协议会不断变化和适应，而安全审计应反映这一点。
毕竟，腌黄瓜只有在罐子里才能保持新鲜 ...
继续阅读与本文标签相同的文章
-
HF RealX成功通过CertiK和MetaTrust审计，树立区块链安全新标杆
2024-12-06栏目： 7x24快讯
-
红魔币与股权NFT最新动态
2024-12-04栏目： 7x24快讯
-
HF RealX融通链成功上线，开启真实世界资产代币化新时代
2024-11-24栏目： 7x24快讯
-
Kava宣布上线Memecoin Launchpad平台HARD.fun
2024-11-22栏目： 7x24快讯
-
BingX 危機持續發酵，代理反水與使用者資產問題全面暴露
2024-11-22栏目： 7x24快讯
发表评论 已发布 0 条