php://filter过滤器的奇妙操作
前言
在一个Laravel Debug RCE(CVE-2021-3129)利用中看到的奇妙操作,通过php://filter过滤器配合文件写入读取操作,去除文件中的多余字符,很有意思。
phar
一个phar文件要满足什么条件才能正常地触发反序列化?
翻一翻php源码,在phar.c中找到phar解析函数phar_parse_pharfile,第一个条件:
1 |
|
可以看到,php会搜索stub中的:
1 |
|
标识作为phar文件的开头,在实际测试中如果存在多个标识,则会选择最后一个,所以phar文件前面部分有冗余数据并不影响,后面就是一个完整的phar文件。
再看看phar文件后面部分存在冗余数据会不会影响,再看后面的代码:
1 |
|
这里会读取最后的8个字符,限制了必须以GBMB这个标识结束,所以后面就不能存在一些乱七八糟的冗余数据了。
经过测试,在phar压缩包的内部文件数据部分加上些奇奇怪怪的数据并不会影响phar反序列化。
场景
原场景中的处理代码如下:
1 |
|
简单来说就是读取某个文件中的内容,处理之后又放了回去,期间就可以通过php://filter对文件内容进行编码方面的修改。
read/write
用于标识文件操作类型的标识,类似:
1 |
|
在标识为write的情况下,file_get_contents这种文件读操作就不会触发编码转换,所以就可以在不影响读出数据的情况下对写入的数据进行修改。
Base64编码
先看一眼php进行base64解码的相关代码,找到base64.c,这里首先设置了一张base64码表:
1 |
|
然后
1 |
|
解码时的第二个参数代表是否开启strict模式(默认不开启),此时会跳过空格和非法字符。
而开启之后,解码过程中只会跳过空格,而遇到非法字符(或者=后面还有其他字符)则会终止解码。
实际上php://filter会进行的base64解码却有些许不一样,找到filter.c,同样先是一个类似的码表:
1 |
|
其中一段处理代码则如下:
1 |
|
这里的变量命名比较奇特,ustat看起来用于标识是否识别到了padding(即=),当识别到合法字符则会进入上面的判断,如果上个字符为=则会判断为解码失败而结束解码。
一般情况下如果识别到了非法字符或者=,则会跳过。
所以虽然可以通过多次解码跳过非法字符来清除冗余字符,但是其中还是存在问题的,如果多次解码中出现了=,而且=后面还存在合法字符则会发生错误。
UTF编码
既然base64不是很好用,那么就需要找到另一种更方便去除冗余字符的编码方式了,比如UTF-8和UTF-16le。
UTF-8大家都知道是什么,UTF-16le用两个字节表示UTF-8中的一个字节(所以需要让冗余字符数为偶数),对我们常用的字母和符号来说就是在UTF-8的字符后面加多一个\x00。
它们之间的转换一般不会发生错误(字符数为奇数时会发生错误),同时一般可写文件也不会存在\x00这种奇怪字符,所以通过这两种编码之间的编码转换就可以将文件中原本存在的字符转化为base64中的非法字符,再结合base64解码就可以去除冗余字符。
quoted-printable
一种看起来不是很有用的转码,能够将不可见字符替换成=xx的形式,可以用来处理一些特殊字符。
CVE-2021-3129
总之先搭个环境,因为我只是对其中一部分感兴趣,所以根据参考文章简单弄一个,去下载一个别人搭建好的环境,然后用docker-compose启动。
先简单看看它的报错日志,有点长:
1 |
|
调用file_get_contens读文件时,因不存在的文件名报错后会将文件名会写入日志中,一共会写入三处,因为第三处会将超出长度上限的内容省略,所以这里可以控制的内容为两处,它们前后都存在一些冗余字符。
正确操作应该是运用前面提到的多种转码手段,quoted-printable用于解决文件名无法存在\x00的问题(UTF-16le需要用到),UTF-16le用于解决base64解码会因为=出现错误的问题,base64解码用于去除冗余字符。
具体的操作流程应该如下:
- 通过base64解码和write标识符,利用解码失败解码结果为空的特性清空整个log(可跳过),如果清空不了可以和convert.iconv.utf-16le.utf-8一起用
- 加上15个字符的前缀发送poc
- 发送一个数据包,用于保证UTF-16le转码时字符数为偶数
- 按顺序解码去除冗余字符
- 触发phar反序列化
此时会解码出两段poc,可以通过添加后缀也可以通过修改phar数据的方式来完成反序列化。