Eosbet上次遭受所謂的“假EOS”攻擊被盜(被薅走5w EOS)，這次又爆出假EOS轉賬通知(被捲走14w EOS)，真是讓大家對Eosbet的專業技術能力產生質疑。當然具體真相如何，只有官方最清楚。下面就來簡單描述下這兩個BUG

“假EOS”攻擊

    “假EOS“攻擊是攻擊者在自己的智慧合約裡建立一個假EOS代幣，並給Eosbet賬號轉賬假的eos代幣，並主動通知Eosbet智慧合約，這樣系統就會呼叫Eosbet合約的transfer函式，Eosbet合約沒有檢測通知來源，誤當做真的EOS轉賬，於是仍按照真的開獎流程開獎，由於價EOS不值錢，而Eosbet合約開的獎是真EOS，所以攻擊者假錢換真錢，無成本薅羊毛。 這個bug通過檢測code來源即可修復。

“假EOS通知”攻擊

“假EOS通知”攻擊是指攻擊者通過eosio.token給自己的智慧合約賬號(eosbethack)轉真EOS， eosio.token合約會通過require_receipt程式碼呼叫攻擊者的智慧合約eosbethack，由於攻擊者在eosbethack通過require_receipt主動呼叫eosbet, 導致eosbet的transfer函式被呼叫，但合約的code還是eosio.token,從而合法的通過了上述"eosio.token"檢測邏輯。具體原理如下：

第一步(偽造轉賬通知):

第二步(eosbet沒有檢測to)

EOS權威開發指南缺失

    上次的“假EOS” bug可以理解為真正的bug ,而這次的假EOS轉賬通知，我覺得EOS開發團隊也要負一點點小的責任。理論上eosbethack通過require_receipt進入eosbet合約時, 上下文環境應該切換為eosbethack, 而不應該仍然是eosio.token。也就是code的值應該為eosbethack而不應該是eosio.token。這有點像函式A呼叫B，B又呼叫C, 結果C檢測到是A呼叫C(A->C), 所以說目前EOS的這種上下文規則有點違背程式設計思維習慣，估計除非有官方文件(事實上缺失詳細文件)或者檢視原始碼，否則一般的開發人員很容易掉坑。require_receipt這裡已經出現了3個bug, 惡意消耗RAM，假EOS攻擊，假EOS通知攻擊。10月1日，慢霧同學出版了安全開發手冊，但是該bug也沒有涉及到。當然如果通過專業審計稽核的程式碼還是會考慮各種corner case的，也會避免這個bug，比如pixelmaster的遊戲程式碼就加了這個檢測。

但是這種反常理未明確提示的使用方法及規則，一般開發人員很容易入坑，所以Dapp開發，開發人員要多一份敬畏，畢竟Dapp離錢這麼近，小小錯誤損失的可不是體驗，使用者而是大量金錢。

攻擊回放實踐

    大家可以參考如下原始碼實踐

    執行過程如下：

作者個人技術能力有限，如有錯誤請指點

嘗試長按二維碼關注公眾號吧（^_^)

公眾號:區塊鏈斜槓青年

歡迎大家加我微信:itleaks