酷应用

攻击技术还原：维基解密是如何遭到黑客攻击的？

观点作者：嘶吼 2017-09-12 08:43:23

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