在这篇文章中,我们将探讨curl中一个鲜为人知的特性,该特性导致了Burp Suite Pro和Google Chrome的本地文件泄露漏洞。虽然我们早已为Burp Suite发布了补丁,但怀疑该技术可能对利用其他具有"复制为curl命令"功能或从命令行调用curl的应用程序有所帮助。该漏洞由Paul Mutton通过我们的漏洞赏金计划私下报告,并慷慨地允许我们发布这篇分析报告。
Burp Suite用户经常构造复杂的HTTP请求来演示网站漏洞。为了更轻松地与他人共享这些概念验证漏洞利用,我们提供了"复制为curl命令"功能,可生成复制Burp Suite中请求的curl命令。
例如,给定以下请求:
|
|
点击"复制为curl命令"后,Burp Suite会生成以下命令并复制到剪贴板:
|
|
您可以将此命令粘贴到终端中,在Burp Suite外部重新发出请求。我们非常注意转义这些数据,以避免用户因恶意请求注入额外的shell命令或任意curl参数而受到攻击。但不幸的是,存在一个更微妙的问题。您能发现吗?
答案一如既往地藏在友好的手册中:
|
|
因此,以下命令是安全的:
|
|
而这个就不那么安全了:
|
|
我们在2020.5.1版本中修复了这个漏洞,如果请求体以@符号开头,就改用更新、更安全但支持较少的–data-raw标志。
我们很幸运,因为在Burp Suite中利用此漏洞需要相对较多的用户交互——攻击者需要诱导用户访问恶意网站,将精心设计的请求复制为curl命令,然后通过命令行执行。如果网站使用curl并带有攻击者控制的请求体,则可能产生更大的影响,因此在SSRF测试期间绝对值得关注。@文件读取行为也适用于标头,因此在允许定义自定义标头的网站上可能有用。
尽管这个特性让我们(和Chrome)感到意外,但它已完全记录在案,因此我们不认为这是curl本身的漏洞。这让我想起了服务器端模板注入,在那里沙箱逃逸可能就像阅读一个被其他人忽视的手册页面一样简单。
再次感谢Paul分享这个很酷的技术。下次见!