十幾天前，維基解密遭受了一次攻擊，導致很多訪問者看到了“OurMine”的聲明，他們聲稱已經獲取了維基解密服務器的控制權。這次攻擊之後，很多人（包括維基解密的粉絲及其死對頭）在沒有基礎知識與技術功底，且未查明事件真相的情況下，發表了很多觀點。所以在這裏，作者從技術性的觀察角度，來陳述一些事實。

猜測

第一：有些人看到的東西顯然不是維基解密的網站，很多人拿出了這樣或者那樣的截圖，然後便有人推測：維基解密的服務器被入侵，入侵者修改了其內容。這是一個十分大膽的推測：因為從用戶瀏覽器到網頁顯示的整個過程是相當復雜的，其中有很多因素可以導致最後的判斷出錯。

第二：對於維基解密，另一種猜測是服務器並沒有被入侵，但是域名wikileaks.org被黑客當成目標且成功接管，觀察發現域名wikileaks.org並沒有被解析成以往的IP地址，而是被解析到了另一個主機，這是如何實現的？後果是什麽樣的？

觀察與分析

眾所周知，對於互聯網上的一些事件，調查起來通常都比較困難，外部分析師通常獲取不到全部的數據，有時分析剛開始，就已經太遲了，因為數據已經改變了。而內部分析師幾乎都是噤若寒蟬，有時甚至連蒙帶騙。不可否認，有一些組織的交流是十分開放的（參見Cloudflare報告或Gandi報告），但是他們只是例外。在這次的攻擊中，維基解密的反應更像是一個典型的公司，他們否認這個問題，不向用戶發布任何有價值的東西，並試圖逐漸淡化帶來的影響。因此我們閱讀到的很多網絡事件的聲明都沒有足夠的事實作為支撐。由於維基解密身處眾多熱點爭議的中心，問題就變得更糟糕了，由於沒有任何有價值的回應，一些維基解密的粉絲就開始了妄加猜測。

所以問題的關鍵就在於域名wikileaks.org。為了解釋到底發生了什麽，我們需要從DNS講起，它作為將域名和IP地址相互映射的一個分布式數據庫，能夠使人更方便地訪問互聯網。當一般Web瀏覽器訪問http://www.okstate.com/時，用戶機器上的軟件執行名稱為www.okstate.com的DNS查詢，並返回HTTP服務器的IP地址。最後連接到服務器。（註：一些黑客通過偽造DNS服務器將用戶引向錯誤網站，以達到竊取用戶隱私信息的目的。這種DNS服務器大約有68000臺。）

不過在一些情況下，域名持有者（如wikileaks.org）會選擇一個註冊商，然後再註冊商提供的控制面板中輸入解析的IP地址，如果使用了弱密碼，那麽賬號就非常容易被攻破，也就是賬號被盜用，這種攻擊非常普遍，而且也說明了並非所有攻擊都是十分高明的。

那麽維基解密發生了什麽呢？我們使用了基於被動DNS的DNSDB，它可以觀察到DNS流量，並允許用戶查詢改變之前的情況。說了這麽多，NDSDB裏到底有什麽？

;;  bailiwick: org.
;;      count: 9
;; first seen: 2017-08-30 04:28:40 -0000
;;  last seen: 2017-08-30 04:30:28 -0000
wikileaks.org. IN NS ns1.rivalhost.com.
wikileaks.org. IN NS ns2.rivalhost.com.
wikileaks.org. IN NS ns3.rivalhost.com.
;;  bailiwick: org.
;;      count: 474
;; first seen: 2017-08-30 04:20:15 -0000
;;  last seen: 2017-08-30 04:28:41 -0000
wikileaks.org. IN NS ns1.rival-dns.com.
wikileaks.org. IN NS ns2.rival-dns.com.
wikileaks.org. IN NS ns3.rival-dns.com.

在攻擊期間，註冊表正在對非法的服務器組進行回復。

