BlogHacking Web Apps

Cómo: explotar la inclusión de archivos PHP en aplicaciones web

La inclusión de archivos puede permitir que un atacante vea archivos en un host remoto que no deberían poder ver, e incluso puede permitir que el atacante ejecute código en un objetivo.

Para demostrar estas vulnerabilidades, practicaremos la inclusión de archivos PHP utilizando el Maldita aplicación web vulnerable. Cubriremos cómo funcionan tanto la inclusión de archivos remotos como la inclusión de archivos locales con el objetivo de lograr acceso de shell al host vulnerable.

En nuestro primer ejemplo, veremos una inclusión de archivo local (LFI). Este tipo de inclusión de archivos incluye archivos presentes en el host remoto. Se puede usar para ver archivos de configuración, buscar documentos interesantes y obtener un shell con pocos privilegios. Este tipo de inclusión está presente en PHP, JSP, ASP y otros lenguajes.

En nuestro segundo ejemplo, analizamos la inclusión de archivos remotos (RFI). Es esencialmente el mismo concepto, con la diferencia de que el atacante no está limitado por lo que está disponible para él en el host remoto. Un atacante puede incluir archivos directamente desde su máquina para que los ejecute el host remoto. Este tipo de inclusión también está presente en muchos lenguajes de programación.

Inclusión de archivos locales

La inclusión de archivos locales le permite leer archivos en el host vulnerable y, si tiene la capacidad de modificar archivos en el host local, ejecutar código también. Por ejemplo, usaré la aplicación web Damn Vulnerable, o simplemente DVWA para abreviar, ejecutándose en una máquina virtual en mi red local. Las instrucciones completas para hacerlo se pueden encontrar en Página de GitHub de DVWA.

Paso 1: Pruebe el LFI

En este escenario básico de LFI, usaremos una inclusión de archivo local para recopilar información sobre el host remoto y luego explotar una vulnerabilidad que nos permite obtener un shell raíz. A continuación se muestra la página predeterminada “Inclusión de archivos” en DVWA, que se puede encontrar en el menú de la izquierda.

Primero, probaré para ver si puedo leer un archivo común como / etc / passwd. Para hacerlo, ingresé suficientes directorios anteriores para volver a la raíz, luego ingresé la ruta para / etc / passwd. La parte? Page = que se ve a continuación normalmente apuntaría a file1.PHP.

En este caso, usamos el recorrido de directorio para acceder al archivo / etc / passwd. En la mayoría de los sistemas operativos, .. representa el directorio anterior. Dado que en realidad no sabemos de qué directorio está leyendo archivos la aplicación, le decimos a la aplicación que regrese a un montón de directorios y luego a / etc / passwd.

Como era de esperar, puedo recuperar el archivo / etc / passwd. Por supuesto, esto no se limita a usar solo en / etc / passwd, esto se puede usar para recuperar cualquier archivo en el que el usuario de la aplicación web tenga privilegios de lectura.

Vamos a desglosarlo un poco más con una ruta de ejemplo. Este es el directorio de trabajo de nuestra aplicación ficticia:

/ var / www / cgi-bin / things /

Cuando se le pasa un parámetro como? Page = file1.php, busca en su directorio de trabajo para cargar file1.PHP. Cuando ejecutamos estos ataques, en realidad no conocemos el directorio de trabajo de la aplicación; podría estar enterrado en lo más profundo de un árbol de directorios o podría estar en el directorio de inicio de un usuario. Así que queremos estar seguros de que nuestra ruta incluye suficientes directorios anteriores para volver al directorio raíz, lo que puede ser un juego de adivinanzas.

../../../../../../../../../../../../../../etc/passwd

En esta ruta relativa, tengo un total de 14 directorios anteriores. Esta bien. Se ignoran todos los directorios anteriores más allá del directorio raíz del sistema de archivos. Esta ruta vuelve al directorio raíz y, desde allí, a / etc / passwd.

Esto es increíblemente útil para escenarios en los que necesita leer archivos de configuración. Algunas LFI funcionarán cuando no haya iniciado sesión en la aplicación, y puede encontrar nombres de usuario y contraseñas u otra información útil en los archivos de configuración.

Ahora que sabemos que un archivo local incluye trabajo en esta aplicación, ¿cómo recuperamos un shell?

Paso 2: inyectar código

En este caso, tomaré la ruta fácil e insertaré el código de mi shell en los archivos de registro, luego accederé a él con la aplicación web. Primero, verifico que puedo acceder a los archivos de registro. En algunos casos, es posible que no se puedan leer.

Si hemos realizado nuestro reconocimiento inicial, tendremos una idea de a qué tipo de sistema nos enfrentamos, incluido el tipo de servidor web que está ejecutando el host. Armados con este conocimiento, podemos determinar la ruta de los archivos de registro.

En este ejemplo, tenemos un servidor Apache y la ubicación predeterminada para los registros de Apache es / var / log / apache2 / o / var / log / apache. Como podemos ver a continuación, he incluido correctamente el registro de acceso de Apache en la página.

A continuación, verificamos la ejecución del comando. Usando Netcat, me conecto a mi servidor web y envío un código PHP.

nc 192.168.1.111 80

Lo que estoy haciendo aquí es enviar código PHP directamente al servidor web. Esto no es lo que Apache espera de una solicitud HTTP, y el servidor devuelve el error 400 pero registra la solicitud en /var/log/apache2/access.log. Esto me permitirá volver a leer el archivo de registro utilizando la aplicación web, que ejecutará cualquier PHP que encuentre.

