Comprender un intento de explotar un servidor web

  

¿Esto parece ser inútil ya que la salida se imprimirá en la salida estándar y no se devolverá como una respuesta del servidor?

Depende de la vulnerabilidad que se esté explotando. A veces, un atacante puede determinar si un sistema es vulnerable a un ataque basado en el código de estado HTTP o el tiempo que demora la respuesta. Si el atacante puede enviar un ataque y saber que el sistema es vulnerable, puede enviar ataques de seguimiento, pero si no funcionó, continúe con el intento de un exploit diferente.

No hay ninguna razón técnica por la que un servidor no pueda procesar GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0 como ejecutando el archivo cmd.exe y pasando '/ c dir' como argumentos, capturando el resultado y enviándolo como una respuesta al usuario. Todo depende del diseño del servidor con el que se está interactuando. En retrospectiva, este diseño es tonto, ya que permite a los atacantes aprovechar un sistema, pero en los primeros años de la web, permitir este tipo de acceso podría haber sido deseable.

  

Además, ¿por qué es posible solicitar archivos fuera del directorio www? ¿No debería estar prohibido por defecto?

Los servidores web son complicados y los ingenieros cometen errores. Tenga en cuenta que este tipo de ataque es característico de la web en su infancia.

  

¿Cuáles son los privilegios de usuario que tiene un atacante de este tipo cuando emite esos comandos en una shell creada por el usuario? Supongo que los privilegios del servidor en ejecución.

Si un atacante podría aprovechar tal vulnerabilidad, es probable que obtenga el privilegio del servidor en ejecución. Pero, la ejecución va a ocurrir de acuerdo a como se haya escrito el programa. También es posible que el servidor pueda reducir los privilegios antes de pasar de la ejecución. No es probable, pero el punto es que siempre depende del contexto del sistema que se explota.

  

¿Podría un firewall evitar este ataque y, de no ser así, hay otras medidas que podrían haberlo evitado?

Sí y no. El firewall es un término un poco sobre suscrito, por lo que algunos firewalls tendrán esta capacidad y otros no. Algunos firewalls solo se enfocan en el tráfico de red en el sentido de IP de origen: puerto, ip de destino, y no miran el mensaje real que se está enviando. Otros firewalls incluyen un Intrusion Prevention System o IPS. Esta es una aplicación que compara el tráfico con las firmas de tráfico mal conocido. Entonces, si el firewall tiene un IPS, y hay una regla para este tráfico, se bloquearía.

¡Tienes muchas preguntas aquí!

Es probable que el servidor responda con un código de estado diferente dependiendo de si el comando se ejecuta o no. Con toda probabilidad, un sistema bien configurado devolvería un error interno de 500 servidores, mientras que un sistema mal configurado devolvería 200, confirmando que se ejecutó el comando. Esto le daría a un adversario información para proceder con un ataque.

Un sistema configurado correctamente limitaría el acceso al directorio www u otras ubicaciones válidas autorizadas explícitamente. Sin embargo, existe una clase completa de vulnerabilidad conocida como cruce de directorios, que es donde puede escapar de las regiones autorizadas del sistema de archivos, a menudo por algo tan simple como usar "../ .." en la URL. Por ejemplo, aquí hay uno de 2014: enlace Los errores existen en todo el software, y las cosas que tienen perfecto sentido no siempre suceden como deberían.

Correcto, la ejecución del shell estaría en el contexto del usuario que ejecuta el servicio web. Esta es la razón por la que nunca debe ejecutar un servidor web como root, para evitar que un exploit en su servicio web sea un exploit para su caja completa.

Finalmente, un WAF bien configurado podría prevenir este ataque. Lo que normalmente define un WAF es que es consciente del contenido con respecto a las aplicaciones web, por lo que puede inspeccionar y descartar las solicitudes que se ven mal. Sin embargo, el diablo está en los detalles, por lo que no basta con tener un WAF.