區塊鏈安全技術總結

x00前言

區塊鏈的安全需求越來越多，下面就將這些需求一一拆分，看看區塊鏈安全需求到底是個什麼樣子。

x01拆分

目前針對安全服務行業的區塊鏈安全需求，更多的是基於其上層應用（紅色箭頭指向）比如數字貨幣交易平台、移動數字貨幣錢包、DAPP等

在實際測試中也是按照這幾類進行的劃分，下面我會針對這幾類常見的區塊鏈應用說明其使用過程中存在的風險，如何避免風險，以及一些實際操作過程中的案例。

x02金融新戰場-數字貨幣交易所

數字貨幣交易所，常見火幣，OKcoin，幣安，都是我們這些韭菜掙（pei）錢（guang）的好去處。對於這類平台就按照平時對Web站點的滲透思路進行挖掘就行，但是有一點千萬記住，別上來就掃描器，Sqlmap，御劍什麼的，否則今天的活也就別幹了。根據測試經驗，這種費力不討好的活就放在最後,上來可以先選擇邏輯進行測試，因為數字貨幣平台的邏輯來來回回就那麼幾樣：註冊、登錄、地址管理（充幣、提幣、交易）、委託交易查詢、買入賣出（法幣、幣幣、槓桿和期貨）、賬號安全（密碼修改、谷歌驗證、手機和郵箱驗證）、買家身份實名認證、場外交易時使用的支付寶、微信和銀行卡的地址和二維碼等、以及多平台快速交易使用的API介面管理等。

從功能上其實並不複雜，功能與功能之間的業務關聯性也是顯而易見：

註冊->實名認證->手機/郵箱/谷歌驗證碼->法幣交易獲取代幣->幣幣交易/槓桿交易->提幣到其他地址

這裡給出兩個案例

案例一：收款賬戶處的存儲型XSS

在微信賬號，支付寶賬號處可插入惡意腳本，惡意腳本隨交易廣告下發

當用戶與惡意廣告用戶進行交易時，需要顯示賬戶信息，此時觸發該XSS

此處的XSS影響比較大，可以get到其他與攻擊者進行交易的身份認證信息。

案例二：無密買入賣出功能的CSRF漏洞

進入某幣交易模塊，設置交易措施為每次交易不輸入密碼

構造CSRF表單並生成偽造交易請求的表單，因掛單交易是自動確認，所以存在極大風險，易被惡意攻擊進行交易操作。

當用戶訪問並點擊時，表單內容提交給交易網站，買入賣出操作成功

x03放在兜里的記賬本-移動數字貨幣錢包

錢包從早期的PC端全節點錢包（體積大又不能攜帶）到現在到小而輕的移動錢包（就是APP了），將個人數字資產的管理做到更快截和方便。如圖，移動錢包可以用於資產的查看，轉賬，地址管理等不需要全節點參於的功能。

重點關注以下四個方面：

私鑰生成與存儲的安全

助記詞生成與存儲的安全

Keystore生成與存儲的安全

和錢包口令生成與存儲的安全

針對四個方面，可以總結出多個滲透維度

密鑰保存維度：私鑰是否明文存儲本地，keystore是否明文存儲本地、助記詞是否明文存儲本地

錢包備份：私鑰導出過程安全（檢查私鑰導出過程是否阻止屏幕劫持，是否保存在日誌當中或臨時文件當中）

keystore 導出過程安全：檢查keystore導出過程是否阻止屏幕劫持，是否保存在日誌當中或臨時文件當中）

轉賬過程：轉賬數據的機密性和完整性

x04區塊鏈應用新寵-DAPP

DAPP-分散式應用：基於不同的底層區塊鏈開發平台和共識機制。現在絕大多數都是在以太坊（Ethereum），比如各種加密遊戲，分散式寵物 ，百度的萊茨狗，網易 的網易星球，360的區塊貓 ，小米的區塊鏈遊戲加密兔等等。

這裡給出一個區塊鏈養貓例子。

案例一：

全美最火的區塊鏈寵物，價格也不貴，0.0019 ETH 大概6塊左右

這個DAPP與傳統的Web或者頁游最大的區別就是其去中心化的結構，除了瀏覽器和伺服器外，所有的交換操作都寫入到了以太坊中的多個智能合約當中，對操作過程和結果進行安全的記錄。

