关于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里到底有什么？

在攻击期间，注册表正在对非法的服务器组进行回复。

所以名称服务器被篡改了，根据DNSDB，这些流氓服务器提供了一组不同的NS（名称服务器）：

要注意的是，DNS主机Rival并不是此次攻击的共犯，这可能只是一些流氓客户。现今，大多数大型服务提供商中都存在这种情况。

当你将所有内容复原时，可以看到最后一次更改whois输出的日期：

很明显，流氓名称服务器正在提供指向“假”网站的IP地址。再次回到DNSDB中：

维基解密的正常IP地址前缀为95.211.113.XXX，141.105.XXX和195.35.109.XXX（如果你想要查看它们，可以使用DNS Looking Glass）， 181.215.237.148是由Rival托管的流氓网站的IP，你可以使用whois工具查询：

这表明这个前缀是在智利分配的，黑客无法改变服务于wikileaks.org的名称服务器。

社交网络上的很多人声称，这次袭击是由“DNS中毒”造成的，可见多数人对DNS中毒一知半解。对域名配置系统的攻击是很常见的，例如，2013年，臭名昭著的SEA（叙利亚电子军）对纽约时报网站进行了攻击（详见纽约时报与一份技术分析），他们拿下了纽约时报的DNS登记服务器( Melbourne IT)，修改解析，指向自己的服务器。最近还有一次对圣路易斯联邦储备委员会的攻击。这种攻击的后果是什么？如上所述，一旦你控制DNS，你就可以控制所有内容。您可以将用户重定向到伪造的网站（不仅是外部访问者，而且还包括目标组织的员工，可以连接到内部服务，潜在窃取密码和其他信息），劫持电子邮件等。因此，声称“服务器没有被泄露“没有意义。如果成功对域名进行攻击，那么攻击者就不需要入侵服务器。

以上哪部分在维基解密案件中被破解？分析了外部原因，我可以肯定地说，名称服务器被改变了。维基解密本身，注册商（Dynado）或注册管理机构（.org，由PIR管理，技术上由Afilias管理）都有弱点。从现有的信息来看，人们很难说清楚问题出在哪里。但根据推测，大多数时候问题出在用户，不过薄弱的环节还有注册商或注册管理机构，因为在过去它们都被曝出了严重的安全漏洞。

之前我说过，当你控制域名时，你可以将外部和内部的访问者发送到你想要的服务器。但是这种说法并不是完全正确的，因为良好的安全性依赖于深度的防御，即使您的域名受到威胁，也可采取一些措施来降低风险。其中一个就有使用HTTPS（维基解密就在使用），从纯HTTP站点重定向，HSTS（在RFC 6797中标准化）以避免普通访问者通过不安全的HTTP访问。维基解密也在使用：

这些技术至少会引起网站管理者的警惕，同样，使用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域名的粘合记录显然已被修改：（注意攻击后几个小时）：

一些DNSDB探测确实注意到了这个IP地址，意味着这是本地主机，

由于DNS严重依赖于缓存，即使在配置被修复之后，信息仍然能被看到。 在这里，作者使用RIPE Atlas探针与Atlas解析工具，以查看有多少探针仍然能看到错误的值（注意日期和时间，全部以UTC为单位，这是分析网络问题时的规则）：