攻击技术还原：维基解密是如何遭到黑客攻击的？
8 月 30 號，沙特阿拉伯黑客組織OurMine成功入侵了維基解密網站，消息已經公布，輿論頓時嘩然，詳情請點擊此處。眾所周知，維基解密 賴以成名的手段就是攻擊別人來獲取機密信息，沒想到這次竟被人黑了一把，不知阿桑奇心理是什么滋味。下面，我就為大家來詳細從技術角度還原一下維基解密是怎樣被黑客攻擊的。
關于被攻擊的種種技術猜測
之前有些人推測，維基解密的Web服務器被破解后，破解者修改了其頁面的內容（網站被替換成了"OurMine" 的聲明），但根據我的分析這種猜測根本就不靠譜。
還有一種猜測是，黑客成功將wikileaks.org域名破解，但根據我的觀察，wikileaks.org域名的名稱沒有被解析成通常的IP地址而出現在另外一個主機中。
由于對網絡安全的事件分析需要大量的數據證據，所以分析往往都非常延后，因為當分析師收集到所有的數據時，新的事件又出來了，以前的分析也已經沒有什么實際意義了。而對于內部人員來說，他們在遭受攻擊后，往往不會如實地公布事實，這讓分析變得更加困難。維基解密在被攻擊后的反應就是否認這個事實，然后嘗試淡化該事件，迄今為止，他們還沒有為用戶發布任何有價值的信息，這就造成了大家不斷地對其行為妄加猜測。
利用DNS下手
基于此，本文我的分析會從DNS開始著手，因為DNS是互聯網的關鍵基礎設施。 DNS分布式數據庫是以域名為索引的（如wikileaks.org域名或ssi.gouv.fr），每個索引節點都是一顆倒置的樹，每一個節點實際上也是一個域命名空間。當你查詢給定域名的DNS時，你將獲得各種技術信息，例如服務器的IP地址，加密密鑰，服務器名稱等。比如，當Web瀏覽器訪問http://www.okstate.com/時，用戶設備上的軟件執行名稱為www.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?-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.在攻擊期間.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.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 ...可以看出，注冊表提供的內容與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?-0000 wikileaks.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?-0000 wikileaks.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.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:??????noc@AS61440.NET address:?????Moneda,?970,?Piso?5 address:?????8320313?-?Santiago?-?RM country:?????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（http://suw74isz7wqzpmgu.onion/壓根就不起作用，http://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?-0000 ns1.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?-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原文發布時間為：2017年9月7日 本文作者：xiaohui 本文來自云棲社區合作伙伴嘶吼，了解相關信息可以關注嘶吼網站。 原文鏈接
總結
以上是生活随笔為你收集整理的攻击技术还原：维基解密是如何遭到黑客攻击的？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： webpack entry和output
- 下一篇： 原创：原创：拿破仑为何要把广袤富饶的路易