- Como en la primera línea es visible, intentó usar el agujero de seguridad de shell bash.
Su idea fue probablemente la siguiente: Shellschock funciona con variables de entorno, es decir, en algunos casos, bash ejecutaría una variable de entorno como una función de shell. Y apache asigna los parámetros de las solicitudes http (cookies, cadenas de consulta, argumentos publicados, etc.) a las variables de entorno.
Si hubiera habido un script cgi en su servidor escrito en bash e interpretado por un shell bash no fijado, sus comandos podrían haberse ejecutado.
-
Más tarde trató de ejecutar diferentes comandos de shell. Estos comandos enviaron su salida en el protocolo tcp o udp a un servidor bajo su control. Esto se debe a que bash tiene un mecanismo de redireccionamiento interno para las secuencias de datos tcp y udp, es decir, los archivos que comienzan con / dev / tcp / ip / port se asignan a los sockets de la red. Es un mecanismo interno del shell bash.
-
Probablemente no fue un ataque directo, manual, sino un robot que rastrea a servidores vulnerables.
-
Las direcciones IP que usó probablemente no son su servidor (es) original (es), sino las que ya puede controlar de forma remota.