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查詢時的錯誤。無論如何，在進入網路前發生的位元錯誤不會從中受益，因為在傳輸前計算的校驗和是基於錯誤的資料得出的。“
我非常鼓勵讀者重複我的實驗，並且分享你們的結果。如果需要更多資訊，請隨時聯絡我。