¿Cuál es el siguiente paso de este ataque de carga de archivos?

15

Ayer descubrí que alguien había subido este código PHP a mi servidor como un archivo .jpg a través del formulario "Sube su imagen de perfil" de la aplicación MVC de asp.net. Creo que el ataque no tuvo éxito por varias razones (a las imágenes se les asignan nombres de archivo aleatorios, luego se les cambia el tamaño y se almacenan en un directorio que no se ejecuta). El archivo quedó sobrante porque no pude limpiar el archivo temporal si falló el cambio de tamaño, que ahora he corregido.

Pero me preocupa que no entiendo cuál sería el siguiente paso de este ataque ... Supongamos que ha subido con éxito un archivo .jpg que tenía un código PHP malicioso en mi servidor de Windows / IIS, y Conocía la URL del archivo. ¿Ahora que? Necesitaría que IIS interpretara ese archivo .jpg como código PHP en lugar de una imagen, ¿verdad? ¿Cuál podría haber sido su plan para lograr eso?

Lo único que se me ocurre es que si se tratara de un servidor apache y los archivos .php se filtraran pero los archivos .htaccess no lo estaban, tal vez podría haberlo logrado. ¿Hay algún enfoque equivalente que podría haber funcionado en IIS?

    
pregunta Jared Phelps 13.03.2013 - 19:27
fuente

3 respuestas

13

Un camino posible sería intentar que se incluya de alguna manera. Una gran cantidad de marcos complementarios pueden ejecutar un archivo de código PHP arbitrario. Si el atacante pudiera encontrar dicho marco complementario, podría asignarle la ruta al archivo y se ejecutaría como PHP independientemente de la extensión del archivo.

    
respondido por el AJ Henderson 13.03.2013 - 20:37
fuente
1

Es un guión interesante que encontraste allí. Una cosa que noté es que aparentemente servirá imágenes, si has registrado mod-php para manejar archivos .jpg:

No tengo idea de para qué está esta imagen, pero es una característica interesante.

De todos modos, el script parece ser un shell remoto. Estoy en desacuerdo con Manishearth en casi todos los puntos. AJ Henderson tiene una respuesta mucho mejor: no importa cuál sea la extensión del archivo o dónde esté almacenado, PHP intentará ejecutarlo si se le indica. Si el atacante puede controlar la ruta a un archivo incluido, entonces el atacante puede ejecutar este script.

    
respondido por el Mark E. Haase 14.03.2013 - 16:35
fuente
1

Siempre que tenga control sobre el nombre del archivo y dónde está almacenado 1 , no es un problema. Básicamente, podrían intentar reemplazar un archivo php existente, de modo que la próxima vez que se ejecute, su código se ejecute en su lugar.

Otro truco que podrían intentar es forzar a su servidor a ejecutar el archivo. PHP se ejecuta con permisos que un hacker no puede obtener a través de HTTP normal. El atacante podría cargar foo.php , y su servidor lo moverá a images/foo.php . Ahora, el atacante visita la página. Esto se puede evitar controlando el nombre del archivo (nuevamente) y / o configurando su .htaccess para deshabilitar PHP en su directorio de imágenes.

Debe tener especial cuidado con esto cuando su sitio tenga el formato donde se mostrará o incluir 'abc.php' en una página del formulario run.php?name=abc.php . En tal caso, mantenga las restricciones en el parámetro GET para que solo puedan ejecutarse ciertos archivos. Esto se aplica a cualquier parte de su aplicación que incluya o ejecute algún archivo PHP basado en la entrada del usuario. Examine estos y asegúrese de que el usuario no pueda forzar al sistema a ejecutar un archivo que no sea el que desea ejecutar.

1 Esto incluye evitar que guarden el archivo como ../../foo.jpg o (shudder) ../index.php

    
respondido por el Manishearth 13.03.2013 - 20:49
fuente

Lea otras preguntas en las etiquetas