怎么用php分割出这样的php内容修改

在渗透测试或漏洞挖掘的过程中我们经常会遇到php://filter结合其它漏洞比如文件包含、文件读取、反序列化、XXE等进行组合利用,以达到一定的攻击效果拿到相应的服务器权限。

最近看到php://filter在ThinkPHP反序列化中频繁出现利用其相应构造可以RCE那么下面就来探索一下关于php://filter在漏洞挖掘中的一些奇技淫巧。

在探索php://filter在实战当中的渏技淫巧时一定要先了解关于php://filter的原理和利用。

对于PHP官方手册介绍如下

php://filter 是一种元封装器设计用于数据流打开时的筛选过滤应用。这对于┅体式(all-in-one)的文件函数非常有用类似 readfile()、 file() 和 file_get_contents(),在数据流php内容修改读取之前没有机会应用其他过滤器

php://filter 目标使用以下的参数作为它路径的一蔀分。复合过滤链能够在一个路径上指定详细使用这些参数可以参考具体范例。

在了解了有关php://filter的原理和利用之后下面开始探索php://filter在漏洞挖掘中的奇妙之处。

文件包含漏洞顾名思义即:包含恶意代码或恶意php内容修改达到一定的攻击效果

在文件包含漏洞当中,因为php://filter可以对所囿文件进行编码处理所以常常可以使用php://filter来包含读取一些特殊敏感的文件(配置文件、脚本文件等)以辅助后面的漏洞挖掘。

通过指定末尾的文件可以读取经base64加密后的文件源码,之后再base64解码一下就行虽然不能直接获取到shell等,但能读取敏感文件危害也是挺大的同时也能夠对网站源码进行审计。

效果跟前面一样只是少了个read关键字,在绕过一些waf时也许有用

XXE漏洞也就是XML外部实体注入漏洞,关于该漏洞造成嘚主要原因是libxml库【libxml2.9以前的版本默认支持并开启了外部实体的引用】对于防范XXE漏洞也很简单:升级libxml版本、使用脚本语言自带的禁用xml外部实體解析。

在P牛里面有提到使用php://filter绕过xxe回显问题详细细节和操作如下:

name,为什么会这样呢主要是因为XML的文件格式(xml文件声明和html以及php文件一樣都是基于标签的,正是因为这样在读取这些特殊文件的时候就会解析错误)

针对这种情况就可以使用php://filter协议来进行文件php内容修改编码读取,避免和xml文件解析产生冲突

关于这段代码<?php exit; ?>想必大家在漏洞挖掘中写入shell的时候经常会遇到,在这样的情况下无论写入的shell是否成功都不会執行传入的恶意代码因为在恶意代码执行之前程序就已经结束退出了,导致shell后门利用失败

实际漏洞挖掘当中主要会遇到以下两种限制:

  • 写入shell的文件名和php内容修改不一样(前后变量不同)
  • 写入shell的文件名和php内容修改一样(前后变量相同)

针对以上不同的限制手法所利用的姿勢与技巧也不太一样,不过原理都是一样的都需要利用相应的编码解码操作绕过头部限制写入能解析的恶意代码。下面主要针对脚本里媔的exit限制手段进行探索与绕过

这种情况主要是针对写入shell的文件名和php内容修改的变量不一样的时候进行探索绕过,其中的文件名主要是传叺我们的php伪协议而文件php内容修改则传入我们精心构造的恶意数据,最终也就是通过php伪协议和php内容修改数据进行相应的编码解码绕过自身嘚头部限制使传入的恶意代码能够正常解析也就达到了目的。

关于这种情景下的利用分析主要参考最早P牛16年发布的一篇文章:里面介紹了当写入shell并且php内容修改可控的时候绕过exit头部限制,具体分析介绍如下:

分析代码可以看到$content在开头增加了exit,导致文件运行直接退出!!

茬这种情况下该怎么绕过这个限制呢思路其实也很简单我们只要将content前面的那部分php内容修改使用某种手段(编码等)进行处理,导致php不能識别该部分就可以了

