Bitsquatting表示去注册一个域名，它和知名的域名只有一个bit的差别。这个单词源自typosquatting，意为注册一个和知名域名只有一字之差的域名。在解析域名时，bitsquatting可能通过DNS导致计算机上的硬件错误。关于bitsquatting更详细的信息，可以参看我的Blackhat 2011 whitepaper。YouTube上有人发布了我在DEF CON 19上有关此话题的演讲视频，当时使用的幻灯片可以在这里下载。
引言
计算机常常由于一个或多比特的内存损坏出现错误，而造成这些错误的原因可能是制造上的缺陷或者宇宙射线、高温之类的环境因素。虽然单个机器中出现这样的错误的可能性是极小的，但是整个互联网上设备的总量却非常庞大：2010年时就有大约50亿个设备连接到互联网。我们可以将这种存在于各个设备上的小概率错误更加形象地描述，那就是买彩票。赢得头奖的概率是极小的，但是只要有足够多的人去买，总有人会成为赢家。
研究人员之前就在很多惊人的地方利用了比特错误（bit-errors）。现在，在互联网尺度上，我们又有新的办法去利用它。Bitsquatting是其中之一，也就是注册和某个常被访问的域名仅一比特之差的新域名。
工作原理
当比特错误发生时，内存中的数据会被修改。计算机内存的内容可能代表各种意义，有时，它刚好就表示域名。如果程序使用这块内存，就会读取到错误的域名。
下面的图解能够更清楚的说明这个问题，表中是cnn.com的二进制表示方法：
| 01100011 | 01101110 | 0110111 | 0101110 | 01100011 | 01101111 | 01101101 |
| c | n | n | . | c | o | m |
现在假设你使用的计算机含有损坏的内存模块，你打开一个包含超链接到cnn.com的网页，然后你点击了这个链接。会有多少个操作将cnn.com的二进制数据保存到你的内存？写这篇文章时，我想到了下面这些：
- TCP/IP协议栈由核心态向用户态转化时（根据操作系统的具体实现各有区别）
- 在浏览器解析HTML时
- 在创建DOM树的内部表示时
- 在创建新的HTTP请求时
- 在操作系统解析域名时
更进一步，假设其中有一次将域名写入到了损坏的内存模块，它的二进制形式被修改了1bit，现在表示为：
| 01100011 | 01101111 | 0110111 | 0101110 | 01100011 | 01101111 | 01101101 |
| c | o | n | . | c | o | m |
这样一来，当你点击链接时，浏览器将会跳转到con.com，而不是cnn.com。
实验
这个实验背后的概念很简单：如果比特错误确实改变了设备内存中的域名，那么这些设备会访问到和正确域名一比特之差的bitsquat域名。因此很多频繁解析的域名的bitsquat域名会被全球各地的设备访问到。
然而这个实验实施起来却没有那么容易，首要的问题是选择合适的域名来进行比特修改。流行的网站和常被解析的域名是不太相同的，很多鲜为人知的域名实际上会被频繁解析。这类域名一般属于内容分发网络或者广告网络，例如fbcdn.net,、2mdn.net和 akamai.com。由于很少有人实际在浏览器中输入这些域名，它们也成为本次实验中最合适的目标。还有个问题就是每次DNS查询必须有两次响应：一次是原本的域名，一次是经过比特修改的域名。因为原始的请求可能会得到正确域名的响应，而丢弃对无效域名的响应。这方面更多的信息，请参考白皮书或者幻灯片。
为了这次实验我注册了下面这些域名。
注：目前它们全都已经过期，不再属于我了。
| Bitsquat Domain | Original Domain |
| ikamai.net | akamai.net |
| aeazon.com | amazon.com |
| a-azon.com | amazon.com |
| amazgn.com | amazon.com |
| microsmft.com | microsoft.com |
| micrgsoft.com | microsoft.com |
| miarosoft.com | microsoft.com |
| iicrosoft.com | microsoft.com |
| microsnft.com | microsoft.com |
| mhcrosoft.com | microsoft.com |
| eicrosoft.com | microsoft.com |
| mic2osoft.com | microsoft.com |
| micro3oft.com | microsoft.com |
| li6e.com | live.com |
| 0mdn.net | 2mdn.net |
| 2-dn.net | 2mdn.net |
| 2edn.net | 2mdn.net |
| 2ldn.net | 2mdn.net |
| 2mfn.net | 2mdn.net |
| 2mln.net | 2mdn.net |
| 2odn.net | 2mdn.net |
| 6mdn.net | 2mdn.net |
| fbbdn.net | fbcdn.net |
| fbgdn.net | fbcdn.net |
| gbcdn.net | fbcdn.net |
| fjcdn.net | fbcdn.net |
| dbcdn.net | fbcdn.net |
| roop-servers.net | root-servers.net |
| doublechick.net | doubleclick.net |
| do5bleclick.net | doubleclick.net |
我使用Python脚本应答DNS请求，并且使用Apache记录HTTP请求。令我惊讶的是，有设备连接了。
实验发现
以下结论是基于2010年9月26日至2011年5月5日间的Apache日志得出的。由搜索引擎爬虫和Web漏洞扫描器引起的日志已经被手动过滤了。正因为是手动操作，所以最后统计时可能还有很小一部分漏网之鱼。
发现1：比特错误可以被利用在DNS上
在记录日志期间总共有52317次针bitsquat域名的请求，它们来自与12949个独立IP。除去其中3次产生巨大网络流量的事件，平均每天有59个独立IP对32个bitsquat域名进行了请求。这些请求不是来自于拼写错误或者其他形式的手工输入URL，还有一部分表现出有多个比特错误的特征。以下是一些实际的例子（个人信息已经移除）：
static.ak.fjcdn.net 109.242.50.xxx “GET /rsrc.php/z67NS/hash/4ys0envq.js HTTP/1.1″ “http://www.facebook.com/profile.php?id=xxxxxxxxxx” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; GTB6.5; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.30729; .NET CLR 3.5.30729; InfoPath.2; Hotbar 11.0.78.0; OfficeLiveConnector.1.5; OfficeLivePatch.1.3; AskTbZTV/5.8.0.12304)”
msgr.dlservice.mic2osoft.com 213.178.224.xxx “GET /download/A/6/1/A616CCD4-B0CA-4A3D-B975-3EDB38081B38/ar/wlsetup-cvr.exe HTTP/1.1″ 404 268 “Microsoft BITS/6.6″
s0.2ldn.net 66.82.9.xxx “GET /879366/flashwrite_1_2.js HTTP/1.1″ “http://webmail.satx.rr.com/_uac/adpage.html” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; HPNTDF; AskTB5.2)”
mmv.admob.com 109.175.185.xxx “GET /static/iphone/img/app@2x.png HTTP/1.1″ “Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; HW iPhone2,1; en_gb) AppleWebKit/525.18.1 (KHTML, like Gecko) (AdMob-iSDK-20101108; iphoneos4.2)”
发现2：并不是所有的比特错误都造成同等程度的影响
有些机器相比其他而言，明显控制着更多的网络流量。当一个比特错误发生在普通PC机或者手机上时，它只会影响到一个用户。然而当它发生在代理、DNS服务器或者数据库缓存中时，将会影响到成千上万的用户。在我的实验中，已经观察到了比特错误出现在Web应用、DNS解析服务器和代理服务器中。例如，一个比特错误将fbcnd.net变为fbbdn.net，将使上千个开心农场的玩家请求到我的服务器。
发现3：手机和嵌入式设备可能比传统硬件受的影响更大
我对2011年3月期间访问Wikipedia和bitsquat域名的HTTP User-Agent进行了对比，展示在下面的图例中。其中Other包括了各种手机、游戏机控制台和其他嵌入式设备，它们在对bitsquat域名的访问中，增加的幅度最大。令人好奇的是，来自MacOS针对bitsquat域名的访问相比Wikipedia有显著减少，对此我还没有一个合理的解释。（译注：这里是按两个域名各自的设备分布算的，其中有增多必然有减少，也许分别计算每种设备访问错域名的几率更加合理，即访问错误域名的次数 / 对两种域名的访问总数。）
发现4：对bitsquat域名的访问流量是日常网络流量的真实写照
Bitsquat域名的访问者来自于全球各地，其使用的设备也几乎涵盖每种主流的操作系统和嵌入式平台。除使用MacOS的访问者所占的百分比在两种域名间有显著差别之外，使用Windows、Linux、Android和iPhones的百分比基本相同。另外，基于IP地理位置数据库，我们可以观察到来自于美国的访问者在一天内的流量走势。
发现5：HTTPS/TLS不会有帮助，DNSSEC可能会有一丁点
HTTP 1.1在头中包含了一个叫Host的字段，其数值是客户端想要访问的域名。如果Host中包含着bitsquat域名，那么比特错误在域名解析前就发生了。如果Host中是原始域名，那么错误就是发生在域名解析中。我数据中96%的情况是在DNS解析前就出现了比特错误。
像SSL和TLS这种安全传输技术是用于保证两端之间数据的机密性、真实性和完整性，但是比特错误更多发生在数据在某一端还未传输的时候。DNSSEC只能解决那4%发生在域名解析过程中的比特错误。
数据
DNS流量的全部PCAP在此：dnslogs.tar.7z，56Mb
HTTP日志可能包含个人信息，因此不会公开发布。如果你有正当的研究目的需要它们，请联系我。
这里有个工具可以快速识别潜在的bitsquat域名：bitsquat.py，github
进一步研究
来自Verisign的Duane Wessels也在DNS查询中寻找过网络级别的比特错误，他指出“网络中比特错误相对而言是很少见的，但是有一个可预期的概率”。他研究的主要目的，是确定那4%发生在域名解析时的比特错误是否由UDP包在传输后的损坏造成。结论是网络中传输的包不太可能被损坏，用他自己的话说：“我们相信UDP的校验和能够有效防范bitsquat攻击或者其他DNS查询时的错误。无论如何，在进入网络前发生的比特错误不会从中受益，因为在传输前计算的校验和是基于错误的数据得出的。“
我非常鼓励读者重复我的实验，并且分享你们的结果。如果需要更多信息，请随时联系我。
