Laboratorio: carga de shell web mediante recorrido de ruta
PreviousLaboratorio: carga de shell web mediante omisión de restricción de tipo de contenidoNextLaboratorio: carga de shell web mediante omisión de la lista negra de extensiones
Last updated
Last updated
En este caso como vemos el server de la aplicación está configurado para evitar la ejecución de archivos proporcionados por el usuario, nada de scritps ni nada por el estilo, sin embargo podemos hacer algo al respecto y es que el sitio web es vulnerable al path traversal, así que vamos a ver que podemos hacer.
Aqui terminamos de entender lo que estabamos apuntando, las paginas si no lo validan a la final lo toman como un texto plano sin formato.
14 Horas después, ya encontré cual es el vector de ataque por el cual podemos encaminar la subida del xploit sin que hayan controles estrictos de subida, en la pagina de portswigger hay una cascarita cuando hablan, la cual es:
Si puede encontrar una manera de cargar un script en un directorio diferente que no debe contener archivos proporcionados por el usuario, el servidor puede ejecutar su script después de todo.
Simplemente subimos el PHP pero lo modificamos con el path traversal, con tan solo una movida antras de directorio ../ Y listo solo sería así directamente.
Anteriormente si subiamos meramente el exploit entonces quedaba en el directorio files/avatar/ alli ese directorio si validaba el control estricto, sin embargo yendonos un directorio atrás ../ en /files/ allí pudimos subir exitosamente el xploit.php y que se ejecutará normal para poder mostrar el SECRET
Siuuu, lo solucioné.
