FOR:二十三種 DeFi 安全事故匯總：智能合約風險與防范

撰文：AustinZhang，JonLi，AsymmetriesTechnologies

智能合約的安全性問題一直是業界的一個重點話題，由于程序員的某些疏忽造成了思維和邏輯上的漏洞，從而導致黑客有了可乘之機。我們搜集了目前在DeFi領域已經發生了安全事故的智能合約，并根據我們編寫的示例代碼來實證分析其中的原因，希望能給到同事和同行們一些啟示。

重入攻擊

主要攻擊方式之一：合約調用惡意外部合約結束之前，惡意外部合約函數反向調用原合約函數利用相關漏洞。

示例代碼

案例1：2021年12月22日UniswapV3流動性管理協議Visor被盜120ETH

事故原因：deposit函數沒有防重入鎖也沒有驗證from地址是否是合法的Visor合約地址。攻擊者傳入攻擊合約地址，重復調用deposit函數繞過取款金額檢查多次取款。

案例2：2021年6月5日BurgerSwap被盜700萬美金

事故原因：類似Uniswap的原創dex，分為Platform和Pool兩個合約。Platform類似Uniswap的Router，Pair類似Uniswap的Pool，開發者錯誤的將K值校驗放在Platform計算，攻擊者在Platform中進行重入攻擊，多次以舊的K值換取代幣，造成流動性提供者損失。

解決方案：調用外部合約前確保所有中間狀態變量已更新并使用再入鎖。

未檢查函數返回值

調用外部合約函數時，有些函數調用失敗不會拋出錯誤回滾交易而是返回false，如果忘記檢查函數返回值會導致誤以為調用成功。

示例代碼

案例：2021年4月4日ForceDao到被攻擊損失183ETH

中幣（ZB）第二十二期投票上幣將于5月31日14:00正式開啟:據官方公告，第二十二期投票上幣將于2021年5月31日14:00 - 2021年6月2日14:00開啟為期2天的社區投票上幣，參與本期投票上幣的候選項目分別為PPT（Populous）、DOM（DOM Chain）、UBT（Unibright）。并沿用前期規則，中幣用戶使用ZB平臺積分進行投票。在投票期間獲得超過200萬ZB票數的項目可獲得上幣資格，本期投票上幣沒有設置項目代幣購買環節，投票也沒有相關糖果贈送，滿足條件的項目按照投票達標的先后順序進行上幣對接。投票正式開啟后，可登錄中幣官網進入投票頁面。[2021/5/31 22:58:09]

事故原因：Force代幣的transferFrom余額不足時返回false而不是直接回滾交易，合約中未做判斷導致轉賬失敗時也被認為成功，可以換取到對應代幣。

解決方案：使用call函數調用外部合約時必須檢查調用是否成功。注：call調用外部合約未匹配到函數時，會調用外部合約fallback或者receive函數，如果外部合約有定義receive函數且call函數未攜帶calldata則會調用外部合約receive函數，其他情況調用fallback函數。

未正確設置函數可見性

Solidity中函數默認為public，可以被外部調用，一旦未將關鍵函數設置為Private，就會導致安全風險。

示例代碼

案例1：2022年1月22日DexCrosswise被攻擊損失80萬美金

事故原因：Crosswise雖然實現了權限驗證函數onlyOwner，但忘記設置setTrustedForwarder為private，導致被攻擊者利用，將自己設置為池子的Owner將代幣全部轉走。

Asproex(阿波羅)生態通證MOON完成第二十一期回購銷毀:官方消息，1月12日，Asproex(阿波羅)生態通證MOON完成第二十一期回購銷毀，銷毀數量為?1,805,620?枚MOON，區塊高度為?11639597??，銷毀交易哈希值為

0xa0d79657c8d7f445e882443a60c0808ec6c0756a2ed73d2b0076a16ae557480c。據悉，此次銷毀價值總金額高達523630美金，MOON當前價格為0.2926U（實時數據），到目前為止，Asproex（阿波羅）二十一期回購銷毀計劃累計銷毀23,942,748枚MOON。

