记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

“维基解密网站被黑”事件的正确打开方式

2017-09-06 06:55

前情提要

8月30日,WikiLeaks网站遭遇网络攻击,一些游客在WikiLeaks的Web站点看到了“OurMine”留下的标记。一石激起千层浪,有很多无知的人(有些是WikiLeaks的粉丝,也有些是反对者)在网上说了许多关于这次攻击事件的蠢话。大多数时候,当一个他们关注的事件发生时,在对事件的真相没有任何调查或了解的情况下,就开始夸夸其谈,不能忍!

这篇文章,我向描述一下,从技术层面上可以观察到的一些事实。提前声明,没有任何耸人听闻的阴谋论或启示,只是单纯想看热闹的人可以点击右上角的关闭按钮了。

初探事件起因

首先,一个基本的事实:有些人看到的显然不是维基解密的网站,网上流传的维基解密被攻击的页面截图,如下图1、图2所示:

图1、图2:维基解密被黑的截图

有些人推断维基解密的Web服务器被攻破了,而骇客们修改了它的内容(例如,你可以在边缘找到它)。这其实是一个大胆的推论,因为从用户浏览器到网页显示的整个过程相当复杂,有很多参与者,这中间很多环节都可能出错。

在“维基解密被黑”这次事件中,事情发生的非常迅速,似乎Web服务器没有被攻破,但攻击者成功掌控了wikileaks.org的域名。事后的观察表明,wikileaks.org这个域名没有被解析到通常的IP地址,而是被导向了另一个不同的主机。这怎么可能呢?如何发生的?会有什么后果?

要知道,对网络上发生的事件进行电子取证是比较困难的。作为一名外部分析人员,并不能获取到所有的数据,甚至几乎没有任何证据。有些情况下,开始分析时,已经太晚了,想要获取的数据已经改变了。而内部分析家人员几乎从不披露任何东西,有时甚至还会撒谎。不排除有一些组织更加开放,但坦诚布公是例外,而不是规则。

这次事件中,维基解密与其他大多数公司一样,否认问题,然后试图淡化它,而没有发布任何有价值的东西。因此,大多数关于这次网络事件的声明都没有事实依据,特别是没有公开已经核实的事实。维基解密是许多热点争论的中心,一些维基解密的粉丝从一开始就声称“维基解密的服务器没有被泄露”,而事实上他们也没有获取到任何信息,而且也没有足够的时间去分析这次事件,因此,这次事件的情况显然更加糟糕。

回到事件分析的思路,问题的关键之一可能是域名wikileaks.org。因此,我们需要回顾一下DNS的概念。DNS不仅是互联网的一个关键基础设施,也是一个大多数人都未理解(或者说underknown)的技术。DNS是一个数据库的索引(如域名wikileaks.org)。给定的域名查询DNS时,会得到的各种技术信息,如服务器的IP地址、名称和加密密钥等。用户使用一个浏览器并在URL地址栏输入:wikileaks.org时,网络上经过一系列的DNS查询,返回给用户HTTP服务器的IP地址,然后用户就可以连接到服务器上。

从上边这个简短的描述中,您可以看到,谁控制了DNS,谁就可以控制用户最终目的地和看到的内容。整个DNS解析过程(从名称到数据)本身相当复杂,为攻击者提供了许多机会。不妨做这样的总结:DNS是至关重要的,而大多数机构低估了这一点,更糟的是,都声称这不是他们的责任。

DNS中的数据来自何处?不像许多人所认为的那样,大多数所谓的“DNS攻击”其实根本不是DNS攻击,也就是说,这些攻击并不是利用DNS协议中的弱点。实际情况是:大多数情况下,攻击者会针对域名持有者进行攻击,这些域名持有者负责供应和维护基础设施、用户名和服务器列表等数据。

网站运营者需要将站点托管到一个网络服务提供商,需要连接到注册商的网站,创建一个帐户,并配置相关的信息(如域名、IP、注册邮箱、用户名和密码等信息),最终这些配置信息将被用于DNS解析。如果注册账号使用了一个弱密码,或者操作人员将密码写在了办公桌下边,或者通过其他途径泄露了这个密码,总之,这个账号可能会被窃取。攻击者使用这一凭据,登录网站注册商的管理员控制面板,修改DNS解析的IP地址。这种攻击是很常见的,而且有时候可能不需要使用复杂的攻击技术。

尝试还原维基解密遇袭事件

由于开始观察的时间太晚了,已经无法从网络上搜索第一手的资料,因此在这里需要使用一个到DNSDB。DNSDB是一个数据库,用于存储和索引“被动的”DNS数据,它会观察并记录网络上的DNS流量,允许用户事后查看之前的DNS信息。

DNSDB是不公开的,只允许授权用户访问。

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.

这是什么意思?攻击发生期间(04:30 UTC左右),该.org网站被设置为指向非法的服务器。通常的服务器是(使用 dig工具,它是调试DNS问题的最佳工具):

% 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管理员工作的太草率了)

因此,我们可以知道,域名服务器被更改,指向了非法的服务器。需要注意的是,攻击过程中,域名服务器是有差异的,这表明攻击者使用了一组不同的NS(域名服务器),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.

请注意,这并不意味着域名服务商是攻击者或帮凶。他们可能只是有一个流氓客户。任何大的服务提供商都不能保证所有客户的行为都是合法的。

当一切都被恢复成原位,使用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(通过dig A wikileaks.org命令,或者使用DNS Looking Glass工具进行查看)。181.215.237.148是流氓网站的地址,被攻击者再次利用,可以通过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

