译者：buusc
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
也许你还不知道，但你的网站可以被他人劫持！通过利用DNS区域委派配置上出现的疏忽，黑客可以控制你的网站的域或子域。这种攻击被称为子域劫持（subdomain takeover）。
子域劫持是个高危互联网安全漏洞，其基本原理是黑客通过注册他人没有续费的云服务子域来恶性控制一个或多个正经网站的域。这开创了一些独特的攻击方式，从最基本的利用用户对网站域名的信任进行诈骗，到越权访问（在这篇Arne Swinnen写的漏洞报告中有详细解释和实例）。
情景再现
假设你在一个制造并销售某种产品的大型企业工作，企业的主网站是example.com。因为这是二十一世纪，所以企业决定在通过实体店销售产品的同时也入军互联网销售。你被安排的工作就是建立并管理销售公司产品的电子商务平台。
为了快速建立一个电商平台，你决定选择一家提供电商解决方案的云服务公司（如阿里云, 华为企业云等）。在你完成平台的设置后，你的云服务供应商会分配给你一个它的子域，如阿里云可能会分配给你example.aliyun.com。当然，这个域名不太引人瞩目，你更希望使用一个属于你自己公司的域名，比如shop.example.com。
你可以通过两种不同方法实现这一点：
1. 使用HTTP 301或302重定向，将访问shop.example.com的用户重新定向到电商供应商的子域（如example.aliyun.com）。不过这个方法有个很大的缺陷– 被重定向的浏览器在地址栏中会更改为供应商的域名，而不保留你公司的域名。
2. 在你的DNS服务器上配置一个CNAME记录，将公司电商网站所属区域的DNS解析委派给电商平台供应商。使用这个方法的话，用户的浏览器地址栏会保留公司的域名。
使用CNAME记录的方案更加完善，所以你选择了方案2。
现在快进到一年后。很可惜的是，因种种市场原因电商平台的营业额远低于预期值。为了削减支出，管理层迫于无奈让你暂时将公司的电商平台离线，等待他们重新规划公司战略。
为了省钱，你取消了公司在电商平台供应商订购的云服务。在这一刻，子域劫持漏洞便可能出现：如果你在取消订购后忘记将你DNS区域文件（zone file）中的CNAME记录删除，那么任何人都可以通过在电商平台供应商注册你所用过的子域来劫持你的域。
换句话说，如果有人在你取消订购后去阿里云注册了你曾经使用的example.aliyun.com，并且你没有将你DNS服务器上相关的CNAME记录删除，则任何访问shop.example.com的用户都会被指向劫持者的网站。
不少读者可能对这种情况不太熟悉，但事实上子域劫持已经逐渐成为了一个不可忽视的威胁。不久前，特朗普的网站的一个子域(secure2.donaldtrump.com)就被伊拉克黑客劫持了，使美国政府颜面尽失。
以下是几篇记录不同知名网站子域劫持漏洞的漏洞报告，若读者感兴趣可以阅读：
作为这个领域的专家，Sweepatic（原作者的公司）的渗透工程师们近期发现了许多企业都存在子域劫持漏洞，其中不乏银行，政府机关等大型机构。我们目前正在与这些机构联络以便修复这些漏洞，但子域劫持漏洞的广泛度可见一斑。
云服务供应商
当然，这种漏洞的影响不限于提供电商平台的云服务公司，它对整个云服务产业都有威胁。随着云服务的普及，互联网上存在许多指向大型云服务供应商（如亚马逊和微软）的CNAME记录。在特定情况下，这些CNAME记录的子域很容易被劫持。
我们以亚马逊的CloudFront云服务为例。CloudFront是个内容分发网络服务（CDN），以“分发”为基本的信息存储单元。 简单来说，每个分发都可以被看做在亚马逊Cloudfront服务器上托管的一组静态文件。
在创立一个新的分发后（如上图所示），亚马逊会随机生成一个域名，如d2erlblaho6777.cloudfront.net；通过访问这个域名就可访问分发里的文件。从表面上看，随机生成域名似乎可以避免子域劫持，因为黑客无法控制自己获取什么域名，但可惜事实并没有这么简单。
问题的始因在于分发域与IP地址间的映射并非一对一；各个分发域并没有专用的独立IP地址 。相反，Cloudfront使用的是多对多映射。 Cloudfront使用了虚拟主机技术，将所有分发域都被映射到较少的一组Cloudfront服务器上，并在内部通过映射表将分发域转换为储存其文件的服务器的地址。熟悉虚拟主机技术的读者应该都明白，在虚拟主机环境下使用CNAME记录并非易事，因为网络服务器需要通过HTTP Host字段判定用户所请求的域–而这个特性却恰好给了黑客可乘之机。
假设你想使用static.example.com作为提供静态文件的服务器，那就需要在你的DNS服务器上添加这样一条CNAME记录：
static.example.com. 600 IN CNAME d2erlblaho6777.cloudfront.net.
但是，如果用户通过static.example.com来访问托管你分发的CloudFront服务器，那么亚马逊在用户的HTTP请求的 Host字段看到的域名就会是static.example.com。可是这个域名并不在Cloudfront的映射表里，所以服务器无法将这个域名解析到对应的分发的网络地址。
为了解决这个问题，CloudFront允许客户通过设置界面为自己的分发域添加额外的备用域名。CloudFront会将这些域名加入自己的内部映射表，这样在使用CNAME时亚马逊的服务器就能正常解析分发的地址了。
如果一个域拥有一个指向CloudFront的CNAME记录，但是相对应的分发被删除了，那么黑客就可以利用以上方法对这个域名实行劫持。黑客只需建立一个CloudFront分发，再将目标域的域名添加到备用域名设置里即可。在用户下次访问时，CloudFront就会通过映射表将用户指向黑客提供的文件。
风险
大部分机构都没有定期审查DNS设置的习惯。多数情况下，这些机构都缺乏用于添加、更改或删除DNS区域文件中的记录的标准化流程；有的甚至缺乏记录对DNS区域文件的改动的日志。虽然管理员们对于信息安全的重视在日益提高，但对于这个DNS解析类漏洞的认知度还需改进。
“若把同一项责任分给多个人，则没有人会承担此责。”- 爱德华兹·戴明（著名管理学家）
如前文所述，子域劫持的后果十分严重。黑客可以通过利用用户对你公司域名的信任开展钓鱼活动。对于用户来说，根本无法辨别所浏览的网页究竟是拥有这个域名的公司所提供的，还是黑客提供的。
同时，黑客还可以结合其他漏洞造成更严重的影响。举个例子： 许多Web应用都把会话cookie的访问权限设立为一个通配符域（如*.example.com），所以这个域名下的各个子域都可访问它。通过劫持目标Web应用的一个被遗忘的子域并诱骗用户访问它，黑客就能越过应用所有的XSS（跨站脚本攻击）防护措施并盗取用户的会话cookie。这可以被看做一种进阶版的XSS。
防范措施
防范子域劫持等DNS解析漏洞的第一步是定期检查并分析你所管理的网站的DNS记录。想要避免子域劫持，管理员必须确保在取消云服务时同时删除DNS文件里的相关记录。我在前一篇文章里提到过如何进行子域枚举，这对搜寻你的DNS文件里是否存在被遗忘的子域很有帮助。
从宏观角度来看，任何拥有多个网站的机构都应该建立一套完善的DNS记录管理体系，否则漏洞出现只是时间的问题 。在互联网时代，拥有上百个子域的机构非常常见，且各个子域很可能由不同人员负责管理 ，而在这种混乱的局势下很容易出现疏忽。在我的渗透工作中，经常会碰到客户自己都不知道公司所拥有的所有域名是哪些，这是十分危险的。将管理DNS的责任清晰划分，并保持对你所管理的网络的结构的准确认知在今天是至关重要的。
下次再见！
发表评论
您还未登录，请先登录。
登录