DNS Rebinding繞過浏覽器SOP同源政策

看了大佬的以太坊生态缺陷導緻的一起億級代币盜竊大案，頓時感覺錯過了一次财富自由的機會，然而機會總是留給有積累的人

網際網路産品的開發往往遵循“小步快跑”的原則，先落地一個功能健全的“孩子”​，然後看着她慢慢長大，并輔以各種優化、各種更新檔

此案的關鍵是區塊鍊RPC接口監聽在公網，且沒有任何鑒權機制，隻能說以太坊“尚在幼年”，安全問題正在引起重視​。此案緩解措施：監聽端口綁定在本機位址，而不是公網位址

然而并沒有根本解決問題，黑客仍然可以通過dns rebinding技術攻擊以太坊：以太坊用戶端Geth、Mist、Parity等（更多以太坊概念）在本地監聽的服務，沒有任何鑒權

一、DNS rebinding原理

為了保證DNS服務的可靠性，DNS響應記錄A中包含一個TTL（time to live）值，表示目前解析結果的有效時間，用戶端（浏覽器）會在超過這個時間值後重新請求解析域名（取決于用戶端是否遵循這個TTL值），得到的新響應中又會存在一個過期時間，用戶端會再次去解析域名，如此保證擷取到最新的域名解析結果。

若DNS服務前後響應傳回的ip位址不一樣，浏覽器并不會認為跨域。如果域名後續解析到的ip為127.0.0.1、192.168.0.1等不同于先前解析結果，浏覽器依然認為符合同源政策，會将請求發送到127.0.0.1機器上。如此就産生了dns rebinding攻擊

浏覽器​和作業系統均會存在DNS緩存，緩存時間一般不按照DNS伺服器響應中的TTL值，比如固定為60s。檢視chrome的dns cache，chrome://net-internals/#dns，檢視Windows作業系統dns緩存 ipconfig /displaydns

​

2、攻擊場景

》使用者通路到攻擊者的網站www.evil.com

》網站加載一個隐藏iframe​，randomattack.evil.com:8545

》iframe過了60s後 使用ajax請求randomattack.evil.com:8545/sectest，此時域名解析到的ip為127.0.0.1

》之後的所有請求都是在使用者本機處理​

​攻擊着很容易搭建一個類似DNS服務，https://github.com/brannondorsey/whonow

但這個屬于被動攻擊，需要使用者通路到攻擊者網站才會發生

DNS rebinding分為ip劫持和防火牆繞過兩種攻擊，不但可以攻擊以太坊用戶端，redis、mongodb等，也可以用來繞過 SSRF或防火牆 的ip限制通路

​

另外很多開發者的電腦都配置有本地服務，存在資料被盜風險；wifi環境下，路由器也可以被此種方式攻擊；

當然隻有惡意網站會進行攻擊！

3、緩解措施

》浏覽器存在解析緩存及DNS pinning機制，不過有個小trick：可以先加載一個img，指向randomattack.evil.com:81/xx，由于81端口并沒有存在服務，導緻浏覽器DNS緩存及pinning失效，浏覽器會立刻再次進行DNS解析

》浏覽器屏蔽掉對特定端口的通路，如ssh(22), redis(6379),smtp(25)等​

》本地或内網服務，對于使用http協定的，應檢測http host頭​

​》網關處使用dnswall，過濾掉指向私有IP的DNS響應​

​​

4、參考

》http://bouk.co/blog/hacking-developers/

》https//crypto.stanford.edu/dns/dns-rebinding.pdf

​》https//github.com/mikispag/dns-rebinding-PoC

》https://ret2got.wordpress.com/2018/01/19/how-your-ethereum-can-be-stolen-using-dns-rebinding/

》​http://www.dtic.mil/dtic/tr/fulltext/u2/a508892.pdf

篇外，​ethereum foundation并不認為，利用dns rebinding攻擊geth等是有效漏洞