上述信息显示所有人(Owner)显示为智利一家公司。世界是个复杂的地方,互联网更加如此。

所以,这就是攻击者的作案手法。他设法改变服务于wikileaks.org的域名服务器集合,并将游客发送到他能控制的服务器上(注意,目前IP地址为181.215.237.148的HTTP服务器,不再是Cracker的页面,这可能是因为供应商将其删除了)。

可能是“DNS中毒”吗?

社交网络上许多人声称这次袭击是由“DNS中毒”(DNS poisoning,也可称为“DNSS投毒”)造成的。首先,作为一个DNS专业人士,在这里必须说:当有人输入“DNS中毒”时,可以很肯定地说他对DNS一无所知。DNS中毒是一个非常具体的攻击,(对应的解决方案是DNSSEC,这个后面会提到),但它似乎并不是很常见的。正如我在文章开始时就强调过的,大多数攻击都是没有正确的分析和记录,所以很难更精确的描述事件的经过、还原事件的发生。

最常见的是对域名供应系统的攻击。使用这类攻击的典型案例有:2013年针对纽约时报发起的攻击,以及最近针对圣路易斯联邦储备委员会和其他许多人的攻击。这些攻击不使用DNS协议,将其标记为“DNS攻击”或是“DNS中毒”是相当困难的。

这种攻击的后果是什么?如前所述,一旦你控制了DNS,你就控制了一切。你可以将用户重定向到一个网站(不仅是外来游客,而且可以针对目标组织的内部员工,当他们连接到内网服务时,可能窃取其账户密码和其他信息)、劫持电子邮件等,声称“服务器未被入侵”(技术上的)几乎是无用的。对域名的攻击,黑客不需要真实的入侵服务器。

维基解密案中谁的账号被破解了?

从外部看,我们可以自信地说,域名的名称服务器已被更改。纰漏可能是WikiLeaks的域名管理账号的持有人,也可能是注册处(通过whois查询)或登记管理处(PIR 或Afilias)。从现有的信息中,我们不能明确问题出在哪里(因此,公开喊“维基解密不负责”的人,充分表现出的是他们的盲目信仰,而不是他们的分析能力)。当然,大多数时候,最薄弱的环节是用户(注册时使用弱密码,而且没有激活2FA),但一些注册或登记处的服务提供商在过去也曝出过严重的安全漏洞。我们唯一能说的是,似乎没有其他域名被劫持。(当某人控制注册或登记的服务商时,有能力改变许多域名,当然,也可能攻击者就是针对WikiLeaks也说不定,可以获取的信息太少,不能判断)。

防护措施

这里请允许我再次强调一个问题,之前我说过,当你控制一个域名时,可以将外部和内部访问者发送到你指定的服务器,这并不是完全正确的,因为良好的安全性依赖于纵深防御,并且可以采取一些措施来限制风险,即使您的域名被攻破了。其中当然包括使用HTTPS和HSTS(RFC 6797中标准化),以避免固定的访客通过不安全的HTTP连接。维基解密就使用了:

%  wget –server-response –output-document /dev/null https://wikileaks.org/

Strict-Transport-Security: max-age=25920000; includeSubDomains; preload

被恶意攻击时,使用了这些安全防护技术至少会引起警报,告诉来访者有异常。

同样的,使用Tor(.onion )网址也会有帮助。但我一直还没能找到维基解密对应的洋葱站点对维基解密(http://suw74isz7wqzpmgu.onion/暂停服务,这http://wlupld3ptjvsgwqw.onion似乎只能上传)。

还可以通过启用注册表锁定的方式来限制来自可能被盗用的帐户的风险,这是大多数TLD(包括.org)提供的一种防止未经授权的更改的技术。激活这项功能后,对任何更改都需要额外的检查步骤。我不能肯定维基解密是否启用了它,但从安全的角度考虑,敏感域名必须做到这一点。

有趣的是,有许多人称这次事件是“DNS中毒”,所以这里也多说几句。对于“DNS中毒”这种特定的攻击,DNSSEC是最好的保护措施,维基解密并未使用(有一个wikileaks.org 的DNSSEC密钥,但没有签名和DS记录)。如果“Wikileaks”使用了签名,并且你使用一个验证DNS解析器(每个人都应当这么做),你可能就不会偏向于选择DNS中毒的方式去攻击维基解密了。当然,倘若使用入侵一个持有人、注册或登记者账户的方式,DNSSEC就没什么作用了。

最后再分享一个有趣的发现。维基解密的域名服务器使用了glue records。它描述了维基解密服务的域下的域名服务器的名称,当查询某个授权子域的数据时,就会出现一个“鸡生蛋和蛋生鸡”的问题。为了允许DNS客户机查询它们,父节点必须知道这个子域的域名服务器的IP地址。这就是所谓的glue records。DNSDB的数据显示,主攻击后的几个小时,ns1.wikileaks.org的glue records显然被修改过:

;;  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

上述IP指向的服务器依然在线,这对维基解密来讲可以算做一个有价值的数据。使用dig或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探针来查看有多少探头仍然会看到错误的值(*注意这里的日期和时间统一使用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

更多资料

https://www.dnsdb.info

https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

https://github.com/bortzmeyer/dns-lg

https://labs.ripe.net/Members/stephane_bortzmeyer/using-ripe-atlas-to-debug-network-connectivity-problems

知识来源: www.mottoin.com/105372.html

阅读:304344 | 评论:0 | 标签:观点

想收藏或者和大家分享这篇好文章→复制链接地址

““维基解密网站被黑”事件的正确打开方式”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

关注公众号hackdig,学习最新黑客技术

推广

工具

标签云

本页关键词