周六，DeFi協(xié)議PickleFinance因其Jar策略中的漏洞而被黑客盜走了2000萬美元。之后，由Rekt、StakeCapital團隊成員、samczsun等白帽黑客組成的臨時小隊對Pickle協(xié)議內(nèi)剩余易受攻擊的5000萬美元用戶資金進行了搶救，并由作者Rekt對這次事件進行了總結(jié)。

金融的發(fā)酵繼續(xù)進行，即使是酸黃瓜也有保質(zhì)期。PickleFinance因一個假的「Picklejar」漏洞被黑客盜走了1970萬DAI。PickleFinance成為了這次黑客攻擊的受害者。

然而，這一次和之前有些不同... 當(dāng)Twitter上的人們試圖接受另一次金融災(zāi)難時，Rekt開始調(diào)查。我們聯(lián)系了StakeCapital團隊，他們查看了代碼并警告我們其他Picklejar存在風(fēng)險。隨后，我們迅速聯(lián)系了PickleFinance團隊，并與SketchCapital的成員（@bneiluj，@vasa_developer）以及經(jīng)驗豐富的開發(fā)者@samczsun、@emilianobonassi建立了一個作戰(zhàn)室。在我們進行調(diào)查后，很明顯，我們看到的是與最近幾周的DeFi黑客攻擊事件非常不同的情況。這不是一次套利。

攻擊者對Solidity和EVM非常了解，可能已經(jīng)密切關(guān)注了一段時間的Yearn代碼，因為這個漏洞與一個月前在Yearn中發(fā)現(xiàn)的漏洞類似。本質(zhì)上，PickleJar就是以YearnyVaults為基礎(chǔ)的，這些Jar由一個名為theController的合約控制，該合約允許用戶在Jar之間交換資產(chǎn)。不幸的是，Pickle沒有設(shè)置白名單，允許哪個Jar使用這個交換功能。黑客制造了一個假的PickleJar，并交換了原Jar中的資金。這是有可能的，因為swapExactJarForJar沒有檢查「白名單」jar。PickleFinance團隊知道他們需要幫助，并非常愿意與其他人合作，以防任何進一步的損害。Pickle曾試圖調(diào)用「withdrawAll」函數(shù)，但這筆交易失敗了。這個取款請求需要通過治理DAO，而這存在12個小時的時間鎖（timelock）。只有一個Pickle多重簽名組的成員有能力繞過這個時間鎖，而當(dāng)時他們正在睡覺。這意味著管理者無法清空PickleJar，但這并不能保護他們免受另一次黑客攻擊。隨后，PickleFinance和Curve發(fā)出警告，要求用戶立即從Pickle中提取資金，然而，潛在易受攻擊的Picklejar中還有5000萬美元，而白帽團隊調(diào)查了這一漏洞，并檢查了剩余資金的安全性。救援小隊要么叫醒睡著的管理員，要么自己抽干這些jar內(nèi)的資金。

這個小隊必須克服5大挑戰(zhàn)： 1. 讓PickleFinance團隊跨多個時區(qū)聚集在一起，通過將交易推到12小時時間鎖（通過6個多重簽名中的3個）提取資金，以拯救這些資金； 2. 讓成千上萬的投資者提取他們的資金，并阻止他們在資金池TVL下降和APY膨脹到1000%以上時再進行再投資； 3. 對其他jar進行安全檢查，看看是否有可能發(fā)生更多攻擊； 4. 在任何人再次攻擊這些jar之前，復(fù)制這種攻擊，將資金轉(zhuǎn)移出來； 5. 在試圖挽救剩余的5000萬美元資金時，避免被搶先交易。

我們還能依賴偽匿名白帽黑客的幫助多久呢？顯然，與保護者相比，攻擊者的動機更加一致，那白帽黑客為什么要協(xié)調(diào)這樣一次艱苦的反擊？榮譽歸白帽，資金卻歸黑客，這是不可持續(xù)的。要讓這些白帽變成黑帽需要多久時間？

通過發(fā)布這些技術(shù)信息，我們意識到我們可能會引發(fā)新的黑客攻擊。我們與PickleFinance及其他開發(fā)人員討論了潛在的后果，并確認(rèn)我們不知道Pickle的任何運營分叉可能會受到模仿攻擊的影響。選擇性披露會帶來責(zé)任的一個方面，所以我們決定自由發(fā)布這些信息。如果有任何協(xié)議在運行Pickle的代碼分叉，他們應(yīng)該要意識到正在發(fā)生的事件，并采取預(yù)防措施來防止黑客模仿者。

看看相對較新的保險協(xié)議CoverProtocol如何處理這一事件是有趣的，這對他們的第一筆索賠來說是一筆巨大的金額。你可以在這里找到保險索賠的快照投票。

腌漬酸黃瓜是一個緩慢的過程。幾十年來，「敏捷開發(fā)」的倡導(dǎo)者一直在告訴開發(fā)人員，要快速行動，迅速失敗，并發(fā)布最小的可行產(chǎn)品。然而，這些想法不適用于在敵對環(huán)境中建設(shè)。在DeFi中，迅速失敗是要付出巨大代價的。我們不需要另一種方法，我們需要一個范式轉(zhuǎn)換，允許快速迭代，同時減少被攻擊的可能性。我們不要再認(rèn)為「擁有審計就擁有了安全的保證」，在大多數(shù)情況下，它是在項目進入主網(wǎng)后快照式地應(yīng)用于移動目標(biāo)的檢查表式安全措施，這些目標(biāo)通常很快變

熱點：pi 平臺