在DeFi中，快速失敗的后果是非常嚴(yán)重的，所以「敏捷開發(fā)」是否適用于DeFi？上周末，DeFi協(xié)議PickleFinance因?yàn)槠銳ar策略中存在的漏洞，被黑客盜走了2000萬(wàn)美元。隨后，一支由Rekt、StakeCapital團(tuán)隊(duì)成員和samczsun等白帽黑客組成的臨時(shí)小隊(duì)對(duì)剩下的5000萬(wàn)美元資金進(jìn)行了搶救。這篇文章是作者Rekt對(duì)此事件進(jìn)行的總結(jié)。

金融領(lǐng)域的創(chuàng)新仍在繼續(xù)，即使是對(duì)于「酸黃瓜」，也有保質(zhì)期。PickleFinance因?yàn)橐粋€(gè)名為「Picklejar」的假漏洞而被黑客盜走了1970萬(wàn)DAI。PickleFinance成為了這波黑客攻擊的最新受害者。

然而，這一次有一些不同...

當(dāng)Twitter上的人們?cè)噲D接受這次金融災(zāi)難時(shí)，Rekt開始了調(diào)查。我們聯(lián)系了StakeCapital團(tuán)隊(duì)，他們查看了代碼并警告我們其他Picklejar可能存在風(fēng)險(xiǎn)。隨后，我們迅速聯(lián)系了PickleFinance團(tuán)隊(duì)，并與SketchCapital（@bneiluj，@vasa_developer）的成員以及有經(jīng)驗(yàn)的開發(fā)者@samczsun和@emilianobonassi共同組建了一個(gè)工作小組。在我們的調(diào)查中，很明顯，我們看到的與最近幾周DeFi領(lǐng)域的黑客攻擊非常不同。

這并不是一次套利行為。攻擊者對(duì)Solidity和EVM有很好的了解，并且可能已經(jīng)密切關(guān)注Yearn代碼一段時(shí)間，因?yàn)檫@個(gè)漏洞類似于一個(gè)月前在Yearn中發(fā)現(xiàn)的漏洞。實(shí)質(zhì)上，PickleJar就是Yearn Vaults的分叉，這些Jar由名為theController的合約控制，該合約允許用戶在Jar之間交換資產(chǎn)。不幸的是，Pickle并沒有設(shè)置白名單，以允許哪個(gè)Jar使用這個(gè)交換功能。黑客制造了一個(gè)假的PickleJar，并交換了原Jar中的資金。這是可能的，因?yàn)?swapExactJarForJar"沒有檢查"白名單"中的Jar。PickleFinance團(tuán)隊(duì)知道他們需要幫助，并愿意與其他人合作，以防止進(jìn)一步的損害。他們?cè)鴩L試調(diào)用"withdrawAll"函數(shù)，但這個(gè)交易失敗了。這個(gè)取款請(qǐng)求需要通過(guò)治理DAO，并存在12個(gè)小時(shí)的時(shí)間鎖。當(dāng)時(shí)，只有Pickle多重簽名組中的成員有能力繞過(guò)這個(gè)時(shí)間鎖，而他們當(dāng)時(shí)正在睡覺。這意味著管理員無(wú)法清空PickleJar，但這并不能保護(hù)他們免受另一次黑客攻擊。

隨后，PickleFinance和Curve發(fā)出警告，要求用戶立即從Pickle中提取資金。然而，剩下的易受攻擊的Picklejar中還有5000萬(wàn)美元。由白帽團(tuán)隊(duì)進(jìn)行了調(diào)查，并檢查了剩下資金的安全性。救援小隊(duì)要么叫醒睡著的管理員，要么自己抽干這些jar內(nèi)的資金。這個(gè)小隊(duì)必須克服5大挑戰(zhàn)：讓PickleFinance團(tuán)隊(duì)跨多個(gè)時(shí)區(qū)聚集在一起，通過(guò)將交易推到12小時(shí)時(shí)間鎖（通過(guò)6個(gè)多重簽名中的3個(gè)）提取資金，以拯救這些資金；讓成千上萬(wàn)的投資者提取他們的資金；對(duì)其他jar進(jìn)行安全檢查，看看是否有可能發(fā)生更多攻擊；在任何人再次攻擊這些jar之前，模仿這種攻擊，將資金轉(zhuǎn)移出來(lái)；在試圖挽救剩下的5000萬(wàn)美元資金時(shí)，避免被搶先交易。

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

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

關(guān)于更多詳情，請(qǐng)參閱官方的調(diào)查報(bào)告。了解相對(duì)較新的保險(xiǎn)協(xié)議CoverProtocol如何處理此事件是有趣的，因?yàn)檫@是他們的首次索賠，而且金額巨大。你可以在此處找到有關(guān)保險(xiǎn)索賠的快照投票。

腌漬酸黃瓜是一個(gè)緩慢的過(guò)程。幾十年來(lái)，「敏捷開發(fā)」的倡導(dǎo)者一直告訴開發(fā)人員要迅速行動(dòng)，快速失敗，并發(fā)布最小可行產(chǎn)品。但這些想法并不適用于敵對(duì)環(huán)境中的建設(shè)。在DeFi中，迅速失敗是要付出巨大代價(jià)的。我們不需要另一種方法，我們需要一個(gè)范式轉(zhuǎn)變，允許快速迭代的同時(shí)減少遭受攻擊的可能性。我們不能再認(rèn)為「有審計(jì)就有安全保證」了，在大多數(shù)情況下，這只是針對(duì)流動(dòng)目標(biāo)的一份檢查表式的安全措施快照，這些目標(biāo)通常在項(xiàng)目上線后不久就會(huì)發(fā)生改變。MixBytes（10月3日）和Haechi（10月20

熱點(diǎn)：pi 交易平臺(tái) 平臺(tái)