Curl | bash, Como detectar el uso en el servidor

Curl | Bash



La instalación del software mediante la canalización de curl y bash es obviamente una mala idea y un usuario bien informado lo más probable que haría es comprobar el contenido en primer lugar. Por lo tanto, ¿no sería genial si una carga maliciosa sólo se haría cuando uses curl |bash? Algunas personas han intentado esto antes mediante la comprobación de la aplicación del usuario, curl es de ningún modo a prueba de fallos – el usuario puede simplemente hacer curl al URL y en la línea de comandos revelar su código malicioso. Por suerte el comportamiento de curl (y wget) cambia cuando usas pipe (|) en bash. Esto permite que un atacante pueda presentar dos versiones diferentes de su script en función del contexto 🙂

No es que las solicitudes HTTP desde curl cuando son entubadas (piped) en bash sean diferentes hacia el stdout, de hecho para todos los efectos y propósitos son idénticos.

# curl -vv http://pluver.xqi.cc/setup.bash
* Hostname was NOT found in DNS cache
*   Trying 69.28.82.189...
* Connected to xqi.cc (69.28.82.189) port 80 (#0)
> GET /setup.sh HTTP/1.1
> User-Agent: curl/7.35.0
> Host: xqi.cc
> Accept: */*
>

La diferencia clave está en el tiempo que toma para que el contenido de las respuestas HTTP grandes para ser ingeridas por bash.

Ocultación de datos desde el terminal

El único caracter que realmente se puede utilizar para llenar el búfer es un byte nulo, ya que no se desplegará en la mayoría de las consolas. Incluso también no se desplegara en Google Chrome cuando se especifica el conjunto de caracteres text/html. Como no sabemos la longitud del contenido, se transfieren con la codificación fragmentada con cada trozo siendo una cadena de bytes nulos del mismo tamaño que el buffer de envío TCP.

Al final tenemos un servidor HTTP que genera respuestas de la siguiente manera:

HTTP/1.1 200 OK
Host: xqi.cc
Transfer-type: chunked
Content-type: text/html; charset=us-ascii

sleep 10                                <-- chunk #1
0x0000000000000000000000000000000000... <-- chunk #2
0x0000000000000000000000000000000000... <-- chunk #3
0x0000000000000000000000000000000000... <-- chunk #4
...

Demo de curl | bash

Poniendo todo junto terminas con un servidor basado en Python que puede ofrecer diferentes cargas útiles en base a lo que el contenido es canalizado a (esto también funciona con “wget -O / dev / null -O -“). Si por alguna razón la conexión no es fiable (la varianza es alta) o solicitar el archivo a través de un navegador mostrará la carga útil no maliciosa:

Curl demo
Curl demo

Código Fuente: Descargar

¿Cómo detectarlo?

Entonces, ¿cómo detectar si un servidor está haciendo esto? La detección se realiza a través de un simple retraso, ya sea en busca de grandes secuencias de comandos que contienen una gran cantidad de código:

curl https://example.com/setup.bash | (sleep 3; cat)

Sin embargo, esto no es en modo a prueba de tontos, ya que un atacante puede utilizar otros métodos (por ejemplo, las devoluciones de llamada http / DNS) o retrasos múltiples pasivos. La mejor solución es nunca usar pipes en flujos de datos no confiables en bash. Si aún deseas ejecutar scripts en bash, en el cual no se confía, es mejor un enfoque consiente y esto es entubar los contenidos del URL en un archivo, y revisar los contenidos en el disco y sólo entonces ejecutarlo.

Fuente: idontplaydarts.com