利用面向公众的服务是在网络中获得初步立足点的方法之一，这种情况在野外会经常看到。众所周知，各种攻击者都会滥用诸如缓冲区溢出(G0098)、SQL注入(G0087)或其他已知带有功能利用代码(G0016)的漏洞。

本文描述了一个HTTP请求走私(HRS)漏洞，这是我们在一次渗透测试中发现的。它可以用来模拟利用面向公众的服务，同时在客户的网络中获得初步立足点。在这个示例中，它允许我们获取Active Directory凭据，从而用该凭据登录到Outlook Web Access (OWA)查看敏感数据。

本文还会介绍如何通过将客户端迁移到一个中间人Exchange服务器来获得对OWA的持久访问权。

HTTP请求走私

HTTP请求走私(HRS)漏洞现在非常普遍。早在2005年，CGISecurity就发布了一份白皮书，详细描述了漏洞是如何产生的，它会造成什么后果，以及如何缓解它。如果你不确定HRS是如何工作的，我强烈建议你阅读这篇白皮书或PortSwigger关于HRS的文章来熟悉一下。当网络服务器和代理可以不同步时，就会出现 HRS。攻击者发送的请求在前端服务器和后端服务器上的解释不同。例如，攻击者发送一个特殊的请求，前端服务器将其解释为1个请求，但后端服务器将其解释为2个请求。第二个请求因此被“走私”通过前端服务器并最终到达后端服务器。正如 PortSwigger 的 James Kettle 所描述的，该请求的响应将被提供给下一位访问者。

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

在我们的例子中，HRS允许我们获取Active Directory凭据，这将在下面的攻击叙述中描述。这种攻击叙述包含了从起初到最后的整个路径。

识别代理基础设施

在一次渗透测试中，我们的目标是通过渗透客户的数字基础设施获得初步立足点。由于自动扫描无法产生结果，我们很快进行了手动测试。包括 Outlook Web Access (OWA) 在内的各种服务在使用 GoBuster 工具对子域进行暴力破解时被识别。使用中的词表由@bitquark 生成，包含 100000 个最常用的子域。

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

要求：

一般的web服务器会生成一个“421 Misdirected Request”响应。下面包括一个示例。

响应：

然而，当我们在owa.customer.com上运行此操作时，服务器返回了以下响应，即 302 Moved Temporarily。那时，我个人认为这种重定向是HTTP代理的典型行为。但是，后来我意识到它应该是带有实际响应正文的 200 OK 或 203 Non-Authoritative Information，如 RFC7230中所述。

响应：

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

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

识别易受攻击的代理设置

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

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

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

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

这也适用于其他方式（如果代理使用分块编码而 OWA 使用内容长度）。基础设施易受 HRS 攻击的方式有多种。所有这些方式都在 PortSwigger 的博客中进行了描述。实际上，我们使用的真正技巧是在传输编码标头之前插入了一个空格，Transfer-Encoding: chunked。虽然代理无法解析它并使用 Content-Length 来确定正文长度。但是，OWA 能够解析它并使用 Transfer-Encoding 标头来确定正文长度。

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

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

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

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

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

总而言之，这意味着有可能从用户那里获取更多信息，我们将在接下来的章节中介绍这些信息。

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

可以在各种邮件客户端中配置 ActiveSync，例如 Apple Mail。正如 Apple 连接到 ActiveSync 端点的手册中所见，用户必须提供服务器、域、用户名和密码。这些详细信息很可能会通过 HTTP 请求发送到服务器。在配置期间或在每个请求中。

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

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

盗取并使用凭据

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

可以通过多种方式捕获非法服务器上的请求标头。为了进行概念验证，我选择使用Burp Collaborator，它充当HTTP和各种其他协议的所有捕获服务器。

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

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

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

HRS攻击如下图所示。

将受害者的邮箱永久迁移到我们的非法交易服务器上

未记录的功能

作为渗透测试人员，我们想更深入地研究这一发现可能产生的影响。出于这个原因，我们从攻击者的角度寻找进一步的选择，其中最值得注意的是获得对受害者凭据的永久访问权限。事实证明，ActiveSync有一个功能，可以在用户的邮箱从办公场所迁移到Office365时自动更新邮件客户端的配置。此功能的工作原理如下：

· 客户端尝试通过 HTTP ActiveSync 协议检索邮件；

· Exchange 会检查用户的邮箱是否存在或者是否迁移到 Office365；

· DC 返回未找到邮箱（这意味着已迁移）；

· Exchange 尝试获取域的 TargetOWAURL（邮箱所在的位置）；

· DC 返回 TargetOWAURL（在本例中为outlook.office365.com）；

· Exchange 使用一个HTTP 451重定向到TargetOWAURL来响应客户端；

· 客户端将 TargetOWAURL 用于所有未来的请求；

· 对 TargetOWAURL 的 HTTP ActiveSync 请求成功。

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

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

将受害者的邮箱迁移到我们的非法交易所

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

想要将Bob的邮箱迁移到非法交换服务器的攻击者需要首先执行HRS攻击，将Bob的ActiveSync请求重定向到非法服务器。下面提供了一个示例。

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

当 Bob 成为 HRS 攻击的受害者时，他将收到非法服务器的 451 Unavailable For Legal Reasons 响应。 Bob 的电子邮件客户端会将服务器地址更改为 rogue-exchange.remote，因为响应表明邮箱迁移到了这个Exchange 服务器。

最初的几次尝试都没有成功。但是在连续尝试了几次之后，HRS攻击最终触发了Bob的同步请求，导致Bob的邮件客户端将配置更改为非法交换。这可以在下面的Bob的Exchange设置中看到。

由于恶意交换器将所有请求代理给合法交换器，Bob不会注意到恶意配置更改(除非他查看自己的exchange设置)。作为一个攻击者，我们现在能够拦截他的所有ActiveSync请求，即使在Bob更改了他的凭据之后。

缓解措施

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

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

最后，我们强烈建议不要将基本身份验证用作 Exchange 的身份验证方法。请改用现代身份验证。使用现代身份验证，攻击者只能拦截oAuth令牌。

如果你认为自己是Exchange遭受HRS攻击的受害者，请主动重置Exchange客户端的配置和密码。