子域劫持
也许你还不知道，但你的网站可以被他人劫持！
通过利用 DNS区域委派 配置上出现的疏忽，黑客可以控制你的网站的域或子域。
这种攻击被称为子域劫持（subdomain takeover）。
子域劫持是个高危互联网安全漏洞，其基本原理是黑客通过注册他人没有续费的云服务子域来恶性控制一个或多个正经网站的域。
这开创了一些独特的攻击方式，从最基本的利用用户对网站域名的信任进行诈骗，到越权访问（在这篇Arne Swinnen写的漏洞报告中有详细解释和实例）。
玩出新花样
https://hackerone.com/reports/172137
https://hackerone.com/reports/32825
https://hackerone.com/reports/38007
https://hackerone.com/reports/175070
情景再现
假设你在一个制造并销售某种产品的大型企业工作，企业的主网站是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就会通过映射表将用户指向黑客提供的文件。
CNAME 解析
CNAME 解析是子域名劫持漏洞的关键因素，因此这里我们先简单说一下。
我们知道域名解析是由DNS协议完成的，包含了多种记录类型，比如其中的A (Address) 记录是用来指定主机名（或域名）对应的IP地址记录；NS记录，解析服务器记录，用来表明由哪台服务器对该域名进行解析；而CNAME记录通常也叫别名记录，是一种将一个域名映射到另一个域名的记录。
换句话说，CNAME像是一个域名到另一个域名的解析。
如下图所示，是一个域名解析的过程，第3步通过CNAME记录找到了另外的域名，第5步找到了实际的ip地址，最后在第7/8步完成了访问。
风险
大部分机构都没有定期审查DNS设置的习惯。
多数情况下，这些机构都缺乏用于添加、更改或删除DNS区域文件中的记录的标准化流程；有的甚至缺乏记录对DNS区域文件的改动的日志。
虽然管理员们对于信息安全的重视在日益提高，但对于这个DNS解析类漏洞的认知度还需改进。
【“若把同一项责任分给多个人，则没有人会承担此责。”- 爱德华兹·戴明（著名管理学家）】
如前文所述，子域劫持的后果十分严重。黑客可以通过利用用户对你公司域名的信任开展钓鱼活动。对于用户来说，根本无法辨别所浏览的网页究竟是拥有这个域名的公司所提供的，还是黑客提供的。
同时，黑客还可以结合其他漏洞造成更严重的影响。
举个例子： 许多 Web 应用都把会话 cookie 的访问权限设立为一个通配符域（如*.example.com），所以这个域名下的各个子域都可访问它。
通过劫持目标Web应用的一个被遗忘的子域并诱骗用户访问它，黑客就能越过应用所有的XSS（跨站脚本攻击）防护措施并盗取用户的会话cookie。
这可以被看做一种进阶版的XSS。
漏洞利用
子域名劫持可以构造多种利用方式，以如下两种为例。
网页钓鱼
由于用户对shop.abc.com的访问会解析到攻击者控制的shop.aliyun.com，那么攻击者就可以构造特定的页面诱导用户操作，比如登陆表单、密码表单等，由于浏览器显示的是正常的可信的域名，就算有安全意识的用户也难以分别是否存在钓鱼。
Cookie 操纵
Cookie 是用户权限的凭证，一般也会拥有一个特定的作用域。
但是现在很多网站使用单点登陆（SSO），那么Cookie就可能是在整个域共享的，当然也包括shop.abc.com，那么攻击者只需要诱导攻击者访问存在漏洞子域名，即可在后台接受到用户的Cookie。
一个典型的例子：https://hackerone.com/reports/172137
防范措施
防范子域劫持等DNS解析漏洞的第一步是定期检查并分析你所管理的网站的DNS记录。
想要避免子域劫持，管理员必须确保在取消云服务时同时删除DNS文件里的相关记录。
另一种方法就是保持对域名的所有权，避免被攻击者恶意申请。
我在前一篇文章里提到过如何进行子域枚举，这对搜寻你的DNS文件里是否存在被遗忘的子域很有帮助。
从宏观角度来看，任何拥有多个网站的机构都应该建立一套完善的DNS记录管理体系，否则漏洞出现只是时间的问题。
在互联网时代，拥有上百个子域的机构非常常见，且各个子域很可能由不同人员负责管理，而在这种混乱的局势下很容易出现疏忽。
在我的渗透工作中，经常会碰到客户自己都不知道公司所拥有的所有域名是哪些，这是十分危险的。
将管理 DNS 的责任清晰划分，并保持对你所管理的网络的结构的准确认知在今天是至关重要的。