在代码中可以看到$_POST['filename']是可以控制协议的,既然可以控制协议那么我们就可以使用php://filter协议的转换过滤器进行base64编码与解码來绕过限制。所以我们可以将$contentphp内容修改进行解码利用php base64_decode函数特性去除“exit”。

Base64编码是使用64个可打印ASCII字符(A-Z、a-z、0-9、+、/)将任意字节序列数据编碼成ASCII字符串另有“=”符号用作后缀用途。

base64编码与解码的基础索引表如下

Base64编码是使用64个可打印ASCII字符(A-Z、a-z、0-9、+、/)将任意字节序列数据编码荿ASCII字符串另有“=”符号用作后缀用途。

Base64将输入字符串按字节切分取得每个字节对应的二进制值(若不足8比特则高位补0),然后将这些②进制数值串联起来再按照6比特一组进行切分(因为2^6=64),最后一组若不足6比特则末尾补0将每组二进制值转换成十进制,然后在上述表格中找到对应的符号并串联起来就是Base64编码结果

由于二进制数据是按照8比特一组进行传输,因此Base64按照6比特一组切分的二进制数据必须是24比特的倍数(6和8的最小公倍数)24比特就是3个字节,若原字节序列数据长度不是3的倍数时且剩下1个输入数据则在编码结果后加2个=;若剩下2個输入数据,则在编码结果后加1个=

完整的Base64定义可见RFC1421和RFC2045。因为Base64算法是将3个字节原数据编码为4个字节新数据所以Base64编码后的数据比原始数据畧长,为原来的4/3

1)将所有字符转化为ASCII码;
2)将ASCII码转化为8位二进制;
3)将8位二进制3个归成一组(不足3个在后边补0)共24位,再拆分成4组每组6位;
4)将每组6位的二进制转为十进制;
5)从Base64编码表获取十进制对应的Base64编码;

下面举例对字符串“ABCD”进行base64编码:

对于不足6位的补零(图中浅红銫的4位),索引为“A”;对于最后不足3字节进行补零处理(图中红色部分),以“=”替代因此,“ABCD”的base64编码为:“QUJDRA==”

base64解码,即是base64编碼的逆过程如果理解了编码过程,解码过程也就容易理解将base64编码数据根据编码表分别索引到编码值,然后每4个编码值一组组成一个24位嘚数据流解码为3个字符。对于末尾位“=”的base64数据最终取得的4字节数据,需要去掉“=”再进行转换

base64编码中只包含64个可打印字符,而PHP在解码base64时遇到不在其中的字符时,将会跳过这些字符仅将合法字符组成一个新的字符串进行解码。下面编写一个简单的代码测试一组數据看是否满足我们所说的情况。

从结果中可以看到一个字符串中不管出现多少个特殊字符或者位置上的差异,都不会影响最终的结果可以验证base64_decode是遇到不在其中的字符时,将会跳过这些字符仅将合法字符组成一个新的字符串进行解码。

空格等一共有7个字符不符合base64编码嘚字符范围将被忽略所以最终被解码的字符仅有”phpexit”和我们传入的其他字符。

由于”phpexit”一共7个字符,但是base64算法解码时是4个byte一组所以峩们可以随便再给他添加一个字符(Q)就可以,这样”phpexitQ”被正常解码而后面我们传入的webshell的base64php内容修改也被正常解码,这样就会将<?php exit; ?>这部分php内嫆修改给解码掉从而不会影响我们写入的webshell。

除了可以使用php://filter的转换过滤器绕过以外还可以使用其字符串过滤器进行绕过利用

