关于8月31日维基解密被攻击的观察与分析
十几天前，维基解密遭受了一次攻击，导致很多访问者看到了“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: noc@AS61440.NET
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)
*参考来源：bortzmeyer，Covfefe编译，转载请注明来自FreeBuf.COM
官方 