Esta solicitud intenta contactar con algo ubicado en la URL /shell y que toma como parámetro un conjunto de comandos de shell para ejecutar.
Mientras que los comandos de shell para ejecutar pueden parecer confusos al principio, lo más probable es que en realidad no lo estén. Los comandos de shell a menudo pueden contener caracteres que tienen un significado especial en las direcciones URL de HTTP, por lo que para evitar que los comandos sean corrompidos por el cliente o el servidor HTTP, la solución más sencilla es codificarlo por completo por HTTP (esto es menos una cuestión de confusión que la el hecho de que el atacante probablemente no se preocupe por la legibilidad de la URL).
Con respecto a esta URL /shell que (afortunadamente!) no se encontró en su servidor, existen dos posibilidades principales:
- Este puede ser el nombre de un recurso específico del servicio atacado por el atacante. El nombre del archivo que este comando intenta descargar parece indicar que está esperando un dispositivo ARM, por lo que el atacante puede ser un robot que busca en Internet un dispositivo incrustado vulnerable específico donde este URL
/shell está presente y habilitado de forma predeterminada ( por ejemplo, una función de depuración dejada habilitada por un fabricante. Suceden cosas malas ...).
- Otra posibilidad es que esta solicitud no sea el primer paso del ataque. Es posible que el atacante ya haya dado uno o varios pasos antes de este, lo cual, cuando se enfrenta a un servidor vulnerable, habría llevado a la creación de este lado del servidor de script
/shell . Estos pasos anteriores podrían haber sido realmente cualquier cosa que hubiera obligado al servidor o al servicio que ejecuta para generar este archivo /shell o aceptar subirlo.
En tus comentarios, con respecto a la segunda opción, parece que te preguntas por qué actuar en dos (o más) pasos. Cuando un atacante obtiene su primer pie en un objetivo, la mayoría de las veces tiene que enfrentar varias limitaciones en términos de tamaño y contenido de la carga útil que puede ejecutar (por ejemplo, puede cargar / crear solo archivos ASCII, o el contenido debe tener menos de 100 caracteres, etc.).
Por lo tanto, para comprometer completamente una máquina, primero lanzará una carga útil de la primera etapa que será lo mínimo que le permitirá descargar una carga útil binaria completa como segundo paso. La forma clásica es crear un script del lado del servidor que ejecute cualquier comando de shell pasado como parámetro (una web clásica shell ). El acceso a dicho shell web produciría exactamente el mismo tipo de registro que el citado en su pregunta.
Y finalmente, en cuanto a por qué proceder con los siguientes pasos si aparentemente el anterior no funcionó, nuevamente dos posibilidades:
- Según los detalles de la vulnerabilidad, puede suceder que el atacante no tenga una respuesta definitiva durante los primeros pasos que le permitan definir claramente si el servidor es vulnerable o no. Él lo sabrá si el ataque tuvo éxito y si se pone en contacto con la URL '/ shell' no arroja un mensaje de error 404, sino que descargue y ejecute correctamente la carga útil de la segunda etapa.
- Algunos bots que escanean Internet se desarrollan de forma rápida y sucia y simplemente ejecutan a ciegas todos los pasos de un ataque dado en todos los servidores que se encuentran en un rango de IP, ignorando la respuesta del servidor. Las máquinas vulnerables, al ejecutar la carga útil de la segunda etapa, devolverán la llamada al atacante por sí mismas.