Asproex（阿波羅）作為一家離岸銀行控股持牌交易平臺，涵蓋CTO(Corporate Token Offering)企業通證上市、合約跟單、ETT指數通證、數字礦業、Digital Bank板塊并持有5國合法牌照，致力于為全球中小微企業提供數字化上市一站式服務。[2021/1/12 15:59:57]

案例2：2020年6月18日跨鏈橋BancorNetwork被攻擊損失14萬美金

事故原因：合約用于轉賬的函數默認為public，攻擊者可以直接調用轉走合約中的代幣。

解決方案：提款函數事關合約資產的轉移，需謹慎設置權限控制，確保初始化函數只能運行一次。

未驗證Map中Key不存在的情況

Solidity中的Mapping在獲取對應Key的Value時，如果Key不存在，會返回對應類型的默認值，而不是報錯。例如Mapping(int→int)，如果對應int的Key不存在，會返回默認值0。

示例代碼

案例：2021年7月11日跨鏈橋ChainSwap被攻擊損失400萬美金

事故原因：ChainSwap依賴其網絡中的validator進行轉賬。為了限制validator一次轉走超過其質押的代幣，設置了配額。結果合約中存在漏洞可以繞過配額限制，當地址變量signatory不存在時，authQuotes和lasttimeUpdateQuoteOf會返回0，導致配額計算錯誤返回預期外的大量配額。

比特幣成為按市值計算全球第二十大資產:金色財經報道，根據AssetDash的數據，比特幣市值已接近3000億美元，成為目前全球市值排名第二十的資產。目前，比特幣超越了美國家居建材零售商家得寶（Home Depot）、Verizon和貝寶（PayPal）。[2020/11/13 14:10:16]

解決方案：使用map時必須檢查key是否存在。

在狀態變更前進行轉賬

轉賬時有可能被重入，利用未變更的狀態進行攻擊。

案例：2021年8月17日XSURGE被攻擊損失500萬美金

事故原因：在轉賬后才修改totalSupply，轉賬時被重入另外一個未加重入鎖的函數損失500萬美金。

解決方案：使用了再入鎖也要在所有狀態變更之后在轉賬。

初始化函數未做調用和權限限制

很多合約需要初始化子合約，例如Uniswap需要通過Factory合約初始化Pool合約，這時候如果忘記對子合約的初始化函數做權限和重復初始化限制，可能被攻擊者進行惡意初始化。

案例：2021年8月11日PunkProtocol被攻擊損失400萬美金

事故原因：池子的initialize函數未做權限和重復調用限制，攻擊者調用該函數將自己設置為Forge管理員權限，并調用withdrawToForge將池子所有資金都發送到攻擊者地址。

解決方案：初始化函數必須設置成只能初始化一次。

未正確檢查對應合約函數實現

通常智能合約被調用的函數不存在時會報錯，但如果合約實現了fallback函數，則會自動調用fallback函數。有時fallback函數并不會報錯，導致調用方誤以為調用成功。

bitFlyer用戶報告：二十多歲男子參與的數字貨幣交易量迅速增加:日本交易所bitFlyer的用戶報告稱，在之前的交易中三十多歲的男子占主導地位，但是最近二十多歲的男子參與的交易數量在迅速增加，年齡占比從2018年7月份的24%上漲到2020年7月份的34%，這也意味著“經驗不足的投資者”占總數的比例也在增加。（coinpost）[2020/8/21]

案例：2022年1月18日跨鏈橋Multichain被攻擊損失450ETH

事故原因：通常ERC20的合約會實現permit函數，用于簽名檢查與授權操作。但WETH、PERI、OMT、WBNB、MATIC、AVAX六種代幣的合約沒有實現permit卻實現了fallback，Multichain在檢查這些代幣的權限時誤以為用戶已經授權轉賬給攻擊者，導致代幣被盜。

