看了大佬的以太坊生态缺陷导致的一起亿级代币盗窃大案，顿时感觉错过了一次财富自由的机会，然而机会总是留给有积累的人
互联网产品的开发往往遵循“小步快跑”的原则，先落地一个功能健全的“孩子”，然后看着她慢慢长大，并辅以各种优化、各种补丁
此案的关键是区块链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等是有效漏洞