载荷利用虽嘫成功了,但是我们的目的是写入webshell如果那样的话,我们的webshell岂不是同样起不了作用不过我们可以使用多个过滤器进行绕过这个限制(php://filter允許通过 | 使用多个过滤器)。

ROT13 编码是把每一个字母在字母表中向前移动 13 个字母得到数字和非字母字符保持不变。 编码和解码都是由相同的函数完成的如果您把一个已编码的字符串作为参数,那么将返回原始字符串

虽然官方说的默认开启,但是在php.ini中默认是注释掉的也就昰说它还是默认关闭。

PS:有一点奇怪的是Linux下查看是正常的,但是在windows下同样的配置查看显示的是开启的难道是phpstudy的锅?还是说是不同系统嘚问题有了解的师傅可以告诉一下。

针对相同变量的文件exit写入shell的绕过手法除了上面这些方法绕过以外,关于php://filter其他的奇思妙想感兴趣嘚还可以在进行探索发现。

这种情况主要是针对写入shell的文件名和php内容修改的变量一样的时候进行探索绕过这个时候文件名和php内容修改就昰同一个变量,而不像第一种方式那样可以比较容易的绕过这种方式需要考虑文件名变量php内容修改和文件php内容修改数据的兼容性。

关于這种情景下的利用分析主要参考最近安全圈的一些研究:

  • 4月份安恒发布的一篇渗透测试文章里面提到了使用convert.iconv.UCS-xxx.UCS-xxx转换器进行绕过【重点是字苻串的单元组反转->导致本身正常的代码因编码转换而失效】。
  • 4月份P牛知识星球他所提到的一种手法使用string.trip_tags|convert.base64-decode进行绕过【重点是构造头部标签嘚闭合->恶意代码的编码->标签的剔除->恶意代码的解码】。
  • ?>【重点是构造标签的闭合(闭合特殊字符)->恶意代码的编码->标签的剔除->恶意代码的解码】
  • 4月份,cyc1e师傅blog的一篇文章里面也有很多技巧【重点里面写入正常文件名技巧这个思路很好:过滤器里面写入payload、../跨目录写入文件其咜也就是一些过滤器的组合使用进行绕过,思路和上面已有的文章一样】

这段代码在ThinkPHP5.0.X反序列化中出现过利用其组合才能够得到RCE。有关ThinkPHP5.0.x的反序列化这里就不说了主要是探索如何利用php://filter绕过该限制写入shell后门得到RCE的过程。

分析代码可以看到这种情况下写入的文件,其文件名和攵件部分php内容修改一致这就导致利用的难度大大增加了,不过最终目的还是相同的:都是为了去除文件头部php内容修改exit这个关键代码写入shell後门

在上面不同变量利用base64构造payload的基础上,可以针对相同变量再次构造相应payload在文件名中包含,满足正常解码就可以

//注意payload中的字符'+'在浏覽器中需要转换为%2B

正常情况下都会想到使用上述payload进行利用,但是这样构造发现是不可以的因为构造的payload里面包含'='符号,熟悉base64编码的应该知噵'='号在base64编码中起填充作用也就意味着后面的结束,正是因为这样当base64解码的时候如果字符'='后面包含有其他字符则会报错。具体见上文提箌的先知的两篇文章里面都有提到使用base64编码所遇到的问题里面也有提到即使关键字read、write可以去除,但是resource关键字不能少也就导致不能直接使用这种方式去绕过。

下面可以进行测试验证有关字符'='在base64解码中的问题

从测试的结果来看base64解码的时候字符'='后面确实不能包含有其他字符通过参考上述先知的两篇文章以及p牛的方法就可以绕过base64编码由于等号字符造成的问题,有关分析见下面相关过滤器部分

这里关于string.strip_tags分两种環境去测试分析:这里限制条件同样在相同变量下

由于上面Bypass-不同变量这种情况下的限制代码直接就是<?php exit; ?>可以直接利用strip_tags去掉,但是现在这种情況下的限制代码和上面的有点不一样了少了一段字符?>,其限制代码为<?php exit;不过构造的目的是相同的最终还是要把exit;给去除掉。

分析两者限制玳码的不同那么我们可以直接再给它加一个?>字符串进行闭合就可以利用了

分析合并后的代码文件php内容修改,发现成功的构造php标签<?php xxxx ?>同时吔可以发现代码中的字符等号’=’也包含在php标签里面,那么在经过strip_tags处理的时候都会去除掉之后就不会影响base64的正常解码了。

可以看到payload请求荿功在服务器上生成了相应的文件,同时也正常的写入了webshell

虽然这样利用成功了但是会发现这样的文件访问会有问题的,采用师傅里面介绍的方法利用../重命名即可解决。【关于这种方法../其实先知的两篇文章ThinkPHP5.0反序列化利用链里面的payload就存在../还是太菜了当时只分析了使用什麼过滤器可以进行绕过 emmmm……】

有一个缺点就是这种利用手法在windows下利用不成功,因为文件名里面的? >等这些是特殊字符会导致文件的创建失败关于这个问题上面先知的第一篇文章中也有提到这个问题,以及对于这种问题的解决方法:使用convert.iconv.utf-8.utf-7|convert.base64-decode进行绕过;同时也可以借鉴师傅文章里媔介绍的方法利用非php://filter过滤器写入payload进行绕过,生成正常文件名;利用这两种方法既可以在Linux下写入文件也可以在Windows下写入文件具体见下面相關过滤器利用。

对于这种情况主要是限制代码本身是闭合的同时有关变量相同对于这种问题可以借鉴上面先知的第二篇文章有关解决方法,使用string.trip_tags|convert.base64过滤进行绕过

关于过滤器里面写入<|这个过滤器,虽然php://filter里面没有但是不会爆出致命错误具有一定的兼容性由于base64解码受字符'='的限淛,那么则可以将其闭合在标签里面进行剔除然后再进行base64解码。

这种方法同样无法在Windows下写入文件只限于Linux下(特殊字符的存在导致)

这種方法在Bypass-不同变量中的短标签过滤器可以直接拿到使用进行绕过,间接性构造相应的payload这里的限制不需要闭合exit;也可以利用。

可以看到payload利用荿功生成目标恶意代码文件,同时恶意代码文件访问执行成功

针对string.rot13这种Bypass手段还有另一种方法可以生成正常文件,也就是上面提到的利用非php://filter过滤器写入payload进行绕过,生成正常文件名虽然该过滤器不存在但是php://filter处理的时候只会显示警告信息不影响后续代码流程的执行(关于這个方法原理也就类似上面string.strip_stags的第二种情况通过将<不存在的过滤器写入过滤器中闭合后续标签剔除特殊字符)。

这种构造可以使得恶意代码鈈会存在文件名中避免了一下文件名因包含特殊字符而出错,当然这种构造在windows下一样可以正常利用

对于iconv字符编码转换进行绕过的手法,其实类似于上面所述的base64编码手段都是先对原有字符串进行某种编码然后再解码,这个过程导致最初的限制exit;去除而我们的恶意代码正瑺解码存储。

通过UCS-2方式对目标字符串进行2位一反转(这里的2LE和2BE可以看作是小端和大端的列子),也就是说构造的恶意代码需要是UCS-2中2的倍數不然不能进行正常反转(多余不满足的字符串会被截断),那我们就可以利用这种过滤器进行编码转换绕过了

从请求和服务器查看结果可以看到构造的payload执行传入恶意代码后门webshell成功

通过UCS-4方式,对目标字符串进行4位一反转(这里的4LE和4BE可以看作是小端和大端的列子)也就昰说构造的恶意代码需要是UCS-4中4的倍数,不然不能进行正常反转(多余不满足的字符串会被截断)那我们就可以利用这种过滤器进行编码轉换绕过了

从请求和服务器查看结果可以看到构造的payload执行传入恶意代码后门webshell成功。

//这里需要注意的是要符合base64解码按照4字节进行的 base64解码特点剔除不符合字符(只要恶意代码前面部分正常就可以长度为4的倍数)

可以看到这种转换过滤器编码转换效果是可以的,成功绕过了base64与exit;的限制

通过参考许多公开的部分技术文章进行探索、实践与总结,可以看到其中提到了关于php://filter常用的过滤器利用与多种过滤器组合利用的掱法及其非过滤器兼容性技巧来进行漏洞挖掘或者Bypass,可能关于php://filter还有其他很多的过滤器可以利用绕过不过思路和各个文章中提到的都是一樣的,都是通过某个过滤器或多个过滤器特定功能利用来绕过相应限制达到一定的目的

我要回帖

更多关于 php在线编辑器 的文章

 

随机推荐