% dig @a0.org.afilias-nst.info. NS wikileaks.org
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21194
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 3
...
;; AUTHORITY SECTION:
wikileaks.org.	86400 IN NS ns1.wikileaks.org.
wikileaks.org.	86400 IN NS ns2.wikileaks.org.
;; ADDITIONAL SECTION:
ns1.wikileaks.org.	86400 IN A 46.28.206.81
ns2.wikileaks.org.	86400 IN A 46.28.206.82
...
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Fri Sep 01 09:18:14 CEST 2017
...

所以名稱服務器被篡改了，根據DNSDB，這些流氓服務器提供了一組不同的NS（名稱服務器）：

;;  bailiwick: wikileaks.org.
;;      count: 1
;; first seen: 2017-08-31 02:02:38 -0000
;;  last seen: 2017-08-31 02:02:38 -0000
wikileaks.org. IN NS ns1.rivalhost-global-dns.com.
wikileaks.org. IN NS ns2.rivalhost-global-dns.com.

要註意的是，DNS主機Rival並不是此次攻擊的共犯，這可能只是一些流氓客戶。現今，大多數大型服務提供商中都存在這種情況。

當你將所有內容復原時，可以看到最後一次更改whois輸出的日期：

% whois wikileaks.org
...
Updated Date: 2017-08-31T15:01:04Z

很明顯，流氓名稱服務器正在提供指向“假”網站的IP地址。再次回到DNSDB中：

;;  bailiwick: wikileaks.org.
;;      count: 44
;; first seen: 2017-08-30 04:29:07 -0000
;;  last seen: 2017-08-31 07:22:05 -0000
wikileaks.org. IN A 181.215.237.148

維基解密的正常IP地址前綴為95.211.113.XXX，141.105.XXX和195.35.109.XXX（如果你想要查看它們，可以使用DNS Looking Glass）， 181.215.237.148是由Rival托管的流氓網站的IP，你可以使用whois工具查詢：

% whois 181.215.237.148
inetnum:     181.215.236/23
status:      reallocated
owner:       Digital Energy Technologies Chile SpA
ownerid:     US-DETC5-LACNIC
responsible: RivalHost, LLC.
address:     Waterwood Parkway, 1015, Suite G, C-1
address:     73034 - Edmond - OK
country:     US
owner-c:     VIG28
tech-c:      VIG28
abuse-c:     VIG28
...
nic-hdl:     VIG28
person:      AS61440 Network Operating Center
e-mail:      [email protected]
address:     Moneda, 970, Piso 5
address:     8320313 - Santiago - RM
country:     CL

這表明這個前綴是在智利分配的，黑客無法改變服務於wikileaks.org的名稱服務器。

社交網絡上的很多人聲稱，這次襲擊是由“DNS中毒”造成的，可見多數人對DNS中毒一知半解。對域名配置系統的攻擊是很常見的，例如，2013年，臭名昭著的SEA（敘利亞電子軍）對紐約時報網站進行了攻擊（詳見紐約時報與一份技術分析），他們拿下了紐約時報的DNS登記服務器( Melbourne IT)，修改解析，指向自己的服務器。最近還有一次對聖路易斯聯邦儲備委員會的攻擊。這種攻擊的後果是什麽？如上所述，一旦你控制DNS，你就可以控制所有內容。您可以將用戶重定向到偽造的網站（不僅是外部訪問者，而且還包括目標組織的員工，可以連接到內部服務，潛在竊取密碼和其他信息），劫持電子郵件等。因此，聲稱“服務器沒有被泄露“沒有意義。如果成功對域名進行攻擊，那麽攻擊者就不需要入侵服務器。

