標籤：

攻擊技術還原：維基解密是如何遭到黑客攻擊的？

02-08

8 月 30 號，沙烏地阿拉伯黑客組織OurMine成功入侵了維基解密網站，消息已經公布，輿論頓時嘩然，詳情請點擊此處。眾所周知，維基解密 賴以成名的手段就是攻擊別人來獲取機密信息，沒想到這次竟被人黑了一把，不知阿桑奇心理是什麼滋味。下面，我就為大家來詳細從技術角度還原一下維基解密是怎樣被黑客攻擊的。

關於被攻擊的種種技術猜測

之前有些人推測，維基解密的Web伺服器被破解後，破解者修改了其頁面的內容（網站被替換成了"OurMine" 的聲明），但根據我的分析這種猜測根本就不靠譜。

還有一種猜測是，黑客成功將wikileaks.org域名破解，但根據我的觀察，wikileaks.org域名的名稱沒有被解析成通常的IP地址而出現在另外一個主機中。

由於對網路安全的事件分析需要大量的數據證據，所以分析往往都非常延後，因為當分析師收集到所有的數據時，新的事件又出來了，以前的分析也已經沒有什麼實際意義了。而對於內部人員來說，他們在遭受攻擊後，往往不會如實地公布事實，這讓分析變得更加困難。維基解密在被攻擊後的反應就是否認這個事實，然後嘗試淡化該事件，迄今為止，他們還沒有為用戶發布任何有價值的信息，這就造成了大家不斷地對其行為妄加猜測。

利用DNS下手

基於此，本文我的分析會從DNS開始著手，因為DNS是互聯網的關鍵基礎設施。 DNS分散式資料庫是以域名為索引的（如wikileaks.org域名或ssi.gouv.fr），每個索引節點都是一顆倒置的樹，每一個節點實際上也是一個域命名空間。當你查詢給定域名的DNS時，你將獲得各種技術信息，例如伺服器的IP地址，加密密鑰，伺服器名稱等。比如，當Web瀏覽器訪問okstate.com/時，用戶設備上的軟體執行名稱為okstate.com的DNS查詢，並返回HTTP伺服器的IP地址，最後連接到伺服器。

如此，你就可以追蹤到是誰在哪裡控制了DNS，用戶最終的IP地址等。整個DNS解析過程（從名稱到數據）本身都是相當複雜的，這就為黑客提供了許多機會。不過，雖然DNS如此重要，但大多數組織忽略了對其的防護。

但DNS中的數據來自哪裡呢？這是線索的關鍵，在此要注意的是，大多數所謂的「DNS攻擊」都不是真正的DNS攻擊，這意味著它們不會利用DNS協議的漏洞。大多數情況下，黑客是針對配置基礎設施的攻擊，域名持有者（如維基解密wikileaks.org域名）用於配置數據的一些開發者和伺服器。假設你負責一個名為Foobar組織的在線活動，那你的域名就是foobar.example。又假設該網站由Wonderful Hosting公司管理，那麼你選擇頂級域名時通常需要選擇一個註冊商，如此一來，該代理人成為你和頂級域名實際註冊表（registry）的代理人。大多數情況下，你將連接到註冊商的網站，創建一個帳戶，最終這些信息都將顯示在DNS中的數據種。例如，當網站在Wonderful Hosting上創建時，你將在註冊商提供的控制面板中輸入你的IP地址。如果你使用了弱密碼，該帳戶可能會被盜用。這種攻擊是非常普遍的，同時也說明並非所有的攻擊在技術上都是複雜的。

那麼回到維基解密事件，它的DNS是否遭受到攻擊？我將首先使用基於「被動DNS」的DNSDB，DnsDB是全球最大的DNS查詢資料庫，我可以通過該資料庫觀察到DNS流量，並將其記錄下來。

DNSDB中有什麼？

;; bailiwick: org.;; count: 9;; first seen: 2017-08-30 04:28:40 -0000;; last seen: 2017-08-30 04:30:28 -0000wikileaks.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 -0000wikileaks.org. IN NS ns1.rival-dns.com.wikileaks.org. IN NS ns2.rival-dns.com.wikileaks.org. IN NS ns3.rival-dns.com.

在攻擊期間.org註冊表對非法的伺服器進行過回復：

% 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.81ns2.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...

