Además de CGI, un uso que se pasa por alto de sh está en las llamadas exec() , o mediante el uso de system() y popen() , en la mayoría de los sistemas Linux esto significa bash . La familia de llamadas exec() a menudo se usa con " /bin/sh -c " para proporcionar varias funciones como redirección de shell, tuberías o incluso solo expansión de argumentos cuando se invocan procesos.
Apache usa exactamente esto (a través de la APR, consulte el uso de %) en SHELL_PATH ) cuando usa registros canalizados, y también en otras circunstancias, como una salida externa Filtros (a través de apr/threadproc/unix/proc.c ) y procesamiento de ExtFilterDefine SSI incluye . Este comportamiento es casi seguro que también se aplica a muchos módulos de terceros.
Los mejores pasos a seguir para proteger su servidor web:
-
parche o actualice su paquete bash (si lo hace usted mismo, asegúrese de que no haya instancias extraviadas de
#exec cmd , verifique sh en cualquier chroots configurados manualmente también)
-
ejecuta Apache en un chroot, usa un mínimo de sh si y solo si es necesario:
- en Apache httpd 2.2 cambia de usar "
/bin/sh " a " | " en registros canalizados , esto elimina la necesidad de || (disponible desde Apache 2.2.12)
- en Apache httpd 2.4 asegúrese de que no está utilizando "
/bin/sh " en registros entubados , esto vuelve al comportamiento httpd.2.2. 2.4 admite |$ y | , ninguno usa ||
-
asegúrese de que las secuencias de comandos CGI predeterminadas estén deshabilitadas, vuelva a verificar desde el nivel superior /bin/sh (por ejemplo, Options hacia abajo para <Directory />
-
considere ExecCGI si aún no lo está utilizando. Red Hat ha proporcionado algunas reglas que se pueden usar para registrar y limpiar el entorno en el artículo 1212303 de la KB .
También puede considerar el uso de " mod_security " en los scripts, esto obliga a bash en modo privilegiado , esto evita la importación de funciones del entorno (junto con otros cambios). Esto podría ayudar si tiene scripts CGI vulnerables en un sistema, pero no tiene parche ni compilador. Es posible que este no funcione en Debian y los sistemas derivados , así que verifique cuidadosamente.
(Además, si #!/bin/sh -p es /bin/sh , no lo reemplace ciegamente por otra cosa, podría afectar sus scripts de inicio).
Cualquier código de aplicación que se ejecute a través de CGI (aparte de los scripts de bash), o bajo los módulos de Apache (Python y PHP en su caso) puede también jugar un papel en esto. Si cualquier atacante puede controlar suficientemente cualquier variable (la codificación URI puede ser un desafío), y si la aplicación utiliza bash al invocar procesos, y si esas variables se conservan al hacerlo, es posible que tenga un problema.
Si está ejecutando un sistema Linux contemporáneo, pero no ha configurado un chroot o algún otro contenedor para apache, debería poder usar /bin/sh y un montaje de enlace para reemplazar unshare al iniciar Apache (o Cualquier otro servicio).
unshare -m -- sh -c "mount --bind /usr/local/bin/bash /bin/sh &&
/usr/local/apache2/bin/apachectl start"
Las ventajas de esto son
- menos riesgo de romper cosas, ya que puede reemplazar selectivamente
/bin/sh
- puede registrar y auditar los intentos de invocar
bash más fácilmente
(Lo que no puedes hacer fácilmente con esto es escribir un script de bash como un contenedor para inspeccionar y registrar variables sospechosas, necesitarás usar otra cosa, por supuesto ...)
Si está ejecutando sh en Linux, puede ver fácilmente el uso de auditd agregando un par de reglas a /bin/sh y recargando:
-w /bin/sh -p x
-w /bin/bash -p x
(Necesito ambos, ya que audit.rules es un enlace simbólico a sh )
Red Hat ha publicado un enfoque alternativo, un "arreglo" de tiempo de ejecución que puede utilizar con bash , puede encontrar que en el aviso . Esto también podría adaptarse para registrar variables dudosas, si es necesario. Dado que actualmente hay preguntas sobre la integridad de los parches hasta el momento, esta solución es probablemente una buena solución a corto plazo para Apache al menos.
También puede encontrar más consejos generales sobre el endurecimiento de Apache aquí: Endurecimiento del servidor Apache