Carga de archivos no restringida - Posibles vulnerabilidades

3

Durante una prueba de penetración (ejercicio) en un servidor web IIS + MYSQL DBMS, encontré una vulnerabilidad de carga de archivos sin restricciones para la cual puedo cargar un archivo .php.

Así que he intentado cargar un shell php usando un comando passthru o exec pero he recibido la famosa respuesta "No se puede bifurcar ..." porque, por lo que entiendo, la carpeta en la que Cargar el archivo tiene algún tipo de protección de seguridad que evita la ejecución de comandos.

Sin embargo, he subido un archivo .php para leer un archivo de muestra con el comando fopen , fread , etc. y lo he hecho con éxito.

Entonces mi pregunta es: ¿Qué archivos específicos puedo leer para obtener información confidencial de cualquier tipo? En otras palabras: puedo cargar un archivo php que pueda mostrar el contenido de un archivo, pero no sé qué archivos debo buscar.

Pregunta final: ¿Conoce otros métodos de explotación para la vulnerabilidad de carga de archivos sin restricciones si no está permitido cargar un shell como el anterior?

    
pregunta ibrahim87 18.12.2013 - 19:51
fuente

2 respuestas

2

Los archivos específicos que buscaría serían:

  1. php.ini
  2. páginas PHP
    • Es muy probable que estas tengan credenciales incrustadas para el acceso a la base de datos o te darán pistas sobre dónde buscar a continuación.
  3. mi.cnf
    • archivo de configuración de MySQL
  4. web.config
    • Puede haber algunas configuraciones útiles en IIS que se pueden recuperar al revisar este archivo.
  5. máquina.config
    • Igual que web.config pero a nivel de máquina.
  6. archivos de caché
    • Podría haber algunos datos interesantes en la carpeta temporal.

Esos son los que puedo pensar: una vez que empieces a investigar estos archivos, es probable que surjan otras ideas.

  

Pregunta final: ¿conoce otros métodos de explotación para la vulnerabilidad de carga de archivos sin restricciones si no está permitido cargar un shell como el anterior?

  1. Puede intentar cargar un archivo que se ejecutará en el próximo reinicio o colocarlo en una ubicación donde un administrador pueda ejecutar el archivo accidentalmente.
  2. Puedes realizar un ataque de DOS agotando el espacio en disco en la caja.
respondido por el jamiescott 27.12.2013 - 23:27
fuente
0

Hay algunos escenarios de ataque posibles en los que puedo pensar ...

Atacar al servidor:

Como ya se mencionó, puede usar PHP para abrir / leer otros archivos en el sistema que puedan otorgar credenciales, o guiarlo en la dirección de otros vectores de ataque.

A pesar de que la vulnerabilidad de carga coloca el archivo malicioso en un directorio específico que puede contener ciertas características de seguridad, esto no siempre evita que el script malicioso escriba un nuevo archivo en el directorio principal.

Puede usar el script para ver quién se está ejecutando, verifique los permisos de otras carpetas en el sistema para ver si ese usuario puede escribirlos.

Otro ataque obvio sería acceder a la base de datos mediante el método de escaneo de scripts y archivos de configuración para obtener credenciales. Con esta base de datos, puede descifrar la contraseña o compararla con una tabla de arco iris si no está salada.

Si puede leer y escribir en otros scripts en el servidor web, podría crear una copia de seguridad del código con la esperanza de recopilar la contraseña de administrador en texto sin formato en lugar de tener que forzar las contraseñas en la base de datos.

Atacando al usuario:

Una de las mayores preocupaciones con este tipo de vulnerabilidad es que puede ejecutar código en el servidor como servidor. Esto le da acceso a las cookies de los usuarios de ese sitio, que pueden contener información valiosa, lo que posiblemente lleve a una sesión secuestrada.

También existe la amenaza de que el sitio propague malware, ataques de suplantación de identidad (phishing) y cualquier otro tipo de ataque dirigido a que los usuarios confíen en que el sitio sea legítimo.

Obviamente, hay más formas de atacar el sistema con este tipo de vulnerabilidad. Gran parte de la siguiente fase del ataque dependerá de los resultados de la recopilación de información que realice en este momento.

Aunque no siempre es cierto, generalmente es seguro decir que si un script puede ser cargado por un tercero que no es de confianza ... el sistema está comprometido. Lo que haces en este punto es solo una cuestión de intención.

    
respondido por el David Houde 28.12.2013 - 04:37
fuente

Lea otras preguntas en las etiquetas