【BCS大咖说安全】网络异域、风险同天 ——互联网基础设施安全依赖性研究
星期四, 八月 6, 2020
物理世界，一场席卷世界各国的新冠疫情让我们看到全球化的今天，各国的经济、卫生和安全是相互依赖的——“山川异域、风月同天”，唐代的日本友人已经意识到风险的全球化。
从健康或防疫的角度，不同国家、不同种族的人口在基因上是高度相似的（99.99%），在各种生物病毒的攻击面前所面临的威胁几乎是一样的。
从经济和生产的角度，世界经济已经高度一体化了，技术、生产和市场是相互依存的，疫情导致的隔离对世界各国的生产和生活都造成了严重的影响。
“虚拟世界”，也就是我们所说的网络空间（cyberspace），也是全球一体的。我们所使用的计算机或终端设备，虽然形态各异，但都是冯诺伊曼体系结构、大致相同的编程语言和二进制代码，使用统一的TCP/IP协议进行通信。像人类面对生物病毒的攻击一样，网络空间里不同国家的网络所面临的风险是非常相似的。
另外，互联网上的各种应用和服务，严重依赖其他的基础服务的安全可靠运行，比如路由系统、域名系统等等；软件的开发更加依赖全球工业和学术界共同体的共同努力，形成了一个复杂的生态系统。像物理世界的生产链条一样，网络世界的运行、生产也是相互依赖、很难独立生存的。
事实上，在互联网历史上发生的多起全球性攻击事件中，很少有国家可以高枕无忧。2001年爆发的红色代码（Code Red，一种利用微软Web服务器IIS漏洞MS01-033传播的网络蠕虫）曾经在14小时内感染了40多万台计算机。被感染的Web网站显示“Hacked by Chinese”，但是最早发现这个蠕虫的美国安全公司eEye认为，这个蠕虫可能源自菲律宾。
2017年5月爆发的勒索蠕虫WannaCry感染了150多个国家的200多万电脑或终端，它的核心攻击代码源于美国国家安全局NSA的承包商泄露出来的攻击工具，后来有研究者指出是朝鲜的黑客利用这个工具写成了这个极具破坏性的勒索蠕虫。可见，攻击武器的生产也是全球性、跨国界的，它的传播更加具有全球化的性质。
网络空间全球大流行的病毒、蠕虫或攻击本身是全球化的产物，防御工作需要全球共同协作。另外，互联网的基础设施更加依赖不同国家、组织结构的合作。
本文结合清华大学-奇安信集团联合研究中心近期的研究，从四个方面讨论互联网基础设施的依赖性：1）路由系统；2）域名系统；3）公钥基础设施（PKI）或公钥证书系统；4）软件供应链安全。
路由（Routing）是互联网最基础的功能，负责选择合适的路径把数据包送到目的地。广域的互联网是一个网间网(Inter-net)，每个接入的网络（比如一个运营商级的网络）是一个自治系统（AS），自治系统之间通常使用路由协议BGP(Border Gateway Protocol）实现路由信息的交换。
每个自治系统向邻居宣告自己拥有的网络地址范围或可达的网络，同时根据邻居宣告的路由信息和自己网络的政策决定把数据包发往哪个网络。因此，BGP系统是一个信誉系统，它几乎完全依赖自治系统（运营商）之间的信任与协作。
如果某个运营商有意或无意地把不属于自己地址范围的路由信息（路由前缀）宣告给网络邻居（这种现象被称为路由劫持或路由泄露），那么邻居的网络可能把去往该网络的数据包全部转发给这个捣乱的运营商，从而导致路由劫持攻击，如图1所示。
路由劫持攻击可能导致大规模的网络瘫痪或信息泄露，劫持路由的运营商可能监听本来物理上接触不到的网络连接。
图1. BGP劫持攻击
最著名的路由劫持攻击案例是2008年巴基斯坦电信劫持YouTube路由事件。如图2所示，Google公司（AS 36561）本来拥有Youtube的地址前缀208.65.152.0/22，但是2008年2月25日，巴基斯坦电信(AS1755)发布了一条更长的前缀208.65.152.0/24。
根据BGP路由选择的规则，24位前缀的路由表项有更高的优先级。于是两分钟后，全球去往Youtube的流量被全部劫持到巴基斯坦电信。
图2. 巴基斯坦电信劫持Youtube网络事件，2008年
与路由劫持类似的事件还有路由泄露，由于路由信息被通告到预期的网络范围之外，往往也会引起大规模的网络故障或信息泄露。
路由前缀劫持和路由泄露经常发生，我们中国的某个大型运营商也曾经发生过不止一次影响全球的路由泄露事件。不过，绝大多数的类似事件都是管理员的误配置引起的。
尽管路由攻击很容易操作，而且可能引起的很大的破坏，但是这种攻击隐蔽性很差，全球的路由监测系统很容易定位路由攻击的始作俑者。如果频繁的以误操作为名发起攻击，会丧失邻居的信任，最终无法接入互联网。
尽管正在研究的路由安全机制（如RPKI、BGPSec等）可以在防范这种路由劫持或路由泄露攻击，但是这些技术离大规模部署还有很长的路要走。短期内，我们仍然还只能相信运营商大部分都是诚实的，不会故意滥用别人的信任。
像路由系统一样，域名系统（DNS）也是互联网重要的基础服务，它最基本的功能是完成名字空间向地址空间的转换。
DNS是一个树形结构的数据库，域名数据以资源记录的形式存储在权威服务器上，由递归解析服务器代替用户执行自顶向下的递归解析操作。
显然，一个底层域名的解析过程依赖于它所有上级域名的解析，比如要想解析tsinghua.edu.cn的IP地址，必须先要成功解析edu.cn的域名和地址，以此类推。
然而，域名解析的依赖关系有时并不取决于域名所在的层次，比如CERNET.NET的域名的解析依赖于.CN、.HK和.DE，如图3所示。根据2015年的测试结果，CERNET.NET的域名解析可能依赖于24个域名。
图3.CERNET.NET的域名解析可能依赖CN、HK和DE(2015年)
在2013年，我们分析了全球100万热门网站的域名，发现这些域名的解析依赖关系是相当普遍的，平均一个域名的解析依赖于46个其他域名，最多的依赖117个，如图4所示。如果解析路径上有一条路径出现问题（比如被劫持），这个域名的解析就可能受到影响。
图4. 一个域名的解析可能依赖117个其他域名的解析
因此，我们不能仅凭域名的上下级层次关系判断域名解析的依赖关系，有些不为大众所熟知的域名，可能构成域名解析的瓶颈。在大规模的网络攻击面前，对这些瓶颈域名的攻击可能导致网络大规模的瘫痪。
2009年的暴风影音是一个典型的域名瓶颈攻击案例。这次攻击最初的受害者是域名托管服务商DNSPod（后来被腾讯公司收购）。
先是DNSPod的某个客户受到拒绝服务攻击，导致DNSPod服务器所在的数据中心网络流量异常增大；于是数据中心管理员把DNSPod的服务器做紧急断线处理，导致DNSPod的域名及其所托管的大量域名都无法解析。
其中一个托管的域名是baofeng.com，这是装机量巨大的暴风影音播放器所使用的域名。在ISP各地递归解析服务缓存的域名记录过期后，暴风影音媒体播放器开始频繁地访问baofeng.com的域名，导致ISP各地递归解析服务器负载过高而几近瘫痪。
我们后来对热门网站的域名依赖关系进行了统计分析，发现DNSPod在域名空间里被依赖的程度非常之高，仅次于俄罗斯和德国的国家顶级域名，如图5所示。
如果把依赖于该域名的网站看作一个国家，那么DNSPod域名解析的失败导致互联网上排名第三的国家消失了，而直接的攻击动作只是服务器托管机房的管理员拔了一根网线。
图5. 解析过程依赖DNSPod的域名数量仅次于俄国和德国的顶级域名
第三个重要的互联网基础服务是公钥基础设施（PKI），或者说公钥证书系统，一个典型的应用场景是Web服务器和浏览器之间的安全通信：由一个可信的第三方CA（Certificate Authority）为Web服务器签发公钥证书，浏览器信任该CA（预知了CA的根证书），便相信该CA所签发证书的真实性，从而进行后续的安全通信，包括密钥协商、数据加密等等。
这种基于可信第三方的信任模型和安全通信协议TLS已经成为互联网安全通信的基础。然而，这种信任模型和应用场景仍然存在严重的安全问题。
3.1. CA的信任模型问题
与DNS的唯一权威（根）不同，CA的信任体系没有唯一的信任根（信任锚点，Trust Anchor）。目前的CA信任体系可以说是森林状结构，预装到浏览器或操作系统中的可信根CA证书有一百多个，他们又通过成千上万个二级或三级CA签发最终的服务器证书。
这种信任模型最大的安全问题是，任何一个CA都可以为任何一个网站（域名）签发公钥证书，而不需要该网站的授权。于是，一个可信的CA未经授权为目标网站签发的假证书可能被用来发起中间人攻击，而浏览器因为信任该CA签发的所有证书不会给用户弹出告警。因此，在预装到我们系统中的一百多个根CA中有任何一个被攻破，都可能颠覆整个互联网的信任体系。
历史上根CA被攻击的安全事件曾经出现过多次，2011年荷兰的CA DigiNotar被攻破，许多假冒Google网站的证书被部署到伊朗的网络上，这一事件导致谷歌、苹果、微软等厂商把DigiNotar的根证书紧急删除，DigiNotar因为失去了信任而很快破产。
2015年Google 发现Symantec 公司下属的著名的证书服务提供商VeriSign签发了假冒的Google的证书，威胁说要把VeriSign的根证书从Chrome浏览器中删除。
此事件导致VeriSign公司开除了几名违反操作规范的员工。尽管Google公司近年来提出了许多新的技术（如公钥证书绑定、证书透明化等），但是并非所有的浏览器和服务都可以在近期内很快部署。因此，短期内互联网上的安全服务仍然依赖所有CA都诚实可信、尽职尽责。
3.2. 共享证书问题——熟悉的陌生人攻击
最初的公钥证书和证书的持有者是一一对应的；然而随着技术的发展，多个实体（如网站）共享一个证书的情况已经比比皆是了。
最常见的场景是内容分发网络（CDN）的场景，两个毫无关联的网站因为使用了签发的同一个CDN厂商的服务而共享同一个公钥证书。
另外还有一种场景出现在集团公司和子公司之间的证书共享，比如图6中IBM公司在收购了一个天气预报的公司以后，在公钥证书中增加了nic.weatherchannel的域名。事实上，我们发现nic.weatherchannel并没有启用HTTPS。
图6. 共享证书实例：ibm.com与45个域名共享证书
类似IBM 和nic.weatherchannel的情况非常普遍，由于Web网站的HTTPS部署比较复杂而且技术仍在进一步发展，共享证书的多个网站之间难免会出现配置故障或者策略不一致的现象。
清华大学-奇安信集团联合研究中心的研究人员发现，这种证书共享的场景下存在较大的安全风险。如果共享证书的多个网站中有一个网站的HTTPS的配置不安全，即使配置安全的网站也可能受到攻击。也就是我们常说的木桶效应，或者说一个链条的强度由最弱的一环决定。
在著名的漏洞挖掘比赛GeekPwn 2019年的竞赛中，清华大学——奇安信集团联合研究中心的研究人员获一等奖的项目“熟悉的陌生人”攻击就是这个原理。
在主持人黄健翔和全场观众的见证下，参赛队员在20分钟内劫持了HTTPS配置完善的某知名网站，实现了加密HTTPS保护下的用户名和口令的窃取、传输的网页内容的修改等攻击。
攻击原理如图7所示。Server A按照HTTPS当前的最佳安全实践配置，本来是没有安全漏洞的；但是由于它和Server B 共享一个证书，但是安全配置上存在缺陷（比如没有配置HSTS）。
于是攻击者可以对Server A 和客户端浏览器之间的HTTPS实现中间人攻击，使之降级成为明文传输的HTTP，从而实现传输内容的监听和篡改。
图7. 熟悉的陌生人攻击——证书共享导致的HTTPS中间人劫持
奇安信技术研究院利用天罡大数据平台对热门的网站进行了大范围的测量和分析，发现世界排名前100的网站及其子网站，63%的存在可被攻击的风险。
我们的研究人员为这一攻击也提出了降低风险的解决方案。目前，这一研究成果已经被网络安全顶级学术会议CCS 2020录用，可是说在学术界和工业界都产生了重要的影响力。
网络空间里的软件开发越来越依赖第三方的开发平台、开发工具或软件模块，特别是开源软件。由于现在的软件系统功能越来越复杂，而且软件产品的开发迭代越来越快，几乎很少有公司能够脱离第三方或开源软件的工具平台或者代码模块。
然而，这种依赖性也存在很大的风险，因为第三方的开发工具、软件模块中的安全漏洞也会影响到我们自己开发的软件产品。
2015年发生的XCodeGhost事件是典型的软件供应链安全问题。XCode本是苹果公司的软件开发平台，有些程序员从非官方的渠道下载了植入木马的XCode，于是使用该恶意软件开发的软件中都被植入了木马。
这些软件产品被上传到苹果公司的App Store供更多用户下载，其中包括12306等许多流行的应用，植入木马的功能包括盗用受害者的很多隐私信息。苹果公司尽管对此采取了紧急处理，清除了大批植入后门的应用，但这一事件造成了苹果公司在中国最大的一次信任危机。
奇安信技术研究院在软件智能分析领域进行了多年的研究，近期推出了软件供应链安全分析系统——“问天”软件空间测绘系统。目前，问天系统对数十万的软件样本进行了庖丁解牛式的分析，把软件所依赖元素分解成文件、动态链接库、模块、域名、IP等，找出这些元素可能存在的漏洞或者后门。
以WinRAR漏洞为例介绍问天系统的一个功能。WinRAR是Windows平台最常用的解压缩软件，它集成了ACE解码动态库unacev2.dll，它存在一个高危漏洞可能让受害者的机器被完全控制。
那么，究竟还有哪些软件也受到这个漏洞的影响呢？也许直观的想法是所有压缩和解压缩的软件也存在这样的漏洞，这一点不错，但是远不止这些。我们用问天系统所做的分析（如图8所示）表明，改漏洞影响到220多款软件，其中55%不属于压缩/解压缩软件，比如很多系统管理软件内置了这个有漏洞的动态链接库。
图8. 问天系统对WinRAR中unacev2.dll漏洞的分析
网络空间类似路由、域名、PKI和软件供应链的依赖关系是比比皆是的，就像物理世界中生态或生产链条一样，一个链条出了问题，可能影响到整个生态系统中所有产品或服务。
然而，近年来由于贸易、政治等因素的影响，本来应该相互信任、相互依存的国家和机构之间，隔阂越来越大，以至于有人曾提出要建设我们与世界隔离的互联网，所有依赖国外的组件都要自己生产。
这种主动选择与世界脱钩的做法是有害的，互联网的价值在于它的全球性。目前，不仅我们使用的互联网运行依赖国际组织、软件产品生产需要依赖第三方或者开源软件，我们的产品也需要一个全球化的市场。
我相信就像疫情一样，暂时的、局部的隔离不能取代常态的互联互通。虽然安全研究的是攻防对抗，但是安全机制归根结底，最终还是要建立最基本的信任的基础上。
如有侵权请联系:admin#unsafe.sh