关于8月31日维基解密被攻击的观察与分析

2017-09-12 173754人围观 ,发现 2 个不明物体 WEB安全

十几天前,维基解密遭受了一次攻击,导致很多访问者看到了“OurMine”的声明,他们声称已经获取了维基解密服务器的控制权。这次攻击之后,很多人(包括维基解密的粉丝及其死对头)在没有基础知识与技术功底,且未查明事件真相的情况下,发表了很多观点。所以在这里,作者从技术性的观察角度,来陈述一些事实。

6c13cb4b05be71d-600x399.jpg

猜测

第一:有些人看到的东西显然不是维基解密的网站,很多人拿出了这样或者那样的截图,然后便有人推测:维基解密的服务器被入侵,入侵者修改了其内容。这是一个十分大胆的推测:因为从用户浏览器到网页显示的整个过程是相当复杂的,其中有很多因素可以导致最后的判断出错。

第二:对于维基解密,另一种猜测是服务器并没有被入侵,但是域名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

发表评论

已有 2 条评论

取消
Loading...
css.php