交易緩存池的重放攻擊

WF曲速未來提醒：對于曾經被盜幣，修復方案僅為：關閉對公網暴露的RPC接口，關閉后繼續使用節點中相關賬戶的節點，可能會受到該攻擊。

在之前講到，為了實現攻擊者不停的發送轉賬請求的功能，筆者使用了while True循環，并且在geth終端中看到了多條成功簽名的交易hash。由于交易緩存池擁有一定的校驗機制，所以除了第一筆交易0x4ad68aafc59f18a11c0ea6e25588d296d52f04edd969d5674a82dfd4093634f6外，剩下的交易應該因為賬戶余額不足而被移出交易緩存池。

但是在測試網絡中卻出現了截然不同的情況，在我們關閉本地的geth客戶端后，應該被移出交易緩存池的交易在余額足夠的情況下會再次出現并交易成功：

（為了避免該現象的出現，可以在成功轉賬之后利用break終止相關的循環）

這個交易奇怪的地方在于：在賬戶余額不足的情況下，查找不到任何Pendding Transactions：

當賬戶余額足夠支付時，被移出交易緩存池的交易會重新出現，并且是 Pendding 狀態。

在部分pendding的交易完成后，剩余的交易將會繼續消失。

這也就意味著，如果攻擊者能夠在利用偷渡漏洞的過程中，在交易被打包進區塊，賬號狀態發生改變前發送大量的交易信息，第一條交易會被立即實行，剩余的交易會在受害人賬號余額大于轉賬金額 gas 消耗的金額的時候繼續交易，而且這個交易信息在大多數情況下不會被查到。

對于這個問題進行分析研究后，我們認為可能的原因是：以太坊在同步交易緩存池的過程中可能因為網絡波動、分布式的特點等原因，導致部分交易多次進入交易緩存池。這也導致部分應該被移出交易緩存池的交易多次重復進入交易緩存池。

具體的攻擊流程如下：

本地復現過程

對于前面講到的現象進行了多方面的猜測。最終在低版本的geth中模擬復現了該問題。但由于現實環境的復雜性和不可控性，并不能確定該模擬過程就是造成該現象的最終原因，故該本地復現流程僅供參考。

攻擊復現環境位于私鏈中，私鏈挖礦難度設置為0×400000，保證在挖出區塊之前擁有足夠的時間檢查各節點的交易緩存池。geth的版本為1.5.0。

被攻擊者的節點A：通過geth–networkid 233–nodiscover–verbosity6–ipcdisable–datadir data0–rpc–rpcaddr0.0.0.0console啟動。

礦機節點B，負責挖礦：通過geth–networkid 233–nodiscover–verbosity 6–ipcdisable–datadir data0–port30304–rpc–rpcport 8546 console啟動并在終端輸入miner.start(1)，使用單線程進行挖礦。

存在問題的節點 C：通過geth–networkid 233–nodiscover–verbosity 6–ipcdisable–datadir data0–port 30305–rpc–rpcport 8547 console啟動。

各節點啟動后通過admin.nodeInfo和admin.addPeer()相互添加節點。

1. 攻擊者掃描到被攻擊節點A開放了rpc端口，使用如下代碼開始攻擊：

2.節點A的用戶由于轉賬的需求，使用personal.unlockAccount()解鎖賬戶，導致偷渡漏洞發生。由于一共進行了三次轉賬請求并成功廣播，所以A、B、C交易緩存池中均存在這三筆交易。

3. 由于網絡波動等原因，此時節點C與其它節點失去連接。在這里用admin.removePeer()模擬節點C掉線。節點B繼續挖礦，完成相應的交易。后兩筆交易會因為余額不足從交易緩存池中移除，最終節點A，B的交易緩存池中將不會有任何交易。

4.上述步驟1-3即是前文說到的偷渡漏洞，被攻擊者A發現其節點被攻擊，迅速修改了節點A的啟動命令，去除了–rpc–rpcaddr 0.0.0.0，避免RPC端口暴露在公網之中。之后繼續使用該賬戶進行了多次轉賬。例如，使用其它賬號給節點A上的賬號轉賬，使的節點A上的賬號余額為1.980065000882e 24

5.節點C再次連接進網絡，會將其交易池中的三個交易再次廣播，發送到各節點。這就造成已經移除交易緩存池的交易再次回到交易緩存池中。

6.由于此時節點A的賬戶余額足夠，第二個交易將會被打包進區塊，節點A中的余額再次被盜。

WF曲速未來提醒：在實際的場景中，不一定會出現節點 C 失去連接的情況，但由于存在大量分布式節點的原因，交易被其它節點重新發送的情況也是可能出現的。這也可以解釋為什么在前文說到：賬戶余額足夠時，會出現大量應該被移除的pendin交易，在部分交易完成后，pending交易消失的的情況。當賬戶余額足夠時，重新廣播交易的節點會將之前所有的交易再次廣播出去，在交易完成后，剩余pending交易會因為余額不足再次從交易緩存池中被移除。

除了文章說到的現象外，亦不排除攻擊者設置了惡意的以太坊節點，接收所有的交易信息并將部分交易持續廣播。但由于該猜想無法驗證，故僅作為猜測思路提供。