CVE-2024-24919 Check Point SSL VPN 任意文件读取漏洞分析

大家聚过来，大家聚过来——是时候再写一篇博客文章，剖析一台SSL VPN设备，并揭露最近在野外被利用的一个漏洞。这一次，我们的焦点是Check Point。

Check Point，对于那些不知道的人，是负责“CloudGuard网络安全”设备的供应商，这是另一个声称是安全和加固的设备。他们的口号——“你值得拥有最好的安全”——意味着他们是一个你可以信赖的公司，可以负责你的网络安全。这是一个大胆的声明。

为了看看Check Point是否真的提供了他们的客户应得的安全——最好的安全——我们想看看他们的设备内部，我们最近有了一个绝佳的机会，那就是CVE-2024-24919。这是一个“高”优先级的漏洞，根据CVE本身的说法，它属于“向未授权行为者暴露敏感信息”的类别。Check Point建议这个漏洞正在被积极利用，并给出了以下摘要（在其他建议中）：

该漏洞可能允许攻击者在网关连接到互联网并启用远程访问VPN或移动访问后读取某些信息。

这里没有错误类别，只是一个非常模糊和含糊的描述。我们想知道“某些信息”在这个上下文中到底意味着什么——它意味着我们可以读取会话令牌吗？还是设备的配置？密码哈希？（剧透：实际上情况比这更糟）。互联网上关于这个漏洞的信息并不多，所以我们决定找出它有多糟糕，以便我们可以与需要做出重要修补决定的设备管理员分享细节。

补丁差异分析时间

这个漏洞似乎是进行补丁差异分析的绝佳候选，通过比较易受攻击的系统和已修补的系统来揭示有关补丁本身的详细信息，从而揭示漏洞。

像往常一样，这的第一个障碍是获得修补版本的软件。虽然从咨询链接中的补丁被锁定在登录表单后面，但我们发现设备本身会在没有任何凭证的情况下获取补丁，所以我们适当地安装了补丁并编目了结果文件，以便将每个文件与其补丁前的对应物进行比较。

不过，我们并不需要如此大费周章，因为在检查设备文件系统时，我们很快就在临时目录中找到了包含更新本身的.tgz文件。太好了！打开它，我们发现了很多无聊的安装脚本，还有一个听起来很有希望的文件名为sslvpn.full的ELF二进制文件。至少这次我们不需要盯着令人昏昏欲睡的PHP代码——它是一个二进制文件，所以我们要看的是漂亮的x86反汇编。太棒了。

$ find -exec file {} ;
...
./CheckPoint#fw1#All#6.0#5#1#HOTFIX_R80_40_JHF_T211_BLOCK_PORTAL_MAIN/fw1/bin/vpn.full: ELF 32位LSB可执行文件，Intel 80386，版本1（SYSV），动态链接，解释器/lib/ld-linux.so.2，适用于GNU/Linux 2.6.9，BuildID[sha1]=9484c3b95be69aa112042766793877d466fe9626，已剥离
...

我们把易受攻击和修补过的文件版本扔进了IDA，并使用Diaphora来观察差异。马上有一些东西引起了我们的注意（易受攻击的代码在左边，修补过的在右边）：

O_o

嗯，有趣——添加了新代码，它记录了字符串“怀疑路径遍历攻击来自”。这似乎是一个很好的猜测，这个漏洞实际上是一个路径遍历。

在代码中四处查看，我们可以看到添加了一个新的日志记录函数，名为send_path_traversal_alert_log，如果我们再深入一点，我们还发现了一个新的函数sanitize_filename，它调用了新的日志记录函数。如果我们看看引用sanitize_filename本身的内容，我们会发现一个单一的调用者——一个具有自动生成名称sub_80F09E0的大型函数。如果我们再次搜索这个大型函数的引用，我们的坚持得到了回报，因为我们发现它被传递给了函数cpHttpSvc_register_query，以及HTTP路径/clients/MyCRL，强烈暗示它是这个端点的处理程序。

这很棒——我们只分析了几分钟，就已经发现了一些重要的线索！首先，我们相当确定我们在寻找一个路径遍历漏洞，其次，我们强烈怀疑它影响端点/clients/MyCRL。

一点调查揭示了这个端点被设计用来从文件系统的一个位置提供静态文件。可以通过URI本身指定文件，形式为/clients/MyCRL/file_to_get，也可以通过POST正文指定。我们对此进行了一些实验，并发现了一些有趣但无用的服务器中的怪异现象——在URL中添加某些控制字符（例如/clients/MyCRL/test%0Atest）会使请求挂起，并且错误处理检测到转义的空字节似乎也值得怀疑，因为尽管在日志中生成了严重的警告，但请求服务代码的部分仍会被执行。然而，我们尝试的URL路径中没有任何东西看起来像是受控的文件读取。

尝试在URL中添加路径遍历元素如..没有结果，因为Web服务器会正确处理它们——但是POST正文呢？它不受Web服务器的路径处理代码限制。我们尝试添加了常见的../../etc/passwd有效负载，但很快就失望了，因为我们收到的只是一个微不足道的404。服务器日志显示，设备确实拒绝提供我们的路径：

[vpnd 29382 4082644928]@i-022337f52dc65ca35[30 May  3:02:00][slim] http_get_CCC_callback: Invalid filename: /opt/CPsuite-R80.40/fw1//../../etc/passwd

不好！我们如何弄清楚发生了什么，并将我们自己提升到盲目猜测之外？当然，通过看看那个大的sub_80F09E0！

理解反编译的代码

