几个月前，我正在编写一篇关于PHP反序列化漏洞的博客文章，决定为这篇文章找一个真实目标，能够让我将测试数据传输给PHP unserialize ()函数来实现演示目的。于是我下载了一批WordPress插件，并开始通过grepping来寻找调用unserialize ()的代码实例：
这个插件的问题在于发送HTTP请求，并且将该请求响应传递给了unserialize ()函数。就真实而言，它并不是最佳入口点，但是如果我能通过这种微不足道的方式向unserialize ()函数提供输出来触发代码的线 PHP反序列化
简单来说，当者能够将他的数据提供给应用程序，而该应用程序将数据为运行对象时没有作适当验证的时候就会出现反序列化漏洞。如果者数据被允许去控制运行对象的属性，那么者就可以任何使用这些对象属性的代码执行流程，就有可能使用它发起。这是一种称为面向属性编程（POP）的技术，一个POP小工具是可以通过这种方式控制任何代码片段，开发实现是通过向应用程序提供特制对象，以便在这些对象进行反序列化的时候触发一些有用的行为。如果想了解更多详情的话，可以我的博客文章《Attacking Java Deserialization》（），其中的一般概念适用于任何基础技术。
在PHP应用程序的现状来看，POP小工具最为人熟知和最可靠的原因在于类的__wakeup()方法（PHP“魔术方法”，unserialize()函数会检查是否存在__wakeup()，如果存在，则会先调用__wakeup()方法，预先准备对象需要的资源），如果一个类定义了__wakeup()方法，那么无论何时该类的某个对象使用了unserialize ()函数进行反序列化都能__wakeup()方法被调用，另外一个原因是__destruct ()方法（当创建的对象被或遇到PHP结束标记的时候，比如程序已经执行完毕，对象会自动调用__destruct()执行一些相应的操作，可以自行定义），例如PHP脚本执行完成时（未发生致命错误），当反序列化对象超出范围时仍几乎可以__destruct ()方法被调用。
除了__wakeup ()和__destruct ()方法之外, PHP还有其他“魔术方法”，可以在类中定义，也可以在反序列化之后调用，这取决于反序列化对象的使用方式。在一个更大更复杂的应用程序中可能很难追踪到反序列化对象在哪里结束以及如何来使用它或调用那些方法，于是确定那些类可以用于PHP反序列化漏洞利用也很困难，因为相关文件可能未包含在入口点，或者一个类的自动加载器（例如spl_autoload_register()函数）可能以及被注册来进一步混淆。
为了简化这个过程，我编写了一个PHP类，它定义了所有魔术方法并且在调用任何魔术方法时将详细信息写入日志文件。特别有趣的是魔术方法__get()和__call()，如果应用程序尝试获取不存在的属性或调用该类中不存在的方法时就会调用以上魔术方法，前者可以用来识别在payload object上设置的属性，以便并使用这些属性的代码，而后者可以用来识别POP小工具触发使用的非魔术方法（并且可以将它们自身用作POP小工具）。
该类的__wakeup ()方法还使用了get_declared_classes ()函数来检索和记录可以利用exploit payload的已声明类的列表（虽然这不会反映当前未声明但可以自动加载的类）。
将的代码保存到一个PHP文件中，我们可以通过这个在其他任何PHP脚本中插入一个include’/path/to/UniversalPOPGadget.php’语句，并使这个类可用。以下Python脚本将查找给定目录中所有PHP文件，并将语句写入文件前端，从而有效地检测应用程序，以便我们可以向为其提供序列化的UniversalPOPGadget对象，来用它们研究反序列化的入口点。
在使用这种手段后，我开始像往常一样使用WordPress实例，特别注意了与目标WordPress插件相关的所有功能，同时查看UniversalPOPGadget日志文件。很快地，生成了一些日志文件，其中包括以下内容（为简洁起见，已将大量可用类删除）：
日志文件中显示，在UniversalPOPGadget对象被反序列化之后，用程序试图获取或检查是否存在多个属性（段、版本、作者等等）。首先这就告诉我们，通过这个特定的入口点我们可以使用任何可用类中的任何定义在__get ()或__isset ()方法中的代码来作为POP小工具，其次它了目标应用程序试图获得的几个属性，这些属性几乎影响执行流程，因此可能对开发有用处。
现在来看最初的目标插件，它在调用unserialize ()之后做的第一件事是检查名为rating的属性是否存在，那么这个日志并不是我当初注意的第三方插件产生的！
对WordPress代码进行一次快速grep，对于提到的HTTP URL，显示该请求是由wp-admin/includes/plugin-install.php文件中的WordPress插件API发送的。浏览代码时并不清楚反序列化的payload object是如何使用的，或者切确地说这个HTTP请求以及随后对unserialize ()函数的调用是从哪里触发的。我继续点击WordPress管理界面，谭凯的妻子发现日志是从主控制面板、更新页面和插件页面生成的。重新加载这些页面使我能够触发目标HTTP请求，并向unserialize ()函数提供任意数据。
我记录了一些WordPress发出的HTTP请求并把它们发送到真正的api.wordpress.org以获取实例响应，结果响应的是stdClass类型的序列化对象，更重要的是示例响应给了我一个预期中WordPress会收到的属性的确切列表，其中每个属性都有可能用于操控某些核心WordPress代码的执行流程。我根据捕获到的真实响应修改了伪造的api.wordpress.org用来返回序列化对象。以下是这个的一个简单例子：
我开始修改这些对象的属性并刷新相关的WordPress页面，来测试修改内容对结果页面有何影响（如果有的话）。在有些情况下WordPress使用了HTML编码来防止HTML/Java注入，但是最终我发现了几个可以插入任意HTML和Java的字段。请记住这个情况是发生在管理界面内，如果管理员登录并浏览“更新”或“插件”页面，者就能够对WordPress站点执行MitM或DNS，也可能会利用此漏洞实现远程代码执行。
在快速尝试一些Java和Python脚本之后我有了假设漏洞的运用证明。这个PoC会导致WordPress管理界面中的“更新和插件”菜单旁显示一个徽章，表示有更新可用（当然即使没有也会显示），这可能会管理员点击这些链接来检查并可能安装这些更新。如果有管理员点击任一链接，那么一个Java payload被注入到该页面中，然后就添加了一个新的管理员账户并将一个基本PHP命令shell注入到现行的WordPress主题的index.php中。
在大多数情况下这种PoC足以实现代码执行，但是我也发现了我可以使用类似方式向WordPress发送一个错误的插件更新来WordPress管理界面的点击更新功能，如果有管理员点击了更新按钮，就会导致下载一个假插件更新的ZIP文件并将其提取至服务器上。
WordPress会每天两次调用wp_version_check ()函数、wp_update_plugins ()函数和wp_update_themes ()函数。默认情况下，这些更新检查也可以通过wp-cron.php发送HTTP请求来触发。于是我开始手动审计这些函数，并修改代码来记录各种数据以及分支和函数调用的结果，查看发生了什么，函数是否根据来自api.wordpress.org的响应而做出了任何的操作。
最终我设法伪造了来自api.wordpress.org的几个响应，来触发对$upgrader-upgrade()的调用，然而以前的伪造插件更新在这里似乎不起作用，之后我在should_update()方法中发现了以下注释：
者既然可以对WordPress网站执行MitM或DNS，那么就可以针对自动更新功能执行零交互，并将恶意脚本写入服务器。当然这不一定是一次简单的，但这仍然不可能！
WordPress团队意识到这些问题，但是他们的立场似乎是，如果HTTPS启用失败，为了允许在具有旧或损坏的SSL堆栈系统上运行的WordPress网站进行更新，WordPress将会故意降级为HTTP连接（或者安装恶意代码）……
如果WordPress的PHP脚本属于不同的用户，那么WordPress将默认无法自动更新（因此不容易受到上述），例如index.php为用户foo拥有，但WordPress是在用户权限下运行的。
本文由来源于财鼎国际(http://cdgw.hengpunai.cn:27531/)
网友评论 ()条 查看