DeFi 常見安全漏洞及預防措施

近期，一位安全專家爲社區成員分享了一堂 DeFi 安全課。專家回顧了過去一年多 Web3 行業遭遇的重大安全事件,探討了這些安全事件發生的原因以及如何規避,總結了常見智能合約的安全漏洞及預防措施,還對項目方和普通用戶給出了一些安全建議。

常見的 DeFi 漏洞類型一般有閃電貸、價格操縱、函數權限問題、任意外部調用、fallback 函數問題、業務邏輯漏洞、私鑰泄漏、重入等。下面重點介紹閃電貸、價格操控以及重入攻擊這三種類型。

閃電貸

閃電貸本身是 DeFi 的一種創新,但當被黑客利用時,他們可以在不需要任何成本的情況下借到大量資金,執行完整個套利流程後歸還,只需支付少量的 Gas 費用就可以獲得巨額收益。

過去兩年裏,閃電貸出現了很多問題。一些 DeFi 項目看起來收益很高,但實際上項目方的水平參差不齊。有的項目代碼可能是購買的,即便代碼本身沒有漏洞,在邏輯上仍可能存在問題。例如,曾經有一個項目會在固定時間根據持倉者持有的代幣數量發放獎勵,卻被攻擊者利用閃電貸購買大量代幣,在獎勵發放時,大部分獎勵都流向了攻擊者。此外,還有一些通過 Token 來計算價格的項目,可以通過閃電貸影響價格。作爲項目方應該對這些問題提高警惕。

價格操控

價格操控問題與閃電貸關係密切,這個問題主要是由於價格計算時其中一些參數可以被用戶控制,經常出現的問題類型有兩種:

1. 計算價格時使用第三方的數據,但使用方式不正確或檢查缺失導致價格被惡意操控。

2. 使用了一些地址的 Token 數量作爲計算變量,而這些地址的 Token 餘額可以被臨時增加或減少。

重入攻擊

調用外部合約的主要危險之一是它們可以接管控制流,並對你的數據進行調用函數未預料到的更改。

由於用戶的餘額直到函數的最後才設置爲 0,第二次(和以後的)調用仍然會成功,並且會一遍又一遍地提取餘額。

針對不同的合約,重入存在的方式很多,可以結合合約的不同函數或多個不同合約的函數完成重入攻擊,所以我們在解決重入問題時需要注意以下幾點:

1. 不只是防止單一函數的重入問題;

2. 遵循 Checks-Effects-Interactions 模式進行編碼;

3. 使用經過時間驗證的防重入 modifier。

其實最怕的就是重復造輪子,需要什麼都自己寫。在這個圈內有很多最佳安全實踐,我們拿來用就好,完全沒有必要重復造輪子。當你造一個輪子的時候,是沒有通過充分的驗證的,這個時候出問題的概率,很明顯比用一個非常成熟的久經考驗的出問題的概率要大得多。

安全建議

項目方安全 Tips

1. 合約開發遵循最佳安全實踐。

2. 合約可升級、暫停:很多攻擊不是一次性的把幣全轉走,而是分多筆交易去執行,如果有一個相對健全的監控機制的話,是可以發現的,發現之後合約假設是可以暫停的,就可以有效的去降低損失。

3. 採用時間鎖:如果有時間鎖的話,假設是 48 小時之內才能完成,這個時候在時間鎖的很多人能發現這個創建者重新更新了一個 mint 的方法,且誰都可以用,監控的人就知道項目應該是被黑了,就可以通知項目方去改變,即使假設通知了也沒人管,至少可以先把自己的那部分錢給拿出來,先保證自己的收益不受損。所以說一個項目如果沒有時間鎖的話,理論上來講是增加了出問題的概率。

4. 加大安全投入,建立一套完善的安全體系:安全不是一個點,也不是一條線,安全是成體系的。不要覺得作爲項目方,合約通過多家公司審計就沒問題了。要盡量做風險建模,然後逐步地將大部分風險規避掉,剩餘風險也是可接受風險,在可承受範圍內。安全和效率是不可能兼得的,要做一定的取舍。但如果完全不管安全,在安全上沒有投入的話,被攻擊是很正常的。

5. 提高所有員工的安全意識:提高安全意識並不需要很多技術。在這個大環境內,只要稍微多問一些爲什麼,稍微多想一點就能規避掉很多問題。

6. 預防內部作惡,在提升效率的同時增強風控。

7. 三方引入安全性:作爲生態中的一環,項目方都會有自己的上下遊。安全上有一個"默認上下遊都是不安全"的原則。無論對於上遊還是下遊,都要做校驗。對於三方我們是很難控制,安全的風險敞口實際上特別大,所以要很注意三方的引入。合約是開源的,可以去引入、調用它;如果合約不開源,就絕對不能引用。

用戶/LP 如何判斷智能合約是否安全?

對於普通用戶,我們判斷項目是否安全主要看以下六點:

1. 合約是否開源:凡是合約不開源的項目,堅決不碰,因爲我們無從得知合約寫的是什麼。

2. Owner 是否採用多籤,多籤是否去中心化:如果不用多籤,我們無法判斷項目的業務邏輯和內容,一旦出現安全事件,無法判斷是否爲黑客所爲。即便採用多籤,也需要判斷一下多籤是不是去中心化的。

3. 合約已有的交易情況:尤其市面上有很多搞釣魚詐騙的項目,可能會做一個比較相似的合約,這個時候我們就要看一下合約的部署時間、交互次數等,這些都是判斷合約是否是安全的衡量標準。

4. 合約是否爲代理合約,是否可升級,是否有時間鎖:如果合約完全不能升級,就太死板了,還是推薦項目的合約是可以升級的。但是升級要講究方法,當升級有升級內容、重要參數更改的時候,要有一個時間鎖定,要有給大家一個時間窗口去判斷真實升級是對用戶有害的還是有利的,這也是公開透明的一種方式。

5. 合約是否接受過多家機構審計(不要盲目信任審計公司), Owner 權限是否過大:首先不要只相信一家審計公司,因爲不同的審計公司,不同的審計人員,看問題的角度是不一樣的。其次要看 Owner 的權限是否過大。一個正常的項目 Owner 的權限一定是可控的,這樣就不會有太多高危操作,操作也會用時間鎖的方式,讓用戶知道操作的是什麼。

6. 注意預言機:如果項目使用市面上的龍頭預言機,基本上不會有太大問題,但如果使用自建的預言機,或者用一些隨便抵押一些代幣就可以往裏去喂價的預言機,那就要注意了。當發現預言機可能會存在一些問題,或者說存在被操縱可能的時候,即便項目收益再高也不能參與。