http://wonderkun.cc/index.html/?p=626
0x00 前言
做了一个CTF题目,遇到了一些有趣的东西,所以写了这篇文章记录了一下。 但是我却不明白造成这个问题的原因在哪里,所以不知道给文章起什么标题,就姑且叫这个非常宽泛的名字吧。
0x01 CTF题目原型
在遇到的题目中,最后一步是getshell,大概可以简化为以下代码:
|
我把这个问题发到phithon的代码审计圈里征求答案,师傅们的答案都在理,但是却不是我想要的那个答案,下面就来一一的分析以下。
0x02 一些不完美的做法
我最开始的想法跟大多数师傅的想法一样
|
在我本地测试一下,一切都是那么的美好,轻松getshell:
我本地的环境是 mac默认安装的apache+php。
当我在ubuntu上测试的时候傻眼了,
ubuntu上的apache并没有把这个文件当做php文件来解析。这到底是为什么呢?这里先留个坑,一会仔细讲。
这种方法不行之后,很快就有人想到了,会不是是apache2的文件解析漏洞呢?然后我就在ubuntu上测试了一下
apache的版本是2.4.7,并不存在解析漏洞。
然后我又在本地测试了一下。
What fuck!!! 我的本地竟然存在php文件解析漏洞,这笔记本是假的吧,装的apache也是假的吧。版本都是2.4.25了怎么还会存在文件解析漏洞呢?
在我的印象中apache的文件解析漏洞是在2.3.x以下版本才会存在的啊?这到底是为什么?
之后朋友又给我发来了一张图片,我当时就炸毛了,他的版本是2.4.18,并不存在漏洞。我觉得我这apache可能是假的。
经过冷静的思考,我得出结论:Apache文件解析漏洞,可能与apache的版本并没有关系,而是与apache解析php的配置相关。
0x03 再提apache的文件解析漏洞
apache的文件解析漏洞正火的时候,我还没上大学呢,所以也没有真正的去分析产生这种漏洞的原因,一直模糊的认为这是apache本身的问题:Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。
所以我以为apache后来已经修复了这个bug了,不会再出现文件解析漏洞了。
经过比对,我发现我本地mac上的php5.conf是这样写的:
|
而ubuntu上的php5.conf是这样的:
|
看ubuntu的配置
<FilesMatch
".+\.ph(p[345]?|t|tml)$"
>
|
这个正则和题目中的正则是一样的,很容易明白,当文件名和这个正则匹配上之后,就交给mod_php处理。
这就解释了为什么233%0a.php
不会被解析的。
还有下面这段,也禁止解析以.
开头的php文件执行的:
|
所以我觉得产生文件解析漏洞的根源是这句话:
AddType application
/x-httpd-php
.php
|
为了验证我的想法,我把这句修改为下面这样,然后重启apache
AddType application
/x-httpd-php
.phtml
|
在这种情况下.php后缀已经不再被解析了,而被解析的是.phtml和.phtml.xxxxxxx
所以这样的错误配置才是引起apache 解析漏洞的关键。
最后感悟:无论是apache文件解析漏洞还是nginx文件解析漏洞,本来都不应该是apache,nginx 或者php的锅,它们有的只是功能,而且开发这些功能也是为了方便使用者,而恰好这些功能恰好被一个管理员用在了不恰当的时候,所以才造成了漏洞。
0x04 回到题目中
经过测试发现一个可以再windows和linux上都行得通的方法:
filename=1.php/.&content=<?php phpinfo();?>
|
在操作系统中,都是禁止使用/
作为文件名的,但是不知道为什么后面加一个.
就可以成功的写入1.php了。
而且奇怪的是无论是在windows上还是linux上,每次都只可以创建新文件,不能覆盖老文件。要想知道php里面是怎么处理这个路径的,就需要看php源代码了,但是我目前并没有看明白里面的处理逻辑,等我抽个时间分析完了,再做补充吧。