解決方案：不同代幣的實現方式不同，引入新代幣之前應仔細檢查其具體實現。

未正確處理帶轉賬費的代幣

有些代幣在轉賬時會銷毀一部分轉賬費用，導致實際收到的代幣余額偏少，如果開發者沒考慮到這一點，以轉賬值計算，會導致出現偏差。

案例：2021年8月19日Pinecone被盜20萬美金

事故原因：Pinecone使用其代幣PCT作為資金池的質押代幣，PCT轉賬會有手續費的損耗。合約并沒有考慮相關損耗導致用戶份額和質押的PCT總額出現偏差，被攻擊者利用領取多余的獎勵。

解決方案：謹記不是所有的代幣轉賬費都為nativetoken。

簽名驗證漏洞

簽名被重復使用，或者利用橢圓曲線簽名算法的對稱性，根據已有簽名構造合法簽名。

案例：2021年7月12日AnySwap被盜800萬美金

創大資本許洪波：區塊鏈是未來二十年最大的商業變數:創大資本許洪波：區塊鏈是未來二十年最大的商業變數，帶來一個比互聯網要大百倍以上的產業和變革。具體而言，包括兩個方向：一個是物聯網，一個是人工智能。[2018/3/21]

事故原因：對交易簽名除了私鑰外需要一個隨機數R，但是Anyswap部署新合約失誤，導致在BSC上的V3路由器MPC帳戶下有兩個交易具有相同的R值簽名，攻擊者反推到這個MPC賬戶的私鑰轉走了被盜資金。

解決方案：使用EIP-712標準驗證簽名，參考OpenZeppelin的實現：https://docs.openzeppelin.com/contracts/3.x/api/drafts。

未考慮合約余額可能產生的變化

礦工挖出塊時或者智能合約調用selfdestruct函數銷毀自己時可以向任意地址強行打幣改變其原生代幣的余額。當使用余額函數返回值作為判斷條件時，余額有可能被強行改變導致風險，極端情況下甚至導致合約拒絕服務。

示例代碼

即使捐贈合約不能接受代幣轉賬，合約余額也可能在部署后被改變，嚴格檢查已空投總量與合約余額之和等于總供應量可能導致捐贈合約拒絕服務。

解決方案：在合約中避免對合約余額做嚴格相等的檢查。

使用delegatecall調用外部合約

delegatecall可以將對應合約的函數代碼內嵌到當前上下文中執行，就像調用內置函數一般。如果不小心調用了惡意合約極易導致攻擊。

示例代碼

當攻擊者調用forward函數并傳入Attack合約地址以及函數setOwner()作為參數時，Proxy合約owner將被修改為攻擊者地址。

解決方案：不推薦使用delegatecall調用外部合約。

授權tx.origin

tx.origin是交易的發起者地址，合約如果使用tx.origin做權限檢查，當合約的授權用戶與惡意合約交互時，惡意合約調用合約即可通過合約權限檢查。

示例代碼

當MyWallet合約owner使用transferTo函數向Attack合約轉賬時，Attack合約會重入MyWallet合約，并調用transferTo函數，此時tx.origin仍然為MyWalletowner，require條件滿足，MyWallet余額將被全部轉移至Attack合約。

解決方案：不使用tx.origin做權限檢查。

交易排序競爭

全節點運行者可以在交易被確認之前獲取交易信息，進而根據獲取的交易信息，構造高手續費交易，讓礦工優先打包自己的交易以執行對自己有利的策略。例如，謎語合約獎勵最快找出謎底的用戶，惡意用戶可以在獲悉誠實用戶提交的謎底后，構造高手續費交易優先誠實用戶提交謎底，從而獲取獎勵；又如當用戶更新授權額度時，被授權用戶可以在更新授權額度交易被確認之前轉移舊的授權額度，如此，被授權人實際獲得的授權額度為兩次授權額度之和。

