作者：慢霧安全團隊
公眾號：慢霧科技
披露時間線
2019 年 3 月 10 日，我們捕獲了 EOS DApp 上的一種新型攻擊手法，一個帳號名為 fortherest12 的攻擊者通過 hard_fail 狀態攻擊手法攻擊了 EOS 游戲 Vegas town ，并造成了一定數量的損失。
2019 年 3 月 10 日，我們注意到出現了數量更多的 hard_fail 類型攻擊。
2019 年 3 月 11 日，我們披露了相關的攻擊手法，但是沒有披露具體的攻擊細節，并及時聯系了相關的交易所以及項目方。
2019 年 3 月 12 日，我們發布紅色預警，提醒交易所和錢包需要對 EOS 交易執行狀態進行校驗，必要時可暫停充提系統。
2019 年 3 月 13 日，預警得到 EOS New York 及 Block.one 的 BM 等核心成員響應及認可。
2019 年 3 月 14 日，細節正式公開。
漏洞細節
參考官方文檔，可以得知 EOS 交易的執行狀態存在多種，相應的類別及相應的描述分別為：
- executed：交易正確執行，沒有觸發 error handler
- soft_fail：交易客觀失敗(沒有執行)，但正確觸發 error handler
- hard_fail：交易客觀失敗，但沒有觸發 error handler
- delayed：交易延遲/deferred/在隊列中待執行
- expired：交易過期
此次的攻擊手法就是利用了上述狀態中的 hard_fail 狀態進行攻擊，在以前的開發過程中，許多開發者都不曾碰到過這種交易執行狀態，常規的區塊瀏覽器上也無法查詢到相關的交易，造成了開發者缺少對這種交易狀態的認知。開發中的慣常思維也是只有合約才能發起延時交易。但是，通過 cleos 中的具體參數配置 delay-sec 參數：
即使使用非合約帳號也能正常發起 delay 交易，針對使用中心化開獎的 DApp 項目方或使用中心化管理的交易所及錢包，如果沒有對 EOS 交易的執行狀態進行校驗，就有可能出現 “假充值” 攻擊，攻擊者不需要付出任何成本，卻可以獲得大量的 EOS。這是一種全新的攻擊手法，而且也是大家十分容易忽略的點，但是導致的危害卻是巨大的。對于這種手法，我們已經捕獲到真實攻擊，并成功阻止了一起損失金額以人民幣億為單位的攻擊及多起巨額損失。但遺憾的是，還是存在幾起被成功攻擊的事件，這個超出了我們的能力，我們的客戶或伙伴只是這個生態里的一小部分而已。
基于上述情況，我們于 3 月 12 日發布了我們的紅色預警，但由于我們的翻譯不夠嚴謹，在 EOS 社區引起了恐慌，讓 EOS 社區誤以為這是 EOS 的漏洞，我們對此致以歉意。EOS 社區的一些成員認為，只要交易所及錢包做好相關的檢查，并不會出現此類問題。但是我們很難要求所有程序員都能寫出最佳安全實踐的代碼，當出現不嚴謹的校驗方式便會導致攻擊發生。
經過我們的分析，我們更傾向于 transaction status 屬于 EOS 的一種特性(features)，歷史上曾經出現多例與特性相關的 “假充值” 漏洞。
如我們主導披露的：
USDT 虛假轉賬安全?險分析
以太坊代幣“假充值”漏洞細節披露及修復方案
及我們參與披露的：
XRP 官方披露的假充值漏洞及相關分析
這些問題都不是鏈自己本身的漏洞，但是由于鏈自己本身的特性的原因，以及開發者對此類特性校驗的不嚴謹從而導致了攻擊的發生。這就是我們為什么會發布紅色預警。這不是恐嚇(FUD)，更像是一種容易被人忽略的攻擊手法。此類攻擊手法之前在 EOS 上沒有相同的攻擊案例，但在我們公布相關的攻擊手法后，根據我們聯合 EOSPark 的數據分析系統發現，已經有十幾個帳號開始分別對 DApp、交易所以及錢包作出攻擊測試，這些帳號有：
bobukulabobu
cuancuan2323
testsuperdex
zhangjiayiba
justjiezhan1
wnze2qwdiyne
havls3k3iyge
ha11w4zzmpge
wkdoptxcjvdn
xmqukuailian
allosauruses
ccholr1ub2ku
walletthomas
fuckhakcer.x
johnwickteam
eosiotokenio
peospeospeos
eczpfezhvnrk
等等其他帳號其中不乏攻擊成功的帳號。因此，我們繼續發出后續預警，提醒相關項目方做好防范措施。除此之外，Twitter 帳號 Whale Alert 也關注到了此類攻擊行為。Whale Alert 官方帳號在 3 月 11 日發布推文稱帳號 fuckhacker.x 轉賬 1 萬億 EOS，隨后被官方證明為虛假交易。可見此次攻擊波及范圍之廣。應引起足夠的重視。
修復方案
針對此類型的交易，相關項目方以及交易所及錢包需要對 EOS 轉賬的執行狀態進行校驗，確保交易執行狀態為 “executed”，除此之外，在區塊不可逆的情況下，也要做到以下幾點防止其他類型的 “假充值” 攻擊的發生
- 判斷 action 是否為 transfer
- 判斷合約賬號是否為 eosio.token 或其它 token 的官方合約賬號
- 判斷代幣名稱及精度
- 判斷金額
- 判斷 to 是否是自己平臺的充幣賬號
后記 Q&A
Q：節點開啟 read only 模式能防范此類攻擊嗎？
A：根據官方文檔對 read only 模式的描述
節點開啟 read only 模式后可以查詢到線上記錄并存在的確認的交易。而此類攻擊手法是先發出 defer 交易，defer 交易是在鏈上保存的真實存在的交易，隨后這筆交易才會轉變成 hard_fail，所以開啟 read only 模式并不能防御此類攻擊手法。交易的狀態是從 delay 轉變成 hard_fail，并不是回滾，這是需要注意的地方。
Q：為什么我在其他的區塊瀏覽器上，如 EOSX 等不能查詢到 hard_fail 交易？
A：現有的查詢交易是通過 EOS 的歷史插件 history plugin 來查詢的，而根據 history plugin 的代碼實現
可以發現，除了 executed 和 soft_fail 交易外其他交易都無法查詢到。
Q：是否使用 history plugin 獲取交易即可避免此類攻擊？
A：無法保證，不同的節點 history plugin 插件的實現方式不一，不排除節點提供方自己修改 history plugin 實現，導致查詢到的交易存在除 exectued 及 soft_fail 外的其他狀態。
Q：交易所及錢包等項目方平臺該如何配置他們自己的節點免受攻擊？
A：使用默認的 history plugin 配置，除此之外檢查 EOS 轉賬的交易狀態，確保交易執行狀態為 “executed”。同時，也需要判斷以下幾點防止其他類型的 “假充值”
- 判斷 action 是否為 transfer
- 判斷合約賬號是否為 eosio.token 或其它 token 的官方合約賬號
- 判斷代幣名稱及精度
- 判斷金額
- 判斷 to 是否是自己平臺的充幣賬號
這些點都是曾在歷史上出現過問題的點，我們認為 EOS 生態是一個很強大，靈活的全新的生態，從 EOS 主網啟動以來，我們參與了許多的安全應急事件，開發者想在這個生態內安全的發展的確是一件充滿挑戰的事情。需要做好各方面的安全檢查，才能確保資產不受損失。
結語
我們希望閱讀此文的 EOS 生態中的用戶不要模仿文中的攻擊手法，我們無意對 EOS 社區造成恐慌。慢霧安全團隊本著為 EOS 生態帶來更多的安全感為宗旨，及時披露相關安全事件細節，目的是為了 EOS 生態中的更多成員獲得安全保障。相關項目方應及時做好充提系統的安全保障，落實對應的風控策略，保障自身財產的安全。
相關參考
- How to monitor state with State History Plugin：https://developers.eos.io/eosio-nodeos/docs/how-to-monitor-state-with-state-history-plugin
- 官方文檔對 nodeos 三種模式的描述：https://developers.eos.io/eosio-nodeos/docs/read-modes
- USDT 虛假轉賬安全?險分析：https://mp.weixin.qq.com/s/CtAKLNe0MOKDyUFaod4_hw
- 以太坊代幣“假充值”漏洞細節披露及修復方案：https://mp.weixin.qq.com/s/3cMbE6p_4qCdVLa4FNA5-A
- XRP 官方披露的假充值漏洞及相關分析：https://developers.ripple.com/partial-payments.html
- EOS 新型攻擊手法之 hard_fail 狀態攻擊：https://mp.weixin.qq.com/s/qsqqPB24fEjBgnq3Xr3xjQ
- EOS 智能合約最佳安全開發指南：https://github.com/slowmist/eos-smart-contract-security-best-practices
致謝
EOSPark
IMEOS
jerry@EOSlive 錢包
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/853/
暫無評論