對這類DAPP進行滲透的時候需要考慮到整個DAPP的身份認證機制是基於密碼學中的 公鑰認證機制（私鑰簽名，公鑰驗簽），那麼後端伺服器是否能夠正確的安全的驗證簽名後的信息就是很關鍵的點，比如下圖中的請求（這是一個DAPP和以太坊地址綁定的過程），sign是對以太坊地址的簽名，伺服器處理請求時如果未對請求中的sign進行安全校驗，那麼M ITM手段可以偽造以太坊地址進行惡意綁定，同時如果未對溢出進行防禦，比如 AAAA*10000… 也會發生拒絕服務的問題。

另一個問題是，以太坊modifiers（修改器）特性導致的特權函數的惡意調用。在以太坊應用中modifiers會被用作定義某些只能被特定地址（特權地址）調用的函數。在調用函數之前需要對請求的私鑰進行驗簽，此處就會存在一個風險，伺服器如果能保證這些私鑰不丟失，一旦特定地址的私鑰丟失，那麼特權函數就會被惡意調用造成無法估計的後果。

x05區塊鏈中堅力量-智能合約

智能合約（Smart contract）：以信息化方式傳播、驗證或執行合同的計算機協議。在沒有第三方的情況下進行可信交易，這些交易可追蹤且不可逆轉

現在做智能合約審計的公司有，慢霧科技，降維科技和知道創宇等。但從審計方向上講大方向上是對合約中危險函數的使用，加密的生成和數據傳遞等方面進行安全審計。

下面給出一些智能合約審計過程常關注的問題

1. 重入問題-關鍵函數被惡意多次調用

當使用call.value()()處理轉幣時，會將剩餘的 Gas 全部給予外部調用（fallback 函數）智能合約的fallback函數內遞歸withdrawBalance()便可以轉走更多的幣。攻擊者可以部署一個包含惡意遞歸調用的合約將公共錢包合約里的 Ether 全部提出。

修復：使用send() 和 transfer() 轉幣，只會傳遞2300Gas供調用，防止重入攻擊。

2. 訪問控制-初始化函數可被任何人調用

風險：

合約 A 以 call 方式調用外部合約 B 的 func() 函數，在外部合約 B 上下文執行完 func() 後繼續返回 A 合約上下文繼續執行；A 以 delegatecall 方式調用時，相當於將外部合約 B 的 func()代碼複製過來（其函數中涉及的變數或函數都需要存在）在 A 上下文空間中執行。當合約幣中存在惡意代碼，直接對合約A的運行邏輯造成危害。

修復：

每一個外部調用都會有潛在的安全威脅，儘可能的從你的智能合約內移除外部調用。如果你沒法完全移除外部調用，另一個簡單的方法來阻止這個攻擊是確保你在完成你所有內部工作之前不要進行外部調。

3. 不安全的函數返回值-函數返回值未進行檢查和判斷

風險：

使用send() 函數進行轉賬時，因為沒有驗證 send() 返回值，如果msg.sender 為調用失敗，則send() 返回 false。未驗證false並進行回滾，最終導致賬戶餘額減少了，錢卻沒有拿到。

修復：

使用transfer() 進行安全的轉幣操作，當發送失敗時會自動回滾狀態，該函數調用沒有返回值。

4. 跨函數競爭-在餘額清零前調用轉幣

風險：

使用withrawBalance函數時調用transfer()，此時，withdrawBalance沒有執行到userBalances[msg.sender] = 0;（餘額清0）那麼餘額就沒有被清零，能夠繼續調transfer()重複轉走代幣。攻擊者利用該漏洞進行惡意提幣和轉賬。

修復：

先減少發送人的餘額再進行價值轉移；另外一個解決方法就是用互斥鎖，從而一起緩解各種競爭條件。

5. 溢出-數值未進行校驗造成的溢出攻擊

向上溢出：

如果任何用戶都有權利更改uint的值，讓其大於最大值（2^256），因為溢出而被設置為0

向下溢出：

如果一個uint別改變後小於0，那麼將會導致它下溢並且被設置成為最大值（2^256）

修復：

使用SafeMath的安全方法，進行數值的安全處理。

