STATEMENT

声明

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，雷神众测及文章作者不为此承担任何责任。

雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经雷神众测允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

前言

本文使用的是php5.6.10版本源码，我们主要来看看该版本下绕过wakup魔术方法这个CVE-2016-7124漏洞，用以记录前段时间的分析。

serialize分析

先写一个小demo，不含__sleep()函数的：

<?phpclass serialize_test{public $a = 'nekoc';public $b = 123456;function show(){echo 123;}}$obj = new serialize_test();echo serialize($obj);

接下来在/php-5.6.10/ext/standard/var.c下面，找到PHP_FUNCTION(serialize)，这里是定义serialize的函数，在其中下一个断点，接下来开始调试，让其直接跳到serialize函数这里。
开始调试后发现，php经过一系列的处理后，进入到php_var_serialize函数对序列化进行处理：

接下来继续跟进php_var_serialize_intern方法，只列举重要部分，可以看到，该处根据struc的值来判断进入到哪个case循环，由于struc的值为5，根据定义：

判断进入IS_OBJECT的case下进行处理：

在该case中的处理如下图：

由于在demo中没写__sleep()函数，所以在处理__sleep()函数的位置被跳过，所以在IS_OBJECT中没有一处函数被执行，而且case中不存在跳出循环的语句，所以代码继续向下走，来到IS_ARRAY中进行处理：

经过一系列处理后，代码来到php_var_serialize_intern函数递归解析哈希数组，最后将序列化后的代码存到buf中，至此，序列化过程结束。
接下来，我们在demo中添加一段__sleep魔术函数，来看看PHP是如何处理__sleep魔术方法的：

<?phpclass serialize_test{public $a = 'nekoc';public $b = 123456;
function show(){echo 123;}function __sleep(){$this->show();return ['1','2','3'];}}
$obj = new serialize_test();echo serialize($obj);

进入到处理__sleep()方法后，跟进到call_user_function_ex方法中：

在此方法中，对传入的参数进行赋值给fci后，将fci交给zend_call_function方法处理，而且，此时的fci.function_name就是我们在demo中新增的__sleep方法，接下来，在zend_call_function方法中，PHP会将我们在__sleep中写的操作压进zend_vm引擎中，而后，利用zend_execute方法进行解析，这里就不再过多赘述。

unserialize分析

<?phpclass serialize_test{public $a = 'nekoc';public $b = 123456;
function show(){echo 123;}}
$obj = new serialize_test();$ser = serialize($obj);$unser = unserialize($ser);var_dump($unser);

我们在PHP_FUNCTION(serialize)方法下方找到PHP_FUNCTION(unserialize)下断点：

开始调试后，依据流程进入到php_var_unserialize方法，由于序列化后的第一个字母为O，所以在函数中判断为object对象，接下来跳转到处理对象的流程，经历两个处理后，流程来到yy20，首先，会检查当前的类名是否存在：

接下来，利用object_common1方法判断当前剩余的元素个数：

接下来将elements参数交给object_common2方法：

在此方法中我们可以看到，首先使用了process_nested_data判断了一个东西，接下来判断我们自定义的类中是否存在__wakeup方法，有的话就像serialize流程一样使用call_user_function_ex进行调用，我们接下来就重点看process_nested_data这段判断的代码：

在process_nested_data方法中，首先使用了两段php_var_unserialize方法，一个解析了序列化字符串对中名称，另一个解析名称对应的值，至此，反序列化部分基本结束。综上我们可以得出序列化与反序列化的一个流程：

序列化：调用__sleep—>利用zend_vm进行解析—>序列化操作
反序列化：获取反序列化字符串—>根据类型进行反序列化—>检测是否有这个类—>判断元素个数—>解析字符串—>判断是否有wakeup方法—>调用wakeup方法

经过简单了解的源码结构，我们可以看看CVE-2016-7124这个漏洞，由于php5.6.10的代码逻辑问题，导致反序列化时首先被调用的__wakeup方法可以被绕过，下面给出这个漏洞复现的demo：

<?phpclass test{public $a = 'hello';public function __wakeup(){var_dump("wakeup");}public function __destruct(){var_dump("destruct");}}unserialize('O:4:"test":2:{s:1:"a";s:5:"hello";}');// 执行时绕过了wakeup函数，只输出了destruts，以下几种都可以实现相同的效果unserialize('O:4:"test":2:{s:2:"a";s:5:"hello";}');unserialize('O:4:"test":2:{s:1:"a";s:4:"hello";}');unserialize('O:4:"test":1:{s:1:"a";s:6:"hello";}');

执行以上代码我们发现，在控制台上只会输出destruct，__wakeup方法根本没被调用，这是为什么呢，我们接下来开始调试跟一下代码看看。
在调试的过程中，我们发现，在调用__wakeup方法前有一处使用了process_nested_data进行了判断：

并且该函数的返回值为0，调试时发现流程到这里时直接被返回了，在上面我们知道process_nested_data做了解析字符串名称的操作，我们继续跟进看看到底发生了什么。
在跟进process_nested_data的时候我们发现，其中的while循环被成功的执行了一次，在第二次执行时，当流程进入第一个php_var_unserialize的时候，解析失败了，这就导致直接被返回了0值，跳过了__wakeup的解析过程，而这，正是我们payload中修改的部分，我们将序列化后的字符串中对象属性的个数由原来的1改为了2，导致解析失败，所以才绕过了__wakeup方法的执行，而在demo中给出的其他payload都是修改了要解析成员的字符数，这样也会导致解析失败而跳过__wakeup的执行，而这是php5.6.10的逻辑错误导致的。

征稿通知

知识应该被分享，安全更需携手共进

RECRUITMENT

招聘启事

安恒雷神众测SRC运营（实习生）
————————
【职责描述】
1.  负责SRC的微博、微信公众号等线上新媒体的运营工作，保持用户活跃度，提高站点访问量；
2.  负责白帽子提交漏洞的漏洞审核、Rank评级、漏洞修复处理等相关沟通工作，促进审核人员与白帽子之间友好协作沟通；
3.  参与策划、组织和落实针对白帽子的线下活动，如沙龙、发布会、技术交流论坛等；
4.  积极参与雷神众测的品牌推广工作，协助技术人员输出优质的技术文章；
5.  积极参与公司媒体、行业内相关媒体及其他市场资源的工作沟通工作。

【任职要求】 
 1.  责任心强，性格活泼，具备良好的人际交往能力；
 2.  对网络安全感兴趣，对行业有基本了解；
 3.  良好的文案写作能力和活动组织协调能力。

简历投递至 

[email protected]

设计师（实习生）

————————

简历投递至 

[email protected]

安全招聘

简历投递至

[email protected]

岗位：红队武器化Golang开发工程师

[email protected]

END

长按识别二维码关注我们