以太坊JSON-RPC接口多種盜幣揭秘之重放攻擊區(qū)塊鏈
WF曲速未來提醒:對于曾經(jīng)被盜幣,修復方案僅為:關(guān)閉對公網(wǎng)暴露的RPC接口,關(guān)閉后繼續(xù)使用節(jié)點中相關(guān)賬戶的節(jié)點,可能會受到該攻擊。
交易緩存池的重放攻擊
WF曲速未來提醒:對于曾經(jīng)被盜幣,修復方案僅為:關(guān)閉對公網(wǎng)暴露的RPC接口,關(guān)閉后繼續(xù)使用節(jié)點中相關(guān)賬戶的節(jié)點,可能會受到該攻擊。
在之前講到,為了實現(xiàn)攻擊者不停的發(fā)送轉(zhuǎn)賬請求的功能,筆者使用了while True循環(huán),并且在geth終端中看到了多條成功簽名的交易hash。由于交易緩存池擁有一定的校驗機制,所以除了第一筆交易0x4ad68aafc59f18a11c0ea6e25588d296d52f04edd969d5674a82dfd4093634f6外,剩下的交易應該因為賬戶余額不足而被移出交易緩存池。
但是在測試網(wǎng)絡(luò)中卻出現(xiàn)了截然不同的情況,在我們關(guān)閉本地的geth客戶端后,應該被移出交易緩存池的交易在余額足夠的情況下會再次出現(xiàn)并交易成功:
(為了避免該現(xiàn)象的出現(xiàn),可以在成功轉(zhuǎn)賬之后利用break終止相關(guān)的循環(huán))
這個交易奇怪的地方在于:在賬戶余額不足的情況下,查找不到任何Pendding Transactions:
當賬戶余額足夠支付時,被移出交易緩存池的交易會重新出現(xiàn),并且是 Pendding 狀態(tài)。
在部分pendding的交易完成后,剩余的交易將會繼續(xù)消失。
這也就意味著,如果攻擊者能夠在利用偷渡漏洞的過程中,在交易被打包進區(qū)塊,賬號狀態(tài)發(fā)生改變前發(fā)送大量的交易信息,第一條交易會被立即實行,剩余的交易會在受害人賬號余額大于轉(zhuǎn)賬金額 gas 消耗的金額的時候繼續(xù)交易,而且這個交易信息在大多數(shù)情況下不會被查到。
對于這個問題進行分析研究后,我們認為可能的原因是:以太坊在同步交易緩存池的過程中可能因為網(wǎng)絡(luò)波動、分布式的特點等原因,導致部分交易多次進入交易緩存池。這也導致部分應該被移出交易緩存池的交易多次重復進入交易緩存池。
具體的攻擊流程如下:
本地復現(xiàn)過程
對于前面講到的現(xiàn)象進行了多方面的猜測。最終在低版本的geth中模擬復現(xiàn)了該問題。但由于現(xiàn)實環(huán)境的復雜性和不可控性,并不能確定該模擬過程就是造成該現(xiàn)象的最終原因,故該本地復現(xiàn)流程僅供參考。
攻擊復現(xiàn)環(huán)境位于私鏈中,私鏈挖礦難度設(shè)置為0×400000,保證在挖出區(qū)塊之前擁有足夠的時間檢查各節(jié)點的交易緩存池。geth的版本為1.5.0。
被攻擊者的節(jié)點A:通過geth–networkid 233–nodiscover–verbosity6–ipcdisable–datadir data0–rpc–rpcaddr0.0.0.0console啟動。
礦機節(jié)點B,負責挖礦:通過geth–networkid 233–nodiscover–verbosity 6–ipcdisable–datadir data0–port30304–rpc–rpcport 8546 console啟動并在終端輸入miner.start(1),使用單線程進行挖礦。
存在問題的節(jié)點 C:通過geth–networkid 233–nodiscover–verbosity 6–ipcdisable–datadir data0–port 30305–rpc–rpcport 8547 console啟動。
各節(jié)點啟動后通過admin.nodeInfo和admin.addPeer()相互添加節(jié)點。
1. 攻擊者掃描到被攻擊節(jié)點A開放了rpc端口,使用如下代碼開始攻擊:
2.節(jié)點A的用戶由于轉(zhuǎn)賬的需求,使用personal.unlockAccount()解鎖賬戶,導致偷渡漏洞發(fā)生。由于一共進行了三次轉(zhuǎn)賬請求并成功廣播,所以A、B、C交易緩存池中均存在這三筆交易。
3. 由于網(wǎng)絡(luò)波動等原因,此時節(jié)點C與其它節(jié)點失去連接。在這里用admin.removePeer()模擬節(jié)點C掉線。節(jié)點B繼續(xù)挖礦,完成相應的交易。后兩筆交易會因為余額不足從交易緩存池中移除,最終節(jié)點A,B的交易緩存池中將不會有任何交易。
4.上述步驟1-3即是前文說到的偷渡漏洞,被攻擊者A發(fā)現(xiàn)其節(jié)點被攻擊,迅速修改了節(jié)點A的啟動命令,去除了–rpc–rpcaddr 0.0.0.0,避免RPC端口暴露在公網(wǎng)之中。之后繼續(xù)使用該賬戶進行了多次轉(zhuǎn)賬。例如,使用其它賬號給節(jié)點A上的賬號轉(zhuǎn)賬,使的節(jié)點A上的賬號余額為1.980065000882e 24
5.節(jié)點C再次連接進網(wǎng)絡(luò),會將其交易池中的三個交易再次廣播,發(fā)送到各節(jié)點。這就造成已經(jīng)移除交易緩存池的交易再次回到交易緩存池中。
6.由于此時節(jié)點A的賬戶余額足夠,第二個交易將會被打包進區(qū)塊,節(jié)點A中的余額再次被盜。
WF曲速未來提醒:在實際的場景中,不一定會出現(xiàn)節(jié)點 C 失去連接的情況,但由于存在大量分布式節(jié)點的原因,交易被其它節(jié)點重新發(fā)送的情況也是可能出現(xiàn)的。這也可以解釋為什么在前文說到:賬戶余額足夠時,會出現(xiàn)大量應該被移除的pendin交易,在部分交易完成后,pending交易消失的的情況。當賬戶余額足夠時,重新廣播交易的節(jié)點會將之前所有的交易再次廣播出去,在交易完成后,剩余pending交易會因為余額不足再次從交易緩存池中被移除。
除了文章說到的現(xiàn)象外,亦不排除攻擊者設(shè)置了惡意的以太坊節(jié)點,接收所有的交易信息并將部分交易持續(xù)廣播。但由于該猜想無法驗證,故僅作為猜測思路提供。
1.TMT觀察網(wǎng)遵循行業(yè)規(guī)范,任何轉(zhuǎn)載的稿件都會明確標注作者和來源;
2.TMT觀察網(wǎng)的原創(chuàng)文章,請轉(zhuǎn)載時務(wù)必注明文章作者和"來源:TMT觀察網(wǎng)",不尊重原創(chuàng)的行為TMT觀察網(wǎng)或?qū)⒆肪控熑危?br>
3.作者投稿可能會經(jīng)TMT觀察網(wǎng)編輯修改或補充。