以上哪部分在維基解密案件中被破解？分析了外部原因，我可以肯定地說，名稱服務器被改變了。維基解密本身，註冊商（Dynado）或註冊管理機構（.org，由PIR管理，技術上由Afilias管理）都有弱點。從現有的信息來看，人們很難說清楚問題出在哪裏。但根據推測，大多數時候問題出在用戶，不過薄弱的環節還有註冊商或註冊管理機構，因為在過去它們都被曝出了嚴重的安全漏洞。

之前我說過，當你控制域名時，你可以將外部和內部的訪問者發送到你想要的服務器。但是這種說法並不是完全正確的，因為良好的安全性依賴於深度的防禦，即使您的域名受到威脅，也可采取一些措施來降低風險。其中一個就有使用HTTPS（維基解密就在使用），從純HTTP站點重定向，HSTS（在RFC 6797中標準化）以避免普通訪問者通過不安全的HTTP訪問。維基解密也在使用：

%  wget --server-response --output-document /dev/null https://wikileaks.org/
...
Strict-Transport-Security: max-age=25920000; includeSubDomains; preload

這些技術至少會引起網站管理者的警惕，同樣，使用Tor進入.onion網址也將有所幫助。但是我沒有能夠找到維基解密的.onion（http://suw74isz7wqzpmgu.onion/不起作用，http://wlupld3ptjvsgwqw.onion似乎只是為了上傳用的）。

維基解密也可以通過啟用註冊表鎖定來限制帳戶被攻擊的風險，這是大多數頂級域名（包括.org）提供的技術，以防止未經授權的更改。激活時，需要額外的步驟和檢查。

有趣的是，有許多人把這種攻擊稱之為“DNS毒化”，針對這種特定攻擊的最佳防護DNSSEC並未被維基解密激活（在wikileaks.org域名中有一個DNSSEC密鑰，但在父級沒有簽名和DS記錄 ）。如果wikileaks.org域名被簽名，並且如果使用了驗證的DNS解析器，那麽維基解密就不會被“DNS毒化”。當然，如果黑客是對持有人賬戶，註冊商或註冊管理機構進行入侵，DNSSEC就不會有太大的用處。

維基解密為其名稱服務器使用膠合記錄。它們是域名服務器的名稱服務器名稱， 要允許DNS客戶端查詢它們，父級必須知道此名稱服務器的IP地址，這就是所謂的粘合記錄。通過對DNSDB的記錄，ns1.wikileaks.org域名的粘合記錄顯然已被修改：（註意攻擊後幾個小時）：

;;  bailiwick: org.
;;      count: 546
;; first seen: 2017-08-31 00:23:13 -0000
;;  last seen: 2017-08-31 06:22:42 -0000
ns1.wikileaks.org. IN A 191.101.26.67
這臺機器還是上線，為wikileaks.org提供了一個有趣的值（再次提醒，你可以使用DNS Looking Glass）：
% dig @191.101.26.67 A wikileaks.org
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53887
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
wikileaks.org.	400 IN A 127.0.0.1

一些DNSDB探測確實註意到了這個IP地址，意味著這是本地主機，

;;  bailiwick: wikileaks.org.
;;      count: 1
;; first seen: 2017-08-31 09:17:29 -0000
;;  last seen: 2017-08-31 09:17:29 -0000
wikileaks.org. IN A 127.0.0.1

由於DNS嚴重依賴於緩存，即使在配置被修復之後，信息仍然能被看到。 在這裏，作者使用RIPE Atlas探針與Atlas解析工具，以查看有多少探針仍然能看到錯誤的值（註意日期和時間，全部以UTC為單位，這是分析網絡問題時的規則）：

% atlas-resolve -r 1000 -t A wikileaks.org
[141.105.65.113 141.105.69.239 195.35.109.44 195.35.109.53 95.211.113.131 95.211.113.154] : 850 occurrences 
[195.175.254.2] : 2 occurrences 
[127.0.0.1] : 126 occurrences 
Test #9261634 done at 2017-08-31T10:03:24Z

(點擊這裏查看報告PDF)

關於8月31日維基解密被攻擊的觀察與分析