再看CVE-2018-12613 phpmyadmin后台文件包含&&RPO攻击

写在前面

因为看了朋友的一篇分析又回头想了想自己去年遇到的这个纠结的问题。

去年写过一篇phpmyadmin后台文件包含的文章,写的非常的草草,并没有分析的过程,只是把自己的问题记了下来。当时纠结于最后一步能通过两次urlencode问号就能再跨出路径了呢,

payload:

db_sql.php%253f/../../../../../../windows/system.ini  

回头来看其实很容易理解,之前也看到了一篇RPO攻击,里面的路径有点相似,也让我回头来,理解了这个payload。

当时虽然我放上来别人的图片作为我的问题的解答

其实当时看错了一个地方,导致最后的分析钻了牛角尖。

关键的代码在于最后第一个urldecode出了问题

$_page = urldecode($page);
  $_page = mb_substr(
           $_page,
            0,
            mb_strpos($_page . '?', '?')
        );
  if (in_array($_page, $whitelist)) {
            return true;
        }  

我们两次编码?后,浏览器解析一次%253f转化成%3f,然后这里又解析一次,转化成?,截断到前面的db_sql.php,使其符合了白名单。但是关键的是最后包含的是target,传入的参数,而不是两次urldecode的参数。

也就是包含的是

db_sql.php%3f/../../../../../../windows/system.ini  

为什么能包含成功呢。

这里的原理就是php将db_sql.php%3f 作为了一个目录,不管他是不是存在的,因为后面有../,会跨越到上级目录。

所以据我的分析,当php遇到这样的包含路径时,不会去检索这个目录是否会存在,只要后面存在../跨越目录,即直接包含后面的路径,直接将这个不存在的路径作为一个目录处理。

形象点比喻就是,执行者不管这个db_sql.php%3f是不是能走的路,他看到了../,他就不会走进这条路,直接按着接下来的路继续走(../../../../etc/passwd)。

再讲的能够理解点就是执行者将db_sql.php%3f/../看作了一个整体,看到了../,他就不管db_sql.php%3f是不是条路了。

这里实验如下,uploads/test.php  上层目录test.txt

其实就是将souce.php%3f作为了目录而已,进入然后跨两层就到了上层,然后读到test.txt

include fuzz

文件夹A中有a.php,b.php,上层目录B中有echoa.php

echoa.php
<?php
$a='php_test_heihei';
?>
a.php
<?php
include "b.php/../../echoa.php";
echo $a;  

测试特殊字符串:!@#$%^&*()-_ []{}<>~`+=,.;:/?|"' 

fuzz发现,只有出现?或者*时候,include会包含错误,输出不了$a。

其他的拼接特殊字符均可以完成目录穿越。include到echoa.php

结束

RPO攻击

是暑假时候通过郁离歌强网杯的WP了解到的RPO攻击,忘记写了,这里补上。

这里简单概述下记录下,Freebuf有篇讲的很详细的,放在文章下方链接处l。

什么是RPO?

RPO (Relative Path Overwrite)相对路径覆盖,作为一种相对新型的攻击方式,由 Gareth Heyes在2014年首次提出,利用的是nginx服务器、配置错误的Apache服务器和浏览器之间对URL解析出现的差异,并借助文件中包含的相对路径的css或者js造成跨目录读取css或者js,甚至可以将本身不是css或者js的页面当做css或者js解析,从而触发xss等进一步的攻击手段。

在什么情况下漏洞会触发

触发这个漏洞有两个基本的前提:

①Apache 配置错误导致AllowEncodedSlashes这个选项开启(对Apache来说默认情况下 AllowEncodedSlashes 这个选项是关闭的),或者nginx服务器。

②存在相对路径的js或者css的引用

第一个场景:加载任意目录下静态资源文件

对于第一个场景,服务端对url的解析,将%2f自动解码为/。而浏览器对url的解析,不认得%2f,服务器返回的页面后,在加载相对路径下的js时,浏览器将..%2f..%2fxxx当作一个文件,而不会解析为路径,所以链接到相对路径的js文件时,会跨目录,链接

第二个场景:将返回内容按静态文件解析(需要url-rewrite)

对于第二个场景,比如访问/index.php/view/article/98749/..%2F..%2F..%2F..%2Findex.php,服务器解析url,请求的时index.php,index.php下有一个外部脚本js链接,scr=1.js。客户端解析后,将..%2F..%2F..%2F..%2Findex.php当作一个文件,然后在当前目录链接1.js,即链接/index.php/view/article/98749/1.js(然而这是个98749.html文件,这里我的理解是,直接将这个页面当作1.js解析),并且不需要script标签,直接作为外部引入的js文件处理。因此可以结合xss漏洞利用。

 

参考链接:

https://www.freebuf.com/articles/web/166731.html

原文地址:https://www.cnblogs.com/BOHB-yunying/p/11799079.html