可以看出，註冊表提供的內容與nsX.wikileaks.org域名名稱伺服器之間的內容存在差異，因為管理維基解密DNS的任何管理員都會發動惡意活動，這就是為什麼通常要來查詢父級的名稱伺服器。

所以，對於流氓伺服器來說，名稱伺服器也被改變了。請注意，攻擊期間也有一些差異。根據DNSDB，這些流氓伺服器提供了一組不同的名稱伺服器：

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

不過，這並不意味著黑客的DNS主機Rival從事了攻擊，因為黑客可能只是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 -0000wikileaks.org. IN A 181.215.237.148

維基解密的正常IP地址位於前綴95.211.113.XXX，141.105.XXX和195.35.109.XXX中， 181.215.237.148是由Rival託管的另一個流氓網站的地址，可以使用whois工具查看：

% whois 181.215.237.148inetnum: 181.215.236/23status: reallocatedowner: Digital Energy Technologies Chile SpAownerid: US-DETC5-LACNICresponsible: RivalHost, LLC.address: Waterwood Parkway, 1015, Suite G, C-1address: 73034 - Edmond - OKcountry: USowner-c: VIG28tech-c: VIG28abuse-c: VIG28...nic-hdl: VIG28person: AS61440 Network Operating Centere-mail: noc@AS61440.NETaddress: Moneda, 970, Piso 5address: 8320313 - Santiago - RMcountry: CL

這也表明這個前綴是在智利分配的，所以，根據以上的分析，貿然判斷攻擊者是通過改變服務於wikileaks.org域名的一組名稱伺服器來獲取訪問伺服器的許可權，是不可信的。

對域名配置系統的攻擊是很常見的，例如，2013年8月，敘利亞電子軍(SEA )對紐約時報網站進行了攻擊，採用的就是魚叉式釣魚攻擊拿下紐約時報的DNS登記伺服器( Melbourne IT)，修改解析，指向SEA自己的伺服器。

如前所述，一旦你控制DNS，你就可以控制所有內容。除此之外，你還可以將用戶重定向到假網站，劫持電子郵件等。因此，隨著對域名的攻擊，黑客已經不需要對伺服器發起伺服器了。

維基解密的哪個環節被攻擊了？

通過以上的分析，我可以肯定地說，名稱伺服器被改變了。維基解密本身，註冊商（Dynado）或註冊管理機構（.org，由PIR管理，技術上由Afilias管理）都有可能遭遇攻擊。從現有的信息來看，很難說清楚，問題出在哪裡。但根據推測，大多數時候，最薄弱的環節應該是註冊商或註冊管理機構，因為過去一年它們都被曝出了許多漏洞。

之前我說過，當你控制域名時，你可以將外部和內部的訪問者發送到你想要的伺服器。其實，這種說法，並不完全正確，因為良好的安全性依賴於深度防禦，即使你的域名受到威脅，也可採取一些措施來限制風險。其中一個辦法就是使用HTTPS，維基解密使用的就是它：

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

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

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

有趣的是，有許多人把這種攻擊稱之為「DNS污染」，針對這種特定攻擊的最佳防護DNSSEC並未被維基解密啟動（在wikileaks.org域名中有一個DNSSEC密鑰，但在父級沒有簽名和DS記錄 ）。如果wikileaks.org域名被簽名，並且你使用了驗證的DNS解析器，則維基解密就不會導致DNS污染。當然，如果黑客是對持有人賬戶，註冊商或註冊管理機構進行攻擊，DNSSEC就不會有太大的防禦效果。

維基解密為其名稱伺服器使用了膠合記錄（glue record），它們是域名伺服器的名稱伺服器名稱。 要允許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 -0000ns1.wikileaks.org. IN A 191.101.26.67

為wikileaks.org域名提供了一個有趣的值：

% 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 -0000wikileaks.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

本文翻譯自：bortzmeyer.org/observat ，如若轉載，請註明來源於嘶吼： 4hou.com/info/news/7558 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀：

※為什麼信用卡在銷卡之後要將磁條剪斷？
※懂技術的女人有多可怕系列 その一
※黑客通過控制麥克風竊取烏克蘭600GB數據
※ZoomEye 的網站指紋是什麼概念，如何應用？
※Adobe失誤公開了PGP密鑰，可能會造成哪些影響？

TAG:信息安全 |