这个大型处理程序函数可能看起来很吓人，但实际上相当简单。切换到代码的易受攻击版本，我们可以快速浏览一下，它执行文件I/O，由_fopen和_fread的明显引用给出——这无疑是我们找到我们的错误的地方。但它在做什么？

由于代码以不寻常的方式引用字符串资源，IDA没有捕获到，所以很难看出代码在做什么。看看下面的代码片段：

这里发生了什么？嗯，代码正在将某物（用户请求的URL）与字符串表中的一些硬编码字符串进行比较。IDA不知道字符串表在哪里，但GDB可以在运行时告诉我们——结果是这样的：

足够简单——代码正在检查用户是否正在请求列表中的任何文件，并且只有在匹配时才会允许下载。但这段代码中有一个“错误”。你能发现它吗？

没错！错误并不复杂或涉及，它在于开发人员使用strstr函数。正如C大师所知，这个函数不会直接比较两个字符串，而是在一个字符串中搜索另一个字符串。这立即让我们开始思考——我们能否通过请求包含表中一个字符串的相对路径来滥用这个松散的匹配？只要路径中包含表中的一个字符串，检查就会通过，文件就会被服务。

嗯，事实证明我们不能。我们可以提供如icsweb.cab/../../etc/passwd这样的路径，但操作系统并不傻，会因为找不到文件而失败，抱怨icsweb.cab是一个文件，而不是一个目录。我们很接近了——我几乎可以感觉到它！让我们继续查看那个代码。

这是一个非常相似的代码块，就在第一个下面。再次，我们正在迭代一个字符串表，并与请求的URL进行比较。再次，我们拿出GDB，看看它使用的字符串表：

短小精悍。当我们看到这个条目时非常兴奋——你能明白为什么吗？

是的，没错！因为字符串末尾的斜杠。这表明这个条目不是一个文件，而是一个目录，这意味着我们可以进入它，然后通过可靠的..来回退。只要请求的文件中某个地方有字符串CSHELL/，请求就会被接受，对吗？

嗯，我们尝试了，屏住呼吸提交了以下请求：

POST /clients/MyCRL HTTP/1.1
Host: <已编辑>
Content-Length: 39

aCSHELL/../../../../../../../etc/shadow

我们得到了所请求文件的内容。

HTTP/1.0 200 OK
Date: Thu, 30 May 2024 01:38:29 GMT
Server: Check Point SVN foundation
Content-Type: text/html
X-UA-Compatible: IE=EmulateIE7
Connection: close
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Length: 505

admin:$6$rounds=10000$N2We3dls$xVq34E9omWI6CJfTXf.4tO51T8Y1zy2K9MzJ9zv.jOjD9wNxG7TBlQ65j992Ovs.jDo1V9zmPzbct5PiR5aJm0:19872:0:99999:8:::
monitor:*:19872:0:99999:8:::
root:*:19872:0:99999:7:::
nobody:*:19872:0:99999:7:::
postfix:*:19872:0:99999:7:::
rpm:!!:19872:0:99999:7:::
shutdown:*:19872:0:99999:7:::
pcap:!!:19872:0:99999:7:::
halt:*:19872:0:99999:7:::
cp_postgres:*:19872:0:99999:7:::
cpep_user:*:19872:0:99999:7:::
vcsa:!!:19872:0:99999:7:::
_nonlocl:*:19872:0:99999:7:::
sshd:*:19872:0:99999:7:::

就这样！路径遍历导致任意文件读取！由于我们能够读取这样一个关键文件——影子密码文件——我们必须以超级用户身份运行，并且能够读取我们选择的文件系统上的任何东西。

等等，什么？！

在这一点上，我们有点困惑。我们发现的是一个任意文件读取，允许我们读取系统上的任何文件。这比供应商咨询所暗示的要强大得多。

我们赶紧修补我们的盒子，并确认我们确实发现了CVE-2024-24919，而不是其他错误，并且我们有点惊讶，是的，这是CVE-2024-24919，是的，它是任意文件读取。

有趣的是，供应商声称这个问题只影响启用了用户名和密码认证的设备，而不会影响启用了（更强的）证书认证的设备。查看代码，我们看不出任何明显的原因，我们确实想知道，拥有有效证书的用户是否可以在禁用密码认证时利用这个问题。

供应商的补救建议也让我们感到有些好笑，其中包括这个精华：

为了防止尝试利用这个漏洞，您必须在两个都启用了IPS和SSL检查的Security Gateway 后面保护易受攻击的远程访问网关。

除了明显的语法错误之外，建议将您的加固边界网关设备放在另一个加固边界网关设备后面，让我们感到好笑。

结论

这个漏洞不难发现，一旦我们定位到它，就非常容易利用（完整的利用留给读者作为练习——我们并不想剥夺发现漏洞的所有乐趣）。

不过，我们对供应商的声明有些担忧——它似乎淡化了这个漏洞的严重性。由于这个漏洞已经被真实攻击者在野外使用，将其视为任何低于完全未授权的远程代码执行（RCE）的漏洞都是危险的，应该敦促设备管理员尽快更新。他们声明：

该漏洞可能允许攻击者访问连接到互联网的网关上的信息

考虑到互联网连接并不是一个要求，这是一个相当令人困惑的声明。“访问信息”这个词在这里承担了非常沉重的工作，因为虽然它们在技术上可能是正确的，但在最挑剔的意义上，它们最小化了一个非常严重的漏洞，这个漏洞应该被视为“世界末日”（至少对那些没有第二个Checkpoint设备保护他们真正的Checkpoint设备的管理员来说是这样）。

供应商Checkpoint已经发布了这个漏洞的“热修复”补丁，如果受影响，管理员被指示应用（详见供应商咨询）。