區塊鏈安全技術總結

0 x00 前言

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

0 x01 拆分

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

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

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

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

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

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

這裏給出兩個案例

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

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

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

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

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

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

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

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

0 x0 3   放在兜裡的記賬本-移動數字貨幣錢包

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

重點關注以下 四個方面 ：

私鑰生成與儲存的安全

助記詞生成與儲存的安全

Keystore生成與儲存的安全

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

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

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

錢包備份： 私鑰匯出過程安全（檢查私鑰匯出過程是否阻止螢幕劫持，是否儲存在日誌當中或臨時檔案當中）

keystore 匯出過程安全： 檢查keystore匯出過程是否阻止螢幕劫持，是否儲存在日誌當中或臨時檔案當中）

轉賬過程： 轉賬資料的機密性和完整性

0 x0 4   區塊鏈應用新寵- DAPP

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

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

案例一：

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

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

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

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

0 x0 5   區塊鏈中堅力量-智慧合約

智慧合約（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->手工複審

0 x0 6   區塊鏈源頭-密碼學與金鑰安全

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

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

1.雜湊演算法 比特幣系統中使用的兩個雜湊函式分別是：SHA-256，主要用於完成PoW（工作量證明）計算；RIPEMD160，主要用於生成比特幣地址；
2.Merkle雜湊樹基於雜湊值的二叉樹或多叉樹，在計算機領域，Merkle樹大多用來進行完整性驗證處理，在分佈式環境下，其進行完整性驗證能大量減少數據傳輸和計算的複雜程度；
3.橢圓曲線演算法 比特幣中使用基於secp256k1橢圓曲線數學的公鑰密碼學演算法進行簽名與驗證簽名，一方面可以保證使用者的賬戶不被冒名頂替，另一方面保證使用者不能否認其所簽名的交易。用私鑰對交易資訊簽名，礦工用使用者的公鑰驗證簽名，驗證通過，則交易資訊記賬，完成交易；
4.對稱加密演算法比特幣官方客戶端使用AES（對稱分組密碼演算法）加密錢包檔案，使用者設定密碼後，採用使用者設定餓密碼通過AES對錢包私鑰進行加密，確保客戶端私鑰的安全。

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

1．硬體模組抗拆毀、抗功耗分析、錯誤注入攻擊等側通道分析能力；
2. 隨機數生成演算法強度，隨機數發生器產生隨機數的隨機性；
3. 金鑰與金鑰參與運算過程都在硬體當中；
4. 金鑰匯入匯出過程全在硬體中實現；
5. 金鑰恢復與備份; 主要關注加密貨幣，私鑰通過助記符來協助恢復， 助記符的安全是關鍵。

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

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

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

實現過程如下圖：