6. 偽隨機性-隨機數的生成過程可預測

風險：

合約中的存儲數據都能在鏈上查詢分析得到。如果合約代碼沒有嚴格考慮到鏈上數據公開的問題去使用隨機數，可能會被攻擊者惡意利用來進行「作弊」 。如果seed的使用不夠隨機，那麼產生的隨機數值就可預測。

修復：

所提幣、錢包轉賬，所以除了在編寫合約的時候需要嚴格驗證輸入數據的正確性，而且在 Off-Chain 的業務功能上也要對用戶所輸入的地址格式進行驗證，防止短地址攻擊的發生。

7. 短地址攻擊-利用EVM解析補0操作惡意提幣

風險：

EVM將會為不滿足ERC20的代幣交易地址補上尾部的零，導致轉賬扣除的地址處理時發生變化。攻擊者通過這種方式從其他地址進行惡意扣幣。

修復：

所提幣、錢包轉賬，所以除了在編寫合約的時候需要嚴格驗證輸入數據的正確性，而且在 Off-Chain 的業務功能上也要對用戶所輸入的地址格式進行驗證，防止短地址攻擊的發生。

8. 智能合約審計工具

https://github.com/melonproject/oyente

https://github.com/trailofbits/manticore

https://github.com/ConsenSys/mythril

9. 審計步驟

面談開發者->評審.sol文件->編譯->分析代碼流->運行oyente->運行Manticore->運行MAIAN->手工複審

x06區塊鏈源頭-密碼學與密鑰安全

區塊鏈為什麼有那麼大的魔力，在於它的底層原理，在於它的源頭，那個技術背書-密碼學

區塊鏈中的哪些地方用到了密碼學：

1.哈希演算法 比特幣系統中使用的兩個哈希函數分別是：SHA-256，主要用於完成PoW（工作量證明）計算；RIPEMD160，主要用於生成比特幣地址；

2.Merkle哈希樹基於哈希值的二叉樹或多叉樹，在計算機領域，Merkle樹大多用來進行完整性驗證處理，在分散式環境下，其進行完整性驗證能大量減少數據傳輸和計算的複雜程度；

3.橢圓曲線演算法 比特幣中使用基於secp256k1橢圓曲線數學的公鑰密碼學演算法進行簽名與驗證簽名，一方面可以保證用戶的賬戶不被冒名頂替，另一方面保證用戶不能否認其所簽名的交易。用私鑰對交易信息簽名，礦工用用戶的公鑰驗證簽名，驗證通過，則交易信息記賬，完成交易；

4.對稱加密演算法比特幣官方客戶端使用AES（對稱分組密碼演算法）加密錢包文件，用戶設置密碼後，採用用戶設置餓密碼通過AES對錢包私鑰進行加密，確保客戶端私鑰的安全。

最終的原則還是：保護好私鑰。從私鑰的整個生命周期來看，可以從以下幾個方面進行安全分析

1．硬體模塊抗拆毀、抗功耗分析、錯誤注入攻擊等側信道分析能力；

2. 隨機數生成演算法強度，隨機數發生器產生隨機數的隨機性；

3. 密鑰與密鑰參與運算過程都在硬體當中；

4. 密鑰導入導出過程全在硬體中實現；

密鑰恢復與備份; 主要關注加密貨幣，私鑰通過助記符來協助恢復， 助記符的安全是關鍵。

現有的安全措施—演算法白盒

靜態白盒：演算法+密鑰+白盒密碼技術->演算法密碼庫（白盒庫） 靜態白盒更新密鑰，需要重新生成白盒庫。

動態白盒：白盒庫無需更新，密鑰+白盒密碼技術->白盒密鑰 白盒密鑰傳入相匹配的白盒庫可以進行正常的加密或解密功能。

實現過程如下圖：

現有的安全措施—密鑰隨機化：

橢圓曲線演算法實現生成密鑰 再配合代碼加固，代碼混淆方法

現有的安全措施—協同簽名/解密：

需要一個可信的後台伺服器，解密/簽名密鑰由客戶端和伺服器端協同產生，且子密鑰由各自保管。這種方法安全性和效率相對較高。

*本文作者：Carry your system，本文屬 FreeBuf 原創獎勵計劃，未經許可禁止轉載

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！