Ahora, tengo PHP en el archivo de registro para ejecutar una lista de directorios. Veamos si funcionó:

Puedo ver debajo que el ls El comando funcionó: mi código se ejecutó en el host remoto. Incluimos el archivo de registro de Apache en la aplicación, luego PHP lee el archivo de registro e imprime el contenido del texto en la parte superior de la página. Cuando el intérprete de PHP golpea nuestro código para ejecutar ls en el sistema, lo ejecuta.

He resaltado la parte donde se ejecutó nuestro código; el resto del texto es solo el archivo de registro de Apache. Tenemos RCE, lo que significa que estoy a un paso de un caparazón.

Paso 3: consigue un caparazón

Ahora que podemos verificar nuestro acceso, necesito conseguir un caparazón. Me conectaré de nuevo con Netcat, pero esta vez mi PHP shell_exec () contendrá el comando para una conexión Netcat inversa. Aquí es donde puede volverse complicado. Si Netcat no está instalado, no obtendrá un error, simplemente no obtendrá una conexión. En algunos casos, tienes que ser complicado con tus caparazones. Afortunadamente, hay muchas opciones disponibles para recuperar shells de un host Linux.

Para empezar, escribiré lo siguiente en una ventana de terminal.

nc 192.168.1.111 80

En este comando, establezco una conexión Netcat básica con el host vulnerable en el puerto 80. Luego envío código PHP que le dice al intérprete PHP que ejecute Netcat. El shell_exec () La función en PHP ejecuta un comando a través de un shell del sistema y devuelve una cadena.

El comando que queremos que PHP ejecute es el argumento de la función, específicamente diciéndole a Netcat que se conecte a mi máquina en el puerto 31337. El -mi La opción le dice a Netcat que ejecute Bash. Puede utilizar cualquier puerto al que tenga permiso para vincularse. El PHP se inyecta en el archivo de registro al igual que el PHP para nuestro ls mando.

Para capturar el shell entrante, necesitaremos ejecutar lo siguiente en una ventana de terminal en nuestra máquina atacante.

nc -nlv 31337

Este comando ejecutado en mi máquina atacante le dice a Netcat que configure un oyente en el puerto 31337. El -norte El argumento especifica que Netcat no debe intentar buscar direcciones con DNS, el -l El argumento le dice a Netcat que escuche, y el -v El argumento establece el modo detallado.

La próxima vez que accedo al archivo access.log, la aplicación web ejecuta el código que contiene y me devuelve un shell inverso.

A partir de aquí, hay muchos caminos por recorrer. Generalmente, comenzaría a buscar en el sistema y buscar oportunidades para escalar privilegios. Esta máquina podría convertirse fácilmente en parte de una botnet o usarse como caja de salto. Un atacante también podría agregar fácilmente puertas traseras a la propia aplicación web.

Inclusión de archivos remotos

La inclusión remota de archivos es aún más fácil si está disponible. Esta técnica le permite incluir archivos de su propia máquina o host remoto. Para este ejemplo, voy a omitir las etapas de prueba y solo incluiré mi código PHP para un shell inverso de Netcat.

Paso 1: iniciar un servidor

Primero, necesitaré habilitar mi servidor web. Para los usuarios de Kali Linux, puede escribir lo siguiente en una ventana de terminal.

systemctl iniciar apache2

Paso 2: configura tu código

Usaré el mismo código PHP que usé anteriormente para enviar un shell a mi máquina. Agrego el código a un archivo llamado shell.html, aunque, como ha visto, esta aplicación en particular incluirá casi cualquier archivo con PHP. Podríamos obtener el mismo resultado con shell.PHP o shell.log. Solo necesitamos poner una línea de PHP en este archivo, que el intérprete leerá y ejecutará.

Luego muevo ese archivo a mi raíz web, que para los usuarios de Kali Linux debería estar ubicado en / var / www / html /.

Paso 3: configurar un oyente de Netcat

A continuación, configuro un oyente Netcat en mi máquina atacante escribiendo lo siguiente en una ventana de terminal.

nc -nvl 31337

Este es solo un oyente estándar, el -norte El argumento le dice a Netcat que no resuelva los nombres de host, -v argumento es para verboso, y el -l El argumento es para escuchar. El último argumento es el puerto para escuchar.

Paso 4: incluye tu código

Por último, es hora de que incluya el archivo en la aplicación vulnerable.

La aplicación web ejecuta el código PHP en shell.html y, como podemos ver a continuación, mi oyente Netcat está conectado al host remoto. Tengo una cuenta de usuario con pocos privilegios (www-data) y puedo interactuar con el sistema a través de la línea de comandos.

Algunas advertencias para la inclusión de archivos

Este artículo cubre los conceptos básicos de las inclusiones de archivos locales y remotos. En algunos casos, estas vulnerabilidades pueden ser más difíciles de explotar en la naturaleza. Es posible que deba terminar los nombres de archivo con bytes nulos o incluso escapar de las barras en su ruta. Todo depende de cómo el código en el back-end esté analizando la entrada. Incluso si la vulnerabilidad es más difícil de explotar, sigue siendo un fruto al alcance de la mano.

Si tiene alguna pregunta o comentario, envíelos a mi manera en los comentarios a continuación o en @ 0xBarrow en Twitter.

Imagen de portada de markusspiske / Pixabay; Capturas de pantalla de Barrow / Null Byte

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Mira también
Cerrar
Botón volver arriba
Cerrar