解決方案：針對謎語合約，獲得謎底的用戶先提交「隨機數+自身地址+謎底」的哈希值，謎語合約存儲該哈希值后，用戶再提交隨機信息與答案，合約檢查哈希值匹配后再發放獎勵；更新授權額度時先置零授權額度。

使用block.timestamp或者block.number作為合約時間參考

block.timestamp與block.number都不能獲得精確都時間，用作智能合約的時間參考會引入潛在的風險。

解決方案：使用oracle獲取時間信息。

Denial-of-Service(DoS)拒絕服務

調用外部合約可能永久失敗導致本合約不能接受新的指令，例如當合約主動對另外一個合約轉賬，而被轉賬合約沒有接受轉賬的函數時，轉賬失敗，此時合約可能進入拒絕服務狀態。

示例代碼

當合約向其中一個賬號轉賬失敗會導致所有轉賬全部失敗。

解決方案：合約調用外部合約時可能出現的失敗，合約需包含處理調用失敗情況的代碼，防止合約進入拒絕服務狀態。

使用鏈屬性作為隨機源

鏈屬性如block.timestamp,blockhash,bock.difficulty以及其他屬性可被礦工操控，存在風險。

解決方案：考慮使用RANDAO，oracle或比特幣區塊hash作為隨機源。

繼承順序錯誤

多個被繼承合約都定義了同一個函數時，繼承合約調用該函數的優先級由繼承順序決定，錯誤的繼承順序將導致函數調用錯誤。

解決方案：繼承順序說明請參考官方實例：https://solidity-by-example.org/inheritance/。

Gas不足攻擊

多簽情況下或者需要其他人幫自己代付Gas時，用戶準備好簽名交易并交給代執行人，代執行人再將用戶交易提交給執行合約，代執行人可以提前審查用戶代交易，惡意的代執行人或當交易內容不利于代執行人時，可以通過限制Gas的供給，使交易的執行失敗，從而阻止交易的執行。

示例代碼

當Relayer調用者通過限制Gas使用導致某個交易失敗，那么失敗的交易將永遠不能再被提交。

解決方案：選擇信任的代執行人，或者在執行合約中檢查代理人提供的Gas費是否足夠。

函數類型變量跳轉

solidity支持函數類型變量，當函數類型變量使用匯編指令賦值時，函數類型變量有可能被指向惡意構造當函數。

解決方案：如無必要，盡量避免在智能合約中使用匯編指令。

GasLimit服務拒絕攻擊

區塊設置有Gas使用上限，如果合約當執行超過了區塊Gas使用上限，則合約永遠不能被執行成功。

示例代碼

當操作的循環次數過大時，執行合約所需Gas將超過區塊上限，導致合約執行失敗。

解決方案：在智能合約中謹慎操作大數組，或循環。

abi.encodePacked()哈希碰撞

abi.encodePacked()采用非填充序列化，當序列化參數包含多個變長數組時，攻擊者可以在保持所有元素順序不變的前提下，改變兩個變長數組的元素，如此序列化的結果相同。

示例代碼

通過構造addUser的輸入，攻擊者可以將regularUsers的成員加入admins成員，但是構造的輸入和原輸入的簽名相同。

解決方案：使用定長數組，或者不讓調用者傳入abi.encodePacked()的參數，或者使用abi.encode()。

transfer()和send()函數Gas不足

transfer()和send()函數使用2300gas以防止重入攻擊，公鏈升級后可能導致gas不足。

解決方案：推薦使用call()函數，但需做好重入攻擊防護。

鏈上未加密隱私數據

鏈上數據完全透明，合約的private關鍵字不能阻止合約的隱私數據泄漏。

示例代碼

雖然players為private，但攻擊者仍然可以通過解析鏈上數據讀取players。

解決方案：隱私數據需要加密放在鏈上。

以上是我們分析和總結的二十三種安全事故類型匯總，希望能夠給到您些許參考和啟示。

Tags：ALLACKGASFORmathwalletsproblackmambacoinEthereum Gas LimitNimbus Platform

Gateio