Insecure Deserialisation
TASK 4
Vamos a ver formas de identificar si la web es vulnerable a ataques de serializacion o no , ya sea de caja blanca o caja negra(teniendo el codigo fuente o no).
Teniendo el codigo fuente(caja blanca):
Sin tener codigo fuente (caja negra):
Lo primero que nos piden es que accedamos a la siguiente web:
Y saquemos el nombre de la funcion , para ello utilizaremos el caracter "~" al final de la ruta :
Y asi recuperamos un backup del archivo antes de ser serializado.
TASK 5
Lo primero sera acceder a la web:
Luego vamos a ver el codigo empleado :
Vemos como tenemos una clase notes , con 3 propiedades , y luego se utiliza setter y getter para operar con $isSubscribed
Asi que lo siguiente que haremos es acceder a la web y ver las cookies almacenadas:
Cogemos el valor que esta en base64 y lo descodificamos:
Aqui se explica los apartados del texto deserializado:
Asi que lo que habria que hacer es cambiar el valor de isSubscribed a 1 , volverlo a codificar en base64 y modificarlo en la cookie:
Donde he señalado con la flecha es donde habria que cambiar el valor de la cookie para modificar la web. Nos piden tambien el rol del usuario al entrar a la app , y como vemos en el mensaje antes de ser serializado vemos que es guest:
TASK 6
Primero accedemos a la web que nos dice thm:
Y tras revisar el codgio fuente vemos que hace referencia a una pagina llamada test.php:
Y el contenido de test.php es :
Como podemos ver esta ejecutando una conexion con ncat , asi que lo que haremos ahora sera crear un archivo con la misma clase pero con una reverse shell a nuestro equipo para cuando deserialicemos se ejecute ese comando y nos genere la reverse.El ejemplo seria este:
Este archivo ademas si se ejecuta te serializa la clase al ejecutarlo en base64. que sera lo que tendras que mandarle a traves de la url al equipo que quieras atacar. Vamos a empezar generando el archivo y su base64:
Como podemos ver a continuacion tras escribir este base64 en la url y volvernos al listener que habiamos creado vemos como tenemos una shell:
TASK 7
Comenzamos descargando la herramienta phpggc que es un script automatizado para buscar vulnerabilidades de serializacion , la bajaremos del siguiente repositorio:
Una vez dentro de la carpeta ejecutamos ./phpggc -l para verificar que esta bien instalado y asi ver que gagdets estan instalados:
La misma room nos dice que la web utiliza laravel 5.6.29 asi que vamos a utilizar phpggc para generar un payload. Para ello primero accedemos a la siguiente web donde obtendremos el app-key:
Una vez tenemos el app key vamos a buscar un payload compatible con Laravel:
Para nuestro caso vamos a utilizar RCE3 , asi que generamos el payload con el siguiente comando:
Y asi tendriamos nuestro payload en base 64.En las cookies tambien podemos ver el XSRF Token y la sesion:
Primero nos piden el comando utilizado para explotar el CodeIgniter4/FR1:
Ahora ya si por fin nos vamos a la web que nos propone tryhackme para conseguir el payload ultimo:
Y una vez tenemos el payload lo enviamos a traves de curl al servidor:
Y vemos como el usuario es root.
Ahora vamos a hacer lo mismo pero con el comando uname -r , para ello primero generamos el payload con el phpggc:
Una vez generado nos vamos a la web donde cogimos el payload ultimo anterior y modificamos el parametro payload por el payload que acabamos de generar:
Lo cogemos lo copiamos y ejecutamos el mismo comando que en el apartado anterior:
05.4.0-1029-aws seria la respuesta , asi que podemos deducir que el sistema operativo se esta ejecutando en la nube de amazon (aws).
TASK 8
Vamos a ver formas de mitigar esta vulnerabilidad:
Last updated