Protección completa contra inyecciones de shell-script (como una “inyección Bash”): ¿es posible?

Navega tus respuestas
0

Supongamos que hay un sitio web creado con algunos FOSS CMS (como Drupal) y el directorio de los sitios web es propiedad y está agrupado por root (en lugar de www-data como es común en Apache en Nginx) y un amigo del propietario del sitio ve erróneamente Eso y le dice al dueño:

  

Tenga en cuenta que si un pirata informático encuentra una manera de inyectar código de shell   a través de inodes en ese directorio de sitios podría destruir su servidor y este código se ejecutará sin problemas porque los inodes son propiedad y están agrupados por root.

Me pregunto si tal ataque de "inyección de shell scripting" es posible.

Incluso supongamos que el propietario ahora crea un usuario habitual (por ejemplo, con el nombre de " Boobinio ") y ejecuta: 

chown boobinio /var/www/html/mysite -R && chgrp boobinio /var/www/html/mysite

Todavía no puedo ver cómo protege completamente al propietario porque si el pirata informático conoce a este usuario "boobinio" (y creo que hay varias formas de descubrirlo), podría intentar inyectar un código de shell cuando sea plausible que el el propietario está en sudo activo , y luego, ¿dónde está la diferencia total entre este caso, en un caso de inyección de shell cuando el propietario está en raíz activa ?

Mi pregunta:

Si soy exacto en lo que acabo de describir, ¿qué puede hacer alguien para asegurarse de no tener inyecciones de shell en el CMS cuando trabaja como sudo activo o raíz activa?

    
pregunta JohnDoea 03.01.2017 - 09:01
fuente

2 respuestas

3

AFAIK, no importa cuál sea el propietario del grupo de archivos (a menos que estén configurados). Lo que importa es que este es un indicio de que la aplicación podría ejecutarse como root, lo que es una amenaza para la seguridad.

Las reglas son:

  • la aplicación web debe ejecutarse como un usuario no privilegiado, en particular, ¡a ese usuario nunca se le debe permitir sudo!
  • solo debe tener acceso de escritura a los archivos, esto debe ser escrito o modificado por la aplicación
  • todos los demás archivos (estáticos) solo deben ser legibles y deben pertenecer a otro usuario (administrador)
respondido por el Serge Ballesta 03.01.2017 - 10:08
fuente
1

  1. El hecho de que un directorio o un archivo sea propiedad de root no otorga privilegios de root a las personas que acceden a ellos. (A menos que se establezca el bit suid ). Tener archivos y directorios propiedad de root garantiza que ningún otro usuario escribirá nada, a menos que se cambie el permiso a 777 (permisos completos para todos).

  2. El usuario que sirve web (en su mayoría www-data a través de cualquier servidor web) no debe poder ejecutar sudo . Yo solo pude leer algunos directorios y archivos, esto debe ser suficiente.

  3. Como bash se conoce para una falla de seguridad regular, usted tengo que usar otra shell (como csh , dash o incluso ksh ) como shell predeterminado (enlace a /bin/sh ).

Algunas actualizaciones sobre los permisos de archivos y directorios: 

drwxrwxrwx

Hay un primer signo que podría ser - para un archivo, d para un directorio, l para un enlace simbólico, b para un dispositivo de bloque o c para un dispositivo de caracteres.

Luego 3 grupos de 3 signos 

Type User Group Other
   d  rwx   rwx   rwx

Para cada grupo:

  • r significa que el archivo o directorio es legible por [Usuario, Grupo, Cualquiera]
  • w significa que el archivo o directorio se puede escribir en [Usuario, Grupo, Cualquiera]
  • El archivo de medio x es ejecutable por ... o significa que el directorio es accesible por ...

Entonces, para muestra: 

drwxr-xr-x /var
drwxr-xr-x /var/www
drwx--x--x /var/www/mysite
-rw-r--r-- /var/www/mysite/myfile.txt

Cualquiera podría leer myfile.txt , pero no podrá

  • modificar este archivo
  • ejecuta este archivo (excepto para php en el servidor web)
  • eliminar este archivo
  • lee, modifica o elimina el directorio mysite . (por lo tanto, acceder a /var/www/mysite/myhidden-dc22e606-a281-410c-be4f-df6b2ea175d9.txt está reservado ... Asegúrese de usar solo https para este tipo de trucos.)

Tenga cuidado con setuid y setgid bits, eche un vistazo a Resumen de herramientas de línea de comandos de GNU / Linux / Permisos de archivo

    
respondido por el F. Hauri 03.01.2017 - 11:09
fuente

Lea otras preguntas en las etiquetas

¿Es posible descifrar pero no cifrar usando la clave privada? ¿Cómo puede saber quién hackeó sus cuentas y envió mensajes sucios en su correo electrónico y chat instantáneo [cerrado]