php 操作系统之间的一些黑魔法(绕过文件上传a.php/.)

http://wonderkun.cc/index.html/?p=626

0x00 前言

做了一个CTF题目，遇到了一些有趣的东西，所以写了这篇文章记录了一下。 但是我却不明白造成这个问题的原因在哪里，所以不知道给文章起什么标题，就姑且叫这个非常宽泛的名字吧。

0x01 CTF题目原型

在遇到的题目中，最后一步是getshell，大概可以简化为以下代码：

<?php
 
// 测试环境 linux + apache2  + php
// 没有开rewrite ，所以写 .htaccess 没用
// 没有用cgi ，所以写 .user.ini 也没有
// 要求 getshell
// 修改配置文件，crontab之类的都是没权限的。
 
$content = $_POST['content'];
$filename = $_POST['filename'];
$filename = "backup/".$filename;
 
if(preg_match('/.+\.ph(p[3457]?|t|tml)$/i', $filename)){
   die("Bad file extension");
}else{
    $f = fopen($filename, 'w');
    fwrite($f, $content);
    fclose($f);
}
?>

我把这个问题发到phithon的代码审计圈里征求答案，师傅们的答案都在理，但是却不是我想要的那个答案，下面就来一一的分析以下。

0x02 一些不完美的做法

我最开始的想法跟大多数师傅的想法一样

因为正则表达式中的点（.）不会匹配换行符（0x0a），所以可以在扩展名前面插入一个换行符，构造的文件名为233%0a.php，
这样就可以绕过正则，而且还是合法的文件名(linux允许这样的文件名存在，而windows是不允许的)。

在我本地测试一下，一切都是那么的美好，轻松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是这样写的：

➜  ~ cat /private/etc/apache2/other/php5.conf
<IfModule php5_module>
    AddType application/x-httpd-php .php
    AddType application/x-httpd-php-source .php
    <IfModule dir_module>
        DirectoryIndex index.html index.php
    </IfModule>
</IfModule>

而ubuntu上的php5.conf是这样的：

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+\.phps$">
    SetHandler application/x-httpd-php-source
    Order Deny,Allow
    Deny from all
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(p[345]?|t|tml|ps)$">
    Order Deny,Allow
    Deny from all
</FilesMatch>

看ubuntu的配置

这个正则和题目中的正则是一样的，很容易明白，当文件名和这个正则匹配上之后，就交给mod_php处理。

这就解释了为什么233%0a.php不会被解析的。

还有下面这段,也禁止解析以.开头的php文件执行的：

<FilesMatch "^\.ph(p[345]?|t|tml|ps)$">
    Order Deny,Allow
    Deny from all
</FilesMatch>

所以我觉得产生文件解析漏洞的根源是这句话：

为了验证我的想法，我把这句修改为下面这样，然后重启apache

在这种情况下.php后缀已经不再被解析了，而被解析的是.phtml和.phtml.xxxxxxx

所以这样的错误配置才是引起apache 解析漏洞的关键。

最后感悟：无论是apache文件解析漏洞还是nginx文件解析漏洞，本来都不应该是apache，nginx 或者php的锅，它们有的只是功能，而且开发这些功能也是为了方便使用者，而恰好这些功能恰好被一个管理员用在了不恰当的时候，所以才造成了漏洞。

0x04 回到题目中

经过测试发现一个可以再windows和linux上都行得通的方法：

在操作系统中，都是禁止使用/作为文件名的，但是不知道为什么后面加一个.就可以成功的写入1.php了。

而且奇怪的是无论是在windows上还是linux上，每次都只可以创建新文件，不能覆盖老文件。要想知道php里面是怎么处理这个路径的，就需要看php源代码了，但是我目前并没有看明白里面的处理逻辑，等我抽个时间分析完了，再做补充吧。