此次的攻擊手法就是利用了上述狀態中的 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 生態中的更多成員獲得安全保障。相關專案方應及時做好充提系統的安全保障，落實對應的風控策略，保障自身財產的安全。
致謝 EOSPark IMEOS admin@chaindaily 錢包
