一、前言
本文介绍了我们识别Shopify平台上的子域名接管漏洞的具体过程，该漏洞影响超过55,000个子域名。
首先我们得澄清一下，这个问题并不仅限于Shopify平台，对其他常见的云服务提供商来说也很常见。在过去几周/几天内，我们联系了几个不同的云服务提供商来解决这个问题，我们对Shopify的安全运维小伙伴们印象很好：他们响应快速、对问题高度负责并且沟通起来非常顺畅。非常感谢他们，因为他们知道如何与网络安全研究社区保持良好的沟通。
先来介绍一下Shopify，维基百科上的描述如下图所示。
简而言之，Shopify是一个云服务提供商，允许用户以非常简单的方式创建电子商务网站。
如果大家对Shopify上的子域名接管漏洞比较熟悉，可以直接跳到本文末尾，了解如何大规模利用这个漏洞。
二、Shopify子域名接管漏洞
在漏洞奖励计划或者渗透测试过程中，如果我们遇到如下两个网页，则表明目标可能存在子域名接管漏洞。
接下来看一下如何确定漏洞是否存在。
首先，我们可以使用如下两类DNS记录来接管Shopify上的子域名：
1、使用应用名进行映射（CNAMES指向myshopname.myshopify.com）；
2、使用DNS进行映射（CNAMES指向shops.myshopify.com）。
可能还有其他方法（比如历史遗留域名），后续我们会进一步研究这些方法。
案例1：使用应用名进行映射
在这个例子中，我们为shop.buckhacker.com设置了一个CNAME记录，指向buckhacker.shopify.com：
现在如果Shopify上不存在buckhacker这个商店名称，我们就可以声明该名称来接管子域名。
那么如何判断某个商店名是否已存在？
在账户注册阶段，我们必须选择一个商店名。如果我们利用如下页面，很容易就能知道商店名是否可用：
如果我们使用Burp来观察，可以看到浏览器会发起一个REST API请求，并且会收到两种类型的响应：
({“status”:”unavailable”,”message”:null,”host”:”buckhacker.myshopify.com”})
({“status”:”available”,”message”:null,”host”:”buckhacker2.myshopify.com”})
我们可以开发一个脚本来判断某个域名是否可用，为节省大家时间，这里我们直接在GitHub上公开了这个脚本。
此时如果我们发现商店名可用，那么只需在Shopify网站中连接（connect）该名字即可，来看看具体步骤。
登录Shopify网站后，在左侧菜单处依次选择“Online Store”以及“Domains”：
接下来点击“Connect existing domain”（连接已有域名）：
在下一个表单处填入存在漏洞的域名：
点击“Next”，然后点击“Verify Connection”。
现在如果上述步骤操作正确，我们会被重定向到如下页面：
此时我们已成功接管子域名。
这种情况寻找起来比较麻烦，因为我们需要在账户创建过程中选择目标商店名。因此，为了使该名字可用，用户需要删除整个账户或者改变账户设置。在调查过程中，我们发现2%的网站存在这种错误配置情况。
案例2：使用DNS进行映射
在第二种案例中，子域名为指向shops.myshopify.com的一个CNAME。
我们创建的域名如下图所示：
这是Shopify上最常见的子域名接管场景。在这种情况下，我们基本上可以创建具有任意名称的商店，只需要按照上文所述在Shopify网站中进行连接即可。
接管过程的部分截图如下：
验证结果如下图所示：
也可以通过如下界面验证接管结果：
三、大规模利用
我们在之前一些文章中已经介绍过如何使用Sonar以及FDNS数据集来识别漏洞。
FDNS数据集中包含CNAMES记录。基本上我们要做的就是在这个数据集中寻找CNAME指向shop.myshopify.com或者myshopname.shopify.com的子域名，然后检查是否可以接管子域名即可。
我们只需要使用前文提到的脚本，用一行命令就可以完成这个任务：
zcat $FDNS_DATASET | strings | grep shopify.com | cut -d “”” -f 8 | grep -v “shopify.com” | while read subdomain; do python3 ShopifySubdomainTakeoverCheck.py $subdomain; done
首先我们需要解释一下，为什么在别人已开发了一些脚本的情况下，我们还要开发一个新的脚本来判断Shopify是否存在子域名接管漏洞。现在可用的其他脚本大多数是基于Shopify的错误信息页面来检测是否存在子域名接管漏洞，但这种方法容易得到许多假阳性结果。我们检查过存在这类错误信息的许多页面，只有少部分的确存在子域名接管漏洞。我们开发的简单脚本只执行了3步检查操作：页面错误信息、CNAME以及发起REST API请求（可根据具体情况再执行API请求）。我们希望未来的子域名接管工具可以采用类似技术来减少误报率。
如果我们在FDNSv2数据集（从2017年至今，新增了部分数据）上运行脚本，那么得到的结果非常可观：大约有超过55,000个子域名存在子域名接管漏洞。
现在我们就可以使用这个数据来判断漏洞奖励相关域名或者客户的相关域名是否位于这个大名单上。
显然，我们也可以在其他云服务提供商使用这种技术。
四、总结
我们认为这项研究成果可以让人们了解子域名接管漏洞的影响程度及具体规模。我们认为，在云计算的大背景下，我们面对的是漏洞研究的新时代，不能局限于分析进程堆栈情况，而应提高思维广度（比如分析DNS记录映射情况）来分析漏洞。可能我们需要将云平台甚至互联网本身当成一个大型操作系统来考虑。
五、时间线
- 2018年8月21日 — 通过HackerOne将漏洞报告给Shopify
- 2018年8月21日 — Shopify初步反馈
- 2018年8月23日 — Shopify再次反馈
- 2018年9月10日 — 漏洞公开