security - ejemplos - chmod recursive

¿Cómo se volverá vulnerable un servidor con chmod 777? (5)

A menudo leo artículos que dicen algo como "¡chmod 777 es malo!"

Me preguntaba:

¿Cómo me vuelvo vulnerable cuando ejecuto ''chmod 777'' en un archivo?

¿Qué es un ejemplo de esto que puedo reproducir en el mundo real?

Cada dígito en el comando chmod representa un número octal (3 bits). Con tres dígitos, eso es 9 bits en total. Cada bit representa un permiso; 1 == tiene permiso, 0 == no tiene permiso.

Los tres bits en cada dígito representan lectura (binario 100 == decimal 4), escritura (binario 010 == decimal 2) y ejecución (binario 001 == decimal 1). El decimal 7 es permiso de lectura + escritura + ejecución.

El primer dígito de un comando chmod representa los permisos del propietario de un archivo o directorio. El segundo es para el grupo. El tercero es para el "universo", es decir, todos los demás.

Entonces, chmod 777 representa permisos de lectura, escritura y ejecución para usted, el grupo y todos. Esto suele ser un acceso mucho mayor que el requerido.

Para su ejemplo del mundo real, imagine que un archivo llamado my_bank_account_credentials fue alterado con chmod 777 . ¡No muy seguro! Un usuario malintencionado podría cambiar lo que hay allí o simplemente leerlo y tomar su dinero felizmente.

Para los servidores, el peligro principal es que un error explotado en el código del servidor podría permitir que un atacante acceda a cualquier cosa sobre la cual el proceso del servidor tenga derechos, lo que incluiría cualquier cosa que tenga el conjunto de permisos 777 .

Si el atacante solo tiene acceso a la interfaz web (no a los archivos, por ejemplo, a través de otra cuenta en el mismo alojamiento compartido), el modo 777 no abre directamente ninguna vulnerabilidad. Lo que hace es hacer que sea más fácil para el atacante cambiar las cosas en el sitio una vez que llegan de alguna otra manera.

Por ejemplo, suponga que tiene un sitio de WordPress y hay un error en algún lugar que le permite al atacante ejecutar código PHP arbitrario bajo las credenciales del daemon del servidor (esto ha sucedido muchas veces en el pasado y sin duda volverá a ocurrir en el futuro). El código para WordPress se almacena en archivos .php que el daemon del servidor puede leer. Si esos archivos están en modo 777, el atacante puede escribirles, lo que significa que pueden modificar el código, cambiando lo que hace su sitio. Tal vez instalen un kit "drive by exploit" y ahora todos los que visitan su sitio obtienen un hackeo en su navegador. Tal vez instalen un kit de spam SEO y ahora Google cree que estás vendiendo Viagra (pero si visitas el sitio directamente es invisible, sí, esto realmente sucede).

Si los archivos .php son en modo 755 y son propiedad de un usuario que no es el demonio del servidor, el atacante no puede cambiar permanentemente lo que hace el sitio.

Tenga en cuenta que esto significa que la función de auto-actualización desde el panel de administración de WordPress es arriesgada, ya que solo funciona si WordPress puede modificarse a sí mismo. No puede tener eso y el adversario no puede modificar los archivos una vez que pueden ejecutarse. PHP arbitrario.

Tenga en cuenta también que solo está 100% seguro en este sentido si no hay archivos ni directorios que el daemon del servidor pueda modificar. Incluso solo permitir la carga de archivos a un solo directorio puede ser un problema, incluso si lo único que permite que alguien ingrese allí es archivos de imagen. (Si eso parece imposible, eche un vistazo a http://lcamtuf.coredump.cx/squirrel/ .)

Si una entrada maliciosa llega a su aplicación, sitio web, etc. No importa lo que haga con el código. El punto crítico está en la base de datos y no existe una posible protección contra la "escritura" en ella. Así que los permisos de chmod 777 no son nada peligrosos en absoluto.

chmod es el comando CHange MODe. El 777 indica los permisos. hay tres grupos de personas que pueden tener permisos (cada uno obtiene su propio dígito), en orden: Propietario (del archivo o directorio, los primeros 7), grupo (todos los que pertenecen al mismo grupo que el propietario, segundo 7 ), y mundo (tercero 7).

Propietario es el usuario del archivo, ese serías tú. En el mundo * nix, los usuarios pertenecen a grupos. Así que podrías ser el usuario / propietario Bob en el grupo de Marketing. Este modelo le permite hacer cosas como decir que Bob puede leer / escribir el archivo, el resto de marketing solo puede leer el archivo y otros usuarios pueden leer el archivo.

Cada dígito en el 777 es una representación binaria de: rwx (lectura / escritura / ejecución). Por lo tanto, un chmod de 755 significa: 111 (7): el propietario puede leer y ejecutar ejecutar 101 (5), otros en el grupo pueden ejecutar o leer, no escribir 101 (5), el resto del mundo puede leer y ejecutar, no escribir.

Esa configuración significa que puede leer / escribir y ejecutar sus archivos, pero las personas que visitan su sitio solo pueden leer o ejecutar el archivo. Por lo tanto, debe configurar los programas en su cgi-bin a 755, para que las personas puedan ejecutar el archivo como un programa.

Si configura los permisos en ''chmod 644'', obtendrá un archivo que usted puede escribir, pero que solo el resto del mundo puede leer. Esto es bueno para los archivos HTML rectos, de modo que no se apaga ningún pañuelo. Pero intente ejecutar un archivo con permisos de 644 y obtendrá un error.

CHMOD 777 permitirá que todos realicen cambios en los archivos de su servidor, les dará la condición de ESCRIBIR y todos saben que es malo.

Cualquier persona puede ver y / o modificar el contenido del sistema de archivos : asumiendo que el atacante ya tiene acceso general al sistema, lo cual es muy común en las plataformas de alojamiento compartido ... algunos están más "endurecidos" que otros desde el principio. Aquí hay una pequeña lista incompleta de posibles vectores de ataque:

"su código de seguridad" podría sobrescribirse con "su código malicioso" que se ejecuta en el mismo contexto del servidor web ... podría robar contraseñas / troyanos, exponer bases de datos, eliminar contenido, etc. Es decir, el código de otra persona puede ejecutarse bajo su seguridad contexto
El contenido (por ejemplo, "fuente de script") se puede ver fuera del contexto del servidor web (o propietario). ¿Tiene una contraseña "segura" para conectarse a la base de datos? Bueno ya no mas
Si el contenido estaba protegido por permisos (por ejemplo, el servidor web no pudo acceder antes), el servidor web podría tener acceso / mostrar información confidencial ... no es bueno si no quería compartirla. Las diferentes configuraciones de servidores web también tratarán los "listados" de manera diferente, lo que también puede exponer más de lo que se desea.

En lo anterior, también asumo "grupo" para incluir el principal del servidor web y que hay un servidor web (y / o alojamiento compartido) involucrado que se puede usar como un vector de ataque primario y / o una vulnerabilidad de seguridad. Sin embargo, y subrayo esto otra vez: la lista anterior no está completa .

Si bien no es una "seguridad garantizada", el uso de los permisos más específicos puede mitigar algunas vulnerabilidades / exposición.